Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)
draft-ietf-sip-uri-list-message-03

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    sip mailing list <sip@ietf.org>, 
    sip chair <sip-chairs@tools.ietf.org>
Subject: Protocol Action: 'Multiple-Recipient MESSAGE Requests 
         in the Session Initiation Protocol (SIP)' to Proposed Standard 

The IESG has approved the following document:

- 'Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol 
   (SIP) '
   <draft-ietf-sip-uri-list-message-04.txt> as a Proposed Standard

This document is the product of the Session Initiation Protocol Working 
Group. 

The IESG contact persons are Cullen Jennings and Jon Peterson.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-message-04.txt

Ballot Text

Technical Summary 

This document specifies a mechanism that allows a SIP User Agent 
Client (UAC) to request a SIP URI-list (Uniform Resource Identifier list)
service to send a SIP MESSAGE request to a set of destinations. The client
sends a SIP MESSAGE request that includes the payload along with the
URI-list to the MESSAGE URI-list service, which sends a similar MESSAGE
request to each of the URIs included in the list. 

Working Group Summary 

The document was originally produced by the SIPPING working group, but
was transferred to the SIP working group due to the need to define a new
option tag, in conformance with RFC 3427. There is consensus in the WG to
publish this document. 

Document Quality 

There is a strong requirement from OMA and 3GPP for a SIP solution in
this area. 

Personnel 

Keith Drage is the document shepherd for this document. 
Cullen Jennings is the responsible Area Director.

Note to RFC Editor
 
Page 10:
OLD:
 Failing to copy the From header field of the sender would
 prevent the recipient to get a hint of the sender's identity.

NEW:
 Failure to copy the From header field of the sender results
 in unacceptable security and privacy failures.

Page 11: add reference to RFC 3261
OLD:
  o  A MESSAGE URI-list service SHOULD create a separate count for the
     CSeq header field of the outgoing MESSAGE request.

NEW:
  o  A MESSAGE URI-list service SHOULD create a separate count for the
     CSeq header field [RFC3261] of the outgoing MESSAGE request.
                       ^^^^^^^^^

RFC Editor Note