mappings-01

Mark Davis ⌛ mark at macchiato.com
Sun Jul 5 20:41:15 CEST 2009


What I'm saying is that *no* mapping is better than an optional mapping.
That is, there are three options people have mentioned:

A. mapping required by IDNA protocol
B. no mapping as part of IDNA docs
C. optional, UI-only mapping in IDNA docs

I think that C is far worse than B. So rather than going down the C route,
I'd rather go back to John's original formulation (B).

Both A and C are at least predictable. B is a muddle - it does not advance
interoperability; it simply makes it harder to predict what implementations
are going to do, since some will do it and some won't.

Mark


On Sun, Jul 5, 2009 at 08:20, Vint Cerf <vint at google.com> wrote:

> Mark,
> we will have to see where the consensus forms - at the moment, there seems
> to be motion towards a  more permissive formulation than requiring the
> mapping in protocol.
>
> vint
>
>
> On Jul 5, 2009, at 11:13 AM, Mark Davis ⌛ wrote:
>
> Although I've been arguing for a mapping phase, what I've been arguing for
> is one that is part of the lookup protocol, and so common across all
> implementations. An optional mapping -- one that is only a SHOULD -- and
> only for UI, is as far as I'm concerned, far worse than John's earlier
> version of protocol (
> http://tools.ietf.org/html/draft-ietf-idnabis-protocol-12).
>
> I suggest strongly we just drop the mapping document entirely, and just
> proceed with the previous basis:
> http://tools.ietf.org/html/draft-ietf-idnabis-protocol-12.
>
> Mark
>
>
> On Sat, Jul 4, 2009 at 08:27, Vint Cerf <vint at google.com> wrote:
>
>> Taking advantage of this exchange to underscore for the working group
>> what I consider to be a remarkably perceptive observation:
>>
>> quoting from the authors:
>>
>> >> 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".
>>
>> with the specificity of the new version of the mapping document
>> and the rationale above as to its application, I urge the WG
>> participants
>> to raise any additional substantive issues promptly.
>>
>> We need to reach closure on all documents at the end of the first
>> day of the meetings in Stockholm.
>>
>> I also suggest that the mappings document and the removal of
>> RFC 2119 language eliminates the need for the "mapping forms"
>> that Mark Davis suggested, since the mappings are suggested but
>> not required. The IDNABIS framework establishes clear rules for
>> defining what characters are allowed and what practices are
>> recommended for registration and look up.
>>
>> I hope and believe that we are very close to consensus on the
>> IDNABIS revisions.
>>
>> vint
>>
>> >
>> >
>> >
>> >
>>
>> _______________________________________________
>> 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 --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090705/96c8dabe/attachment.htm 


More information about the Idna-update mailing list