Next message: David.Goodenough@dga.co.uk: "Units of Work"
Message-ID: <65B141FB11CCD211825700A0C9D609BC0205AAE1@chef.lex.rational.com>
From: "Clemm, Geoff" <gclemm@Rational.Com>
To: ietf-dav-versioning@w3.org
Date: Wed, 23 Feb 2000 23:04:11 -0500
Subject: RE: Labels
In section 12.3, rfc2518 tells you to look at section 3.2.1 of
rfc2068 to find the syntax of the value of an href element.
Section 3.2.1 of rfc2068 requires that special characters in a
URI be escaped. In any case, I don't see how one could not
escape the special characters in a URL, since otherwise how would
you distinguish a "slash" that was supposed to be part of a segment
name from a "slash" that was supposed to be a segment delimiter?
Cheers,
Geoff
> -----Original Message-----
> From: Tim_Ellison@oti.com [mailto:Tim_Ellison@oti.com]
> Sent: Wednesday, February 23, 2000 4:40 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: Labels
>
>
>
> .. its bogus to do a URL-encoding in the body just to make it
> consistent
> with what is in the header. If we take that approach, then
> the <href>'s
> should also be URL-encoded, but I didn't see any requirement
> to do that in
> 2518.
>
> Most clients, I suggest, will URL-decode messages early
> enough (maybe even
> in the web server) that the confusion won't occur.
>
> Tim
> ----------
> >From: Clemm, Geoff
> >To: ietf-dav-versioning
> >Subject: RE: Labels
> >Date: Wednesday, February 23, 2000 4:14PM
> >
> >I agree that "putting them in URL's" is a red herring. The
> real issue is
> to
> >make
> >sure they can be sent in either a header or a message body.
> To encode them
> >one way
> >for a message body and another way for a header seems likely to cause
> >confusion and
> >error, though. Why wouldn't we just encode it the same way in both?
> >
> >Cheers,
> >Geoff
> >
> >-----Original Message-----
> >From: Tim_Ellison@oti.com [mailto:Tim_Ellison@oti.com]
> >Sent: Wednesday, February 23, 2000 2:48 PM
> >To: ietf-dav-versioning@w3.org
> >Subject: RE: Labels
> >
> >
> >
> >Is there any reason why we want to transmit a label in a
> URL? I can't
> think
> >
> >of any.
> >
> >Even if you say labels are always URL-encoded UTF-8 a client
> would not know
>
> >(just by looking at it) which segment of the URL was
> 'doubly' encoded.
> >
> >I would be inclined to go for UTF-8 Unicode chars in the
> message body
> (XML),
> >
> >URL-encoded UTF-8 in message headers, and never put them in a URL.
> >
> >Tim
> > ----------
> >>From: Clemm, Geoff
> >>To: WebDAV E-mail
> >>Subject: RE: Labels
> >>Date: Wednesday, February 23, 2000 1:17PM
> >>
> >>I don't think it helps to say that they are URL-encoded if we are
> >>required to transmit it in a URL. These leaves the client wondering
> >>whether they got the label in the URL-encoded form or not (e.g. when
> >>it appears in a Revision-Selector header. I believe it
> will be simpler
> >>and less error-prone if we just say that they are UTF-8
> Unicode characters
> >>that have been URL-encoded. Any client that handles URL's
> will be able
> >>to handle URL-encoding, and assumedly any WebDAV client
> will need to be
> >>able to handle URL's.
> >>
> >>Cheers,
> >>Geoff
> >>
> >>-----Original Message-----
> >>From: Tim_Ellison@oti.com [mailto:Tim_Ellison@oti.com]
> >>Sent: Wednesday, February 23, 2000 9:57 AM
> >>To: ietf-dav-versioning@w3.org
> >>Subject: Re: Labels
> >>
> >>
> >>
> >><geoff>
> >>I agree with those on the mailing list who have argued that it is
> >sufficient
> >>
> >>to internationalize labels to the extent that URL's are
> internationalized,
> >>which does not include tagging with language and charset.
> >></geoff>
> >>
> >>Jim W. pointed out that URLs are exempted from the
> internationallization
> >>rules. I suggest that we say labels are UTF-8 Unicode
> characters; and the
> >>resulting bytes are URL-encoded if we are required to
> transmit it in a URL
> >>(unlikely).
> >>
> >>Tim
> >>
> >>
> >
> >
>