- From: <gclemm@rational.com>
- Date: Thu, 24 Jan 2002 17:40:28 -0500
- To: ietf-dav-versioning@w3.org
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 Thursday, 24 January 2002 17:41:32 UTC