IRIs or URIs? about i-d HOT 7 CLOSED

http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-17#section-3.2.1
and all before: " Newly defined header fields SHOULD limit their field values to US-ASCII octets."

An IRI that isn't a URI contains non-ASCII characters. "Link:" is a (relatively) new header field, the octets should be recommended at least to be URIs, not IRIs.

from i-d.

Right. The counter-argument here is that links are conveyed in a lot more than HTTP headers; e.g., in HTML and Atom. The question is whether those formats should convert from IRI to URI before considering them RFC5988 links.

from i-d.

-1 to changing to URI only. I have implementations written to assume IRI. I see no justification for adding this limitation.

from i-d.

Fine..

from i-d.

Fundamentally, this issue is the time-worn URI/IRI issue -- is there any semantic difference between a IRI and the URI it can be transformed into?

AIUI current IETF thinking is that IRIs are a "presentation artefact" -- i.e., they belong in UIs, not as protocol artefacts (keeping in mind that markup languages like HTML are considered UIs for authors).

Not sure if we'll be able to resolve this until there's a definitive answer elsewhere, though.

from i-d.

I feel like this might be resolved with a note in the Internationalisation Considerations and/or Extension Relation Types sections to the effect of "If you use an IRI for an extension relation type, be aware that it may cause problems."

For targets and contexts, we can't disallow IRIs; we can note that they need to be handled carefully in some systems.

from i-d.

Huh. Internationalisation Considerations in 5988 already says:

Relation types are defined as URIs, not IRIs, to aid in their comparison. It is not expected that they will be displayed to end users.

So, I think we can close this one.

from i-d.