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<[email protected]>  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<[email protected]>   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 originati=
on
>>>> 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 does=
n'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 reques=
ts
>>>> before call answer. If the origination side (UAC) side has a need to s=
end
>>>> early requests, like UPDATE, then the UAC should require 100rel from t=
he
>>>> termination side (UAS) by sending this in INVITE. In a VoIP service
>>>> provider
>>>> world, these kind of capabilities are configured during interconnect t=
urn
>>>> 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 b=
ack
>>>> SIP 183 with the headers that create early dialog. So if the originati=
on
>>>> 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 witho=
ut
>>>> requiring PRACK.
>>>>
>>>> Thanks.
>>>>
>>>> On Wed, Aug 3, 2011 at 11:46 AM, Robert Sparks<[email protected]>
>>>> wrote:
>>>>
>>>>> (removing the rfc-editor and trimming the distribution to the lists)
>>>>>
>>>>> On Aug 2, 2011, at 5:24 PM, I=F1aki Baz Castillo wrote:
>>>>>
>>>>>> 2011/8/2 Robert Sparks<[email protected]>:
>>>>>>> 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 t=
he
>>>>>> request was INVITE, will establish a dialog."
>>>>>>
>>>>>> Section 12.1.1: "When a UAS responds to a request with a response th=
at
>>>>>> 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=F1aki Baz Castillo
>>>>>> <[email protected]>
>>>>>> _______________________________________________
>>>>>> sipcore mailing list
>>>>>> [email protected]
>>>>>> 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 [email protected] for questions on how to develop a
>>>>> SIP
>>>>> implementation.
>>>>> Use [email protected] for new developments on the application of sip.
>>>>> Use [email protected] 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 busines=
s.
>>> Use [email protected] for questions on how to develop a =
SIP
>>> implementation.
>>> Use [email protected] for new developments on the application of sip.
>>> Use [email protected] 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 [email protected] for questions on how to develop a S=
IP
>> implementation.
>> Use [email protected] for new developments on the application of sip.
>> Use [email protected] 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 [email protected] for questions on how to develop a SIP =
implementation.
Use [email protected] for new developments on the application of sip.
Use [email protected] for issues related to maintenance of the core SIP spec=
ifications.