Re: [sipcore] [Editorial Errata Reported] RFC3261 (3237)

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 31 May 2012 15:36 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFE011E8108 for <sipcore@ietfa.amsl.com>; Thu, 31 May 2012 08:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7QsT5n+8QVF for <sipcore@ietfa.amsl.com>; Thu, 31 May 2012 08:36:43 -0700 (PDT)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id D5C0A11E8102 for <sipcore@ietf.org>; Thu, 31 May 2012 08:36:42 -0700 (PDT)
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta13.westchester.pa.mail.comcast.net with comcast id GeCx1j0051GhbT85DfciF4; Thu, 31 May 2012 15:36:42 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta07.westchester.pa.mail.comcast.net with comcast id Gfci1j00907duvL3Tfci5F; Thu, 31 May 2012 15:36:42 +0000
Message-ID: <4FC79009.5020203@alum.mit.edu>
Date: Thu, 31 May 2012 11:36:41 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: sipcore@ietf.org
References: <20120531125741.4B83D621A3@rfc-editor.org> <4FC783D0.4070505@nostrum.com>
In-Reply-To: <4FC783D0.4070505@nostrum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [sipcore] [Editorial Errata Reported] RFC3261 (3237)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 May 2012 15:36:43 -0000

Commenting on the errata itself...

> On 5/31/12 7:57 AM, RFC Errata System wrote:
>> The following errata report has been submitted for RFC3261,
>> "SIP: Session Initiation Protocol".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=3237
>>
>> --------------------------------------
>> Type: Editorial
>> Reported by: Kevin P. Fleming<kpfleming@digium.com>
>>
>> Section: 8.1.3.5
>>
>> Original Text
>> -------------
>> In all of the above cases, the request is retried by creating a new
>> request with the appropriate modifications. This new request
>> constitutes a new transaction and SHOULD have the same value of the
>> Call-ID, To, and From of the previous request, but the CSeq should
>> contain a new sequence number that is one higher than the previous.
>>
>> Corrected Text
>> --------------
>> In all of the above cases, the request is retried by creating a new
>> request with the appropriate modifications. This new request
>> constitutes a new transaction and SHOULD have the same value of the
>> Call-ID, To, and From of the previous request, but the CSeq SHOULD
>> contain a new sequence number that is one higher than the previous.
>>
>> Notes
>> -----
>> We have had one implementor claim that they are not required to
>> increment CSeq when retrying the request because the RFC says 'should'
>> and not 'SHOULD'. Based on current IETF discussions, though, these
>> should probably be changed to MUST anyway, but that's a much more
>> substantive change throughout the whole RFC.

Because the retry is a new request, it is governed by all the normative 
requirements that apply to a new request. So the normative statements 
elsewhere about the CSeq value apply in this case.

For the retry of some arbitrary operation (e.g. OPTIONS) outside of a 
dialog there aren't any requirements other than that it be less than 
2^31. So indeed you could use the same CSeq value if you wished.

But if it was a REGISTER, then section 10.2 says the CSeq must be 
incremented by one. And if the request is within a dialog, then section 
12.2.1.1 also says the CSeq value must be incremented by one.

The lack of a normative statement *here* doesn't grant license to 
violate those rules.

So I don't see any error to be corrected.

	Thanks,
	Paul