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

Paul Kyzivat <> Tue, 27 January 2015 22:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EA7181A9081 for <>; Tue, 27 Jan 2015 14:25:28 -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 mMzpcnjnxz9Y for <>; Tue, 27 Jan 2015 14:25:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4D32E1A902E for <>; Tue, 27 Jan 2015 14:25:23 -0800 (PST)
X-AuditID: 12074413-f79f26d0000030e7-5d-54c81052169e
Received: from (OUTGOING-ALUM.MIT.EDU []) by (Symantec Messaging Gateway) with SMTP id D8.0C.12519.25018C45; Tue, 27 Jan 2015 17:25:22 -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 t0RMPMWo022208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <>; Tue, 27 Jan 2015 17:25:22 -0500
Message-ID: <>
Date: Tue, 27 Jan 2015 17:25:22 -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
References: <> <em45407f81-06bb-4442-871c-707554d1dd23@sydney> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIIsWRmVeSWpSXmKPExsUixO6iqBskcCLEYOs+U4v5958xOTB6LFny kymAMYrbJimxpCw4Mz1P3y6BO6N30zqmgmt6FffvtzA2MJ5X7mLk5JAQMJHYenY3K4QtJnHh 3nq2LkYuDiGBy4wSHx++hXL+MUlc3bODsYuRg4NXQFtiTn8GSAOLgKrE1dONbCA2m4CWxJxD /1lAbFGBZIk1Wyexg9i8AoISJ2c+AYuLCIhI/L47BSwuLGAucXfLYmaI+XcZJRZ+nAqW4BSI lTh0qIsdZBezgLXEt91FIGFmAXmJ7W/nME9g5J+FZOwshKpZSKoWMDKvYpRLzCnN1c1NzMwp Tk3WLU5OzMtLLdI118vNLNFLTSndxAgJPuEdjLtOyh1iFOBgVOLhjbh+LESINbGsuDL3EKMk B5OSKK/w/+MhQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4778DyvGmJFZWpRblw6SkOViUxHnV lqj7CQmkJ5akZqemFqQWwWRlODiUJHgL+E6ECAkWpaanVqRl5pQgpJk4OEGGc0mJFKfmpaQW JZaWZMSD4jG+GBiRICkeoL0TQNp5iwsSc4GiEK2nGBWlxHmngyQEQBIZpXlwY2Ep5RWjONCX wrybQap4gOkIrvsV0GAmoMF9K4+ADC5JREhJNTCyLsmbZtrTEGazbiOjPPdZ5Se6peX6bEtF drHPeVwUH3PvoM7KFwuXzrjDvGbj/OZneosahNfPW62hvezT+67FC1ezbahedUMmhsP0JNvM 42vzXj28NF83te3Pzo6TzIElLFryuo3H67jDjF6VnvZ/aJs97evGt9dMDWW0O0R2bNU8se38 kbIwJZbijERDLeai4kQAFta8fQQDAAA=
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: Tue, 27 Jan 2015 22:25:29 -0000

OK. I'm now reviewing -13 somewhat carefully.

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.

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

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

Section 7:

The term "3PCC" is used without definition. Should include a definition 
and a reference to RFC3725.

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

Also, s/When creating a cascaded conferencing/When creating a cascaded 

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


On 1/25/15 4:34 PM, DRAGE, Keith (Keith) wrote:
> So I guess I am looking for responses from Roland J., Paul K, and Brett
> T. as to whether we now have a version to go forward.
> regards
> Keith
>     ------------------------------------------------------------------------
>     *From:* Paul E. Jones []
>     *Sent:* 24 January 2015 19:55
>     *To:* DRAGE, Keith (Keith);
>     *Subject:* Re: [Insipid] draft-ietf-insipid-session-id-13
>     I think so, but I would like to get positive confirmation from others.
>     Paul
>     ------ Original Message ------
>     From: "DRAGE, Keith (Keith)" <
>     <>>
>     To: "Paul E. Jones" <
>     <>>; ""
>     < <>>
>     Sent: 1/24/2015 2:20:55 PM
>     Subject: Re: [Insipid] draft-ietf-insipid-session-id-13
>>     Apart from this one issue, does this represent closure of all
>>     issues that are currently being discussed?
>>     Keith
>>         ------------------------------------------------------------------------
>>         *From:* insipid [
>>         <>] *On Behalf Of *Paul E. Jones
>>         *Sent:* 24 January 2015 19:20
>>         *To:* Paul E. Jones; <>
>>         *Subject:* Re: [Insipid] draft-ietf-insipid-session-id-13
>>         Folks,
>>         I just noted an alignment problem in the figure in 9.8.1.
>>         I'll fix that in my local copy, but will hold off publishing
>>         another just for that small issue.
>>         Paul
>>         ------ Original Message ------
>>         From: "Paul E. Jones" <
>>         <>>
>>         To: " <>"
>>         < <>>
>>         Sent: 1/24/2015 2:12:42 PM
>>         Subject: [Insipid] draft-ietf-insipid-session-id-13
>>>         Folks,
>>>         I submitted draft -13 that contains all of the text changes
>>>         suggested thus far.  Please let me know if you see any issues
>>>         in that text.
>>>         I believe all (or at least most) of the WGLC comments have
>>>         been addressed.  If that's not the case, we can continue
>>>         discussion on the list of course.
>>>         The chairs have (for a while I might add) expressed a sense
>>>         of urgency to move this along.  So, please let the group (and
>>>         chairs) know if there are other things we need to address or
>>>         whether we can suggest to send this for publication?
>>>         Paul
> _______________________________________________
> insipid mailing list