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

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 04 Feb 2015 23:33:14 +0000

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Feb 2015 12:29:02 -0500

On 2/4/15 6:33 PM, Paul E. Jones wrote:
>> 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.
>

My point is that I think the draft should state normatively that hex in 
either case should be valid when received, but that lower case hex MUST 
be sent.

If the ABNF only describes lower case hex, then those writing matching 
code probably won't match upper case.

But no matter what we do it will probably be implemented wrong.

I will not futher belabor this issue.

>>> "not produce an error if an uppercase hexadecimal character is received"
>>>
>>>> Suppose Alice subsequently sends a reINVITE. What will that look like?
>>> later attempts to modify the session with a re-INVITE, Alice would send
>>> “local-uuid” = “A”, “remote-uuid” = “A” to reflect what was received in

Thanks.

	Paul K