diff options
Diffstat (limited to 'doc/rfc/rfc8217.txt')
| -rw-r--r-- | doc/rfc/rfc8217.txt | 339 |
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc8217.txt b/doc/rfc/rfc8217.txt new file mode 100644 index 0000000..21c69f8 --- /dev/null +++ b/doc/rfc/rfc8217.txt @@ -0,0 +1,339 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Sparks +Request for Comments: 8217 Oracle +Updates: 3261, 3325, 3515, 3892, 4508, August 2017 + 5002, 5318, 5360, 5502 +Category: Standards Track +ISSN: 2070-1721 + + +Clarifications for When to Use the name-addr Production in SIP Messages + +Abstract + + RFC 3261 constrained several SIP header fields whose grammar contains + the "name-addr / addr-spec" alternative to use name-addr when certain + characters appear. Unfortunately, it expressed the constraints with + prose copied into each header field definition, and at least one + header field was missed. Further, the constraint has not been copied + into documents defining extension headers whose grammar contains the + alternative. + + This document updates RFC 3261 to state the constraint generically + and clarifies that the constraint applies to all SIP header fields + where there is a choice between using name-addr or addr-spec. It + also updates the RFCs that define extension SIP header fields using + the alternative to clarify that the constraint applies (RFCs 3325, + 3515, 3892, 4508, 5002, 5318, 5360, and 5502). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8217. + + + + + + + + + + + +Sparks Standards Track [Page 1] + +RFC 8217 name-addr Clarifications August 2017 + + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . . . 4 + 4. Updates to RFCs Defining SIP Extension Header Fields . . . . 4 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 + 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 + +1. Introduction + + [RFC3261] defines several header fields that contain URIs to allow + both a form that contains the bare URI (addr-spec) and one that + provides a name and the URI (name-addr). This subset, taken from the + ABNF [RFC5234] specified in [RFC3261], shows the relevant part of the + definition of the syntax of the "From" header field: + + From = ( "From" / "f" ) HCOLON from-spec + from-spec = ( name-addr / addr-spec ) + *( SEMI from-param ) + name-addr = [ display-name ] LAQUOT addr-spec RAQUOT + addr-spec = SIP-URI / SIPS-URI / absoluteURI + + The prose in Section 20.20 of [RFC3261], which discusses the "From" + header field, constrains how the production may be used by saying: + + Even if the "display-name" is empty, the "name-addr" form + MUST be used if the "addr-spec" contains a comma, question + mark, or semicolon. + + + +Sparks Standards Track [Page 2] + +RFC 8217 name-addr Clarifications August 2017 + + + Section 20.39 of [RFC3261], which discusses the "To" header field, + contains no such constraining text. + + This constraint is specified slightly differently, but with the same + intent, in the introduction to Section 20 of [RFC3261]: + + The Contact, From, and To header fields contain a URI. If the URI + contains a comma, question mark or semicolon, the URI MUST be + enclosed in angle brackets (< and >). + + Unfortunately, this can be read to only apply to the Contact, From, + and To header fields, making it necessary to provide the constraint + explicitly in the prose discussing any other header field using the + name-addr or addr-spec alternative. + + As extension header fields were standardized, the specifications + sometimes failed to include the constraint. Many errata have been + entered to correct this omission. When the constraint has been + included, the requirement to use the name-addr form has not been + consistently stated. + + This memo updates the specifications of SIP and its extensions to + clarify that the constraint to use the name-addr form applies + anywhere there is a choice between the name-addr and addr-spec + production rules in the grammar for SIP header fields. + + It is important to note that a message formed without honoring the + constraint will still be syntactically valid, but it would very + likely be interpreted differently. The characters after the comma, + question mark, or semicolon will, in most cases, be interpreted as + header field parameters or additional header field values as + discussed in Section 7.3.1 of [RFC3261]. (An exception is the + degenerate case of a URL like sip:10.0.0.1,@10.0.0.0 where it is + possible to parse the comma via the 'user' production). + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + + + + + + + + +Sparks Standards Track [Page 3] + +RFC 8217 name-addr Clarifications August 2017 + + +3. Updates to RFC 3261 + + This text from introduction to Section 20 of [RFC3261]: + + The Contact, From, and To header fields contain a URI. If the URI + contains a comma, question mark or semicolon, the URI MUST be + enclosed in angle brackets (< and >). Any URI parameters are + contained within these brackets. If the URI is not enclosed in + angle brackets, any semicolon-delimited parameters are + header-parameters, not URI parameters. + + is replaced with: + + When constructing the value of any SIP header field whose grammar + allows choosing between name-addr and addr-spec, such as those + that use the form '(name-addr / addr-spec)', the addr-spec form + MUST NOT be used if its value would contain a comma, semicolon, + or question mark. + + When a URI appears in such a header field, any URI parameters MUST + be contained within angle brackets (< and >). If the URI is not + enclosed in angle brackets, any semicolon-delimited parameters are + header-parameters, not URI parameters. + + The header fields defined in this specification that allow this + choice are "To", "From", "Contact", and "Reply-To". + +4. Updates to RFCs Defining SIP Extension Header Fields + + The following Standards Track RFCs: [RFC3515], [RFC3892], [RFC4508], + and [RFC5360] + + and the following Informational RFCs: [RFC3325], [RFC5002], + [RFC5318], and [RFC5502] + + are updated to include: + + This RFC contains the definition of one or more SIP header fields + that allow choosing between addr-spec and name-addr when + constructing header field values. As specified in RFC 8217, + the "addr-spec" form MUST NOT be used if its value would contain + a comma, semicolon, or question mark. + + The status of these RFCs remains unchanged. In particular the status + of the Informational RFCs remains Informational. + + + + + + +Sparks Standards Track [Page 4] + +RFC 8217 name-addr Clarifications August 2017 + + +5. IANA Considerations + + This document does not require any IANA actions. + +6. Security Considerations + + The updates specified in this memo clarify a constraint on the + grammar for producing SIP messages. It introduces no new security + considerations. One pre-existing consideration is worth reiterating: + messages produced without honoring the constraint will very likely be + misinterpreted by the receiving element. + +7. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <http://www.rfc-editor.org/info/rfc3261>. + + [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private + Extensions to the Session Initiation Protocol (SIP) for + Asserted Identity within Trusted Networks", RFC 3325, + DOI 10.17487/RFC3325, November 2002, + <http://www.rfc-editor.org/info/rfc3325>. + + [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer + Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, + <http://www.rfc-editor.org/info/rfc3515>. + + [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) + Referred-By Mechanism", RFC 3892, DOI 10.17487/RFC3892, + September 2004, <http://www.rfc-editor.org/info/rfc3892>. + + [RFC4508] Levin, O. and A. Johnston, "Conveying Feature Tags with + the Session Initiation Protocol (SIP) REFER Method", + RFC 4508, DOI 10.17487/RFC4508, May 2006, + <http://www.rfc-editor.org/info/rfc4508>. + + [RFC5002] Camarillo, G. and G. Blanco, "The Session Initiation + Protocol (SIP) P-Profile-Key Private Header (P-Header)", + RFC 5002, DOI 10.17487/RFC5002, August 2007, + <http://www.rfc-editor.org/info/rfc5002>. + + + +Sparks Standards Track [Page 5] + +RFC 8217 name-addr Clarifications August 2017 + + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + <http://www.rfc-editor.org/info/rfc5234>. + + [RFC5318] Hautakorpi, J. and G. Camarillo, "The Session Initiation + Protocol (SIP) P-Refused-URI-List Private-Header + (P-Header)", RFC 5318, DOI 10.17487/RFC5318, December + 2008, <http://www.rfc-editor.org/info/rfc5318>. + + [RFC5360] Rosenberg, J., Camarillo, G., Ed., and D. Willis, "A + Framework for Consent-Based Communications in the Session + Initiation Protocol (SIP)", RFC 5360, + DOI 10.17487/RFC5360, October 2008, + <http://www.rfc-editor.org/info/rfc5360>. + + [RFC5502] van Elburg, J., "The SIP P-Served-User Private-Header + (P-Header) for the 3GPP IP Multimedia (IM) Core Network + (CN) Subsystem", RFC 5502, DOI 10.17487/RFC5502, April + 2009, <http://www.rfc-editor.org/info/rfc5502>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <http://www.rfc-editor.org/info/rfc8174>. + +Acknowledgments + + Brett Tate identified this issue in several extension documents, + submitted several corresponding errata, and drove the discussion that + led to this memo. Substantive comments leading to this text were + provided by Paul Kyzivat, Gonzalo Camarillo, Dale Worley, and + Yehoshua Gev. + +Author's Address + + Robert Sparks + Oracle + + Email: rjsparks@nostrum.com + + + + + + + + + + + + +Sparks Standards Track [Page 6] + |