Re: [Ietf-http-auth] Updating RFC 2617 (HTTP Digest) to use UTF-8

I think the big question is whether there are other outstanding  
problems with 2617 that can be changed without hurting  
interoperability. If there aren't, it may be best to leave it alone.

That's because whether or not 2617 is revised, 2616 needs to clarify  
when encoding of headers is required. Namely, the spec generically  
says that headers can use RFC2047 encoding, but it doesn't say  
whether this is done before or after the header must conform to the  
BNF (which in many cases doesn't allow the necessary flexibility).

If it's before, then implementations must RFC2047-decode every  
incoming header, which I would posit no one currently does (and  
discussion seems to back that up).

If it's the latter, then header specifications (or users of them,  
e.g., authentication schemes) need to explicitly invoke RFC2047  
encoding to have it used.

Since it isn't interoperable to retroactively change requirements,  
the first approach isn't really feasible. Which means that if this is  
clarified in the latter way in 2616, it will have the effect of  
disallowing a number of characters in credentials.

The question to ask at this point is whether we can do any better,  
inside the confines of RFC2617 interoperability. At some point, it  
gets more attractive to just mint a new authentication scheme, rather  
than live within the limits of what's there.

Thoughts?


On 2006/10/16, at 4:37 PM, Robert Sayre wrote:

>
> On 10/16/06, Lisa Dusseault <lisa@osafoundation.org> wrote:
>>  I strongly support efforts to update these specs so
>> let me know how I can help as AD or if there are any questions I can
>> answer.
>
> Hi Lisa,
>
> How do efforts to update these specs relate to the normative folklore
> regarding mandatory to implement security technologies?
>
> -- 
>
> Robert Sayre
>


--
Mark Nottingham     http://www.mnot.net/

Received on Tuesday, 17 October 2006 17:37:24 UTC