W3C home > Mailing lists > Public > public-iri@w3.org > July 2012

[iri] #131: Using document charset causes interoperability problems

From: iri issue tracker <trac+iri@trac.tools.ietf.org>
Date: Thu, 19 Jul 2012 22:04:09 -0000
Cc: public-iri@w3.org
To: draft-ietf-iri-3987bis@tools.ietf.org, stpeter@stpeter.im
Message-ID: <059.d135c0ecb73d7c011940543d3310f638@trac.tools.ietf.org>
#131: Using document charset causes interoperability problems

 As reported by Dave Thaler...

 URIs and/or IRIs can appear in many contexts.

 In normal text in an email message, or in a PDF file or Word doc or
 whatever else.

 Allowing it to vary complicates frameworks considerably since now the doc
 charset has to be passed from whatever extracts the URI from the document
 (HTML or otherwise) and whatever else needs to know the interpretation
 (normalizer code, comparison code, whatever).   Various API frameworks
 already have various sorts of "Uri" classes that take in a URI-like string
 and let you do things like get the URI form or the IRI form, or various
 components or whatever.   This means the constructor needs to change since
 you cannot correctly interpret an IRI(bis) without knowing the document
 charset.

 I'm not yet convinced that's a change worth making.   Currently everything
 assumes UTF-8.   With this change, we'll get random behavior until
 everything is updated, which is a state worse than today in my view.

 Example:
 http://www.sw.it.aoyama.ac.jp/non-existent?Ã

 If the charset were iso-8859-1 then under RFC 3987 as I understand it,
 this would become:

 http://www.sw.it.aoyama.ac.jp/non-existent?%C3%83%C2%A9

 In other words, you have to convert iso-8859-1 to UTF-8 and then pct-
 encode the UTF-8.

 But as I understand 3987bis it would become:

 http://www.sw.it.aoyama.ac.jp/non-existent?%C3%A9

 which would then be passed around via various APIs and protocols that
 would not pass the charset along with it. As such it would be interpreted
 by the receiving code as pct-encoded UTF-8:

 http://www.sw.it.aoyama.ac.jp/non-existent?

 which of course it isn't.

 As such, we should make the RFC 3987 behavior (UTF-8, NOT the doc charset)
 required for everything that doesn't explicitly pass the charset along
 with the URI.

-- 
-----------------------+--------------------------------------
 Reporter:  stpeter@…  |      Owner:  draft-ietf-iri-3987bis@…
     Type:  defect     |     Status:  new
 Priority:  major      |  Milestone:
Component:  3987bis    |    Version:
 Severity:  -          |   Keywords:
-----------------------+--------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/iri/trac/ticket/131>
iri <http://tools.ietf.org/wg/iri/>
Received on Thursday, 19 July 2012 22:04:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 19 July 2012 22:04:45 GMT