(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: [email protected] [mailto:[email protected]] On Behalf Of RFC 
> Errata System
> Sent: Tuesday, August 02, 2011 10:54 AM
> To: [email protected]; [email protected]; 
> [email protected]; [email protected]; 
> [email protected]; [email protected]; [email protected]; 
> [email protected]; [email protected]; 
> [email protected]; [email protected]; [email protected]
> Cc: [email protected]; [email protected]
> 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 <[email protected]>
> 
> 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:
> 
> 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.
> 
> However Table 2 (page 162) says:
> 
>      Header field          where   proxy ACK BYE CAN INV OPT REG
>      ___________________________________________________________
>      Contact                1xx           -   -   -   o   -   -
>      Record-Route        2xx,18x    mr    -   o   o   o   o   -
> 
> Obviously Record-Route is optional since in the absence of a proxy doing 
> record-routing, such header will not be present. However Contact header 
> should appear as mandatory (m) for 1xx responses for INVITE rather than 
> optional (o).
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC3261 (draft-ietf-sip-rfc2543bis-09)
> --------------------------------------
> Title               : SIP: Session Initiation Protocol
> Publication Date    : June 2002
> Author(s)           : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. 
> Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler
> Category            : PROPOSED STANDARD
> Source              : Session Initiation Protocol
> Area                : Real-time Applications and Infrastructure
> Stream              : IETF
> Verifying Party     : IESG

_______________________________________________
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.

Reply via email to