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

[Brett Tate <[e-mail]>]

Hi,

Thanks for the response; reply is inline.

> OK, how about these as the first two paragraphs?

<snip>

> Note I changed a MAY in your document to "might".  I don't
> want to suggest that it's permissible, but noting that it
> might happen is acceptable.

If it is not permissible, then intermediaries which generate (instead of
only relay) requests and responses must track the Session-ID.  You can
remove my suggested paragraph since I only proposed it because you indicated
"We do not want intermediaries really getting involved in the exchange of
UUID values".

Consider the following race condition where the UPDATEs cross between A and
the proxy.  If the proxy generates a 407, SHOULD/MUST it indicate {C,A},
{B,A}, or something else?  What draft snippet supports your answer?

A   proxy

-->  UPDATE {A,B}
<-- UPDATE {C,A}
<-- 407 {?,A}

Do you think intermediaries which generate (instead of relay) requests such
as BYE SHOULD/MAY/MUST track the Session-ID UUIDs so that the BYE could
contain the same UUIDs within the Session-ID?  If so, where is it mentioned
within the draft.


> >>  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?
>
> That's in Section 7.  Just to avoid mismatch in paragraph count, the
> text is:
>
> ====
> When an intermediary transmits a provisional response or a response to a
> CANCEL request, the “remote-uuid” field will contain the UUID value of
> the UA that sent the message that prompted the transmission of the
> response. When the UUID of the destination UA for the message that
> prompted the transmission of the response is known, the intermediary
> MUST insert the UUID of the destination UA in the “local-uuid” field of
> the response. Otherwise, the intermediary MAY set the “local-uuid” field
> of the response to a locally generated UUID value or the null UUID
> value.
> ====
>
> Note that the bit about CANCEL is new and added per our discussion.  The
> word "provisional" was removed from the original text, also, to account
> for the CANCEL response.

Same comment as last time, I don't think that it is adequate.  It looks like
the paragraph only applies to CANCEL responses and provisional responses.
What about all of the other requests and responses that an intermediate can
originate?


> The section in intermediaries started out by limiting when they were
> allowed to touch messages.  The intent was to strictly reduce
> opportunity to do damage, while being mindful that some will.

Damage?  Because of all the potential race conditions, the draft provides no
means to ensure that an endpoint knows the correct remote-uuid.

If A receives the following at about the same time, does A "know" that the
remote-uuid is B or C?  A can only assume that they were sent in the order
received.

200 response with {B,A}
UPDATE with {C,A}


> The one piece of text that is missing is a statement that says something
> like this as a final paragraph in section 7:
>
> ====
> Having said the foregoing, intermediaries that manipulate messages
> containing Session-ID header values should be aware of what values were
> last received by an endpoint and, following any kind of service
> interaction initiated or affected by the intermediary, of what values
> the receiving endpoint should have knowledge to ensure that both
> endpoints in the session have the correct and same values.  If an
> intermediary can determine that an endpoint might not have received a
> current, correct Session-ID header value, the Intermediary SHOULD
> attempt to provide the correct Session-ID header value to the endpoint
> such as by sending a re-INVITE message.
> ====
>
> How does that sound?

I guess that you changed your mind about if an intermediary should ever send
a request solely to update the Session-ID.