- From: Peter Saint-Andre <stpeter@stpeter.im>
- Date: Thu, 07 Jun 2012 12:49:20 -0600
- To: public-iri@w3.org
<hat type='individual'/> While reviewing 3987bis for i18n terminology, I came across this paragraph (Section 3.5): For compatibility with existing deployed HTTP infrastructure, the following special case applies for schemes "http" and "https" and IRIs whose origin has a document charset other than one which is UCS- based (e.g., UTF-8 or UTF-16). In such a case, the "query" component of an IRI is mapped into a URI by using the document charset rather than UTF-8 as the binary representation before pct-encoding. This mapping is not applied for any other scheme or component. The term 'origin' could be ambiguous here. It doesn't seem to be referencing the Web Origin Concept (RFC 6454) but instead seems to be based on the "document" (broadly construed) in which the http or https URL is found (e.g., as a hyperlink in an HTML document or perhaps as running text in an email message). It would be good to make that clear. One way to remove the ambiguity would be to change "origin" here to something else, but even then I think we'd need additional text. I tentatively propose the following: For compatibility with existing deployed HTTP infrastructure, the following special case applies for the schemes "http" and "https" when an IRI is found in a document whose charset is not based on UCS (e.g., not UTF-8 or UTF-16). In such a case, the "query" component of an IRI is mapped into a URI by using the document charset rather than UTF-8 as the binary representation before pct-encoding. This mapping is not applied for any other scheme or component. Martin/Larry, shall I create a ticket for this? Does my proposed text seem acceptable? Peter -- Peter Saint-Andre https://stpeter.im/
Received on Thursday, 7 June 2012 18:49:49 UTC