Implementation questions (digressing from...)

[Vint Cerf]

I believe there has been consensus to remove mappings in the  
formulation of the IDNA2008 standards.
It is clearly an issue how to convey to implementors the implications  
of this - which is one reason that
the Rationale document is so important.

Vint



Vint Cerf
Google
1818 Library Street, Suite 400
Reston, VA 20190
202-370-5637
vint at google.com




On Dec 25, 2008, at 3:31 AM, Patrik Fältström wrote:

>
>
>
>
> 25 dec 2008 kl. 03.03 skrev Erik van der Poel <erikv at google.com>:
>
>> Hi Andrew,
>>
>> The problem is that we don't have universal agreement to pull  
>> mappings
>> out of the middle of the protocol.
>
> This is up to the wg chair to explain, but I strongly disagree with
> this statement. There is strong consensus for removing mappings so
> that A-label etc is more strictly defined.
>
> What there is consensus on as well though is the fact we need  
> protocol/
> context dependent descriptions on how to implement mappings or
> whatever that for example browser vendors ask for.
>
> Mark has a strawman for http/HTML, but noone so far has really taken
> on the task of writing one.
>
> What I have seen that concerns me is an initiative in/by UTC to do
> mappings when at the same time IETF has mapping as part of IETF
> standards. That is though a detail that can and will be worked out
> between the two organizations.
>
>     Patrik
>
>> I don't know what will happen at WG
>> Last Call, etc, but so far, I have not seen any indication from
>> browser developers that they are willing to drop the mappings
>> (lower-casing, etc) from HTML href processing (and address bar
>> processing). Then again, we haven't heard from very many browser
>> developers. Microsoft employees have been participating and we  
>> used to
>> hear from Firefox folks too. I believe we need to get more
>> implementers together (not just HTML implementers), and we need to
>> present the arguments in terms that they are likely to understand and
>> sympathize with. The IDNA2008 draft authors are good writers, but
>> there is a disconnect.
>>
>> The root of that disconnect (from my point of view) is that HTML  
>> has a
>> long history of implementers writing lenient parsers, presumably
>> because HTML used to be written by hand in the old days (and probably
>> still is, to some extent). It is somewhat unfortunate, but a small
>> number of plug-in and browser implementers decided to perform  
>> IDNA2003
>> mappings on HTML hrefs. One might say that that was the point of no
>> return. It is hard to convince HTML implementers to make their  
>> parsers
>> more strict. We can certainly try to convince them.
>>
>> Erik
>>
>> On Wed, Dec 24, 2008 at 8:43 AM, Andrew Sullivan <ajs at shinkuro.com>
>> wrote:
>>> On Wed, Dec 24, 2008 at 07:51:23AM -0800, Erik van der Poel wrote:
>>>
>>>>> From my point of view, this is a leap of faith. I.e. hoping that
>>>>> zone
>>>> operators at all levels of the DNS (not just TLDs) will bundle (or
>>>> block) for eszett/ss.
>>>
>>> As I've already argued, you _have_ to have that faith if you want  
>>> the
>>> current proposed protocol approach to work.  That is, if we're going
>>> to pull mappings out of the middle of the protocol and push them out
>>> to the ends, on the grounds that different circumstances demand
>>> different processing, then we have to accept what moving the  
>>> mappings
>>> entails.  One thing it entails is an opening for possibly foolish
>>> behaviour on the part of zone operators.
>>>
>>> This capacity for bad operation of a DNS zone is nothing new.
>>> Significant portions of the DNS today only manage to operate because
>>> of generous cache acceptance policies on the part of resolvers,
>>> without which some zones would almost certainly go dark.  There are
>>> warnings in the context of both CNAME and DNAMEs that long chains  
>>> can
>>> be made circular, and that you had better be pretty careful not  
>>> to do
>>> that; but operators still manage to do it.  I anticipate that there
>>> will be operators who allow the "same" label spelled with "ss" and
>>>  "ß"
>>> to resolve to different hosts.  I think that will be too bad.  I  
>>> also
>>> think there is nothing we can really do about that in the proposed
>>> protocol, without reopening the question of the deep assumption of
>>> where mappings ought to happen.  We can't have this both ways.
>>>
>>> The best we can do is tell people to be careful, and suggest
>>> different
>>> ways that they can do that.  I think DNAME is probably more
>>> appropriate than CNAME in many but not all of these cases, for
>>> instance.  Also, keep in mind that anything we insist on probably
>>> brings with it more restrictions than maybe we want.  For instance,
>>> MX
>>> records can't point at a CNAME.  Do we really think it a good  
>>> idea to
>>> open the DNS operation can of worms as part of our effort to settle
>>> on
>>> this protocol?  Advice for what we think is sane is, I think, not a
>>> bad idea.  But the closer we get to "SHOULD" or "MUST", the more I
>>> see
>>> a bottomless rathole in our future.
>>>
>>> A
>>>
>>> --
>>> Andrew Sullivan
>>> ajs at shinkuro.com
>>> Shinkuro, Inc.
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> 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/20081225/70fe7676/attachment-0001.htm