W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2004

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 28 Nov 2004 12:33:46 +0100
Message-ID: <41A9B79A.9020904@gmx.de>
To: KAWAGUTI Ginga <g.kawaguti@ntt.com>
CC: Lisa Dusseault <lisa@osafoundation.org>, HTTP working group <ietf-http-wg@w3.org>, "'simple@ietf.org'" <simple@ietf.org>

KAWAGUTI Ginga wrote:
> ...
> XCAP's target document is usually written in UTF-8(it's XML),

Unless XCAP says something normative, it could be any encoding. As far 
as I can tell, the actual decoding doesn't matter at all as long as it 
is one of the XML required ones (thus UTF-8 or UTF-16).

> so XCAP requires Xpath stuff(utf-8) into URL part, which is usually
> considered as US-ASCII.
> There are ways to encode utf-8 string into URL part, but
> I don't think there's any unique, robust and common way for doing it.

No matter what encoding the document uses, XCAP needs to define that 
mapping (and yes, that mapping needs to be based on UTF-8).

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

> (People who lives in us-ascii world, or even iso-8859-* world,
>  might not realize what these problems are...)

Oh yes, I do :-)

Best regards, Julian

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Sunday, 28 November 2004 11:34:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:38 UTC