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

"Paul E. Jones" <> Wed, 04 February 2015 23:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8B2861A0076 for <>; Wed, 4 Feb 2015 15:33:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.688
X-Spam-Status: No, score=0.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UfV0iZmGhMke for <>; Wed, 4 Feb 2015 15:33:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9B4351A002F for <>; Wed, 4 Feb 2015 15:33:12 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.9/8.14.9) with ESMTP id t14NXAQI010369 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Feb 2015 18:33:10 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dublin; t=1423092790; bh=NngkAh/XXYiItAWBq945yL61KJdYvh/bYVoc8/5W7aE=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=LWeDMyP/omhKERbuzpbqkOK5/vpEQ67TZU71xXkxfk8tYJjsNHS7wH6qH+C5V0QQt H0yI5UzyL5zSdqXAaRG7vuNana6nJ4pIrkpLcqqWEQGfvsNuhFEIkA4ifMG7J2Yq/4 mruTl00XS9ot45lHZy5iaSl7+W1NZ5vYNrUvki1M=
From: "Paul E. Jones" <>
To: Paul Kyzivat <>,
Date: Wed, 04 Feb 2015 23:33:14 +0000
Message-Id: <emd4a55ee2-ae35-47ef-947f-e10adeed46e6@sydney>
In-Reply-To: <>
User-Agent: eM_Client/6.0.21372.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-13
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "Paul E. Jones" <>
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Feb 2015 23:33:18 -0000


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

    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 
>>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 
>>>(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 
>>the “remote-uuid” = “B” toward Carol. Carol replies with the
>>“local-uuid” = “A”, “remote-uuid” = “A” to reflect what was received 
>>the INVITE (which Carol already knew from previous exchanges with the
>>B2BUA). Alice then include “remote-uuid” = “C” in the following ACK
>>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:

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