RE: Stringprep (was RE: New draft-yergeau-rfc2279bis-05.txt)

Please note that IDNA effectively can use new characters,
because stringprep/nameprep on the client side does not
apply to unassigned characters. The need for an update
is only on the registration side.

I think I would advocate that we update stringprep/nameprep/idna
immediately to Unicode 4.0 if it were not for the fact that
this technology is just now being introduced. The success of
IDNA does not depend on the few additional characters in
Unicode 4.0. But it may be worth to wait with the update
until we get a bit more actual practical experience.

Regards,    Martin.


At 15:02 03/06/10 -0700, McDonald, Ira wrote:
>Hi Ned,
>
>I understand the need for a stable reference ("these base tables
>have rules that cover the repertoire of Unicode/3.2").
>
>But the proliferation of IETF application and infrastructure
>protocols (like 'iSCSI') using profiles of what I'll call
>Stringprep/3.2 (RFC 3454), means that when they exchange and
>compare URI, internationalized domain names, etc., they can
>only use the repertoire in Unicode/3.2.
>
>That seems self-defeating.  Protocols should be able to use
>any newly assigned Unicode/x.y characters without breaking
>in a Stringprep environment.
>
>My two cents,
>- Ira McDonald
>   High North Inc
>
>
>-----Original Message-----
>From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com]
>Sent: Tuesday, June 10, 2003 3:42 PM
>To: Francois Yergeau
>Cc: McDonald, Ira; 'Markus Scherer'; charsets
>Subject: Re: Stringprep (was RE: New draft-yergeau-rfc2279bis-05.txt)
>
>
> > [Changing the Subject: since this has nothing to do with the UTF-8 draft.]
>
> > McDonald, Ira wrote:
> > > Restricting IETF protocols to use of Unicode/3.2 is not a desirable
> > > outcome of the IETF's wide support for the Stringprep approach.
>
> > Agreed, RFC 3454 needs an update for Unicode 4.0.
>
>Perhaps an update is in order, but this does not change the fact that a
>stable
>reference to a specific version of Unicode that won't be changed or amended
>in
>any way is required by stringprep. Don't expect this requirement to change
>or
>go away.
>
>                                 Ned

Received on Tuesday, 10 June 2003 18:25:12 UTC