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

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

Brett,

>>  >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.
>
>I was just highlighting that the bullet 2 is only potentially true 
>since the
>RFC 7329 device may send requests with the same exact Session-ID that 
>the
>draft compliant device sent within an originating INVITE. Bullet 6 is
>potentially adequate to help ensure that a draft compliant device won't
>think that the remote party has become draft compliant mid dialog 
>because of
>bullet 2.

OK, I see your point now.  However, bullet 6 doesn't cover that initial 
INVITE.  When Bob receives that initial INVITE message, Bob needs to 
know whether it's a 7329 or a newer device.  It needs to know how to 
respond.  However, between bullet 3 and 6, I think you're right that it 
might be redundant.  Still, I think it's best to leave it here.  That 
way nobody has to read between the lines.

However, we really don't know if the 7329 device will ever send a 
request with the exact same Session-ID as was originally sent by an 
endpoint or not. It might echo the Session-ID exactly as it was 
received, or it might remove the "remote" parameter.  Behavior of 
devices in the wild is not entirely known.  So, you might be right.  We 
just don't know and, therefore, can't guarantee this is always correct.


>Concerning my adjusted RFC 3725 figure 13 example, there is currently
>nothing to help the media server from incorrectly thinking that the 
>remote
>device is draft compliant since hit bullet 2. A fix could be introduced 
>by
>allowing the B2BUA to indicate the non-compliance (by header or 
>parameter)
>to the media server. However, introducing extra signaling complexity to
>avoid the misinterpretation is potentially not worth it.

Yeah, I can see this being a battle for a while. It will introduce more 
complexity that folks will not like.

The B2BUA should know what kind of endpoint it's dealing with usually, 
though.  I think this can be handled by implementations.  Still, if it 
connects A (new) and B (old), A and B might be stubborn about switching 
behavior.  We could give guidance about that (e.g., B2BUA modify the 
Session-ID), but that guidance would very much go against what we're 
arguing for in the document of taking a hands-off approach.  A  smart 
newer endpoint should also figure this out, too.  It's either going to 
get what looks like a proper reply or one of the following:
1) An echo of what it sends in its next message
2) A single UUID (indicating 7329 behavior)
3) A response with two unknown UUIDs.  More more message exchange with 
that entity will help to determine if it's new or old, as the old device 
will continue to operate as either (1) or (2).

Paul