Subject: Gen-ART review of draft-ietf-ldapbis-strprep-06

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 06 Jan 2006 11:46:50 +0100

For more details about what a Gen-ART review is, see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html

Document: draft-ietf-ldapbis-strprep-06.txt
Reviewer: Harald Alvestrand
Date: January 6, 2006
Summary: Almost ready, at least one nit needs fixing

This review was done during Last Call.

This document seems competently written and clear enough to permit 
implementation. Good work!

The behaviour of normalization for substring matching in 2.6.1 leaves me 
sad that the world is this baroque, but Appendix B gives a fairly good 
explanation.

There is one technical issue and one formal issue that need addressing; the 
rest of the comments here are nits.

Technical issue:

Section 2.1 "Transcode" says:

  TeletexString [X.680] values are transcoded to Unicode.  As there is
  no standard for mapping TelexString values to Unicode, the mapping is
  left a local matter.

This is confusing, since there is actually an X.409(1984) construct named 
"TelexString". None have been seen for many a year, and never (AFAIK) in 
conjunction with X.500, so it's likely that this is supposed to be 
"TeletexString". Still, the fact that it's a valid ASN.1 construct means 
that it's a technical issue, not just a spelling error....

Format/formal issues:
---------------------
The references section says:

6.1. Normative References

....
  [StringPrep]  Hoffman P. and M. Blanchet, "Preparation of
                Internationalized Strings ('stringprep')",
                draft-hoffman-rfc3454bis-xx.txt, a work in progress.

While there are other normative references to I-Ds, these are to -zeilenga- 
and -ldapbis- documents, which presumably the author has some control over.
This one seems to be a normative reference to an *expired* I-D, which is a 
Bad Thing. (-02 was published in April 2004, and has been expired for 1.5 
years). Please consider whether it's possible to refer to RFC 3454.

Of lesser importance:

[RFC1345] is listed under informative references, but is not referred to. 
Given my opinion on RFC 1345, that's a Good Thing. Please remove.

Appendix A claims to be "normative", but the reference to it in section 
"Conventions and Terms" says that it's derived from Unicode data. I think 
it would be better if Appendix A said "This data is derived from the 
Unicode 3.2 data files by listing all characters with the Mn, Mc or Me 
properties. It is reproduced here for convenience." In that case, it's 
clear what to do if there should ever be a conflict between the two - 
Unicode rules.

Nits/suggestions for clarification (should be ignored unless a revision 
needs to be done anyway):

Given the baroqueness of section 2.6.1, it may be wise to include the 
standard disclaimer somewhere in the document about implementation: "Note 
that this specification is used to describe the  outcome of the matching 
rule. It is not required that an implementation follow this exact sequence 
of steps, as long as the result is identical in all cases to the result of 
following these steps."

Appendix B took me a little while to read. It's been long enough since I 
last worked with the LDAP matching syntax that a sentence saying "In the 
following, the expression (CN=A*B*C) means that A has to match the 
beginning of the string, B has to match somewhere in the middle of the 
string, and C has to match the end of the string" would have helped me.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 10 Jan 2006 12:44:33 -0800

Harald,

Thanks for the review.  My comments below indicate how I
believe each issue raised should be addressed.

Kurt

> no standard for mapping TelexString values to Unicode, the mapping is

Yes, TelexString here should be TeletexString.

>Format/formal issues:

This reference should be revert to RFC 3454.  I have
reviewed the differences between the hoffman-rfc3454bis and
RFC3454, and all references to StringPrep in ldapbis-strprep to
ensure all is well.

>Of lesser importance:
>
>[RFC1345] is listed under informative references, but is not referred to. Given my opinion on RFC 1345, that's a Good Thing. Please remove.

okay.

>Appendix A claims to be "normative", but the reference to it in section "Conventions and Terms" says that it's derived from Unicode data. I think it would be better if Appendix A said "This data is derived from the Unicode 3.2 data files by listing all characters with the Mn, Mc or Me properties. It is reproduced here for convenience." In that case, it's clear what to do if there should ever be a conflict between the two - Unicode rules.

The WG discussed whether "Unicode rules" or "Appendix A rules"
and, on the advice of Paul Hoffman, the WG choose the later.
Basically, Stringprep is table driven.  The tables, including
not only this table but also all other referenced tables, are
to be considered definitive for the purpose of implementing this
algorithm.

I suggest adding the following to 1.3:
  It is noted that while various tables of Unicode characters included
  and/or referenced by this specification are derived from Unicode
  [UNICODE] data, these tables are to be considered definitive for
  the purpose of implementing this specification.

>Nits/suggestions for clarification (should be ignored unless a revision needs to be done anyway):
>
>Given the baroqueness of section 2.6.1, it may be wise to include the standard disclaimer somewhere in the document about implementation: "Note that this specification is used to describe the  outcome of the matching rule. It is not required that an implementation follow this exact sequence of steps, as long as the result is identical in all cases to the result of following these steps."

I suggest adding the following disclaimer to Section 2.
 Note that this six-step process specification is intended to          
 described expected matching behavior.   Implementations are free      
 use alternative processes so long as the matching rule evaluation  
 behavior provided is consistent with the behavior described by this
 specification.

>Appendix B took me a little while to read. It's been long enough since I last worked with the LDAP matching syntax that a sentence saying "In the following, the expression (CN=A*B*C) means that A has to match the beginning of the string, B has to match somewhere in the middle of the string, and C has to match the end of the string" would have helped me.

I suggest adding:
 Note to readers not familiar with LDAP substrings matching: the       
 LDAP filter [Filters] assertion (CN=A*B*C) says "match any value             
 (of the attribute CN) which begins with A, contains B after A, ends
 with C where C is also after B."

and [Filters] as an informative reference to the ldapbis-filter
I-D.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 10 Jan 2006 22:45:55 +0100

I've got no problem with these resolutions.

Thanks, and hope the improvement's worth it!

--On tirsdag, januar 10, 2006 12:44:33 -0800 "Kurt D. Zeilenga" 
<[email-masked]> wrote:

>> [RFC1345] is listed under informative references, but is not referred
>> to. Given my opinion on RFC 1345, that's a Good Thing. Please remove.
>
> okay.
>
>
>> "Conventions and Terms" says that it's derived from Unicode data. I
>> think it would be better if Appendix A said "This data is derived from
>> the Unicode 3.2 data files by listing all characters with the Mn, Mc or
>> Me properties. It is reproduced here for convenience." In that case,
>> it's clear what to do if there should ever be a conflict between the two
>> - Unicode rules.
>
>> standard disclaimer somewhere in the document about implementation:
>> "Note that this specification is used to describe the  outcome of the
>> matching rule. It is not required that an implementation follow this
>> exact sequence of steps, as long as the result is identical in all cases
>> to the result of following these steps."
>