Implementation questions (digressing from...)

[Erik van der Poel]

Ah, I see. Sorry about the misunderstanding. The words "different
circumstances demand different processing" made me think this was
about UI, but now I see that you're talking about "local, not global
context". There is some danger in applying different rules in
different circumstances, but if they are applied in very specific
situations and with a lot of care, interoperability can still be
preserved. I'm thinking about the Turkish upper/lower case mappings
for dotted and dotless 'i'.

I think you're right that we need to have some faith that zone admins
will do the right thing for eszett/ss, especially in the higher level
domains and in high security situations like https (e.g. banks).

It would be great to get some more implementers together after the
holidays, to start discussing implementation options, pros and cons,
rationale, and so on. Perhaps such discussion could/should start
before IDNA2008 is published as a set of RFCs.

Erik

On Thu, Dec 25, 2008 at 9:57 AM, Andrew Sullivan <ajs at shinkuro.com> wrote:
> What I meant by "middle of the protocol" is the middle of _this_ protocol --
> i.e. the one for putting internationalized labels in the DNS. The propsal is
> to move the mapping to the ends, but that need not mean "the UI".  It really
> just means that the rules are to be applied in local, not global context.
>
> Andrew Sullivan
> ajs at shinkuro.com
>
> On 25-Dec-08, at 11:44, Erik van der Poel <erikv at google.com> wrote:
>
>> 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
>>>>
>>>
>