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
>