- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 06 Dec 2004 09:14:18 +0100
- To: Kawaguti Ginga <g.kawaguti@ntt.com>
- CC: Jonathan Rosenberg <jdrosen@cisco.com>, Lisa Dusseault <lisa@osafoundation.org>, HTTP working group <ietf-http-wg@w3.org>, "'simple@ietf.org'" <simple@ietf.org>
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
Received on Monday, 6 December 2004 08:14:57 UTC