Re: [Sip] [sipcore] [Technical Errata Reported] RFC3261 (2910)

"Worley, Dale R (Dale)" <dworley@avaya.com> Sun, 07 August 2011 01:31 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: sip@ietfa.amsl.com
Delivered-To: sip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6764A21F86B9; Sat, 6 Aug 2011 18:31:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.463
X-Spam-Level:
X-Spam-Status: No, score=-103.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 1+FjadiTrMbX; Sat, 6 Aug 2011 18:31:25 -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 D0CB621F861A; Sat, 6 Aug 2011 18:31:21 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqkIAADqPU6HCzI1/2dsb2JhbABCnAaLZHeBQAEBAQECAQECDygxDgULAgEIDQghECEHCiUBAQQBDQUIGodLoR4Cml+FZ18EkHSHNIRIhxY
X-IronPort-AV: E=Sophos;i="4.67,330,1309752000"; d="scan'208";a="296030204"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Aug 2011 21:31:41 -0400
Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Aug 2011 21:23:49 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Sat, 6 Aug 2011 21:31:41 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Samir Srivastava <samirs.lists@gmail.com>, Romel Khan <romel.khan@idt.net>
Date: Sat, 06 Aug 2011 21:31:40 -0400
Thread-Topic: [Sip] [sipcore] [Technical Errata Reported] RFC3261 (2910)
Thread-Index: AcxTJnZvGdfReHLySCa4E0AQQAYa8wBembTs
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B222B1F57E2@DC-US1MBEX4.global.avaya.com>
References: <20110802145359.C9DEE98C50D@rfc-editor.org> <DC49588FF3643F43B3A2A8F6F0A625F0284638642A@mailbox1.acmepacket.com> <69373B11-F46D-4F88-B4A8-BF56A8EC2624@nostrum.com> <CALiegf=1=ZqEcs0kE=Y+ykrcd9miPDSN=mzP99-EWytVXdXMwA@mail.gmail.com> <9B06B312-4BCF-499D-979F-33D8E70DAD5A@nostrum.com> <CAFQP3_afcp=COozZqB+g39LU3XVtYi-tSrxCuyZkOLWbNVasfw@mail.gmail.com>, <CAK+Spiwx+zJb=ccc0aL1bLVb6faSVCQcOYKJsHz_jnHUpmDnVQ@mail.gmail.com>
In-Reply-To: <CAK+Spiwx+zJb=ccc0aL1bLVb6faSVCQcOYKJsHz_jnHUpmDnVQ@mail.gmail.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
Cc: "sip@ietf.org List" <sip@ietf.org>, "SIPCORE (Session Initiation Protocol Core) WG" <sipcore@ietf.org>
Subject: Re: [Sip] [sipcore] [Technical Errata Reported] RFC3261 (2910)
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Aug 2011 01:31:25 -0000

> From: Samir Srivastava [samirs.lists@gmail.com]
> 
> Hi, IMHO presentation of information in tabulated form helps a lot to
> starters. Like ABNF it helps parser developers (expert of syntax &
> semantic analysis) to develop it without referring each line of SIP
> rfc's.

The tables are a useful guide to starters.  But as others have noted,
it is very difficult to keep the tables up to date, and there is no
format for the tables that correctly presents the conditions for
all "optional" headers.

Parser developers may be tempted to use the tables to determine
whether a message has all the required headers, but it is nearly
impossible to make that determination other than while carrying out
the processing for the message.

The real rule for the presence of headers is: "Perform the processing
that is mandated by the SIP message.  Headers whose values are
required to perform this processing must be present; headers whose
values are not used in the processing are ignored.  If a needed header
is not present, the processing of the message is aborted and it has no
effect.  If the message is a request, an appropriate error response is
sent (if enough information is present in the request to allow doing
so)."

Dale