RFC Errata System
2010-02-25 04:32:11 UTC
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=2051
--------------------------------------
Type: Editorial
Reported by: Cullen Jennings <***@cisco.com>
Section: 26.3.1
Original Text
-------------
Proxy servers, redirect
servers, and registrars SHOULD possess a site certificate whose
subject corresponds to their canonical hostname.
Corrected Text
--------------
Proxy servers, redirect
servers, and registrars SHOULD possess a site certificate whose
subject corresponds to the DNS name other SIP devices will use to reach them.
Notes
-----
The term hostname seemed to make some people think if you had two sip servers for the domain example.com with hostnames host1 and host2, the the cert should have host1.example.com when in fact the sip signaling always used exmaple.com and the cert should have a example.com as the name.
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 sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.
"SIP: Session Initiation Protocol".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=2051
--------------------------------------
Type: Editorial
Reported by: Cullen Jennings <***@cisco.com>
Section: 26.3.1
Original Text
-------------
Proxy servers, redirect
servers, and registrars SHOULD possess a site certificate whose
subject corresponds to their canonical hostname.
Corrected Text
--------------
Proxy servers, redirect
servers, and registrars SHOULD possess a site certificate whose
subject corresponds to the DNS name other SIP devices will use to reach them.
Notes
-----
The term hostname seemed to make some people think if you had two sip servers for the domain example.com with hostnames host1 and host2, the the cert should have host1.example.com when in fact the sip signaling always used exmaple.com and the cert should have a example.com as the name.
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 sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.