headers
RFC Errata System | 2 Aug 2011 16:53
Favicon

[Technical Errata Reported] RFC3261 (2910)


The following errata report has been submitted for RFC3261,
"SIP: Session Initiation Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=2910

--------------------------------------
Type: Technical
Reported by: Iñaki Baz Castillo <ibc <at> aliax.net>

Section: Table 2

Original Text
-------------
      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Contact                1xx           -   -   -   o   -   -

Corrected Text
--------------
      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Contact                1xx           -   -   -   m   -   -

Notes
-----
RFC 3261 says:
(Continue reading)

Permalink | Reply | 14 comments |
headers
Bob Penfield | 2 Aug 2011 17:58
Favicon

Re: [Technical Errata Reported] RFC3261 (2910)

The entry in the table should be "c" (not "m"). A Contact is not required in a 100 Trying response. The Contact
is only required for a 1xx that creates a dialog.

-----Original Message-----
From: sip-bounces <at> ietf.org [mailto:sip-bounces <at> ietf.org] On Behalf Of RFC Errata System
Sent: Tuesday, August 02, 2011 10:54 AM
To: jdrosen <at> dynamicsoft.com; schulzrinne <at> cs.columbia.edu; Gonzalo.Camarillo <at> ericsson.com;
alan.johnston <at> wcom.com; jon.peterson <at> neustar.com; rsparks <at> dynamicsoft.com; mjh <at> icir.org;
schooler <at> research.att.com; gonzalo.camarillo <at> ericsson.com; rjsparks <at> nostrum.com;
dean.willis <at> softarmor.com; drage <at> alcatel-lucent.com
Cc: sip <at> ietf.org; rfc-editor <at> rfc-editor.org
Subject: [Sip] [Technical Errata Reported] RFC3261 (2910)

The following errata report has been submitted for RFC3261,
"SIP: Session Initiation Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=2910

--------------------------------------
Type: Technical
Reported by: Iñaki Baz Castillo <ibc <at> aliax.net>

Section: Table 2

Original Text
-------------
      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
(Continue reading)

Permalink | Reply | 13 comments |
headers
Iñaki Baz Castillo | 2 Aug 2011 20:28
Gravatar

Re: [Technical Errata Reported] RFC3261 (2910)

2011/8/2 Bob Penfield <BPenfield <at> acmepacket.com>:
> The entry in the table should be "c" (not "m"). A Contact is not required in a 100 Trying response. The
Contact is only required for a 1xx that creates a dialog.

Right.

--

-- 
Iñaki Baz Castillo
<ibc <at> aliax.net>
_______________________________________________
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.
Permalink | Reply | 2 comments |
headers
Robert Sparks | 2 Aug 2011 20:48
Favicon

Table2/3 maintenance (was Re: [Technical Errata Reported] RFC3261 (2910))

(removing the RFC Editor, and setting reply-to to the sipcore list)

Some thing to think about when considering errata on the existing Tables 2 and 3 in RFC3261:

We have had many conversations about the utility of maintaining tables 2 and 3.
I think the most recent was around the Anaheim meeting - see the notes at:
<http://www.ietf.org/proceedings/77/minutes/sipcore.html>

We had strong support for not continuing to add information to Tables 2 and 3, but not
to remove the existing tables from the document.  Maintaining the existing table is
probably a separate question, but keep the arguments noted in the minutes above in
mind when choosing to do so.

RjS

On Aug 2, 2011, at 1:28 PM, Iñaki Baz Castillo wrote:

> 2011/8/2 Bob Penfield <BPenfield <at> acmepacket.com>:
>> The entry in the table should be "c" (not "m"). A Contact is not required in a 100 Trying response. The
Contact is only required for a 1xx that creates a dialog.
> 
> Right.
> 
> -- 
> Iñaki Baz Castillo
> <ibc <at> aliax.net>

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert Sparks | 2 Aug 2011 20:57
Favicon

Re: [Technical Errata Reported] RFC3261 (2910)

(Attempting to move this to the sipcore mailing list)

