RE: RFC: REST-RPC

A bit more insight into the unicode pbls:

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf
> Of John Wilson
> Sent: Friday, April 21, 2006 8:28 AM

...

> 'Any characters are allowed in a string except < and &, which are  
> encoded as &lt; and &amp;. A string can be used to encode 
> binary data.'
> 

A string in fact can NOT be used to encode binary data. the problem is twofold:
+ control chars (except TAB, CR and LF) are not valid inside xml documents, ie. sending binary will break xml
+ in xml documents the CRLF will (could?) be normalized, ie. standard xml encoders will break binary data
+ charset entities in received xml should be decoded by the xml parser and passed to the xmlrpc toolkit in their standard representation, ie. standard xml parsers will break binary data

> 
> My recommendation to implementers is generally to emit XML with no  
> encoding declaration and to use numeric character references for  
> those Unicode characters with code points > 0X7F. This seems to  
> maximise the interoperability.

This is the best solution I could come up with, too.
The only drawback is that there is no guarantee that the charcters sent will be 'understood' succesfully by the receiver (e.g. when sending a japanese unicode char to some program that uses iso-8859 internally).

In fact, if you read the HTTP specs, you will find out that for text/xml mime type (the mimetype specified by xmlrpc), when no charset encoding is present in the http headers (or xml prologue), you must use ascii only, anyway (see RFC 3023).

So the approach used in the php-xmlrpc lib is the following:

for sending:

default:
encode all emitted Unicode characters with code points > 0X7F to their unicode numeric character reference, send payload using 'text/xml' mime type and no charset spec in the xml prologue.
The payload is granted to be parsed by any xml parser, because it is valid ascii, valid iso-8859-1 and valid utf8 at the same time.

special cases:
When the user specifies a desired charset for the emitted xml, the payload is encoded to the chosen charset, and charset encoding declarations are added to both the http content-type header and the xml prologue.
This breaks 'slightly' the spec (which mandates 'text/xml' with apparently no charset allowed) but maximizes the chances of the receiver getting the charset right.

for receiving:

'guestimate' the charset of the incoming payload by looking at http content-type and xml prologue. If none is found assume UTF-8 by default, because, despite what the specs say, it is what most implemantations out there will be sending (but the user can configure it to use iso-8859-1 as default if he prefers)

Bye
Gaetano

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/xml-rpc/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/