mappings-01

[Patrik Fältström]

Agree.

(Maybe my previous note could be read as if I did not agree, I just  
wanted to explain why I think Mapping is something that users must be  
aware of is happening -- also when just looking at the unicode version  
of an IDN.)

    paf

On 4 jul 2009, at 17.13, John C Klensin wrote:

> FWIW, I think this decision is exactly right.
>
>    john
>
>
> --On Saturday, July 04, 2009 08:10 -0700 Paul Hoffman
> <phoffman at imc.org> wrote:
>
>> At 8:40 AM -0400 7/4/09, Vint Cerf wrote:
>>> second, do the two of you have a preference for how this
>>> mapping  should be referenced?
>>
>> Yes: if it referenced with RFC 2119 language, that language
>> should actually match the definitions in RFC 2119.
>>
>>> Many participants have suggested that the mapping SHOULD be
>>> applied so  as to convey
>>> the importance of the regularity the document produces but
>>> allowing  for circumstances that
>>> might justify not mapping. I would underscore the weight
>>> given in IETF  terms to "SHOULD"
>>> as one is expected to adhere to the advice and only deviate
>>> for very  good reasons.
>>
>> As Pete said, we *took out* the RFC 2119 language from this
>> draft. When a document says "you SHOULD do xyz", it ought to
>> say when the SHOULD needs not be done. Another way of saying
>> this is, for every SHOULD, the document ought to say why it
>> was not a MUST.
>>
>> Everyone unclear on this should go back and read RFC 2119. It
>> is quite short, and quite definitive.
>>
>> In the case of mapping user input, we could not give a good
>> reason why this is needs to be required. It is clearly a good
>> idea because it will prevent user surprise, and we say  so.
>> However, mapping does not promote interoperability between DNS
>> clients and servers, nor between applications. Things that are
>> just good ideas where the exceptions cannot be well defined
>> are not, in my opinion, applicable targets of RFC 2119
>> "SHOULD".
>>
>> If the WG has consensus a proposal for the exact wording they
>> want that uses RFC 2119 language that actually meets the
>> requirements of RFC 2119, Pete and I would be happy to
>> incorporate it. We suspect that it won't happen, and that
>> we'll waste a long time arguing about it, which is why we
>> ripped out the RFC 2119 language in this round.
>> _______________________________________________
>> Idna-update mailing list
>> Idna-update at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/idna-update
>
>
>
>
> _______________________________________________
> 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/20090705/b2eee6dc/attachment-0001.pgp