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

Paul Kyzivat <> Fri, 30 January 2015 16:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3B4C31A1B14 for <>; Fri, 30 Jan 2015 08:47:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fBuCejLlf1Rm for <>; Fri, 30 Jan 2015 08:47:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DA1311A1BF1 for <>; Fri, 30 Jan 2015 08:46:59 -0800 (PST)
X-AuditID: 1207440e-f79bc6d000000c43-f3-54cbb5831947
Received: from (OUTGOING-ALUM.MIT.EDU []) by (Symantec Messaging Gateway) with SMTP id 21.D9.03139.385BBC45; Fri, 30 Jan 2015 11:46:59 -0500 (EST)
Received: from Paul-Kyzivats-MacBook-Pro.local ( []) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t0UGkwcI008432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 30 Jan 2015 11:46:58 -0500
Message-ID: <>
Date: Fri, 30 Jan 2015 11:46:58 -0500
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Paul E. Jones" <>,
References: <em6756914a-d169-45b6-94a0-374745d54029@sydney>
In-Reply-To: <em6756914a-d169-45b6-94a0-374745d54029@sydney>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixO6iqNu89XSIwd3/Ahbz7z9jsjh/YQOT A5PHkiU/mTwa9h1lD2CK4rZJSiwpC85Mz9O3S+DO+PtxI0vBE42KD2s2szcw3pXvYuTkkBAw kVjw7z8rhC0mceHeerYuRi4OIYHLjBKPju5kAkkICTxnkmi9bgxi8wpoS7xZDdHAIqAq0fhi CguIzSagJTHn0H8wW1QgWWLN1knsEPWCEidnPgGLiwjYShyccwWsV1jAXOLulsXMEPOtJVa8 fAS2i1PARmLnmrmMIDazgJlE19YuKFteonnrbOYJjPyzkIydhaRsFpKyBYzMqxjlEnNKc3Vz EzNzilOTdYuTE/PyUot0jfVyM0v0UlNKNzFCQpJvB2P7eplDjAIcjEo8vB6PT4UIsSaWFVfm HmKU5GBSEuWdvPZ0iBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3imTgHK8KYmVValF+TApaQ4W JXFetSXqfkIC6YklqdmpqQWpRTBZGQ4OJQneni1AjYJFqempFWmZOSUIaSYOTpDhXFIixal5 KalFiaUlGfGgiIwvBsYkSIoHaG8KSDtvcUFiLlAUovUUo6KUOG81SEIAJJFRmgc3FpZoXjGK A30pzDsTpIoHmKTgul8BDWYCGhy4+ATI4JJEhJRUA2PDk60p4od6dNafiJEt/LjvDnNVdWgV j9ct1oybqWy9TXGLEy2nND2ZeYfr7DmZCQ+DMle4OkTPmLm8TC12tedf1j83HLxvizE1/J8y Nec1q2RHboSD0oTs2/p5j3iVu8V/TX2/7N6ClkMS58Jvt0w+lbLn1uPndi0dTJJvzTS6+Cc+ 27P1QqsSS3FGoqEWc1FxIgBlqmOsDwMAAA==
Archived-At: <>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-13
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Jan 2015 16:47:06 -0000

On 1/30/15 2:16 AM, Paul E. Jones wrote:
> 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.

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.

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

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

I did that in order to make room for the exceptions. But I guess either 
way works.

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

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.

	Paul K