[jira] [Updated] (COLLECTIONS-854) Changes suggested to M1 release
[ https://issues.apache.org/jira/browse/COLLECTIONS-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated COLLECTIONS-854: -- Assignee: Claude Warren > Changes suggested to M1 release > --- > > Key: COLLECTIONS-854 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-854 > Project: Commons Collections > Issue Type: Improvement > Components: Bloomfilter >Affects Versions: 4.5.0-M1 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > > This is a list of items that we have agreed need to be changed for clarity of > API. > see https://lists.apache.org/thread/4fds9094c06o4gp1r8pf0xx4l0jthhds > > * Be clear that producers are like interruptible iterators with predicate > tests acting as a switch to short-circuit the iteration. > * Rename classes: > * CellConsumer to CellPredicate (?) > * Rename BitMap to BitMaps. > * Rename methods: > * Producer forEachX() to forEachUntil() > * The semantic nomenclature: > * Bitmaps are arrays of bits not a BitMaps object. > * Indexes are ints and not an instance of a Collection object. > * Cells are pairs of ints representing an index and a value. They are not > Pair<> objects. > * Producers iterate over collections of the object (Bitmap, Index, Cell) > applying a predicate to do work and stop the iteration early if necessary. > They are carriers/transporters of Bloom filter enabled bits. They allow us > to query the contents of the Bloom filter in an implementation agnostic way. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (COLLECTIONS-854) Changes suggested to M1 release
Claude Warren created COLLECTIONS-854: - Summary: Changes suggested to M1 release Key: COLLECTIONS-854 URL: https://issues.apache.org/jira/browse/COLLECTIONS-854 Project: Commons Collections Issue Type: Improvement Components: Bloomfilter Affects Versions: 4.5.0-M1 Reporter: Claude Warren This is a list of items that we have agreed need to be changed for clarity of API. see https://lists.apache.org/thread/4fds9094c06o4gp1r8pf0xx4l0jthhds * Be clear that producers are like interruptible iterators with predicate tests acting as a switch to short-circuit the iteration. * Rename classes: * CellConsumer to CellPredicate (?) * Rename BitMap to BitMaps. * Rename methods: * Producer forEachX() to forEachUntil() * The semantic nomenclature: * Bitmaps are arrays of bits not a BitMaps object. * Indexes are ints and not an instance of a Collection object. * Cells are pairs of ints representing an index and a value. They are not Pair<> objects. * Producers iterate over collections of the object (Bitmap, Index, Cell) applying a predicate to do work and stop the iteration early if necessary. They are carriers/transporters of Bloom filter enabled bits. They allow us to query the contents of the Bloom filter in an implementation agnostic way. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (VALIDATOR-487) EmailValidator considers non-ASCII characters valid, assuming RFC 6530 (Internationalized Email)
[
https://issues.apache.org/jira/browse/VALIDATOR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VALIDATOR-487:
-
Summary: EmailValidator considers non-ASCII characters valid, assuming RFC
6530 (Internationalized Email) (was: EmailValidator validates too much)
> EmailValidator considers non-ASCII characters valid, assuming RFC 6530
> (Internationalized Email)
>
>
> Key: VALIDATOR-487
> URL: https://issues.apache.org/jira/browse/VALIDATOR-487
> Project: Commons Validator
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Michael Osipov
>Priority: Major
>
> Coming from https://github.com/everit-org/json-schema which uses
> {{EMailValidator}} to validate JSON schema type:
> {noformat}
> {
> "type": "string",
> "format": "email"
> }
> {noformat}
> The problem is that the following email is returned as valid although
> according to rfc5321#section-4.1.2 local-part/dot-string/atom/atext
> (https://mailarchive.ietf.org/arch/msg/ietf-smtp/QlSTxHlY6cP6_Xwl6CpDvL5PQLo/)
> it must only contain ASCII printable chars:
> {{др.живаго@example.com}}.
> I'd expect that one could validate standard addresses and IDN ones.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (VALIDATOR-487) EmailValidator validates too much
[
https://issues.apache.org/jira/browse/VALIDATOR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842414#comment-17842414
]
Philippe Cloutier commented on VALIDATOR-487:
-
[~michael-o] would you mind retitling this to something like:
??EmailValidator considers non-ASCII characters valid, assuming RFC 6530
(Internationalized Email)??
> EmailValidator validates too much
> -
>
> Key: VALIDATOR-487
> URL: https://issues.apache.org/jira/browse/VALIDATOR-487
> Project: Commons Validator
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Michael Osipov
>Priority: Major
>
> Coming from https://github.com/everit-org/json-schema which uses
> {{EMailValidator}} to validate JSON schema type:
> {noformat}
> {
> "type": "string",
> "format": "email"
> }
> {noformat}
> The problem is that the following email is returned as valid although
> according to rfc5321#section-4.1.2 local-part/dot-string/atom/atext
> (https://mailarchive.ietf.org/arch/msg/ietf-smtp/QlSTxHlY6cP6_Xwl6CpDvL5PQLo/)
> it must only contain ASCII printable chars:
> {{др.живаго@example.com}}.
> I'd expect that one could validate standard addresses and IDN ones.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
