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

[Brett Tate <[e-mail]>]

Hi,

Thanks for the response; reply is inline.

> >A B2BUA can generate requests and responses on behalf of
> >both sides. In my opinion, section 7 covers some individual
> >situations; however, it appears to be missing the general
> >case of tracking remote/local UUIDs and then using the UUIDs
> >when generating (instead of relaying) subsequent requests
> >and responses associated with the "session".
>
> This is largely purposeful.  We do not want intermediaries
> really getting involved in the exchange of UUID values.

Sounds great to me.  If that is really true, add something like the
following paragraph to section 7.

"Intermediaries MAY track the Session Identifier values associated with a
transaction and dialog.  However since it is NOT REQUIRED (and because of
other reasons), they MAY provide inaccurate Session-ID values when
generating related requests and responses."


> If an intermediary is responding on behalf of an endpoint,
> then what the text currently says that "if it knows" the
> UUID value of the opposite endpoint, includes it.  Otherwise,
> it either uses the NULL value or fabricates a value.

What section and paragraph says that?


> In what way would you like to see the text re-worded, keeping
> in mind that we want B2BUAs to take a hands-off approach as
> much as possible.

Sounds great to me.  If the draft is clear about that (such as by adding the
mentioned paragraph), I'll quit being concerned about the race conditions,
CANCEL, et cetera which will make it impossible (when mid-dialog Session-ID
changes occur) for intermediaries to know the correct Session-ID values for
use when subsequently generating (instead of relaying) requests and
responses.  Endpoints have the ambiguity issue; however at least one of the
UUIDs would be accurate.