Subject: Final changes to the base SASL document

From: Alexey Melnikov <[email-masked]>
Date: Mon, 21 Jun 2004 23:51:23 +0100

Rob Siemborski wrote:

>On Fri, 21 May 2004, Sam Hartman wrote:
>  
>
>>    >> It seems we can handle this cleanly enough if we treat it just
>>    >> like the initial response.
>>
>>But is it worth the complexity?  IT seems that if we can avoid the
>>introduction of distinguishing the two cases we should do so.
>>    
>>
>
>If it is not worth the complexity (and, really, I can't think of any
>situation where an empty server success data would be *useful*-- it just
>seems that we'd be giving up some level of flexibility), then we should
>just forbid empty success data -- this would lead to the less confusion
>than attributing two potential meanings to "no success data".
>  
>
Should I treat "forbid empty success data" as the WG consensus on empty 
versa no data on success?

I would like to publish [the last] revision of  the base SASL spec.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Jun 2004 00:00:33 +0100

Ken Murchison wrote:

> Ken Murchison wrote:
>
>> Kurt D. Zeilenga wrote:
>>
>>> At 11:41 AM 5/21/2004, Rob Siemborski wrote:
>>>
>>>> It also states:
>>>>
>>>> 7.4.  External mechanism
>>>>  The client sends an initial response with the authorization identity.
>>>
>>> Note that it does not say:
>>>         The client may optionally send an initial response with the 
>>> authorization
>>>         identity.
>>>
>>> And, if the client were not to send an initial response, there is no
>>> specified challenge for the server to issue to obtain the authorization
>>> identity.
>>
>> I think the problem here is that the EXTERNAL spec uses the term 
>> "initial response" which is implying that the response can only be 
>> sent with the command which starts the authentication.  My 
>> understanding is that EXTERNAL consists of a single message sent from 
>> client to server which contains the authzid.  If the protocol profile 
>> allows for an initial response and the client chooses to do so, then 
>> the authzid MAY be sent as an initial response.  Otherwise, the 
>> server will send an empty challenge to prompt the client for the 
>> authzid.  Either way, the client MUST provide an authzid.
>
>
> I should have added the following to my last sentence: "which may be 
> empty".

I've changed the paragraph to be:

The client sends a single message containing the UTF-8 encoding of the
authorization identity. The message may be empty. The form of the
authorization identity is further restricted by the application-level
protocol's SASL profile.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 21 Jun 2004 23:51:23 +0100

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Jun 2004 00:00:33 +0100

Alexey