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

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 protected]> wrote:

> Harald,
>
> Thanks for the review.  My comments below indicate how I
> believe each issue raised should be addressed.
>
> Kurt
>
> At 02:46 AM 1/6/2006, Harald Tveit Alvestrand wrote:
>> 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.
>
> Yes, TelexString here should be TeletexString.
>
>> 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.
>
> 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.
>
>