Comments on the Stringprep aspects of draft-ietf-snmpconf-pm-13.t xt
"Wijnen, Bert (Bert)" <[email protected]> Tue, 27 May 2003 12:53:40 +0200
| Newsgroups | gmane.ietf.snmpconf |
|---|---|
| Message-ID | <7D5D48D2CAA3D84C813F5B154F43B15501A9FD99@nl0006exch001u.nl.lucent.com> |
Pls react to these comments from Patrik. Pls copy patrik explicitly on your responses, cause he is (probably) not subscribed to our WG list. Thanks, Bert=20 -----Original Message----- From: Patrik F=E4ltstr=F6m [mailto:[email protected]] Sent: dinsdag 27 mei 2003 5:46 To: Wijnen, Bert (Bert) Cc: Ted Hardie (E-mail); Ned Freed (E-mail) Subject: Re: help with Stringprep review On m=E5ndag, maj 26, 2003, at 23:36 Europe/Stockholm, Wijnen, Bert (Bert)= =20 wrote: > Patrik, I think you have been communicating with Steve > Waldbusser about the use of Stringprep in his document > draft-ietf-snmpconf-pm-13.txt (current version). > > Would you be so kind to check if what he has described and > documented is OK? The doc is missing an IANA Considerations > Section, and I have already told them that they must add > one to at least list what IANA needs to do for the Stringprep > profile registration. (1) This spec very explicitly states it uses UTF-8 encoding of Unicode=20 all over the place. Still, the basic functions doesn't take that into=20 account. Examples: The function Integer only look for the digits in the=20 Unicode Codeset which is in the "US-ASCII area". There are digits in=20 other locations as well. When searching for specific values, and doing=20 string comparisons, no stringprep is applied to the UTF-8 strings (the=20 values) before matching is happening. Etc etc. This is a pure US-ASCII=20 spec, even though it claims to use UTF-8. Not good. Either this should=20 be UTF-8/Unicode compliant, or it should be US-ASCII only. (2) The stringprep profile uses no normalization at all. Even though=20 the stringprep profile say that is correct, I would very strongly=20 discourage this for "human readable strings" which are to be compared. paf