- From: Larry Masinter <masinter@adobe.com>
- Date: Wed, 2 Sep 2009 15:20:59 -0700
- To: "Roy T. Fielding" <fielding@gbiv.com>
- CC: "PUBLIC-IRI@W3.ORG" <PUBLIC-IRI@w3.org>
> I think we should specify that pct-encoding is always decoded before > use of a component in resolution, Well, the concern was that if you mapped IRI -> URI by pct-encoding the entire URI, you would then wind up sending around URIs with pct-encoded domain names, into previously compliant URI processors that would send the pct-encoded domain name to DNS. Don't you think we can update the IRI document (Proposed Standard) to not allow (MUST NOT) or at least not encourage (SHOULD NOT) any conversion of IRI -> URI that results in pct-encoded domain names, at least more readily than we can update the URI spec and also expect updates to http:, ftp:, telnet:, etc. etc. URI scheme implementations to mandate pct-decode+punycode-encode transformations before DNS resolution? > and further that registered names > might be Unicode and that the processor is responsible for conversion > to IDNA punycode, if necessary, for the first lookup, and then resort > to sending the raw Unicode string (if their name resolver supports that > in the API) in the next lookup if the first one failed. This allows > IDNA to have precedence (to avoid some localized masking of domains) > and yet still works for non-Internet hostname lookup.
Received on Wednesday, 2 September 2009 22:21:46 UTC