- From: Tim Ellison <Tim_Ellison@uk.ibm.com>
- Date: Fri, 25 Jan 2002 11:10:51 +0000
- To: ietf-dav-versioning@w3.org
UTF-8 first followed by URL-encoding sounds fine to me. Regards, Tim "Julian Reschke" <julian.reschke@greenbytes.de> Sent by: ietf-dav-versioning-request@w3.org 2002-01-25 08:31 To: <gclemm@rational.com>, <ietf-dav-versioning@w3.org> cc: Subject: RE: LABEL comparison Geoff, 1) yes, it has caused interoperability problems, because the convention to "UTF-8 encode first, then URL-encode" of URIs is relatively new. For instance, some Microsoft client implementations use ISO8859-1 encoding, which causes the client to fail if the server only supports UTF-8 (like it should). 2) however, the main difference is that a URI *always* is encoded -- there is no such think like a URI containing non-ASCII characters (so the problems I have with LABEL do not apply here -- actually, I'm proposing to use the same format used for the URI). Julian > -----Original Message----- > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of > gclemm@rational.com > Sent: Thursday, January 24, 2002 11:40 PM > To: ietf-dav-versioning@w3.org > Subject: RE: LABEL comparison > > > It appears to me that the DAV:href element value has all the same problems > as > a label (i.e. the value appears both in header contexts and in > XML element values), but 2518 didn't feel obliged to say anything > about it. > Has this caused interoperability problems? > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@greenbytes.de] > Sent: Thursday, January 24, 2002 4:49 PM > To: gclemm@Rational.Com; ietf-dav-versioning@w3.org > Subject: RE: LABEL comparison > > > > From: ietf-dav-versioning-request@w3.org > > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of > > gclemm@rational.com > > Sent: Thursday, January 24, 2002 4:57 PM > > To: ietf-dav-versioning@w3.org > > Subject: RE: LABEL comparison > > > > > > This is one of the reasons that baselines should be used instead of > > labels, whenever possible (baselines are identified by URL's, not text > > strings, so they have none of these problems). > > > > As I recall, the "octet-by-octet" phrasing was written with the > > label header in mind, but I agree that this phrasing doesn't work > > so well with XML. Perhaps some of the folks that care about labels > > could comment here? > > I just re-read the lable header thread from almost one year ago. > > While I agree that language information isn't relevant, I have serious > concerns about how it's currently described in the spec. > > 1) The matching should not refer to octets. This doesn't make sense if the > label has been set using XML marshalling. > > 2) I'd really like to see a working example of of a label containing > non-ASCII characters being passed through an HTTP header into a server. If > the description in the spec is sufficient, it should be easy to > come up with > an example, right? > > 2b) As an alternative, I'd suggest URL-encoding the label's UTF-8 octet > representation (we know *this* works). > > Julian > > >
Received on Friday, 25 January 2002 06:24:07 UTC