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.