Re: [Insipid] draft-kaplan-insipid-session-id: parameters and session-id

Personally I'd probably follow 4.3, but if both sides are operating correctly, there should not be a conflict.

To add to Paul's discussion points, it is also a question of whether any ambiguity causes misoperation.

Keith 

> -----Original Message-----
> From: insipid-bounces@ietf.org 
> [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: 05 November 2013 21:02
> To: insipid@ietf.org
> Subject: Re: [Insipid] draft-kaplan-insipid-session-id: 
> parameters and session-id
> 
> Brett,
> 
> Since the kaplan draft is effectively historical, intended to 
> document something that has already been implemented, its not 
> evident to me that asking clarifying questions about it is 
> useful. If you have those questions, then the implementers of 
> it must have had them too, or failed to realize the ambiguity.
> 
> I think the only things it is helpful to consider are:
> - what behaviors would be plausibly compliant with kaplan?
> - what do actual known implementations of kaplan actually do?
> 
> 	Thanks,
> 	Paul
> 
> On 11/5/13 8:14 AM, Brett Tate wrote:
> > Hi,
> >
> > Concerning the topic of backward compatibility with 
> draft-kaplan-insipid-session-id, I'm not sure that I 
> understand sections 4.2 and 4.3 of 
> draft-kaplan-insipid-session-id-03 concerning parameters and 
> Session-ID header modifications.
> >
> > Section 4.2 indicates:
> > "The UAC MUST re-use the same Session-ID value for 
> in-dialog messages
> >   as that of the original dialog-creating request".
> >
> > Section 4.3 indicates:
> > "A UAS compliant with this document MUST copy a received Session-ID
> >   header field in a request, into responses and subsequent upstream
> >   requests sent within the dialog."
> >
> > What should the generator of the Session-ID (from section 
> 4.2 perspective) do if receives mid-dialog Session-ID header 
> modification within a request?
> >
> > 1) Follow section 4.2 MUST.
> > 2) Follow section 4.3 MUST.
> > 3) It is abnormal situation; thus it can do whatever it wants.
> >
> > What if there is only a parameter modification: added, 
> removed, or value change?
> >
> > What should the generator of the Session-ID (from section 
> 4.2 perspective) do if receives Session-ID header 
> modification within a response?
> >
> > Concerning the section 4.2 and 4.3 snippets, my 
> understanding is that the MUST includes parameters (instead 
> of just Session-ID's sess-id).  Is my interpretation correct? 
>  I thought that I'd ask to ensure that I'm not 
> misinterpreting the use of "value" and "field".
> >
> > Thanks,
> > Brett
> >
> > This email is intended solely for the person or entity to 
> which it is addressed and may contain confidential and/or 
> privileged information. If you are not the intended recipient 
> and have received this email in error, please notify 
> BroadSoft, Inc. immediately by replying to this message, and 
> destroy all copies of this message, along with any 
> attachment, prior to reading, distributing or copying it.
> > _______________________________________________
> > insipid mailing list
> > insipid@ietf.org
> > https://www.ietf.org/mailman/listinfo/insipid
> >
> 
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid
> 