Subject: [Insipid] comments on draft-jones-insipid-session-id-01

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sun, 4 Nov 2012 01:05:38 +0000

Oops - resending with complete subject this time

> -----Original Message-----
> From: Charles Eckel (eckelcu)
> Sent: Saturday, November 03, 2012 8:44 PM
> To: [email-masked]
> Subject: comments on
> 
>  I read the draft and think this version is a good step forward. Paul K. and
> Salvatore already raised most of the comments I had in mind, but I have the
> following which may still be of some value.
> 
> Section 4 reads as follows:
> 
>   Consider the following example.
> 
>    Endpoint 1 produces this UUID: 0xaeffa652b22911dfa81f12313a006823
>    Endpoint 2 produces this UUID: 0xbe11afc8b22911df86c412313a006823
> 
>    The resulting concatenated Session Identifier would be:
>    0xaeffa652b22911dfa81f12313a006823be11afc8b22911df86c412313a006823
> 
> This is no longer true and does not align with the new ABNF (i.e. the
> addition of the rcvr parameter).
> 
> My other comment is in regard to:
> http://www.ietf.org/mail-archive/web/insipid/current/msg00402.html
> 
> ISTM that a session id aware intermediary should insert a uuid when not
> present on behalf on either the endpoint. It might help to enumerate all
> cases explicitly:
> 
> a) Alice includes a session-id and Bob does too
> Yeah, the intermediary does not alter anything
> b) Alice includes a session-id and Bob does not
> Intermediary inserts a session-id in the response on behalf of Bob
> c)  Alice does not include a session-id and Bob does
> Intermediary inserts a session-id in the request on behalf of Alice
> d) Alice does not include a session-id and Bob does not either
> Intermediary inserts a session-id in the request on behalf of Alice and in the
> response on behalf of Bob
> 
> Cheers,
> Charles

---

From: James Polk <[email-masked]>
Date: Sun, 04 Nov 2012 01:59:29 -0500

> > addition of the rcvr parameter).

Charles - you are correct, and this needs to align with the ABNF 
which is how we are thinking of this solution moving forward. I know 
this was a case of so many changes that a few (hopefully) small 
inconsistencies were overlooked (that needed modification too).

> > present on behalf on either the endpoint.

So, you want this session id aware intermediary to insert a uuid when 
which one is not present, the sender's or the receiver's? It matters 
a lot IMO. I can see uses for this insertion when the sender's is not 
present, but I believe it is bad for a session id aware intermediary 
to insert a receiver's before that receiver has had a chance to 
insert its own. Basically, I want to know which messages you see this 
insertion, the INVITE, the 200 OK, the reINVITE/UPDATE/whatever 
(after the dialog is established?

>It might help to enumerate all
> > cases explicitly:
> >
>_______________________________________________
>insipid mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/insipid

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sun, 4 Nov 2012 19:45:28 +0000

Hi James, please see inline.

> From: James Polk (jmpolk)
> Sent: Sunday, November 04, 2012 1:59 AM
> To: Charles Eckel (eckelcu); [email-masked]
> Subject: Re: [Insipid] comments on draft-jones-insipid-session-id-01
> 

I believe was are in agreement. What I am suggesting is as follows:
Request from Alice through intermediary to Bob.
- Intermediary creates and inserts in request on behalf of Alice if not there.
Response from Bob through intermediary to Alice.
- Intermediary creates and inserts in response on behalf of Bob if not there

The next question is what should the intermediary do if the uuid in the request is not included in the response from Bob (i.e. it contains Bob's uuid but is missing Alice's for some reason, perhaps it was dropped by some other intermediary). I do not see harm in the intermediary re-inserting Alice's uuid, so I think it should add it back.

Cheers,
Charles

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 4 Nov 2012 15:06:45 -0500

> - Intermediary creates and inserts in response on behalf of Bob if not there
I concur things should be like described above by Charles

> The next question is what should the intermediary do if the uuid in the request is not included in the response from Bob (i.e. it contains Bob's uuid but is missing Alice's for some reason, perhaps…
that is a good question, I don't see any harm neither, but I need to to 
think more about it

/Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: James Polk <[email-masked]>
Date: Sun, 04 Nov 2012 23:22:22 -0600

>>- Intermediary creates and inserts in response on behalf of Bob if not there

what if there where multiple intermediaries between Alice and Bob... 
which one gets to decide it inserts? Does it have to be the first SID 
aware server?

>>The next question is what should the intermediary do if the uuid in 
>>the request is not included in the response from Bob (i.e. it 
>>contains Bob's uuid but is missing Alice's for some reason,

this is actually something we looked at in Section 11 in the 
backwards compatibility section when a version 0 UA talks to a 
version 1 UA and the Session-ID changed places. No one is sure what 
the answer is yet.

>>perhaps it was dropped by some other intermediary).

well, that intermediary is broken and should be taken out of service  ;-)

James

>>I do not see harm in the intermediary re-inserting Alice's uuid, so 
>>I think it should add it back.
>that is a good question, I don't see any harm neither, but I need to 
>to think more about it
>
>/Salvatore
>
>--
>Salvatore Loreto, PhD
>www.sloreto.com
>

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 5 Nov 2012 05:10:42 -0500

On 11/5/12 12:22 AM, James Polk wrote:
>>>>>> Salvatore already raised most of the comments I had in mind, but 
>>>>>> I have
>>>> the

yep, the first who is Session Id aware !
but this is more a deployment question then a protocol one, I guess.

/Salvatore

> this is actually something we looked at in Section 11 in the backwards 
> compatibility section when a version 0 UA talks to a version 1 UA and 
> the Session-ID changed places. No one is sure what the answer is yet.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Nov 2012 08:31:54 -0500

> which one gets to decide it inserts? Does it have to be the first SID

To do the insertion, the intermediary needs to be session-id aware, but 
it also must be dialog stateful, so that it can continue to insert the 
id in all the messages of the dialog(s). So this will need to be a B2BUA 
or a record-routing proxy.

(It only needs to be transaction stateful if the insertion is into an 
out-of-dialog transaction that is not dialog establishing.)

	Thanks,
	Paul

---

From: James Polk <[email-masked]>
Date: Mon, 05 Nov 2012 09:27:58 -0600

At 07:31 AM 11/5/2012, Paul Kyzivat wrote:
>To do the insertion, the intermediary needs to be session-id aware, 
>but it also must be dialog stateful, so that it can continue to 
>insert the id in all the messages of the dialog(s). So this will 
>need to be a B2BUA or a record-routing proxy.
>
>(It only needs to be transaction stateful if the insertion is into 
>an out-of-dialog transaction that is not dialog establishing.)

it's the continuous reinsertion issue I was thinking of, and want the 
WG to be aware of. This point is in the slides for today. There is 
not text covering all of this in the draft yet.

James

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 5 Nov 2012 19:34:03 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of James Polk (jmpolk)
> Sent: Monday, November 05, 2012 12:22 AM
> To: Salvatore Loreto; [email-masked]
> >>>>>Salvatore already raised most of the comments I had in mind, but I
> have
> >>>the
> >>>>>http://www.ietf.org/mail-
> archive/web/insipid/current/msg00402.html
> >>>>>

Yes, the first SID aware intermediary would insert it. Any intermediaries later in the path will see this uuid and therefore NOT need to insert one.
 
> well, that intermediary is broken and should be taken out of service  ;-)

Yes, but that is not an option for the properly functioning intermediary encountering this situation.
Forced removal of one intermediary by another is covered in another draft :)

Cheers,
Charles