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

From: Frank Ellermann <[email-masked]>
Date: Thu, 26 Jan 2006 18:31:04 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 26 Jan 2006 12:23:14 -0800

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

I will work with the RFC-Editor to address the editorial
issues during AUTH48.  As far as any non-Editorial issue,
I suggest you bring it up with the responsible AD as any
non-Editorial change at this stage would normally require
his approval to make.

Kurt

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 26 Jan 2006 22:35:10 +0100

Kurt D. Zeilenga wrote:

> As far as any non-Editorial issue, I suggest you bring it
> up with the responsible AD as any non-Editorial change at
> this stage would normally require his approval to make.

Actually I was scanning through several dozens of articles
and confused "protocol action" with a "last call", sorry.

Please ignore my security proposal, "3.2 is not 4 or 5" is
probably a well-known stringprep feature.
              
                      Bye, Frank