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

From: Brett Tate <[email-masked]>
Date: Tue, 5 Nov 2013 16:14:39 +0000

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.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Nov 2013 13:01:48 -0800

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:
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 5 Nov 2013 21:14:42 +0000

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 05 November 2013 21:02
> To: [email-masked]
> 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.
> 
> > 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:
> > 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?
> >
> > 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.

---

From: Brett Tate <[email-masked]>
Date: Wed, 6 Nov 2013 11:44:45 +0000

Hi,

Thanks for the responses.  I'm asking the questions to better understand and evaluate draft-ietf-insipid-session-id from a backward compatibility perspective with draft-kaplan-insipid-session-id.  I look forward to the next version of draft-ietf-insipid-session-id since it might provide answers to my questions (at least from insipid perspective interacting with a draft-kaplan-insipid-session-id device).

One of the call flows of interest is associated with B2BUA acting as 3PCC simulating call waiting type interaction (similar to RFC 3725 figure 13 if assume message 6 is a re-INVITE) using re-INVITE (from B2BUA) to reconnect an insipid device (X) back and forth between connections with insipid device (I) and kaplan device (K).  My current understanding is that X theoretically might change remote value and include parameter changes (new, dropped, or modified).  Thus from a B2BUA perspective, I'd need to know how draft-ietf-insipid-session-id proposes the B2BUA behave to allow backward compatibility with K.  For instance, should it send the completely new Session-ID header (i.e. new sess-id and parameters) to K or continue to send the prior Session-ID header (such as the Session-ID used when dialog created)?  Should prior knowledge of K's non support of draft-ietf-insipid-session-id cause the B2BUA to not include a draft-ietf-insipid-session-id Session-ID within the re-invite sent to X?

Thanks,
Brett

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of DRAGE, Keith (Keith)
> Sent: Tuesday, November 05, 2013 4:15 PM
> To: Paul Kyzivat; [email-masked]
> Subject: 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.
>