Re: Character encoding in PIDF

Graham,

Thanks very much for your detailed reading and helpful suggestions.  
I'm revising the draft based on them. 

For the issue of character encoding, I tend to agree with your observation.  

draft-hollenbeck-ietf-xml-guidelines-06.txt states that, for the IETF protocol
using XML, allowing for UTF-8 is required and allowing for UTF-16 is 
recommended.  From my understanding, it seems that mandating only UTF-8 
in PIDF does not deviate from this guideline.   Is it correct? 


-- Hiroyasu Sugano


> 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]
> 
> 



  [reminder: [email protected] for non-technical discussions, please]