Stop me if I've misunderstood...

[Shawn Steele]

>>  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.

(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)

> 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.  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.

>> 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.

>> 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.

- Shawn