Alexey states:
>
> On 3 May 2012, at 20:40, Peter Saint-Andre <[email protected]> wrote:
>
>> On 5/2/12 1:45 PM, =JeffH wrote:
>>
>>>> 13. Internationalized Domain Names for Applications (IDNA): Dependency
>>>> and Migration
>>>>
>>>> IDNA2008 obsoletes IDNA2003, but there are differences between the
>>>> two specifications, and thus there can be differences in processing
>>>> (e.g., converting) domain name labels that have been registered under
>>>> one from those registered under the other. There will be a
>>>> transition period of some time during which IDNA2003-based domain
>>>> name labels will exist in the wild. User agents SHOULD implement
>>>> IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of
>>>> [RFC5894]) or [UTS46] in order to facilitate their IDNA transition.
>>>>
>>>> I might be kicking a dead horse here, but MAY sounds a bit weak.
>>>> I especially dislike having the choice between 2 incompatible specs,
>>>> I think this might cause some interop problems.
>>>
>>> As far as I can tell, having had fairly extensive discussions with IDNA
>>> folk both privately and on various lists such as idna-update@, the above
>>> relects the the unfortunate state of the world at this time. For
>>> instance, Pete Resnick signed off on the language in the spec in this
>>> message to websec@...
>>>
>>> Re: [websec] wrt IDN processing-related security considerations for
>>> draft-ietf-websec-strict-transport-sec
>>> https://www.ietf.org/mail-archive/web/websec/current/msg01015.html
>>>
>>> we should probably fork off any further discussion on this topic to that
>>> thread.
>>
>> Unfortunately, I think the text that Jeff produced is about the best
>> we're going to do
>
> We are setting ourselves up for some interop problems. We should bite the
> bullet and through RFC 5894 or UTS 46 out.
These overall topics have been discussed in the past on..
[email protected]
<http://www.alvestrand.no/mailman/listinfo/idna-update>
..and it seems to me this particular discussion should probably be taken over
to that list. some pointers to likely pertinent prior threads below.
HTH,
=JeffH
------
Past threads on the idna-update@ list that I'm aware of that are specifically
pertinent to the above include (there may also be others, see also further below)..
referencing IDNA2008 (and IDNA2003?)
http://www.alvestrand.no/pipermail/idna-update/2010-October/006757.html
RFC5895 and UTS46 ?
http://www.alvestrand.no/pipermail/idna-update/2010-October/006821.html
IDN processing-related security considerations for
draft-ietf-websec-strict-transport-sec
http://www.alvestrand.no/pipermail/idna-update/2011-September/007140.html
wrt IDNA2008 migration (was: IDN processing-related...
http://www.alvestrand.no/pipermail/idna-update/2011-September/007152.html
wrt IDNA2003->IDNA2008 transitionn (was: IDN processing-related...
http://www.alvestrand.no/pipermail/idna-update/2011-October/007170.html
Older threads re IDNA2003 - IDNA2008 transition (there also are definitely
(many) other relevant threads)...
Another Transition Plan Proposal
http://www.alvestrand.no/pipermail/idna-update/2009-December/006255.html
An idea for transition principles (see next thread for plain text doc
version; but there were replies in this thread too)
http://www.alvestrand.no/pipermail/idna-update/2009-December/006330.html
Re-sending TXT form of Proposed IDNA2008 Transition Idea
http://www.alvestrand.no/pipermail/idna-update/2009-December/006339.html
PostWG IDNA2008 implementation, transition and deployment document preparation
http://www.alvestrand.no/pipermail/idna-update/2009-December/006374.html
---
end
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
