Stop me if I've misunderstood...

Paul Hoffman phoffman at imc.org
Sat Jul 11 01:28:11 CEST 2009


At 10:38 PM +0000 7/10/09, Shawn Steele wrote:
> >>  I think saying that some applications SHOULD map is sufficient.
>
>> Stop right there. Read the definition of "SHOULD" in RFC 2119.
>
>3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>   may exist valid reasons in particular circumstances to ignore a
>   particular item, but the full implications must be understood and
>   carefully weighed before choosing a different course.
>
>Which is what I meant.  Mapping is RECOMMENDED.  Valid cases not to map may exist.

And they are....? You can't say to implementers "you must understand the full implications of not doing this" with giving them any clues. From our discussion so far, I'm pretty sure your list would be different than others, so leaving this as an exercise for the rest of the WG is not going to get us to finishing this work.

>(I also don't find the "go look it up" response very helpful, it is much more helpful to quote the relevant text and indicate where you see the problem instead of making all of us go look it up and guess where you see the problem)

Noted. But I also note that you stopped after the definition for SHOULD, and didn't quote from section 6 of the document, which is in many ways more appropriate for this discussion.

>
>> An address book does not map: the input mechanism to the address book
>> can map what the user typed to what is stored, and/or the display
>> mechanism of the address book might map from what is stored to what
>> is shown. Precision is important here.
>
>? The IME certainly isn't going to map. 

During the recent discussions, many people have said the opposite: mapping can happen between the user's brain and the beginning of the application receiving the information.

Also, I think many Asian user's would be surprised to hear that their IMEs don't map things like like half-width characters.

>The edit or rich edit control also isn't going to map.  So the address book is going to have to figure out what to do with the values provided by the input mechanism.  (It may be an "input" part of the address book)
>
>I believe that most address books will require the "what is shown" to be identical to the "what is input".  If the user inputs "Microsoft.Com", I believe that address books will want to show "Microsoft.Com".  This requires either a) the value is stored in the non-U-Label form, or b) that it is stored in both forms.  I expect most applications would only chose to store one form.
>
>Assuming that the application chooses to store the non-U-Label form, then mapping is required before (or at least when) that address is looked up in DNS, which might not even be the address book app doing the lookup.

So, are you saying that "address books SHOULD NOT map"? Or "address books MAY map"?

> >> I could enumerate when address books should and should not map,
>> but I really don't think we want to go there.
>
>> Then you cannot use "SHOULD" in the RFC 2119 context. So, some of
>> "we" very much want to go there, or not use RFC 2119 language.
>> MUST is easy, as is MAY.
>
>3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>   may exist valid reasons in particular circumstances to ignore a
>   particular item, but the full implications must be understood and
>   carefully weighed before choosing a different course.
>
>I'm don't see anything in RFC 2119 that requires the valid reasons to be listed in the RFC.  It merely states that valid reasons may exist to ignore a particular item and that a full understanding is required when a course is chosen (eg: by the dev, not by us).  I can see where it would be useful in an RFC to provide examples, however many RFCs don't list those.

Almost half of the developers who create software that uses IDNA2008 will have below-average understanding of what the full implications of skipping or changing the mapping is. By not listing what we consider to be those implications, we are making the "SHOULD" into a "MAY" for many of those folks (and probably for some of the above-average ones as well).

As for "everyone else does it", that's quite true. If you were involved in other long-term WGs, you would know that it almost always ends in acrimony and (ta da!) lack of interoperability where people expected it because "it says SHOULD right there and everyone knows what that means".

>
>>> I would much rather assume that address book developers will be able to figure out what's right.
>
>> So, how the heck does that relate to your desire for interoperability?
>
>We are trying (I think) to define how the Domain Name layer works for International labels.  There's no way we can enumerate all cases where domain names are used and say "MUST" or "MUST NOT" for each application, particularly when many applications don't exist yet and most of us don't even build all of the kinds that do exist.  I may think I know what's best for IE, and how other browsers may behave, but I'm not going to presume that I know better than Mozilla for some edge case.  I would say "browsers MUST map", however if Mozilla wants to have some feature where they know all the values are already U-Labels, they should be allowed to do that.

You have simply reinforced the need to answer the question. If you know the spec allows Vendor A and Vendor B to act differently in a way that prevents interoperability, why talk about it at all?


More information about the Idna-update mailing list