Subject: RE: [AAA-WG]: charset issue with draft-ietf-aaa-diameter-15.txt

From: <[email-masked]>
Date: Wed, 11 Dec 2002 06:57:24 +0200

Hi all,

Trying to close off all IESG comments, and am trying to address
the charset issue.  Below is a mail from Patrik.  I propose
to create a seperate draft for a Diameter stringprep.

Does anyone have any problems with this approach or have an
alternative solution?

Thanks,
John

> -----Original Message-----
> From: ext Patrik Fältström [mailto:[email-masked]]
> Sent: 10 December, 2002 22:30
> To: Loughney John (NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: [AAA-WG]: charset issue with 
> draft-ietf-aaa-diameter-15.txt
> 
> 
> On tisdag, dec 10, 2002, at 20:57 Europe/Stockholm, 
> <[email-masked]> wrote:
> 
> > Do you have any existing references that I could base doing 
> this work?
> 
> Absolutely, for example the iSCSI specification 
> (draft-ietf-ips-iscsi-string-prep-03.txt) for comparison of 
> iSCSI unit 
> names (I think), and kerberos (draft-ietf-krb-wg-utf8-profile-00.txt, 
> which unfortunately has expired) for comparison of kerberos Realms.
> 
> > At IETF 55, the WG pushed back on this solution (it was 
> presented to 
> > them).
> > We are in a bit of a bind, as this is extremely late, about 
> 1 and half
> > years, and the WG is fearful of further delays, without supporting
> > reasons (i.e. - the wg doesn't see why this is needed).
> 
> I understand this.
> 
> The problem with _not_ doing a stringprep profile (a very 
> simple thing) 
> is that many characters is allowed to be represented in more than one 
> way. Especially if you have a character with more than one diacritic. 
> The stringprep profile ensure that the diacritics are sorted 
> in one and 
> only one way, so two implementations of Unicode/UTF-8 which might use 
> different internal representation will store "equal" strings in your 
> protocol.
> 
> Another example which might make sense, are the two following strings 
> equal or not:
> 
>    fooXbar
> 
> where X is either of the following:
> 
>   + U+0020 SPACE
>   + U+00A0 NO-BREAK SPACE
>   - U+1361 ETHIOPIC WORDSPACE
>   - U+1680 OGHAM SPACE MARK
>   + U+2002 EN SPACE
>   + U+2003 EM SPACE
>   + U+2004 THREE-PER-EM SPACE
>   + U+2005 FOUR-PER-EM SPACE
>   + U+2006 SIX-PER-EM SPACE
>   + U+2007 FIGURE SPACE
>   + U+2008 PUNCTUATION SPACE
>   + U+2009 THIN SPACE
>   + U+200A HAIR SPACE
>   - U+200B ZERO WIDTH SPACE
>   - U+200C ZERO WIDTH NON-JOINER
>   - U+200D ZERO WIDTH JOINER
>   + U+202F NARROW NO-BREAK SPACE
>   - U+2420 SYMBOL FOR SPACE
>   + U+3000 IDEOGRAPHIC SPACE
>   - U+303F IDEOGRAPHIC HALF FILL SPACE
>   - U+FEFF ZERO WIDTH NO-BREAK SPACE
>   - U+E0020 TAG SPACE
> 
> Answer: With a stringprep profile, it is defined that the 
> ones with '+' 
> before them are "equal". Not the ones with '-'. You do today 
> say all of 
> these characters are different, which is fine too, but you have to be 
> explicit about it -- and that is what stringprep give you an 
> ability to 
> be. I would not recommend it though.
> 
> Similar examples can be found with ordinary characters and not space.
> 
> One example are the following two sequences:
> 
> U+00A8 (DIAERESIS)
> 
> U+0020 (SPACE) + U+0308 (COMBINING DIAERESIS)
> 
> Both are technically correct according to the Unicode 
> specification and 
> they produce _exactly_ the same result when used in any 
> Unicode engine.
> 
>     paf
> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Dec 2002 20:27:43 -0800 (PST)

> Does anyone have any problems with this approach or have an

I'm just curious as to what we are trying to compare, and why this needs a
unique draft. As I understand it, we are talking primarily about FQDNs,
no? If so, this should be a generic draft, not something unique to AAA. Or
are there other things? We've already discussed why things like
filter lists or routes should be in pure ASCII, and so don't need
stringprep.