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

[Paul Kyzivat <[e-mail]>]

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<[e-mail]>  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<[e-mail]>  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<[e-mail]>:
>>>>> 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
>>>> <[e-mail]>
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> [e-mail]
>>>> 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 [e-mail] for questions on how to develop a SIP
>>> implementation.
>>> Use [e-mail] for new developments on the application of sip.
>>> Use [e-mail] 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 [e-mail] for questions on how to develop a SIP implementation.
> Use [e-mail] for new developments on the application of sip.
> Use [e-mail] for issues related to maintenance of the core SIP specifications.
>