W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: IRIs, IDNAbis, and HTTP [i74]

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Fri, 14 Mar 2008 11:55:33 +0100
Message-Id: <B9B4C5A3-FB79-46A0-855F-090614330F96@greenbytes.de>
Cc: Julian Reschke <julian.reschke@gmx.de>, Martin Duerst <duerst@it.aoyama.ac.jp>, Brian Smith <brian@briansmith.org>, ietf-http-wg@w3.org
To: Mark Nottingham <mnot@mnot.net>

Am 14.03.2008 um 11:46 schrieb Mark Nottingham:
> I think Larry was making much the same point at the app area arch  
> ws, IIRC.
> My gut feeling on issue 74 is that if any encoding (e.g., IRI->URI,  
> RFC2047) is usable in a header, it should be specified on a header- 
> by-header basis explicitly, not inherited as a general rule like  
> this. That allows the flexibility to use the right mechanism for  
> the job, and keeps the overhead low.
> Are there any other headers (besides URI-based headers) that we  
> need to consider, beyond these?
>  * WWW-Authenticate, Proxy-Authenticate, Authorization, Proxy- 
> Authorization
>  * Content-Disposition
>  * From
>  * Warning
>  * PICS-Label

The whole "Auth" header series does not have the problem, I think.  
All header values are ASCII.

Correct me if I'm wrong: the open issue is how to send user names/ 
passwords with non-ascii characters. But that is a matter of the auth  
mechanism to specify, not an issue with HTTP headers. Example: Basic  
puts Base64 values in the header. Those are always ASCII. But Base64  
operates on octets and Basic just fails to specify how a username is  
converted to octets, right?


<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782
Received on Friday, 14 March 2008 10:56:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC