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

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

Paul,

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

But, this is not an ABNF string.  It's a string of characters.  Per the 
ABNF spec:

       To specify a rule that is case sensitive, specify the characters
       individually.

    For example:

          rulename    =  %d97 %d98 %d99

And that's effectively what we have here since sess-uuid specifies 
characters individually.  I think. :)  In any case, if this would 
confuse me, this will confuse somebody else.  I think it's best not to 
go down this path.


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

I don't understand your point.  Here is the full sentence:
"Receiving entities MUST treat sess-uuid components as case-insensitive 
and not produce an error if an uppercase hexadecimal character is 
received in a sess-uuid."

It's entirely about the hexadecimal characters defined in sess-uuid.  In 
what was is this expanding the valid syntax?


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

Darn it.  I did have the B2BUA in my document.  Here's what I have:


    Session-ID
       ---     Alice            B2BUA             Bob            Carol
                 |                |                |               |
                                           ~~~
                 |                |                |               |
                 | (Suppose Alice modifies the session)            |
      {A,B}      |---re-INVITE--->|                |               |
      {A,B}      |                |---re-INVITE------------------->|
      {C,A}      |                |<---200 OK----------------------|
      {C,A}      |<---200 OK------|                |               |
      {A,C}      |------ACK------>|                |               |
      {A,C}      |                |------ACK---------------------->|
                 |                |                |               |

Paul