Implementation questions (digressing from...)

[Patrik Fältström]

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
>