IETF Logo Mail Archive

[sipcore] Input requested on how to proceed with the essential corrections to RFC 3261

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Thu, 25 June 2009 06:12 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A01D3A68A1 for <sipcore@core3.amsl.com>; Wed, 24 Jun 2009 23:12:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYahk55Rc9h3 for <sipcore@core3.amsl.com>; Wed, 24 Jun 2009 23:12:21 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D479B3A67A1 for <sipcore@ietf.org>; Wed, 24 Jun 2009 23:12:20 -0700 (PDT)
X-AuditID: c1b4fb3c-b7bdcae0000052f9-34-4a43115dc071
Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 7B.C4.21241.D51134A4; Thu, 25 Jun 2009 07:55:41 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jun 2009 07:55:40 +0200
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jun 2009 07:55:40 +0200
Received: from [131.160.126.143] (rvi2-126-143.lmf.ericsson.se [131.160.126.143]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7CB34245E; Thu, 25 Jun 2009 08:55:40 +0300 (EEST)
Message-ID: <4A43115C.7040902@ericsson.com>
Date: Thu, 25 Jun 2009 08:55:40 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: SIPCORE <sipcore@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Jun 2009 05:55:40.0576 (UTC) FILETIME=[91EAFA00:01C9F559]
X-Brightmail-Tracker: AAAAAA==
Subject: [sipcore] Input requested on how to proceed with the essential corrections to RFC 3261
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 25 Jun 2009 06:12:23 -0000

Folks,

as you can see in our charter, we have the following milestone:

Sep 2009 - Essential corrections to RFC 3261 (1st batch) to IESG (PS)

The reason why the milestone talks about the "first batch" can be found 
in the following draft:

http://tools.ietf.org/html/draft-drage-sip-essential-correction-03

The draft above talks about RFCs that are updated by tens of RFCs. The 
draft claims that having a lot of RFCs updating a given RFC would be 
confusing for implementers. At the time of writing the draft above, 
there was a belief that RFC 3261 was going to be an example of an RFC 
updated by tens of RFCs. The idea in the draft is that instead of 
issuing a number of RFCs updating the original one, the WG would put all 
those updates together into a batch and publish the batch as a single RFC.

Analyzing the current situation, RFC 3261 has already been updated by 
the following RFCs: 3265, 3853, 4320, 4916, 5393

Additionally, there are a few drafts that will, if approved, update RFC 
3261 as well:

Draft already with the IESG:
http://tools.ietf.org/html/draft-ietf-sip-body-handling-06

Draft that could be included in the essential corrections process when 
their contents are approved:
http://tools.ietf.org/html/draft-ietf-sip-ipv6-abnf-fix-03
http://tools.ietf.org/html/draft-sparks-sip-invfix-03
http://tools.ietf.org/html/draft-camarillo-sipping-reinvite-00

It turns out that the total number of RFCs updating RFC 3261 has not 
grown as much as expected. The number of RFCs documenting essential 
corrections (a subset of all the RFCs updating RFC 3261) is also lower 
than expected. (From Section 3 of the essential corrections draft, an 
essential change is one where in the absence of the correction, it will 
not be possible to implement the specification contained in the original 
RFC in a manner to ensure interoperability or correct operation.)

The general decision we have to make at this point, given the small 
number of drafts documenting essential corrections, is whether we want 
to document essential corrections in batches, per the essential 
corrections process, or in individual drafts, as it has been done in the 
past.

The concrete decision we have to make is whether it makes sense to merge 
the following drafts in a batch, per the essential corrections process, 
or whether we advance these drafts independently.

http://tools.ietf.org/html/draft-ietf-sip-ipv6-abnf-fix-03
http://tools.ietf.org/html/draft-sparks-sip-invfix-03
http://tools.ietf.org/html/draft-camarillo-sipping-reinvite-00

We would appreciate the feedback of the WG on this issue so that we can 
make progress updating RFC 3261.

Thanks,

Gonzalo
SIPCORE co-chair

v2.23.0 | Report a Bug | By Email