Technical Summary:
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
particularly contentious.
Protocol Quality:
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
the IESG.
RFC Editor Note
OLD:
REQ 2: The invocation mechanism SHOULD NOT require more than one RTT
(Round-Trip Time).
NEW:
REQ 2: The invocation mechanism SHOULD NOT require more than one
transaction.
OLD:
[I-D.ietf-sipping-consent-framework]
NEW:
[I-D.ietf-sip-consent-framework]
OLD:
To prevent this
attack, clients SHOULD integrity protect URI lists using mechanisms
such as S/MIME, which can also provide URI-list confidentiality if
needed.
NEW:
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.
OLD:
recipient-list the body contains a list of URIs
NEW:
recipient-list The body contains a list of URIs to which
URI-List Services are to be applied.