W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2002

RE: LABEL comparison

From: <gclemm@rational.com>
Date: Fri, 25 Jan 2002 08:18:02 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B105A31606@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
This is fine with me as well.

Does anyone object to the following two changes to address this issue:

- In section 8.2, Replace "SHOULD use an octet-by-octet case-sensitive
comparision" with "SHOULD use a case-sensitive comparison".

- In section 8.3, replace "encoded using UTF-8" with "encoded using
URI-escaped UTF-8".

Cheers,
Geoff

-----Original Message-----
From: Tim Ellison [mailto:Tim_Ellison@uk.ibm.com]
Sent: Friday, January 25, 2002 6:11 AM
To: ietf-dav-versioning@w3.org
Subject: RE: LABEL comparison


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 08:19:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:43 GMT