- From: Martin Duerst <duerst@w3.org>
- Date: Tue, 04 May 2004 17:06:29 +0900
- To: Larry Masinter <LMM@acm.org>, "'Michel Suignard'" <michelsu@windows.microsoft.com>, public-iri@w3.org
It's now a week since I tentatively closed issue http://www.w3.org/International/iri-edit/#punycodeSHOULD-23. I haven't heard about any problem, so I'm closing this issue. Regards, Martin. At 13:17 04/04/27 +0900, Martin Duerst wrote: >Hello Larry, > >At 03:07 04/03/30 -0800, Larry Masinter wrote: > >>I think this is an interoperability issue, and that neither SHOULD nor MAY >>are appropriate. Rather, there is a MUST with a couple of alternatives. >>Implementations >>resolving an IRI with non-ascii host names MUST use one of the established >>methods of resolving the host name correctly. > >I think this is a very valid point. However, I think that this is >overall covered by the current spec. The spec has an overall MUST >for the general conversion procedure: > >"Applications MUST map IRIs to URIs using the following two steps." > >It then allows (MAY) an additional step in certain well-defined cases: > >"Infrastructure accepting IRIs MAY convert the ireg-name >component of an IRI as follows (before step 2 above) for schemes >that are known to use domain names in ireg-name, but where the >scheme definition does not allow %-escaping for ireg-name:" > >Finally, it recommends that the above additional step be taken >under certain conditions: > >"This conversion SHOULD be used when the goal is to >maximize interoperability with legacy URI resolvers." > >So it seems to me that this is covered. Of course, there is >always the question of whether other things, not discussed in >the spec, are allowed or not, but I think it is a general >principle when writing IETF specs to not include generalities >such as "Any other method than those discussed in this >document MUST NOT be used." > > >I hope this reply sufficiently addresses this issue >(punycodeSHOULD-23). I have noted this as tentatively closed. > > >Regards, Martin.
Received on Tuesday, 4 May 2004 04:17:34 UTC