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

"Worley, Dale R (Dale)" <dworley@avaya.com> Thu, 31 May 2012 19:54 UTC

Return-Path: <dworley@avaya.com>
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 27BED11E8072 for <sipcore@ietfa.amsl.com>; Thu, 31 May 2012 12:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.297
X-Spam-Level:
X-Spam-Status: No, score=-102.297 tagged_above=-999 required=5 tests=[AWL=1.303, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 um7QayyhDTVh for <sipcore@ietfa.amsl.com>; Thu, 31 May 2012 12:54:19 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 673CB21F85CD for <sipcore@ietf.org>; Thu, 31 May 2012 12:54:19 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAJzLx0/GmAcF/2dsb2JhbABEtBWBB4IYAQEBAQIBEihECwIBCA0pEDIlAQEEEwgah2QFnBucVY93YAObCYoCgnw
X-IronPort-AV: E=Sophos;i="4.75,694,1330923600"; d="scan'208";a="350326163"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 31 May 2012 15:52:22 -0400
Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 May 2012 15:51:46 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 31 May 2012 15:54:15 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "sipcore@ietf.org" <sipcore@ietf.org>
Date: Thu, 31 May 2012 15:54:13 -0400
Thread-Topic: [sipcore] [Editorial Errata Reported] RFC3261 (3237)
Thread-Index: Ac0/PSr8fkXciFE5QPy4UjDngUG6+QAKQ6P1
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A0B33@DC-US1MBEX4.global.avaya.com>
References: <20120531125741.4B83D621A3@rfc-editor.org>, <4FC783D0.4070505@nostrum.com>
In-Reply-To: <4FC783D0.4070505@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 19:54:22 -0000

[With a lot of people in the Bcc list.]

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

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

Expanding on what Bret Tate reported, what is "should" about the
statement in 8.1.3.5 is that the new sequence number is *one* higher
than the previous sequence number.  Section 22.2 states that the new
sequence number MUST be *higher*.  Thus, this case is specified in the
same way as all "successor" messages, the CSeq MUST be higher and
SHOULD be 1 higher.

Dale