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

Kawaguti Ginga wrote:
> In Sat, Dec 04, 2004 at 10:44:41AM +0100,
> Julian Reschke <julian.reschke@gmx.de> wrote:
> 
>>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.

...it is one of two required encoding...

> 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).

No, it's not in any way "more" recommended than UTF-16.

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

You need to make this assumption for full portability. These are the 
only encodings a conforming XML parser has to understand.

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

Why would you want to do that? Anyway: if you really need to, you can 
use the Accept-Charset request header 
(<http://greenbytes.de/tech/webdav/rfc2616.html#header.accept-charset>).

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

Even more than what? What alternative are you proposing?

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

But then we're not talking about an HTTP *application* anymore, but only 
about tunneling *through* HTTP.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760