- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 04 Dec 2004 10:44:41 +0100
- 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. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Saturday, 4 December 2004 09:45:18 UTC