Further, they're only going to make sense for 1xx that is sent using 100rel.

So the errata as submitted is incorrect. We could just reject it and move on (my preference given the way
we're handling Table 2),
or try to edit it to be more correct and put it in hold-for-document update (see <http://www.ietf.org/iesg/statement/errata-processing.html>).

RjS

On Aug 2, 2011, at 10:58 AM, Bob Penfield wrote:

> The entry in the table should be "c" (not "m"). A Contact is not required in a 100 Trying response. The
Contact is only required for a 1xx that creates a dialog.
> 
> 
> -----Original Message-----
> From: sip-bounces <at> ietf.org [mailto:sip-bounces <at> ietf.org] On Behalf Of RFC Errata System
> Sent: Tuesday, August 02, 2011 10:54 AM
> To: jdrosen <at> dynamicsoft.com; schulzrinne <at> cs.columbia.edu; Gonzalo.Camarillo <at> ericsson.com;
alan.johnston <at> wcom.com; jon.peterson <at> neustar.com; rsparks <at> dynamicsoft.com; mjh <at> icir.org;
schooler <at> research.att.com; gonzalo.camarillo <at> ericsson.com; rjsparks <at> nostrum.com;
dean.willis <at> softarmor.com; drage <at> alcatel-lucent.com
> Cc: sip <at> ietf.org; rfc-editor <at> rfc-editor.org
> Subject: [Sip] [Technical Errata Reported] RFC3261 (2910)
> 
> 
> The following errata report has been submitted for RFC3261,
> "SIP: Session Initiation Protocol".
>
(Continue reading)

Permalink | Reply | 9 comments |
headers
Fred_Stacey | 2 Aug 2011 21:03
Favicon

Fred Stacey is out of the office.


I will be out of the office starting  07/30/2011 and will not return until
08/08/2011.

I will be out of the office  From Jully 30 to Aug 8 inclusive.
If your inquiry is regarding Mitel AnyWare, please direct to
mitel_anyware_sales <at> mitel.com.
If your inquiry is regarding MICD or the Mitel Service Provider Program,
please direct to Andrew Moses (andrew_moses <at> mitel.com)

_______________________________________________
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.
Permalink | Reply | 0 comments |
headers
Iñaki Baz Castillo | 3 Aug 2011 00:24
Gravatar

Re: [Technical Errata Reported] RFC3261 (2910)

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?

Regards.

--

-- 
Iñaki Baz Castillo
<ibc <at> aliax.net>
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Iñaki Baz Castillo | 3 Aug 2011 00:56
Gravatar

Re: Table2/3 maintenance (was Re: [Technical Errata Reported] RFC3261 (2910))

2011/8/2 Robert Sparks <rjsparks <at> nostrum.com>:
> (removing the RFC Editor, and setting reply-to to the sipcore list)
>
> Some thing to think about when considering errata on the existing Tables 2 and 3 in RFC3261:
>
> We have had many conversations about the utility of maintaining tables 2 and 3.
> I think the most recent was around the Anaheim meeting - see the notes at:
> <http://www.ietf.org/proceedings/77/minutes/sipcore.html>
>
> We had strong support for not continuing to add information to Tables 2 and 3, but not
> to remove the existing tables from the document.  Maintaining the existing table is
> probably a separate question, but keep the arguments noted in the minutes above in
> mind when choosing to do so.

I also think that table 2 (at least table 2) is not useful, and just
adds complexity. It's much better to explain/describe/mandate the
presence of headers in the text (IMHO).

Regards.

--

-- 
Iñaki Baz Castillo
<ibc <at> aliax.net>
_______________________________________________
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.
Permalink | Reply | 0 comments |
headers
Robert Sparks | 3 Aug 2011 17:46
Favicon

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

(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,
(Continue reading)

Permalink | Reply | 7 comments |
headers
Samir Srivastava | 5 Aug 2011 06:15
Picon

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

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

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.
(Continue reading)

Permalink | Reply | 4 comments |

Gmane