MVALID (was Re: M-Label or MVALID, and dangers with mappings?)

Tue Apr 14 07:18:34 CEST 2009

On 14 apr 2009, at 04.03, Pete Resnick wrote:

> On 4/13/09 at 1:31 PM -0700, Paul Hoffman wrote:
>
>> Andrew and Pete: do you feel that it is OK for this WG to update a
>> protocol from one where a conformant application was required to
>> convert "EuroCafé.com" to a valid DNS request to one where a
>> conformant application can simply reject that input? Note that there
>> is no indication to the user which version of the protocol is being
>> used.
>
> Andrew can answer for himself, but as for me, let me answer this way:

FWIW, I am fully on the same side as Pete here, but let me add another  
example:

We already today have problems with people "entering" EuroCafé.com in  
various places and they are confused by the fact that that is not  
either stored in the DNS zone file (it is the xn-- version) or what is  
"coming back" when you convert the xn-- version back to Unicode.

We also have cases where unfortunately the EuroCafé.com has _not_ been  
mapped before passed around in protocols, stored in databases etc, and  
that will now create a huge problem. People did not think the mapping  
had to happen before DNS was to be used, when in reality we need to do  
the mapping whenever one want to do a comparison between domain names  
(LDAP do that comparison for example).

So absolutely, any sensible application will do the mapping on behalf  
of the user, but there are also application that definitely should not  
do it. The important thing is that (a) The user is not surprised, (b)  
The A-label and U-label is what is passed around and stored etc.

We must trust the application developers here, and more importantly,  
we must allow for innovation. I have no idea what user interfaces will  
be created in the future, but I already today have seen plugins to  
browsers that add spaces around the domain name before display of a  
URI. Are those spaces part of the domain name support, or uri support,  
inside or outside of the IDNA-suite-of-documents?

To be honest: I do not care. I think it is important the applications  
can elaborate on what the best mechanisms are, specifically as the  
application also know the LOCALE in which it works. The mappings will  
most certainly be different also between for example a Swedish and  
German context. Or between a Danish and Swedish context! I can for  
example envision an application "trying" with a double lookup to look  
up both "örestad" and "ørestad" although both ö and ø are PVALID. Is  
that wrong? Maybe the application have interest in doing so to  
minimize phishing risks in a Scandinavian Context.

So, I think when talking about mappings it is EXTREMELY dangerous to  
have any MUST, if not in the context of "MUST NOT surprise the user".

I therefore fully support your "simply reject the input". No, that is  
not how it should work. But be forced to always do the mapping?  
Absolutely not, as there are many situations where supporting the  
mapping will be "silently" doing something that will surprise the user.

    Patrik

> I think it would be terribly bad form for an implementation to simply
> reject "EuroCafé.com". I would expect any reasonable application to
> convert that to "eurocafé.com". That said, I can think of cases
> where, in particular contexts, things that are perfectly easily
> mapable might reasonably be rejected by an implementation, so I don't
> think mapping should be a *hard requirement* for conformance. Let me
> explain:
>
> I think of this like I think of email programs: If a user types into
> the To: line in an email user agent:
>
> Pété Résnick <presnick at qualcomm.com>
>
> and the email client rejects it instead of turning it into:
>
> =?iso-8859-1?Q?P=E9t=E9_R=E9snick?=  <presnick at qualcomm.com>
>
> I would be rightly annoyed. Similarly, if a user types:
>
> Peter W. Resnick <presnick at qualcomm.com>
>
> and the user agent didn't turn it into:
>
> "Peter W. Resnick" <presnick at qualcomm.com>
>
> I'd be equally annoyed. But I'd start to get a bit nervous if an
> email client took:
>
> Pete Resnick <Pete Resnick at qualcomm.com>
>
> and turned it into:
>
> Pete Resnick <"Pete Resnick"@qualcomm.com>
>
> That may be a perfectly reasonable interpretation of what was typed,
> but I'd be OK with the email client warning me, "Hey, that doesn't
> look like a kosher email address to me." I don't think it's a
> conformance issue to define how the user agent deals with user input.
> So, if the WG decides to go to the effort of defining a mapping,
> that's fine. I just think it's a mistake to require it as part of the
> lookup protocol.
>
>> I think it is not fine to make a mapping that is commonly done by
>> billions of people and silently remove it from the protocol.
>
> I'm not fine with the "silently" part either. But I'm OK with the
> protocol document simply saying, "Users expect, among other things,
> that DNS lookups to be case insensitive, so any application that is
> taking user input and passing it to IDNA had better at least
> lowercase user input before otherwise determining if it is a
> legitimate name. A full description of user input handling and
> mapping of characters that is reasonably backward compatible with
> IDNA 2003 can be found in [MAPPING]." What I think is not fine is for
> the protocol document to say, "You MUST map user input with
> [MAPPING]." That will codify a particular version of [MAPPING] that
> may not be suitable for some cases and makes one particular user
> input method a requirement for protocol conformance. That I don't
> like.
>
> pr
> -- 
> Pete Resnick <http://www.qualcomm.com/~presnick/>
> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax:  
> (858)651-1102
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.alvestrand.no/pipermail/idna-update/attachments/20090414/e99b7e1b/attachment.pgp 