Re: HTTP sasl draft in last call

I share Joe's concern with definition of 235/236 success codes.  They 
are unnecessary
and introduce a round-trip, and this makes SASL authentication work 
unlike Digest
(and Basic).  I don't see the justification for the change and the 
extra complexity.
Instead, when authentication succeeds, the response to the authorized 
request should
immediately be the regular success response, whether that's 200 OK with 
the body
of the requested resource, or some other success code, with the 
WWW-Authenticate
success header moved from the 235 (236) code response to the real 
success
response.

Joe, why is CONNECT not going to work?  Can you forward your explanation
for that?  Also, why is redefining OPTIONS not going to work (and how 
exactly
are they redefining OPTIONS?)

Ted, I'll forward the 1st para above to the IESG separately as an 
official last call comment.

Lisa

On Apr 30, 2004, at 4:23 PM, Ted Hardie wrote:

>
> Hi Joe,
> 	Can you send your last call comments to the IESG,
> so they can be considered with the draft?
> 			thanks,
> 				Ted
>
>
>
> At 11:47 PM +0100 04/30/2004, Joe Orton wrote:
>> On Fri, Apr 30, 2004 at 11:34:15AM -0700, Ted Hardie wrote:
>>>  http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-11.txt
>>>
>>>  is currently in last call; working group members may wish to review
>>>  it, as it specifies HTTP status codes and SASL mechanisms which may
>>>  be relevant to the work of WEBDAV.
>>
>> The last call is "aarrgggh".... well, how about removing "HTTP/1.1" 
>> from
>> the title so this spec isn't confused with a real HTTP/1.1
>> authentication scheme?
>>
>> What are these new 235/236 status codes for?  They seem to be entirely
>> redundant.  Trying to redefine OPTIONS is still not going to work,
>> neither is the CONNECT-to-port-80 stuff, etc etc as per previous
>> reviews.
>>
>> joe
>

Received on Monday, 3 May 2004 15:24:06 UTC