draft-ietf-sipping-uri-list-message-03.txt   draft-ietf-sipping-uri-list-message-04.txt 
SIPPING Working Group M. Garcia-Martin SIPPING Working Group M. Garcia-Martin
Internet-Draft Nokia Internet-Draft Nokia
Expires: October 10, 2005 G. Camarillo Expires: April 24, 2006 G. Camarillo
Ericsson Ericsson
April 8, 2005 October 21, 2005
Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol
(SIP) (SIP)
draft-ietf-sipping-uri-list-message-03.txt draft-ietf-sipping-uri-list-message-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 10, 2005. This Internet-Draft will expire on April 24, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document specifies how to request a SIP URI-list service to send This document specifies how to request a SIP URI-list service to send
a copy of a MESSAGE to a set of destinations. The client sends a SIP a copy of a MESSAGE to a set of destinations. The client sends a SIP
MESSAGE request with a URI-list to the MESSAGE URI-list service, MESSAGE request with a URI-list to the MESSAGE URI-list service,
which sends a similar MESSAGE request to each of the URIs included in which sends a similar MESSAGE request to each of the URIs included in
the list. the list.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. URI-List document . . . . . . . . . . . . . . . . . . . . . 5 4. URI-List document . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Extension to the resource lists data format . . . . . . . 6 4.1. Extension to the resource lists data format . . . . . . . 6
4.2 URI-list example . . . . . . . . . . . . . . . . . . . . . 7 4.2. URI-list example . . . . . . . . . . . . . . . . . . . . . 7
5. Option-tag . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Option-tag . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Procedures at the User Agent Client . . . . . . . . . . . . 8 6. Procedures at the User Agent Client . . . . . . . . . . . . . 8
7. Procedures at the MESSAGE URI-List Service . . . . . . . . . 9 7. Procedures at the MESSAGE URI-List Service . . . . . . . . . . 9
7.1 Determining the intended recipient . . . . . . . . . . . . 9 7.1. Determining the intended recipient . . . . . . . . . . . . 9
7.2 Creating an outgoing MESSAGE request . . . . . . . . . . . 9 7.2. Creating an outgoing MESSAGE request . . . . . . . . . . . 9
7.3 Composing bodies in the outgoing MESSAGE request . . . . . 10 7.3. Composing bodies in the outgoing MESSAGE request . . . . . 10
8. Procedures at the UAS . . . . . . . . . . . . . . . . . . . 12 8. Procedures at the UAS . . . . . . . . . . . . . . . . . . . . 12
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11.1 Disposition Type Registration . . . . . . . . . . . . . 16 11.1. Disposition Type Registration . . . . . . . . . . . . . . 16
11.2 Option-Tag Registration . . . . . . . . . . . . . . . . 16 11.2. Option-Tag Registration . . . . . . . . . . . . . . . . . 16
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
13. Change control . . . . . . . . . . . . . . . . . . . . . . . 16 13. Change control . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1 Changes from 13.1. Changes from draft-ietf-sipping-uri-list-message-02.txt . 17
draft-ietf-sipping-uri-list-message-02.txt . . . . . . . 16 13.2. Changes from draft-ietf-sipping-uri-list-message-01.txt . 17
13.2 Changes from 13.3. Changes from draft-ietf-sipping-uri-list-message-00.txt . 17
draft-ietf-sipping-uri-list-message-01.txt . . . . . . . 17 13.4. Changes from
13.3 Changes from
draft-ietf-sipping-uri-list-message-00.txt . . . . . . . 17
13.4 Changes from
draft-ietf-sipping-message-exploder-00.txt to draft-ietf-sipping-message-exploder-00.txt to
draft-ietf-sipping-uri-list-message-00.txt . . . . . . . 17 draft-ietf-sipping-uri-list-message-00.txt . . . . . . . . 17
13.5 Changes from 13.5. Changes from
draft-garcia-simple-message-exploder-00.txt to draft-garcia-simple-message-exploder-00.txt to
draft-garcia-sipping-message-exploder-00.txt . . . . . . 18 draft-garcia-sipping-message-exploder-00.txt . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.1 Normative References . . . . . . . . . . . . . . . . . . 18 14.1. Normative References . . . . . . . . . . . . . . . . . . . 18
14.2 Informational References . . . . . . . . . . . . . . . . 19 14.2. Informational References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Introduction 1. Introduction
SIP [6] can carry instant messages in MESSAGE [9] requests. The SIP [6] can carry instant messages in MESSAGE [9] requests. The
Advanced Instant Messaging Requirements for SIP [13] mentions the Advanced Instant Messaging Requirements for SIP [13] mentions the
need for sending a MESSAGE request to multiple recipients: need for sending a MESSAGE request to multiple recipients:
"REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc "REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc
group, where the identities of the recipients are carried in the group, where the identities of the recipients are carried in the
message itself." message itself."
skipping to change at page 6, line 10 skipping to change at page 6, line 12
'recipient-list-history' and its purpose is to indicate a list of 'recipient-list-history' and its purpose is to indicate a list of
recipients that a MESSAGE was sent to. A body whose Content- recipients that a MESSAGE was sent to. A body whose Content-
Disposition type is 'recipient-list-history' contains a URI-list with Disposition type is 'recipient-list-history' contains a URI-list with
the visible recipients of the MESSAGE. The <entry> element in the the visible recipients of the MESSAGE. The <entry> element in the
URI-list MAY also include a 'capacity' attribute, as specified in URI-list MAY also include a 'capacity' attribute, as specified in
Section 4.1. MESSAGE URI-list services MUST implement support for Section 4.1. MESSAGE URI-list services MUST implement support for
this Content-Disposition type. User Agent Servers (UAS) MAY this Content-Disposition type. User Agent Servers (UAS) MAY
implement support for the resource-list document format [10] and the implement support for the resource-list document format [10] and the
'recipient-list-history' Content-Disposition type. 'recipient-list-history' Content-Disposition type.
4.1 Extension to the resource lists data format 4.1. Extension to the resource lists data format
This document defines an extension to indicate the capacity of a This document defines an extension to indicate the capacity of a
resource. We define a new 'capacity' attribute to the <entry> resource. We define a new 'capacity' attribute to the <entry>
element. The 'capacity' attribute has similar semantics to the type element. The 'capacity' attribute has similar semantics to the type
of destination address in e-mail systems. It can take the values of destination address in e-mail systems. It can take the values
"to", "cc" and "bcc". A "to" value of the 'capacity' attribute "to", "cc" and "bcc". A "to" value of the 'capacity' attribute
indicates that the resource is considered the recipient of the indicates that the resource is considered the recipient of the
MESSAGE request. A "cc" value indicates that the resource receives a MESSAGE request. A "cc" value indicates that the resource receives a
carbon copy of the MESSAGE request. A "bcc" value indicates that the carbon copy of the MESSAGE request. A "bcc" value indicates that the
resource receives a blind carbon copy of the MESSAGE request. The resource receives a blind carbon copy of the MESSAGE request. The
skipping to change at page 7, line 33 skipping to change at page 7, line 33
<xs:enumeration value="to"/> <xs:enumeration value="to"/>
<xs:enumeration value="cc"/> <xs:enumeration value="cc"/>
<xs:enumeration value="bcc"/> <xs:enumeration value="bcc"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
</xs:schema> </xs:schema>
Figure 1: Extension to the resource lists data format Figure 1: Extension to the resource lists data format
4.2 URI-list example 4.2. URI-list example
Figure 2 shows an example of a flat list that follows the resource Figure 2 shows an example of a flat list that follows the resource
list data format. Each resource indicates the capacity of a list data format. Each resource indicates the capacity of a
resource. resource.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:capacity" xmlns:cp="urn:ietf:params:xml:ns:capacity"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list> <list>
skipping to change at page 9, line 22 skipping to change at page 9, line 23
service SHOULD answer to the UAC with a 202 Accepted response. Note service SHOULD answer to the UAC with a 202 Accepted response. Note
that the status code in the response to the MESSAGE does not provide that the status code in the response to the MESSAGE does not provide
any information about whether or not the MESSAGEs generated by the any information about whether or not the MESSAGEs generated by the
URI-list service were successfully delivered to the URIs in the list. URI-list service were successfully delivered to the URIs in the list.
That is, a 202 Accepted means that the MESSAGE URI-list service has That is, a 202 Accepted means that the MESSAGE URI-list service has
received the MESSAGE and that it will try to send a similar MESSAGE received the MESSAGE and that it will try to send a similar MESSAGE
to the URIs in the list. Designing a mechanism to inform a client to the URIs in the list. Designing a mechanism to inform a client
about the delivery status of an instant message is outside the scope about the delivery status of an instant message is outside the scope
of this document. of this document.
7.1 Determining the intended recipient 7.1. Determining the intended recipient
On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list
service SHOULD determine the list of intended recipients, by service SHOULD determine the list of intended recipients, by
inspecting the URI-list contained in the body. In case two of those inspecting the URI-list contained in the body. In case two of those
URIs are equivalent (section 19.1.4 of RFC 3261 [6] defines URIs are equivalent (section 19.1.4 of RFC 3261 [6] defines
equivalent URIs), the MESSAGE URI-list SHOULD consider a single equivalent URIs), the MESSAGE URI-list SHOULD consider a single
intended recipient. intended recipient.
7.2 Creating an outgoing MESSAGE request 7.2. Creating an outgoing MESSAGE request
Since the MESSAGE URI-list behaves as a UAC for outgoing MESSAGE Since the MESSAGE URI-list behaves as a UAC for outgoing MESSAGE
requests, for each of the intended recipients, the MESSAGE URI-list requests, for each of the intended recipients, the MESSAGE URI-list
service creates a new MESSAGE request according to the procedures service creates a new MESSAGE request according to the procedures
described in Section 4 of RFC 3428 [9] and the following procedures: described in Section 4 of RFC 3428 [9] and the following procedures:
o A MESSAGE URI-list service MUST include a From header field whose o A MESSAGE URI-list service MUST include a From header field whose
value is the same as the From header field included in the value is the same as the From header field included in the
incoming MESSAGE request, subject to the privacy requirements (see incoming MESSAGE request, subject to the privacy requirements (see
RFC 3323 [7] and RFC 3325 [8]) expressed in the incoming MESSAGE RFC 3323 [7] and RFC 3325 [8]) expressed in the incoming MESSAGE
skipping to change at page 10, line 42 skipping to change at page 10, line 46
o A MESSAGE URI-list service MUST include its own value in the Via o A MESSAGE URI-list service MUST include its own value in the Via
header field. header field.
o A MESSAGE URI-list service SHOULD include any other header field o A MESSAGE URI-list service SHOULD include any other header field
expressed with the "?" mechanism described in Section 19.1.1 of expressed with the "?" mechanism described in Section 19.1.1 of
RFC 3261 [6] and encoded in the intended recipient URI of the URI- RFC 3261 [6] and encoded in the intended recipient URI of the URI-
list. list.
o A MESSAGE URI-list service SHOULD preserve to the outgoing MESSAGE o A MESSAGE URI-list service SHOULD preserve to the outgoing MESSAGE
request any other header field not explicitly indicated in the request any other header field not explicitly indicated in the
above paragraphs. above paragraphs.
7.3 Composing bodies in the outgoing MESSAGE request 7.3. Composing bodies in the outgoing MESSAGE request
When creating the body of each of the outgoing MESSAGE requests, the When creating the body of each of the outgoing MESSAGE requests, the
MESSAGE URI-list service tries to keep the relevant bodies of the MESSAGE URI-list service tries to keep the relevant bodies of the
incoming MESSAGE request and copies them to the outgoing MESSAGE incoming MESSAGE request and copies them to the outgoing MESSAGE
request. The following guidelines are provided: request. The following guidelines are provided:
o A MESSAGE request received at a MESSAGE URI-list service can o A MESSAGE request received at a MESSAGE URI-list service can
contain one or more security bodies (e.g., S/MIME [11]) encrypted contain one or more security bodies (e.g., S/MIME [11]) encrypted
with the public key of the MESSAGE URI-list service. These bodies with the public key of the MESSAGE URI-list service. These bodies
are deemed to be read by the URI-list service rather than the are deemed to be read by the URI-list service rather than the
skipping to change at page 16, line 10 skipping to change at page 16, line 10
SHOULD encrypt the instant message body with a content encryption SHOULD encrypt the instant message body with a content encryption
key. Then, for each receiver in the list, the UAC SHOULD encrypt the key. Then, for each receiver in the list, the UAC SHOULD encrypt the
content encryption key with the public key of the receiver, and content encryption key with the public key of the receiver, and
attach it to the MESSAGE request. attach it to the MESSAGE request.
11. IANA Considerations 11. IANA Considerations
The following sections instruct the IANA to register a new The following sections instruct the IANA to register a new
disposition type and a new SIP option-tag. disposition type and a new SIP option-tag.
11.1 Disposition Type Registration 11.1. Disposition Type Registration
Section 4 defines a new 'recipient-list-history' value of the Mail Section 4 defines a new 'recipient-list-history' value of the Mail
Content Disposition Values registry. This value should be registered Content Disposition Values registry. This value should be registered
in the IANA registry of Mail Content Disposition Values with the in the IANA registry of Mail Content Disposition Values with the
following registration data: following registration data:
+------------------------+------------------------------+-----------+ +------------------------+------------------------------+-----------+
| Name | Description | Reference | | Name | Description | Reference |
+------------------------+------------------------------+-----------+ +------------------------+------------------------------+-----------+
| recipient-list-history | the body contains a list of | [RFCXXXX] | | recipient-list-history | the body contains a list of | [RFCXXXX] |
| | URIs that indicates the | | | | URIs that indicates the | |
| | recipients of the message | | | | recipients of the message | |
+------------------------+------------------------------+-----------+ +------------------------+------------------------------+-----------+
Table 1: Registration of the 'recipient-list-history' Mail Content Table 1: Registration of the 'recipient-list-history' Mail Content
Disposition Value Disposition Value
Note to IANA and the RFC editor: replace RFCXXXX above with the RFC Note to IANA and the RFC editor: replace RFCXXXX above with the RFC
number of this specification. number of this specification.
11.2 Option-Tag Registration 11.2. Option-Tag Registration
This document defines the 'recipient-list-message' SIP option-tag in This document defines the 'recipient-list-message' SIP option-tag in
Section 5. It should be registered in the Option Tags subregistry Section 5. It should be registered in the Option Tags subregistry
under the SIP parameter registry. The following is the description under the SIP parameter registry. The following is the description
to be used in the registration. to be used in the registration.
This option-tag is used to ensure that a server can process the This option-tag is used to ensure that a server can process the
'recipient-list' body used in a MESSAGE request. 'recipient-list' body used in a MESSAGE request.
12. Acknowledgements 12. Acknowledgements
Duncan Mills supported the idea of having 1 to n MESSAGEs. Ben Duncan Mills supported the idea of having 1 to n MESSAGEs. Ben
Campbell, Paul Kyzivat, Cullen Jennings, and Jonathan Rosenberg Campbell, Paul Kyzivat, Cullen Jennings, and Jonathan Rosenberg
provided helpful comments. provided helpful comments.
13. Change control 13. Change control
13.1 Changes from draft-ietf-sipping-uri-list-message-02.txt 13.1. Changes from draft-ietf-sipping-uri-list-message-02.txt
Typos fixed. Typos fixed.
'recipient-list-message' option-tag defined and registered with the 'recipient-list-message' option-tag defined and registered with the
IANA. IANA.
13.2 Changes from draft-ietf-sipping-uri-list-message-01.txt 13.2. Changes from draft-ietf-sipping-uri-list-message-01.txt
Added a reference to missing REQ-GROUP-4 in the Advanced Instant Added a reference to missing REQ-GROUP-4 in the Advanced Instant
Messaging Requirements for SIP document. Messaging Requirements for SIP document.
Since the resource list allows now attribute extensibility, the Since the resource list allows now attribute extensibility, the
former <capacity> element has been replaced by a 'capacity' former <capacity> element has been replaced by a 'capacity'
attribute, which allows a more compact representation of the URI. attribute, which allows a more compact representation of the URI.
Added a new Content-Disposition disposition type 'recipient-list- Added a new Content-Disposition disposition type 'recipient-list-
history'. It is used in the MESSAGE request that the MESSAGE URI- history'. It is used in the MESSAGE request that the MESSAGE URI-
list service sends to each of the recipients. This allows the UAS to list service sends to each of the recipients. This allows the UAS to
differentiate it from a 'recipient-list', which has a separate differentiate it from a 'recipient-list', which has a separate
meaning. meaning.
13.3 Changes from draft-ietf-sipping-uri-list-message-00.txt 13.3. Changes from draft-ietf-sipping-uri-list-message-00.txt
Revision of the treatment of headers the MESSAGE URI-list service, on Revision of the treatment of headers the MESSAGE URI-list service, on
a header by header basis. a header by header basis.
Added an overview section. Added an overview section.
Added functionality that allows the sender of the incoming MESSAGE Added functionality that allows the sender of the incoming MESSAGE
request to tag each of the intended recipients with the "to", "cc", request to tag each of the intended recipients with the "to", "cc",
or "bcc" capacity. If there are resources tagged as "to" or "cc", or "bcc" capacity. If there are resources tagged as "to" or "cc",
the URI-list service will include a URI-list in each of the outgoing the URI-list service will include a URI-list in each of the outgoing
MESSAGE request including those resources. MESSAGE request including those resources.
Procedures at the UAS included. Procedures at the UAS included.
Better example including a flow. Better example including a flow.
13.4 Changes from draft-ietf-sipping-message-exploder-00.txt to 13.4. Changes from draft-ietf-sipping-message-exploder-00.txt to
draft-ietf-sipping-uri-list-message-00.txt draft-ietf-sipping-uri-list-message-00.txt
Clarified that the MESSAGE exploder should not distribute a body that Clarified that the MESSAGE exploder should not distribute a body that
has been encrypted with the public key of the exploder. The has been encrypted with the public key of the exploder. The
exception is the URI-list, which can be distributed by the exploder, exception is the URI-list, which can be distributed by the exploder,
providing that is encrypted with the public key of the receiver. providing that is encrypted with the public key of the receiver.
The security considerations section describes how to encrypt the list The security considerations section describes how to encrypt the list
and how to encrypt the instant message payload. and how to encrypt the instant message payload.
Terminology aligned with the requirements and the framework for URI- Terminology aligned with the requirements and the framework for URI-
list services (e.g., the term "exploder" has been deprecated). list services (e.g., the term "exploder" has been deprecated).
13.5 Changes from draft-garcia-simple-message-exploder-00.txt to 13.5. Changes from draft-garcia-simple-message-exploder-00.txt to
draft-garcia-sipping-message-exploder-00.txt draft-garcia-sipping-message-exploder-00.txt
The MESSAGE exploder may or may not copy the URI-list body to the The MESSAGE exploder may or may not copy the URI-list body to the
outgoing MESSAGE request. This allows to extend the mechanism with a outgoing MESSAGE request. This allows to extend the mechanism with a
Reply-to-all feature. Reply-to-all feature.
It is clarified that the MESSAGE exploder must not include a list in It is clarified that the MESSAGE exploder must not include a list in
the outgoing MESSAGE requests. This avoids loops or requires a the outgoing MESSAGE requests. This avoids loops or requires a
MESSAGE exploder functionality in the next hop. MESSAGE exploder functionality in the next hop.
The MESSAGE exploder must remove the multipart/mixed wrapper if there The MESSAGE exploder must remove the multipart/mixed wrapper if there
is only one body left in the outgoing MESSAGE request. is only one body left in the outgoing MESSAGE request.
Filename changed due to focus on the SIPPING WG. Filename changed due to focus on the SIPPING WG.
14. References 14. References
14.1 Normative References 14.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Troost, R., Dorner, S., and K. Moore, "Communicating [2] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Content- Presentation Information in Internet Messages: The Content-
Disposition Header Field", RFC 2183, August 1997. Disposition Header Field", RFC 2183, August 1997.
[3] Levinson, E., "Content-ID and Message-ID Uniform Resource [3] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998. Locators", RFC 2392, August 1998.
skipping to change at page 19, line 19 skipping to change at page 19, line 26
[10] Rosenberg, J., "Extensible Markup Language (XML) Formats for [10] Rosenberg, J., "Extensible Markup Language (XML) Formats for
Representing Resource Lists", Representing Resource Lists",
draft-ietf-simple-xcap-list-usage-05 (work in progress), draft-ietf-simple-xcap-list-usage-05 (work in progress),
February 2005. February 2005.
[11] Ramsdell, B., "S/MIME Version 3.1 Message Specification", [11] Ramsdell, B., "S/MIME Version 3.1 Message Specification",
draft-ietf-smime-rfc2633bis-09 (work in progress), April 2004. draft-ietf-smime-rfc2633bis-09 (work in progress), April 2004.
[12] Camarillo, G. and A. Roach, "Requirements and Framework for [12] Camarillo, G. and A. Roach, "Requirements and Framework for
Session Initiation Protocol (SIP)Uniform Resource Identifier Session Initiation Protocol (SIP)Uniform Resource Identifier
(URI)-List Services", draft-ietf-sipping-uri-services-02 (work (URI)-List Services", draft-ietf-sipping-uri-services-03 (work
in progress), December 2004. in progress), April 2005.
14.2 Informational References 14.2. Informational References
[13] Rosenberg, J., "Advanced Instant Messaging Requirements for the [13] Rosenberg, J., "Advanced Instant Messaging Requirements for the
Session Initiation Protocol (SIP)", Session Initiation Protocol (SIP)",
draft-rosenberg-simple-messaging-requirements-01 (work in draft-rosenberg-simple-messaging-requirements-01 (work in
progress), February 2004. progress), February 2004.
[14] Peterson, J., "Session Initiation Protocol (SIP) Authenticated [14] Peterson, J., "Session Initiation Protocol (SIP) Authenticated
Identity Body (AIB) Format", RFC 3893, September 2004. Identity Body (AIB) Format", RFC 3893, September 2004.
Authors' Addresses Authors' Addresses
 End of changes. 22 change blocks. 
55 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/