Re: [Sip] [sipcore] [Technical Errata Reported] RFC3261 (2910)
Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 11 August 2011 17:48 UTC
Return-Path: <pkyzivat@alum.mit.edu>
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 C7E9E21F8C5D for <sip@ietfa.amsl.com>; Thu, 11 Aug 2011 10:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.575
X-Spam-Level:
X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 3yQFIJeHE12k for <sip@ietfa.amsl.com>; Thu, 11 Aug 2011 10:48:06 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id A6A6A21F8C5C for <sip@ietf.org>; Thu, 11 Aug 2011 10:48:06 -0700 (PDT)
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta05.westchester.pa.mail.comcast.net with comcast id K5AY1h0011ei1Bg555oi92; Thu, 11 Aug 2011 17:48:42 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta24.westchester.pa.mail.comcast.net with comcast id K5oh1h00k0tdiYw3k5ohf6; Thu, 11 Aug 2011 17:48:42 +0000
Message-ID: <4E4415FB.5070600@alum.mit.edu>
Date: Thu, 11 Aug 2011 13:48:43 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Samir Srivastava <samirs.lists@gmail.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> <4E3BFFFA.7070009@alum.mit.edu> <CAK+Spix083awRqeTZfS5EkR+SmRjw+L7JWsGavtt6xei-+Strw@mail.gmail.com>
In-Reply-To: <CAK+Spix083awRqeTZfS5EkR+SmRjw+L7JWsGavtt6xei-+Strw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: sip@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: Thu, 11 Aug 2011 17:48:07 -0000
On 8/10/11 9:37 AM, Samir Srivastava wrote: > Hi, IMHO the updation (to 3261) requirement MUST be needed for > non-table RFC also. We should be sufficient with tables in different > RFCs. Consider development of PUBLISH if UA doesnot support publish it > can still claim 3261 compliance via tables only. Single table req is > not good. By the same token we might need SINGLE place for headers in > textual description. With c,m, m*, o, t labels it is much easier for > parsers. Let TU developers worry about the context/usage. This needs > updation when it widens/narrows. Text only version will cause lengthy > discussions referring lines etc for message rejection. We can say > table with associated section is normative for parsing. TU usage refer > other sections. Regards Samir I've tried to parse the above, and I just can't figure out what you are proposing. Can you please try again to state how you think these rules should be documented? Thanks, Paul > On 8/5/11, Paul Kyzivat<pkyzivat@alum.mit.edu> wrote: >> On 8/5/11 12:15 AM, Samir Srivastava wrote: >>> 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. 3262 or 100rel should have updated table Ideally each >>> subsequent RFC should conisder table updation. Tabulation of >>> information will be done by vendors internally anyway. So do it in >>> community. SIP needed hitchakers guide. Simplicity for starters >>> please. Regards Samir >> >> That was the concept that led to the table in the first place. >> But history has shown this not to work very well in practice, for a >> number of reasons. Here are some: >> >> - it proved impossible to define a table format that expressed >> all the nuances. There still had to be text to explain the >> complex cases. People tended to believe the table even though >> its flagged as having exceptions >> >> - extensions to sip require updates to the table. But the extensions >> are done in separate RFCs, not revisions to 3261. So they tended >> to specify new rows to the table. These never get rolled up in >> one place. Also, extensions that add methods add columns to the >> table. When that happens, then you need to specify the values >> for the new columns, for rows in 3261 and also in all extensions >> that added rows. This is difficult, and was rarely if ever done >> right. >> >> - given both a table and text descriptions of what is required, >> it was unclear which is the authoritative normative specification. >> >> (I'm certain there are more reasons.) >> >> To be workable we would probably need to move the entire table to an >> IANA registry. That also seemed unworkable. >> >> And with text descriptions it is easier to specify the requirements in >> ways that will apply to most headers and methods that might be defined >> in the future. >> >> The bottom line is that we ultimately decided that the table was a bad >> idea and we didn't want to continue maintaining it. >> >> Thanks, >> Paul >> >>> On 8/4/11, Romel Khan<romel.khan@idt.net> wrote: >>>> So it is useful if one of UAS or UAC requires it, but it does not have to >>>> be >>>> mandatory. Some comments: >>>> -- RFC3261 mentions early dialog without mentioning RFC3262. Then it >>>> seems >>>> logical to me that it needs to be made clear in this RFC3261 that early >>>> dialog must mean Contact and Record-Route (if Record-Route was received >>>> in >>>> INVITE) headers is mandatory in 1xx without reference to 100rel. >>>> >>>> -- A UAS could always send 1xx with headers that are required for early >>>> dialog but it doesn't have to enforce 100rel (eg because the origination >>>> or >>>> UAS side itself may not support reliable provisional response handling, >>>> or >>>> reliable provisioning not really required for its operation). UAS could >>>> send >>>> "support:100rel" if it supports it, or it would not send it if it doesn't >>>> support this. In my opinion, if UAC hasn't sent 100rel required, it >>>> should >>>> be up to the UAS to decide whether to enforce 100rel >>>> (with "required:100rel") if its application really requires SIP requests >>>> before call answer. If the origination side (UAC) side has a need to send >>>> early requests, like UPDATE, then the UAC should require 100rel from the >>>> termination side (UAS) by sending this in INVITE. In a VoIP service >>>> provider >>>> world, these kind of capabilities are configured during interconnect turn >>>> up. >>>> >>>> -- I notice that some vendors gateway implementations, even if gateway is >>>> the termination side, require 100rel for the gateway to receive >>>> pre-answer >>>> requests such as UPDATE. This really didn't have to be this way. I have >>>> always seen these gateways, when it is the termination side, respond back >>>> SIP 183 with the headers that create early dialog. So if the origination >>>> side received the SIP 183 response, then there is no reason for the >>>> origination side to now not be able to send UPDATE request. Also, no >>>> reason for the termination gateways to not accept the SIP UPDATE without >>>> requiring PRACK. >>>> >>>> Thanks. >>>> >>>> On Wed, Aug 3, 2011 at 11:46 AM, Robert Sparks<rjsparks@nostrum.com> >>>> wrote: >>>> >>>>> (removing the rfc-editor and trimming the distribution to the lists) >>>>> >>>>> On Aug 2, 2011, at 5:24 PM, Iñaki Baz Castillo wrote: >>>>> >>>>>> 2011/8/2 Robert Sparks<rjsparks@nostrum.com>: >>>>>>> Further, they're only going to make sense for 1xx that is sent using >>>>> 100rel. >>>>>> >>>>>> This has been discussed in sip-implementors, and that assertion seems >>>>>> incorrect. As I've reported in the errata: >>>>>> >>>>>> >>>>>> Section 12.1: "Dialogs are created through the generation of >>>>>> non-failure responses to requests with specific methods. Within this >>>>>> specification, only 2xx and 101-199 responses with a To tag, where the >>>>>> request was INVITE, will establish a dialog." >>>>>> >>>>>> Section 12.1.1: "When a UAS responds to a request with a response that >>>>>> establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all >>>>>> Record-Route header field values from the request into the response >>>>>> [...]. The UAS MUST add a Contact header field to the response." >>>>>> >>>>>> So it's clear that a 1xx response to an INVITE creates a dialog and >>>>>> then it MUST contain a Contact header and mirrored Record-Route >>>>>> headers, *regardless* the usage of 100rel. >>>>>> >>>>>> Am I wrong? if so, why? >>>>> >>>>> Not wrong, just incomplete. This will create an (early) dialog at the >>>>> UAS. >>>>> It may or may not create a dialog at the UAC without 100rel since the >>>>> message may never get to the UAC. Where I said "make sense" above, >>>>> it might have been better if I had said "be useful". >>>>> >>>>>> >>>>>> Regards. >>>>>> >>>>>> >>>>>> -- >>>>>> Iñaki Baz Castillo >>>>>> <ibc@aliax.net> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>>>> This list is essentially closed and only used for finishing old >>>>> business. >>>>> Use sip-implementors@cs.columbia.edu for questions on how to develop a >>>>> SIP >>>>> implementation. >>>>> Use dispatch@ietf.org for new developments on the application of sip. >>>>> Use sipcore@ietf.org for issues related to maintenance of the core SIP >>>>> specifications. >>>>> >>>> >>> _______________________________________________ >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>> This list is essentially closed and only used for finishing old business. >>> Use sip-implementors@cs.columbia.edu for questions on how to develop a SIP >>> implementation. >>> Use dispatch@ietf.org for new developments on the application of sip. >>> Use sipcore@ietf.org for issues related to maintenance of the core SIP >>> specifications. >>> >> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is essentially closed and only used for finishing old business. >> Use sip-implementors@cs.columbia.edu for questions on how to develop a SIP >> implementation. >> Use dispatch@ietf.org for new developments on the application of sip. >> Use sipcore@ietf.org for issues related to maintenance of the core SIP >> specifications. >> >
- [Sip] [Technical Errata Reported] RFC3261 (2910) RFC Errata System
- Re: [Sip] [Technical Errata Reported] RFC3261 (29… Bob Penfield
- Re: [Sip] [Technical Errata Reported] RFC3261 (29… Iñaki Baz Castillo
- [Sip] Table2/3 maintenance (was Re: [Technical Er… Robert Sparks
- Re: [Sip] [Technical Errata Reported] RFC3261 (29… Robert Sparks
- Re: [Sip] [Technical Errata Reported] RFC3261 (29… Iñaki Baz Castillo
- Re: [Sip] Table2/3 maintenance (was Re: [Technica… Iñaki Baz Castillo
- Re: [Sip] [sipcore] [Technical Errata Reported] R… Robert Sparks
- Re: [Sip] [sipcore] [Technical Errata Reported] R… Samir Srivastava
- Re: [Sip] [sipcore] [Technical Errata Reported] R… Paul Kyzivat
- Re: [Sip] [sipcore] [Technical Errata Reported] R… Iñaki Baz Castillo
- Re: [Sip] [sipcore] [Technical Errata Reported] R… Worley, Dale R (Dale)
- Re: [Sip] [sipcore] [Technical Errata Reported] R… Romel Khan
- Re: [Sip] [sipcore] [Technical Errata Reported] R… Samir Srivastava
- Re: [Sip] [sipcore] [Technical Errata Reported] R… Paul Kyzivat