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