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

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

Paul,

>>That would be true of intermediaries like PBXes that are switching 
>>calls
>>from one leg to another. It's only in situations where the 
>>intermediary
>>is going to do something that causes endpoints to have the wrong value
>>that they need to ensure they convey the right value. If the SBC is 
>>not
>>in the business of switching call legs from one device to another like 
>>a
>>PBX does, it would not have to maintain this state at all.
>
>I think *most* B2BUAs will sometimes need to originate messages. E.g.,
>- send a BYE to terminate a session by policy
>- send a session timer refresh.
>
>Any B2BUA that will ever originate a message needs to maintain this 
>state.
>

Fair point, though this is not really altering a value -- which is what 
most of Section 7 deals with.  In this case, it would be just using 
known values to initiate messages.

But, I don't think we speak about that.  Want to suggest a blurb to say?

Maybe some "Finally, " text at the end (after that "Having said the 
foregoing," paragraph I proposed to Brett) like this:

====
Finally, intermediaries compliant with this specification that initiate 
messages not in response to having received a message from a remote 
endpoint, such as sending a BYE to terminate a dialog, MUST ensure that 
the proper Session-ID value is conveyed in that message.  If the UUID of 
the remote endpoint is known, that value MUST be used as the 
"local-uuid" value of the transmitted message.  If the UUID of the 
remote endpoint is unknown, then the intermediary MUST use either the 
null UUID (preferred) or fabricate a UUID to populate the "local-uuid" 
field.  Likewise, if the UUID of the receiving endpoint is known, that 
value must be included in the "remote-uuid" field.  If the UUID of the 
receiving endpoint is unknown, the "remote-uuid" field must be set to 
null UUID.
====

Thoughts?

Paul