Re: Protocol Action: 'LDAP: Internationalized String Preparation' to Proposed Standard

The IESG wrote:

> <draft-ietf-ldapbis-strprep-07.txt> as a Proposed Standard

Mostly editorial nits:

| presented and stored values are first prepared for comparison
| and so that a character-by-character comparison yields the
| "correct" result.

s/and// (?)

| The following six-step process SHALL be applied to each
| presented and attribute value in preparation for character
| string matching rule evaluation.

s/and// (?)

| The input string is be normalized to Unicode Form KC
| (compatibility composed) as described in [UAX15].

s/is be/is/  Maybe s/KC/NFKC/ as used in 3454.
Or better s/Form KC/NFKC/g (more than one occurence).

| Characters which, per Section 5.8 of [Stringprep], change
| display properties or are deprecated are prohibited.

s/[Stringprep]/[RFC3454]/g

Something with the indentation in appendices A and B is odd.

| Otherwise, if the string being prepared is an initial, any,
| or final substring, then the output string is exactly one
| SPACE character, else the output string is exactly two
| SPACEs.

Apparently 'initial substring', 'any substring', and
'final substring' are terms here, and not simply the same as
any substring, also used later in appendix B:

| That is, if a prepared any substring matches a partition of
| the attribute value, then an assertion constructed by
| subdividing that substring into multiple substrings should
| also match.

How about quoting these terms:  '"initial", "any", or "final
substring"' in the first case, 'if a prepared "any substring"
matches' in the second case (?)  For an xml2rfc source that
could be done with <spanx style="verb">any substring</spanx>.

Actually only the unquoted "any" confused me, normally "any"
should include initial and final.

| All spaces are regarded as insignificant and are to be
| removed.

s/are to be// (?)  More than one occurence.

For the "Security Considerations" a note about mixing tables
for different Unicode versions might help:  RFC 3454 is 3.2,
using an Unicode 5 table to figure out say "unassigned" might
be a bad idea.

| However, only leading and trailing (as well as multiple
| consecutive spaces) of the string (as a whole) are
| insignificant.

s/consecutive spaces)/consecutive) spaces/

                      Bye, Frank

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf