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

--===============1991298630==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="==========7DD16081B953D39D4103=========="

--==========7DD16081B953D39D4103==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=20
implementation. Good work!

The behaviour of normalization for substring matching in 2.6.1 leaves me=20
sad that the world is this baroque, but Appendix B gives a fairly good=20
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=20
"TelexString". None have been seen for many a year, and never (AFAIK) in=20
conjunction with X.500, so it's likely that this is supposed to be=20
"TeletexString". Still, the fact that it's a valid ASN.1 construct means=20
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=20
Bad Thing. (-02 was published in April 2004, and has been expired for 1.5=20
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.=20
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=20
"Conventions and Terms" says that it's derived from Unicode data. I think=20
it would be better if Appendix A said "This data is derived from the=20
Unicode 3.2 data files by listing all characters with the Mn, Mc or Me=20
properties. It is reproduced here for convenience." In that case, it's=20
clear what to do if there should ever be a conflict between the two -=20
Unicode rules.

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

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

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


--==========7DD16081B953D39D4103==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFDvkqgOMj+2+WY0F4RAliAAJ42Qr0x0UbKVtGjrdOD709MDcWf5gCg7WeW
iwBZ4dF9u8x0FJCBtZeAlak=
=9eUv
-----END PGP SIGNATURE-----

--==========7DD16081B953D39D4103==========--



--===============1991298630==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art

--===============1991298630==--