Character encoding in PIDF

Graham Klyne <[email protected]>
Newsgroups gmane.ietf.impp
Message-ID <[email protected]>
I've excerpted this from my fuller review of the PIDF document, because I 
think it should be considered sooner rather than later.

...

4.1.   XML Format Definitions

[...]

    It MUST have the XML declaration and it SHOULD contain an encoding
    declaration in the XML declaration, e.g. "<?XML version='1.0'
    encoding='UTF-8'?>". If the charset parameter of the MIME content
    type declaration is present and it is different from the encoding
    declaration, the charset parameter takes precedence.

What forms of character encoding are CPIM-compliant systems required to accept?

My view is that UTF-8 only should be specified, but others have different 
views.
e.g. see my comments at:
   http://www.imc.org/ietf-xml-use/mail-archive/msg00221.html
which were in response to Tim Bray's message at:
   http://www.imc.org/ietf-xml-use/mail-archive/msg00219.html
which cites a W3C tag decision at:
   http://lists.w3.org/Archives/Public/www-tag/2002Jun/0020.html
I note that the TAG decision, while coming down against general 
restrictions on character encoding, does also say:
[[
For some machine-to-machine routing protocol, we accept that
restricting the encoding to UTF8/16 would be acceptable. But for
specifications designed for editing by humans (such as MathML), we
believe that this restriction should not be imposed.
]]

Tim Bray goes on to argue (see discussion thread from above messages) that 
full-blown generic XML parsers will (or should) be used whenever XML 
appears in a protocol, and hence that it is not appropriate to restrict the 
character encoding to UTF-8.  I happen to disagree -- I think specific 
protocol implementations may reasonably be hand-coded and optimized to deal 
with a single character encoding.

#g


-------------------
Graham Klyne
<[email protected]>




  [reminder: [email protected] for non-technical discussions, please]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.