Re: [Insipid] draft-ietf-insipid-session-id-12: comments

["Paul E. Jones" <[e-mail]>]

Brett,

>Copyright: Replace 2014 with 2015.

Done.

>Section 7 paragraph 6: Remove the extra period. Potentially should 
>reword
>the sentence to avoid it sounding like the request constructs the
>Session-ID.

How about this?
"The Session-ID included in a CANCEL request MUST be identical to the 
Session-ID included in the corresponding INVITE."


>Section 9.1 F2, F3, and F5: Since UDP is the default transport, you 
>might
>want to change the top Via's transport to be UDP within F2, F3, and F5.

Unless there is a good reason to change these, I'd prefer to leave them. 
  UDP is still widely used, but TLS is also extremely common.  It's 
important that we don't have an error here, of course.  Any errors or 
just a preference for UDP.



>Section 9.1 F3: The Route should be removed; Record-Route URI must be
>within <>.

Oh, Word... you have to love that auto-correct.  I didn't even notice it 
did that it removed the <>.


>
>Section 9.1 F5: The Route URI must be within <>.

Fixed.


>
>Section 10 bullets 2 and 6: Bullet 2 isn't necessarily true since it 
>can
>occur within dialog after bullet 6.

This is just a statement of fact, no?  Shouldn't we keep it just to be 
clear and set a firm foundation?  And 6 is about the response, whereas 2 
is about the request.


>However it raises some questions
>concerning how the B2BUA should behave when swapping a connected party
>over the same dialog. For instance when the new endpoint and replaced
>endpoint support different versions of Session-ID, does the B2BUA 
>blindly
>relay the new Session-ID (towards the remaining endpoint which supports
>draft or only RFC 7329) or does it somehow apply section 10 rules? For
>instance consider RFC 3725 figure 13 where pre-paid user supports RFC
>7329; called party supports draft and is actually the calling party; 
>and
>media server supports draft. Message 6 could look like pre-paid user
>supports draft; thus message 8 will contain a new Session-ID unless the
>B2BUA is supposed to somehow apply section 10 to remedy the situation.

What we really want to encourage in this draft is that the B2BUA not try 
to be "smart" and try to "fix" a problem.  What the B2BUA should do is 
merely forward to each endpoint the value used by the opposite endpoint.

You are correct in identifying a potential problem, though.  If two 
older endpoints were exchanging messages and somehow that older endpoint 
started talking with a newer endpoint, the newer endpoint might send 
over "SessionID= a; remote=b" and the older endpoint sends over 
"Session-ID: x".   As each of these endpoints receives a message with 
some unexpected value, what happens?  Well, we never got a clear answer 
on that.  We have a statement in the draft that says that compatibility 
is not ensured due to unknowns.  We do not know if the older endpoint 
will start echoing the new value or will keep using its old value.

I don't think there is really much we can do to try to cover every 
corner case, but I'm happy to add something if we know there is a 
fixable case.

Paul