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

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 <at> 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 <at> 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 <at> 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 <at> 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 <at> aliax.net>
>>>>>> _______________________________________________
>>>>>> sipcore mailing list
>>>>>> sipcore <at> 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 <at> cs.columbia.edu for questions on how to develop a
>>>>> SIP
>>>>> implementation.
>>>>> Use dispatch <at> ietf.org for new developments on the application of sip.
>>>>> Use sipcore <at> 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 <at> cs.columbia.edu for questions on how to develop a SIP
>>> implementation.
>>> Use dispatch <at> ietf.org for new developments on the application of sip.
>>> Use sipcore <at> 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 <at> cs.columbia.edu for questions on how to develop a SIP
>> implementation.
>> Use dispatch <at> ietf.org for new developments on the application of sip.
>> Use sipcore <at> 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 <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.