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: Sat, 04 Dec 2004 10:44:41 +0100
Message-ID: <41B18709.1040502@gmx.de>
To: Jonathan Rosenberg <jdrosen@cisco.com>
CC: KAWAGUTI Ginga <g.kawaguti@ntt.com>, Lisa Dusseault <lisa@osafoundation.org>, HTTP working group <ietf-http-wg@w3.org>, "'simple@ietf.org'" <simple@ietf.org>

Jonathan Rosenberg wrote:
> Julian Reschke wrote:
>> 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).
> 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).

> mapping from UTF-8 strings into a URI, can you clarify why this is hard? 
> Isn't it just a matter of escape-coding the octet sequence associated 
> with non-ascii characters (I admit this is not my area of expertise and 
> I likely am missing something here).

This isn't hard, one just needs to define it.


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Saturday, 4 December 2004 09:45:18 UTC

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