Re: [Insipid] Reviews for INSIPID Session-ID solution draft Version 11

Paul Kyzivat <> Thu, 22 January 2015 14:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D34141A1B30 for <>; Thu, 22 Jan 2015 06:42:16 -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 lGdCttVTB7_g for <>; Thu, 22 Jan 2015 06:42:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 99A221ACCE5 for <>; Thu, 22 Jan 2015 06:42:11 -0800 (PST)
X-AuditID: 12074412-f79e46d0000036b4-0d-54c10c420850
Received: from (OUTGOING-ALUM.MIT.EDU []) by (Symantec Messaging Gateway) with SMTP id E7.32.14004.24C01C45; Thu, 22 Jan 2015 09:42:10 -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 t0MEg93s016512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <>; Thu, 22 Jan 2015 09:42:10 -0500
Message-ID: <>
Date: Thu, 22 Jan 2015 09:42:09 -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: <> <em66cbd059-35a2-4826-8bfe-76937b83cc82@sydney> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYndR1HXiORhi8HuXlcX8+8+YHBg9liz5 yRTAGMVtk5RYUhacmZ6nb5fAnbFv7zHmgk6+ijnXmxkbGOdwdzFycEgImEjsWMbcxcgJZIpJ XLi3nq2LkYtDSOAyo8Tmtl4o5x+TxO0bC9lBqngFtCVaLz5lA7FZBFQl7ry/CtbNJqAlMefQ fxYQW1QgWWLN1klQ9YISJ2c+AYuLCIhI/L47BSwuLBAoMf/3BqgFdxklZry/xw5yEadArMSc KdkgNcwCZhJdW7sYIWx5ie1v5zBPYOSfhWTsLCRls5CULWBkXsUol5hTmqubm5iZU5yarFuc nJiXl1qka6aXm1mil5pSuokREn5COxjXn5Q7xCjAwajEw5tRfCBEiDWxrLgy9xCjJAeTkijv /79AIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8q7gOhgjxpiRWVqUW5cOkpDlYlMR5fy5W9xMS SE8sSc1OTS1ILYLJ6nFwCHz5eO4To8ClN91fGaVY8vLzUpUkeOdxA40SLEpNT61Iy8wpQWhg 4uAEWcclJVKcmpeSWpRYWpIRD4ra+GJg3IKkeIAumQl2SXFBYi5QFKL1FKOilDjvYpC5AiCJ jNI8uLGwxPOKURzob2FeB5AqHmDSgut+BTSYCWhwwfYDIINLEhFSUg2MYd61G0rFnmtP/FYc fcPZpkD9MJdZ5/LnFunpGrbfA+cY+9xaUN9pvqbIy3rlu3unti+P5CjPOWX6Wvbdh/UebIsX MO65mT7fvD/wpu9aBV+NN8LqU3Yrrp6W5zlllp5I8sICHr9nzRqGdZGrOeftFEg9WLLIpWLP 8nmF/nvfTp0i6St7V1NEiaU4I9FQi7moOBEAmjfK+RcDAAA=
Archived-At: <>
Subject: Re: [Insipid] Reviews for INSIPID Session-ID solution draft Version 11
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: Thu, 22 Jan 2015 14:42:17 -0000

On 1/22/15 1:47 AM, wrote:

>>> Section 4.1 (and Section 5)
>>> Would it be worth to mention if the Session-id is case sensitive.
>>> Since when we will need to implement it we have to explicit state it if
>>> it is case sensitive or not.
>> Per RFC 3261, "field names are always case-insensitive". I don't think
>> that needs to be repeated here.
> [RJ] I looking here from Operator point of view. We have so many discussions about the case (in-) sensivity of fields with vendors who should know. I'm partly OK with your proposal. But nevertheless it will led to wrong implementations seen from my experience with vendors. And the point the following point will confuse a little. On one point we say UUID lower case but RFC3261 points that header filds are case insensitive. Thus I would at least prefer a note.
>>> I think it would be worth to mention that the UUID is case insensitive
>>> as defined in RFC 4122
>> The text currently states that the UUID characters are lower-case.  The
>> syntax also enforces this.  The RFC 4122 text is funny, because it says
>> "lower case characters and are case insensitive".  I don't know what
>> that means, except that "F" is not a valid character.  Rather than
>> create confusing language, I'd rather just leave the text as it is in
>> saying the characters are lowercase.
> [RJ] OK

The *safest* (belt and suspenders) way of dealing with this would be to 
require that senders always insert lower case, but require that 
receivers properly process either upper/lower case.

IMO it *should* always have been case-insensitive. IIRC the reason it 
isn't that way is because Kaplan was case sensitive and there are 
implementations in the wild that depend on it.