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-07.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: http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-services-07.txt 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. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
