At 23:53 05/01/25, Julian Reschke wrote:
>
>Bjoern Hoehrmann wrote:
>> * Julian Reschke wrote:
>>
>>>>>The big difference here is that XMLNS uses IRIs/URIs as identifiers and only for that. However, what is an XSLT that transforms Atom content to HTML supposed to do when it encounters a IRI which isn't a legal URI?
>>>>
>>>>http://www.w3.org/TR/xslt#section-HTML-Output-Method
>>>>
>>>> The html output method should escape non-ASCII characters in URI
>>>> attribute values using the method recommended in Section B.2.1 of
>>>> the HTML 4.0 Recommendation.
>>>
>>>How does that help with IDNs?
>>
>> After applying the algorithm, how is the situation different from
>> the current draft-ietf-atompub-format-04.txt draft which refers to
>> RFC2396bis?
>
>If an Atom document contains a URI, it by definition does not contain non-ASCII characters, such as no conversion is needed. Basically, the XSLT would consume a URI and be able to copy it verbatim to the output.
>
>Am I missing something?
Bjoern was making a vaild, but fine, point: Because we decided to refer to RFC2396bis, rather than to RFC2396, we already have bought into the fact that RFC2396bis allows percent-encoded domain names, and thus essentially requires IDN support. (apart from the basic fact that no resolver is required to resolve all URIs or IRIs)
If you want to add another fine point to this, you could say that while RFC2396bis allows percent-encoded domain names, the scheme definitions, e.g. for http:,..., haven't yet been updated to allow that.
I personally think that fine points are interesting, but that implementers and users won't bother too much with them if it's perfectly clear how things are supposed to work.
Regards, Martin.
