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