Re: [kitten] Alexey's comments Re: WGLC of draft-ietf-kitten-sasl-oauth-18

[Bill Mills <[e-mail]>]

and you did mean 4422 not 2244 right? 

     On Tuesday, January 6, 2015 11:06 AM, Bill Mills <[e-mail]> wrote:
   

 Can you point me at an exampel of a cancellation token? 

     On Monday, January 5, 2015 4:41 AM, Alexey Melnikov <[e-mail]> wrote:
   

  On 05/01/2015 05:14, Bill Mills wrote:
 
   Ah OK.  This is a significant change.  Can we make using the cancellation token optional?   
 Not really. Any protocol needs to define the cancellation token (according to RFC 2244) and any mechanism implementation (or SASL framework library) that doesn't complete in 1 round trip need to be able to handle it.
 
 I think it is Ok not to change the spec, but it would be a good idea to point out that standard SASL cancellation token can still be used. Adding an example would be even better.
 
  The extant implementations use the current sequence. 
  -bill
 
       On Sunday, January 4, 2015 3:37 AM, Alexey Melnikov <[e-mail]> wrote:
   
 
 Hi Bill,
 
 > On 3 Jan 2015, at 00:56, Bill Mills <[e-mail]> wrote:
 > 
 > 3.2.3 and an explicit message:  Long ago in the life of this doc I was told that some implementations may not support an empty message, so we put the single  character message there to have an explicit payload.  I'm a bit leery of changing this now since there are implementations in play that use it this way. 
 
 I didn't suggest you should be sending empty message. I said you should be using SASL cancellation token, which is a mandatory RFC 4422 feature.
 
 Any implementation would have to support this mode of operation anyway, because a SASL client can cancel any exchange.