Re: [Insipid] draft-ietf-insipid-session-id-13

[Paul Kyzivat <[e-mail]>]

On 1/30/15 2:16 AM, Paul E. Jones wrote:
> Paul,
>
>> OK. I'm now reviewing -13 somewhat carefully.
>
> Appreciate it!
>
>
>>
>> Regarding the new text in section 5:
>>
>>    The Session-ID header-value is technically case-INSENSITIVE, but only
>>    lowercase characters are allowed in the sess-uuid components.
>>    Receiving entities MUST treat sess-uuid components as case-
>>    insensitive and not produce an error if an uppercase character is
>>    received in a sess-uuid.
>>
>> That can be interpreted to mean that an error should not be reported
>> if the uuid contains a "Z". I suggest a tweak to that:
>>
>>    Receiving entities MUST treat sess-uuid components as case-
>>    insensitive and not produce an error if an uppercase HEXDIG
>>    character is received in a sess-uuid.
>
> Good.  Changed.
>
>
>>
>> Now that the intent has been specified, the actual syntax needs to
>> match. It currently doesn't. Currently we have:
>>
>>      sess-uuid = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f]
>>
>> which isn't consistent with the new statement. Instead, now about:
>>
>>      sess-uuid = 32(HEXDIG)
>>
>> And then replace "The production DIGIT is defined in [RFC5234]" with
>> "The production HEXDIG is defined in [RFC5234]".
>
> HEXDIG is defined only using uppercase characters.  I fear that might
> introduce more confusion.

HEXDIG is defined using quoted uppercase characters. But quoted strings 
are defined in ABNF to be matched in a case insensitive way. So HEXDIG 
matches any of ABCDEFabcdeg.

> How about I just write this:
>
> "not produce an error if an uppercase hexadecimal character is received"
>
> And then leave the syntax alone.

That is confusing because the text is expanding the valid syntax from 
what is written.

>> Also in section 5:
>>
>>    The "local-uuid" in the Session-ID header represents the UUID value
>>    of the UA transmitting the message. If the UA transmitting the
>>    message previously received a UUID value from its peer endpoint, it
>>    MUST include that UUID as the "remote" parameter in each message it
>>    transmits. For example, a Session-ID header might appear like this:
>>
>> This doesn't mention the possibility that *different* remote-uuids are
>> received over the course of the session. I suggest:
>>
>>    The "local-uuid" in the Session-ID header represents the UUID value
>>    of the UA transmitting the message. If the UA transmitting the
>>    message previously received one or more UUID values from its peer
>>    endpoint in a session, it SHOULD include the most recently received
>>    UUID as the "remote" parameter in each message it transmits within
>>    that session. (Exceptions are explicitly called out elsewhere in this
>>    document.) For example, a Session-ID header might appear like
>>    this:
>
> Everything sounds good, except the change from MUST to SHOULD?  Do we
> really want to do that?

I did that in order to make room for the exceptions. But I guess either 
way works.

>> Section 7:
>>
>> The term "3PCC" is used without definition. Should include a
>> definition and a reference to RFC3725.
>
> Sure.  Done.
>
>
>>
>> Section 8:
>>
>> Here and elsewhere are references to "cascaded MCUs". Neither "MCU"
>> nor "cascaded MCU" are defined. I don't know where you go for those
>> definitions. (There is a definition of MCU in
>> draft-ietf-avtext-rtp-grouping-taxonomy, but it focuses on media and
>> isn't sip-specific.)
>
> I don't know where this is defined, either, though there are many
> documents that discuss cascaded MCUs (e.g., ITU-T F.702).  Let me see if
> I can find a definition we can reference.
>
>
>
>>
>> Also, s/When creating a cascaded conferencing/When creating a cascaded
>> conference/
>
> Fixed that.
>
>
>>
>> Section 9.3:
>>
>> It would be very helpful to see subsequent signaling in this case.
>> Suppose Alice subsequently sends a reINVITE. What will that look like?
>> (Alice will send it with {A,B}. Does the B2BUA change it to {A,C} or
>> leave it alone? Either way I presume Carol sends back {A,C}.)
>
> OK.  Done.
>
> That would be:
>
>                  | (Suppose Alice modifies the session)            |
>       {A,B}      |--------------------re-INVITE------------------->|
>       {C,A}      |<--------------------200 OK----------------------|
>       {A,C}      |-----------------------ACK---------------------->|
>
> The text description to go with that is:
>
> "Since Alice never received Carol’s UUID from the B2BUA, when Alice
> later attempts to modify the session with a re-INVITE, Alice would send
> the “remote-uuid” = “B” toward Carol.  Carol replies with the
> “local-uuid” = “A”, “remote-uuid” = “A” to reflect what was received in
> the INVITE (which Carol already knew from previous exchanges with the
> B2BUA).  Alice then include “remote-uuid” = “C” in the following ACK
> message."
>
> Sound OK?

You left the B2BUA out of this. IIUC it is still in the signaling path 
between Alice and Carol. So it is important to show what it does in this 
case too.

	Thanks,
	Paul K