W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2005

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

From: Anderson Njomdret <normerty@lycos.com>
Date: Thu, 27 Jan 2005 22:13:45 +0000
To: ietf-http-wg@w3.org
Message-Id: <20050127221305.D4FE6E5BC7@ws7-2.us4.outblaze.com>

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.

> 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

Find what you are looking for with the Lycos Yellow Pages
Received on Friday, 28 January 2005 08:28:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:26 UTC