Implementation questions (digressing from...)

[Erik van der Poel]

Hi Patrik,

Maybe I misinterpreted Andrew's "middle of the protocol" phrase, but I
assumed his email was about moving the mappings all the way out to the
UI. I am pretty sure that we don't have universal agreement about
that. We may not even have perfect agreement about moving the mappings
out of the IDNA RFCs. As you may recall, Mark had concerns about that,
and Michel suggested a normative reference from IDNA to a document
about mappings.

Anyway, I agree with you that these are things that will be worked out
by the various parties (IETF, Unicode, W3C, WHATWG, implementers,
etc).

Erik

On Thu, Dec 25, 2008 at 12:31 AM, Patrik Fältström <patrik at frobbit.se> wrote:
> 25 dec 2008 kl. 03.03 skrev Erik van der Poel <erikv at google.com>:
>> 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
>>
>