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

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

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.  How about I just write this:

"not produce an error if an uppercase hexadecimal character is received"

And then leave the syntax alone.


>
>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?


>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?

Paul