Clarifications for When to Use the name-addr Production in SIP Messages
updates
- rfc-3261 — SIP: Session Initiation Protocol
- rfc-3325 — Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks
- rfc-3515 — The Session Initiation Protocol (SIP) Refer Method
- rfc-3892 — The Session Initiation Protocol (SIP) Referred-By Mechanism
- rfc-4508 — Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method
- rfc-5002 — The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header)
- rfc-5318 — The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header)
- rfc-5360 — A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)
- rfc-5502 — The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem
Extracted elements (12)
Many errata had been submitted against extension RFCs (3325, 3515, 3892, 4508, 5002, 5318, 5360, 5502) to add the missing name-addr constraint; this document consolidates those corrections into a single normative update rather than processing them individually.
RFC 3261 originally expressed the name-addr constraint as prose copied into each individual header field definition, which caused it to be missed for the To header field and omitted from extension header field specifications; this document replaces the per-field prose with a single generic constraint.
The original RFC 3261 Section 20 introduction language ('The Contact, From, and To header fields...') was ambiguous because it could be read as applying only to those three fields, necessitating a generic restatement that explicitly covers all header fields using the name-addr / addr-spec alternative.
A SIP message formed without honoring the name-addr constraint is still syntactically valid, but characters after a comma, question mark, or semicolon will likely be interpreted as header field parameters or additional header field values rather than part of the URI.
An exception to the parsing ambiguity exists for degenerate URLs like sip:10.0.0.1,@10.0.0.0, where a comma can be parsed via the 'user' production in the SIP ABNF grammar.
If a URI is not enclosed in angle brackets, any semicolon-delimited parameters are treated as header-parameters, not URI parameters; this distinction is load-bearing for correct SIP message interpretation.
For all SIP extension header fields defined in RFCs 3325, 3515, 3892, 4508, 5002, 5318, 5360, and 5502 that allow the addr-spec / name-addr choice, the addr-spec form MUST NOT be used if the value would contain a comma, semicolon, or question mark.
When a URI appears in a SIP header field that allows the name-addr / addr-spec choice, any URI parameters MUST be contained within angle brackets (< and >).
When constructing any SIP header field whose grammar allows choosing between name-addr and addr-spec, the addr-spec form MUST NOT be used if its value would contain a comma, semicolon, or question mark.
The header fields defined in RFC 3261 that allow the name-addr / addr-spec choice are: To, From, Contact, and Reply-To.
The name-addr production is defined as an optional display-name followed by a URI enclosed in angle brackets (LAQUOT addr-spec RAQUOT), while addr-spec is a bare SIP-URI, SIPS-URI, or absoluteURI with no enclosing brackets.
This document introduces no new security considerations; the primary pre-existing concern is that SIP messages produced without honoring the name-addr constraint will very likely be misinterpreted by the receiving element, potentially causing routing or parameter-handling errors.