From: The IESG <firstname.lastname@example.org>
To: IETF-Announce <email@example.com>
Cc: Internet Architecture Board <firstname.lastname@example.org>,
RFC Editor <email@example.com>,
sipping mailing list <firstname.lastname@example.org>,
sipping chair <email@example.com>
Subject: Protocol Action: 'Framework and Security Considerations
for Session Initiation Protocol (SIP) Uniform Resource
Identifier (URI)-List Services' to Proposed Standard
The IESG has approved the following document:
- 'Framework and Security Considerations for Session Initiation Protocol
(SIP) Uniform Resource Identifier (URI)-List Services '
<draft-ietf-sipping-uri-services-08.txt> as a Proposed Standard
This document is the product of the Session Initiation Proposal
Investigation Working Group.
The IESG contact persons are Jon Peterson and Cullen Jennings.
A URL of this Internet-Draft is:
Traditional SIP requests are sent to a single recipient indicated by
the Request URI. Conferencing and other scenarios raised a need to
send a single request to multiple recipients. This document provides
a general methodology, including security considerations, for sending
a SIP request to multiple recipients by including a list of
recipients (URI-list) in the request and targeting the Request URI to
an intermediate service node that will process the list and generate
a singular request for each recipient. This document defines a new
value of the Content-Disposition header used to invoke URI-list
processing on the intermediate service node.
Further standards-track documents (in preparation) will define
the usage of URI-list services with each SIP request type.
Working Group Summary:
This work has progressed fairly steadily in the SIPPING working
group, and is part of larger set of documents including the recently
approved Consent framework, and the consent framework mechanism and
URI-list services specifications for MESSAGE, INVITE and REFER
requests. While there was initially substantial angst in
the working group over the fundamental requirements of the
consent-based (opt-in, as opposed to opt-out) model,
the framework represented by this document has not been
No implementations of this specification are known to exist. However,
the Open Mobile Alliance is in the process of developing systems
specifications that exercise URI-list services for conferencing with
INVITE and REFER requests. The details of these services are defined
in other drafts, but to the extent that this draft applies, OMA has
not reported any difficulties with this specification.
Mary Barnes is the document shepherd. Jon Peterson provided review for
RFC Editor Note
REQ 2: The invocation mechanism SHOULD NOT require more than one RTT
REQ 2: The invocation mechanism SHOULD NOT require more than one
To prevent this
attack, clients SHOULD integrity protect URI lists using mechanisms
such as S/MIME, which can also provide URI-list confidentiality if
To prevent this
attack, clients SHOULD integrity protect URI lists using end-to-end
mechanisms such as S/MIME or, if not available, hop-by-hop mechanisms
such as TLS. Both S/MIME and TLS can also provide URI-list
confidentiality if needed.
recipient-list the body contains a list of URIs
recipient-list The body contains a list of URIs to which
URI-List Services are to be applied.