Implementation questions (digressing from...)

[Erik van der Poel]

Hi Andrew,

The problem is that we don't have universal agreement to pull mappings
out of the middle of the protocol. 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
>