Re: [Simple] Some thoughts on XCAP's resource architecture

In Sat, Dec 04, 2004 at 10:44:41AM +0100,
Julian Reschke <julian.reschke@gmx.de> wrote:
> >This is a good point; I've gotten a private comment about this as well. 
> >I think the simplest thing is to normatively state that all XML 
> >documents managed by XCAP have to be utf-8 encoded. In terms of a 
> 
> That may be a bad choice if lots of your data is in characters that need 
> multi-byte sequences, in which case UTF-16 may be more efficient. I 
> think XCAP should simply stick with what XML requires (which is UTF-8 
> and UTF-16, nothing more).

I agree that "hard-assumption of UTF-8 usage" is a bad choice.
UTF-8 is only a DEFAULT encoding for XML standard.
Yes it is recommended to use UTF-8, but there are many other XML documents
based on other encodings (not only UTF-16, but many more).

If XCAP is intended to be very specific protocol only for
some limited XML documents, then "all documents are UTF-8(and/or UTF-16)" 
assumption might work, but it's a bad idea for general protocol design.

There are many ways to specify encodings in a XCAP-only-way,
like appending "http://.../...?encoding=utf-8?...",
but they're not HTTP-standard way.


And something more, URL string size limitation.
"% encoded" UTF-8 string might suffer even more on this restriction.


Julian's previous mail:
> > If that argument was in body part(header might also be recepted),
> > this consideration is much less problem, because there are ways to
> > declare encodings, and usual gateways/clients are aware of them.
> 
> Don't understand. How are you sending the document selector inside the 
> request body for PUT?

For generic HTTP PUT, there's no way, as denoted in your comment.
My consideration was to use something like SOAP envelope.
It shouldn't be "PUT" anymore, and it should be used over
some original rule anyway.

Regards,
Ginga Kawaguti

-- 
Office:  NTT Communications Innovative IP Architecture Center 1PT 1P
Address: KAWAGUTI Ginga <g.kawaguti@ntt.com>
Phone:   voice=+81-3-6800-3032; fax=+81-3-5388-0550

Received on Monday, 6 December 2004 04:04:47 UTC