Requirements document (Re: New version, draft-faltstrom-idnabis-tables-02.txt, available)

[Vint Cerf]

I would have thought that consideration of passwords is entirely irrelevant
to the consideration of characters to be used in domain names.

Vint
 


Vinton G Cerf
Chief Internet Evangelist
Google
Regus Suite 384
13800 Coppermine Road
Herndon, VA 20171
 
+1 703 234-1823
+1 703-234-5822 (f)
 
vint at google.com
www.google.com
 

-----Original Message-----
From: idna-update-bounces at alvestrand.no
[mailto:idna-update-bounces at alvestrand.no] On Behalf Of Martin Duerst
Sent: Monday, June 18, 2007 5:59 AM
To: Simon Josefsson
Cc: Harald Alvestrand; patrik at frobbit.se; idna-update at alvestrand.no; Kenneth
Whistler
Subject: Re: Requirements document (Re: New
version,draft-faltstrom-idnabis-tables-02.txt, available)

At 17:24 07/06/18, Simon Josefsson wrote:
>Martin Duerst <duerst at it.aoyama.ac.jp> writes:

>> The issues document should probably mention this, because it's an 
>> issue in the sense that it has to be duely considered and checked of, 
>> but for everybody who has looked even a bit into this issue will 
>> understand that it's a non-issue, in the sense that applications 
>> should just upgrade to the new, correct version of normalization 
>> without any problems.
>
>Well, upgrading would violate the current IDNA specification, and 
>libidn will maintain its implementation of the IDNA documents, see:
>
>http://josefsson.org/libidn/manual/html_node/PR29-discussion.html
>http://josefsson.org/libidn/manual/html_node/PR29-Functions.html#PR29-F
>unctions
>
>If the new IDNA specification changes anything wrt pr29, that will 
>break backwards compatibility for a set of strings, and I expect there 
>to be discussion about what the strategy to resolve this 
>incompatibility will be.
>
>The strings doesn't occur in natural language, but may occur in 
>non-natural strings such as passwords, and my suggestion has been that 
>all the problematic strings should be rejected.  It only affects a 
>small number of strings.

Your suggestion is one to consider. My personal opinion would be that
because for passwords, prohibition is as bad as a change (in normalization),
and a normalization change is easier to implement (change one character, in
the case of your source) than a special prohibition, so I'd favor just
changing things.

On top of that, I'd note that even most passwords have some connections with
natural language (at least by the fact that they are usually typed in on a
keyboard), so the chance that a password contains such a string is still
extremely, extremely low (essentially, we are still talking about an empty
set).

Regards,    Martin.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst at it.aoyama.ac.jp


_______________________________________________
Idna-update mailing list
Idna-update at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update