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

Pete Resnick presnick at qualcomm.com
Tue Apr 14 04:03:48 CEST 2009


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:

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


More information about the Idna-update mailing list