W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2001

Re: UTF-8 Encoding Question

From: Dan Brotsky <dbrotsky@Adobe.COM>
Date: Thu, 1 Mar 2001 10:35:51 -0500
Message-Id: <p04330102b6c41435548b@[192.168.1.6]>
To: Greg Stein <gstein@lyra.org>
Cc: w3c-dist-auth@w3.org
At 12:33 AM -0800 3/1/01, Greg Stein wrote:
>That would be a good heuristic for handling this.
>
>We could augment the DAV:href element with an optional attribute, like this:
>
>   <D:href 
>D:original-charset="iso-8859-1">http://some.host/Magn%FCs.txt</D:href>
>and
>   <D:href D:original-charset="utf-8">http://some.host/C%C3%A9sar.txt</D:href>
>
>That will help within the responses (if a server supplies it, then you don't
>have to guess; otherwise, fall back to your heuristic).

This certainly would be a helpful thing for servers to say to clients 
(although maybe in some other way), and I second your request to JimW 
about adding it as an issue.

>  We'd still need a
>way to determine the original charset of the Request-URI, though, to fully
>solve the problem.

I think there's a slightly different way to approach this, especially 
since (in general) there's no way to determine the original charset 
of the client request.

1. In situations where a returned URI in the response was present in 
the client request, I think the server really has to return it 
exactly as it was submitted.  Otherwise a lot of clients are going to 
get really confused, because for sure they're just looking for what 
they sent and not expecting to get into all sorts of "oh it's really 
the same in canonical form" discussions.

2. In situations where a returned URI in the response is not in the 
original request, the server is free to use whatever encoding it's 
going to use for path segments, and it can tell the client what is 
(either specifically as in Greg's proposal above or more generally 
via an OPTIONS setting or some such).

As both clients and servers get smarter about this issue, then 
presumably the distinction between these cases starts going away (and 
it becomes less important for servers to say what encoding they're 
using for path segments).  But on the way there this approach allows 
for backward compatibility with existing clients that are unaware of 
these issues without servers having to guess.

And it has the added advantage of not breaking any client/server 
combinations that currently work.

     dan
Received on Thursday, 1 March 2001 14:46:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:55 GMT