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

[Paul Kyzivat <[e-mail]>]

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

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.

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

Thanks.

	Paul K