Re: Comments on draft-farrell-decade-ni-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Stephen,

On 2012/06/09 22:24, Stephen Farrell wrote:

Hi Björn,

On 06/08/2012 03:16 AM, Bjoern Hoehrmann wrote:
I think the requirement in RFC 4395 section 2.6 applies here, there are
text fields in 'ni' and 'nih' addresses, so there needs to be some dis-
cussion about I18N and IRI issues, or a statement that there are none,
or something along those lines. What if I want a non-ASCII host name in
them, for instance?

So what's reasonable here?

We're inheriting some definitions (authority, unreserved&
pct-encoded) from 3986 and I'd not like to break that, nor
would I like something that doesn't work with most libraries.

Any suggestions?

I shouldn't have missed I18N and IRI issues in my apps review.

For IDNs in the authority part, you are essentially safe because RFC 3986 says exactly how to handle this (%-encoding based on UTF-8; alternatively punycode (A-Labels), for which library suppor may be better than for the former). You don't have to say anything about this, but you can say something if you think it's useful for implementers and if it's limited to a non-normative pointer (to the last paragraph of http://tools.ietf.org/html/rfc3986#section-3.2.2).

For the query part, you should put in the following text (or an equivalent):

For compatibility with IRIs, non-ASCII characters in the query part MUST be encoded as UTF-8, and the resulting octets MUST be %-encoded (see http://tools.ietf.org/html/rfc3986#section-2.1).

My understanding is that there's no danger for getting non-ASCII characters in the path part, and that fragments are separate anyway.

Regards,   Martin.


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]