[Sipping] Protocol Action: 'Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services' to Proposed Standard

[The IESG <[e-mail]>]

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.

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP