draft-ietf-sipping-capacity-attribute-06.txt   draft-ietf-sipping-capacity-attribute-07.txt 
SIPPING Working Group M. Garcia-Martin SIPPING Working Group M. Garcia-Martin
Internet-Draft Nokia Siemens Networks Internet-Draft G. Camarillo
Intended status: Standards Track G. Camarillo Intended status: Standards Track Ericsson
Expires: June 20, 2008 Ericsson Expires: February 2, 2009 August 1, 2008
December 18, 2007
Extensible Markup Language (XML) Format Extension for Representing Copy Extensible Markup Language (XML) Format Extension for Representing Copy
Control Attributes in Resource Lists Control Attributes in Resource Lists
draft-ietf-sipping-capacity-attribute-06.txt draft-ietf-sipping-capacity-attribute-07.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 35
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 June 20, 2008. This Internet-Draft will expire on February 2, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
In certain types of multimedia communications, a Session Initiation In certain types of multimedia communications, a Session Initiation
Protocol (SIP) request is distributed to a group of SIP User Agents Protocol (SIP) request is distributed to a group of SIP User Agents
(UAs). The sender sends a single SIP request to a server which (UAs). The sender sends a single SIP request to a server which
further distributes the request to the group. This SIP request further distributes the request to the group. This SIP request
contains a list of Uniform Resource Identifiers (URIs), which contains a list of Uniform Resource Identifiers (URIs), which
identify the recipients of the SIP request. This URI-list is identify the recipients of the SIP request. This URI-list is
expressed as a resource list XML document. This specification expressed as a resource list XML document. This specification
defines an XML extension to the XML resource list format that allows defines an XML extension to the XML resource list format that allows
the sender of the request to qualify a recipient with a copy control the sender of the request to qualify a recipient with a copy control
level similar to the copy control level of existing e-mail systems. level similar to the copy control level of existing e-mail systems.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of operation . . . . . . . . . . . . . . . . . . . . 4 3. Overview of operation . . . . . . . . . . . . . . . . . . . . 4
4. Extension to the resource lists data format . . . . . . . . . 6 4. Extension to the resource lists data format . . . . . . . . . 7
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Carrying URI-lists in SIP . . . . . . . . . . . . . . . . . . 11 7. Carrying URI-lists in SIP . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. Disposition Type Registration . . . . . . . . . . . . . . 13 9.1. Disposition Type Registration . . . . . . . . . . . . . . 14
9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 13 9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 15
9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 14 9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informational References . . . . . . . . . . . . . . . . . 15 11.2. Informational References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
The Framework and Security Considerations for Session Initiation The Framework and Security Considerations for Session Initiation
Protocol (SIP) URI-List Services [I-D.ietf-sipping-uri-services] Protocol (SIP) URI-List Services [I-D.ietf-sipping-uri-services]
describes a generic framework for carrying Uniform Resource describes a generic framework for carrying Uniform Resource
Identifier (URI)-lists in SIP [RFC3261] messages. Specifically, the Identifier (URI)-lists in SIP [RFC3261] messages. Specifically, the
document provides a common framework for specific implementations of document provides a common framework for specific implementations of
URI-list services, such as conferences initiated with INVITE requests URI-list services, such as conferences initiated with INVITE requests
[I-D.ietf-sip-uri-list-conferencing] or Multiple-recipient MESSAGE [I-D.ietf-sip-uri-list-conferencing] or Multiple-recipient MESSAGE
skipping to change at page 6, line 6 skipping to change at page 6, line 6
'copyControl' attribute include "to", "cc", and "bcc" (analogous to 'copyControl' attribute include "to", "cc", and "bcc" (analogous to
e-mail). This is discussed in greater detailed in Section 4. When e-mail). This is discussed in greater detailed in Section 4. When
the URI-list server expands the request to each recipient, the URI- the URI-list server expands the request to each recipient, the URI-
list server includes a recipient-history XML resource list built upon list server includes a recipient-history XML resource list built upon
the recipient list received from the sender. The recipient-history the recipient list received from the sender. The recipient-history
XML resource list replaces the recipient list in the SIP requests XML resource list replaces the recipient list in the SIP requests
generated by the URI-list server towards each recipient. The URI- generated by the URI-list server towards each recipient. The URI-
list server copies from the recipient list those targets which are list server copies from the recipient list those targets which are
marked with the "to" and "cc" copy control level, and pastes them in marked with the "to" and "cc" copy control level, and pastes them in
the recipient-history list. The URI-list server explicitly excludes the recipient-history list. The URI-list server explicitly excludes
from the copy those URIs marked with a "bcc" copy control. When a from the recipient-history list those URIs marked with a "bcc" copy
recipient receives the SIP request containing the recipient-history control, although it is able to preserve the address of a "bcc"
XML resource list, he is able to determine which other visible tagged URI when it matches the URI of the recipient of the SIP
recipients are getting the same SIP requests, and whether they are request (this is described later in Section 4). When a recipient
marked with the "to" or "cc" copy control level. Later, if needed, receives the SIP request containing the recipient-history XML
the recipient can generate a reply to those visible recipients. resource list, he is able to determine which other visible recipients
are getting a copy of the SIP request, and whether they are marked
with the "to" or "cc" copy control level. Later, if needed, the
recipient can generate a reply to those visible recipients.
In addition to the 'copyControl' attribute for a URI in an XML In addition to the 'copyControl' attribute for a URI in an XML
resource list, we define a second boolean attribute called resource list, we define a second boolean attribute called
'anonymize'. The sender of a SIP request can mark a URI in a 'anonymize'. The sender of a SIP request can mark a URI in a
recipient XML resource list with the 'anonymize' attribute to recipient XML resource list with the 'anonymize' attribute to
indicate the URI-list server that the URI marked with that attribute indicate the URI-list server that the URI marked with that attribute
is to be replaced with an anonymous URI in the recipient-history XML is to be replaced with an anonymous URI in the recipient-history XML
resource list. This provides knowledge to the recipients of a SIP resource list. This provides knowledge to the recipients of a SIP
request of the number of additional visible recipients whose URIs request of the number of additional visible recipients whose URIs
have not been disclosed. have not been disclosed.
skipping to change at page 6, line 37 skipping to change at page 6, line 40
scenario, we define a new 'count' attribute to a URI in the scenario, we define a new 'count' attribute to a URI in the
recipient-history XML resource list. It is expected that the 'count' recipient-history XML resource list. It is expected that the 'count'
attribute is only used with anonymous URIs, although syntactically it attribute is only used with anonymous URIs, although syntactically it
is possible to add a 'count' attribute to any URI in any XML resource is possible to add a 'count' attribute to any URI in any XML resource
list. list.
Initially, it may be thought that the 'anonymize' attribute overlaps Initially, it may be thought that the 'anonymize' attribute overlaps
with the "bcc" value of the 'copyControl' attribute. However, there with the "bcc" value of the 'copyControl' attribute. However, there
are differences between them. If the sender qualifies a URI with a are differences between them. If the sender qualifies a URI with a
'copyControl' attribute of "bcc" in the recipient XML resource list, 'copyControl' attribute of "bcc" in the recipient XML resource list,
the URI-list server will completely remove that URI from the the URI-list server will typically remove that URI from the
recipient-history XML resource list. Recipients of the SIP request recipient-history XML resource list (unless the URI-list server
will not notice that one or more extra URIs also received the decides to preserve a "bcc" marked URI when that URI is itself the
recipient of the SIP request). Recipients of the SIP request will
not notice that one or more extra "bcc" URIs also received the
request. However, if the sender qualifies a URI with the 'anonymize' request. However, if the sender qualifies a URI with the 'anonymize'
attribute in the recipient XML resource list, the URI-list server attribute in the recipient XML resource list, the URI-list server
will replace the URI with an anonymous one in the recipient-history will replace the URI with an anonymous one in the recipient-history
list. Recipients of the SIP request will notice that there have been list. Recipients of the SIP request will notice that there have been
one or more additional recipients of the same request, but their URIs one or more additional recipients of the same request, but their URIs
have not been disclosed. are not disclosed.
4. Extension to the resource lists data format 4. Extension to the resource lists data format
This document defines an extension to the XML resource list data This document defines an extension to the XML resource list data
format [RFC4826] that allows the sender to indicate a copy control format [RFC4826] that allows the sender to indicate a copy control
attribute that qualifies a recipient with a copy control level. We attribute that qualifies a recipient with a copy control level. We
define a new 'copyControl' attribute to the <entry> element of the define a new 'copyControl' attribute to the <entry> element of the
resource list document format [RFC4826]. The 'copyControl' attribute resource list document format [RFC4826]. The 'copyControl' attribute
has similar semantics to the type of destination address in e-mail has similar semantics to the type of destination address in e-mail
systems. It can take the values "to", "cc", and "bcc". A "to" value systems. It can take the values "to", "cc", and "bcc". A "to" value
of the 'copyControl' attribute indicates that the resource is of the 'copyControl' attribute indicates that the resource is
considered a primary recipient of the SIP request. A "cc" value considered a primary recipient of the SIP request. A "cc" value
indicates that the resource receives a carbon copy of the SIP indicates that the resource receives a carbon copy of the SIP
request. A "bcc" value indicates that the resource receives a blind request. A "bcc" value indicates that the resource receives a blind
carbon copy of the SIP request (i.e., this URI is not disclosed in carbon copy of the SIP request (i.e., this URI is not disclosed to
the recipient-history list). The default 'copyControl' value is other recipients of the SIP request). The default 'copyControl'
"bcc". That is, the absence of a 'copyControl' attribute MUST be value is "bcc". That is, the absence of a 'copyControl' attribute
treated as if the 'copyControl' was set to "bcc". URI-list servers MUST be treated as if the 'copyControl' was set to "bcc".
use URIs marked with the "bcc" 'copyControl' attribute to route SIP
requests, but MUST NOT include them in recipient-history lists. When creating a recipient-history list, URI-list servers use "bcc"
'copyControl' attributes to route SIP requests. In addition, URI-
list servers behave similarly to e-mail systems [RFC2822] with
respect to the treatment of these URIs marked with a "bcc" copy
control, because they have two ways of treating "bcc" marked URIs.
URI-list servers MUST treat these "bcc" marked URIs in either of the
following two ways:
o URI-list servers MUST remove all URIs marked with a "bcc" copy
control in recipient-history lists. This mechanism allows URI-
list servers to send the same recipient-history list to each
recipient of the SIP request. However, recipients who are tagged
with "bcc" values are not explicitly informed about it.
o URI-list servers MUST preserve with a "bcc" copy control in the
recipient-history list the URI that identifies the recipient (if
any) and MUST remove the remaining URIs marked with a "bcc" copy
control. Consequently, each recipient receives a different
recipient-history list. However, recipients who have been marked
with a "bcc" copy control are explicitly informed about it.
Implementations that are able to receive recipient-history lists must
pay attention to the contents of the list. If the recipient's URI is
not included in recipient-history list or if it is included but
tagged with a "bcc" copy control, then implementations SHOULD prevent
the user from replying to all the recipients of the SIP request.
This would allow the non-blind recipients to notice the existence of
blind recipients of the SIP request.
A new 'anonymize' attribute can be included in a <entry> element of A new 'anonymize' attribute can be included in a <entry> element of
the resource list document format [RFC4826]. If set to a "true" the resource list document format [RFC4826]. If set to a "true"
value, it provides an indication to the URI-list server for not value, it provides an indication to the URI-list server for not
disclosing the URI itself in a URI-list sent to the recipient, but disclosing the URI itself in a URI-list sent to the recipient, but
instead, to anonymize the URI (i.e., making it bogus in the instead, to anonymize the URI (i.e., making it bogus in the
recipient-history XML resource list). URI-list servers can use URIs recipient-history XML resource list). URI-list servers can use URIs
tagged with the 'anonymize' attribute for routing SIP requests, but tagged with the 'anonymize' attribute for routing SIP requests, but
MUST convert them the SIP URI "sip:anonymous@anonymous.invalid" in MUST convert them the SIP URI "sip:anonymous@anonymous.invalid" in
recipient-history lists. The default value of the 'anonymize' recipient-history lists. The default value of the 'anonymize'
skipping to change at page 9, line 5 skipping to change at page 9, line 9
The 'copyControl', 'anonymize', and 'count' attributes SHOULD be The 'copyControl', 'anonymize', and 'count' attributes SHOULD be
included as modifiers of any of the child elements included in the included as modifiers of any of the child elements included in the
<list> element of a resource list (e.g., attribute of the <entry> or <list> element of a resource list (e.g., attribute of the <entry> or
<external> elements). <external> elements).
Section 5 describes the format of the 'copyControl', 'anonymize', and Section 5 describes the format of the 'copyControl', 'anonymize', and
'count' attributes. Implementations according to this specification 'count' attributes. Implementations according to this specification
MUST support this XML Schema. MUST support this XML Schema.
5. XML Schema Implementations that receive recipient-history lists must pay
attention to the contents of the list. If the recipient's URI is not
included in recipient-history list or if it is included but tagged
with a "bcc" copy control, then they SHOULD prevent the user from
replying to all the recipients of the SIP request. This would allow
the non-blind recipients to notice the existence of blind recipients
in the original SIP request.
5. XML Schema
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:copycontrol" <xs:schema targetNamespace="urn:ietf:params:xml:ns:copycontrol"
xmlns="urn:ietf:params:xml:ns:copycontrol" xmlns="urn:ietf:params:xml:ns:copycontrol"
xmlns:rls="urn:ietf:params:xml:ns:resource-lists" xmlns:rls="urn:ietf:params:xml:ns:resource-lists"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
<xs:documentation xml:lang="en"> <xs:documentation xml:lang="en">
skipping to change at page 10, line 51 skipping to change at page 11, line 49
with a 'copyControl' attribute set to "to" and 'anonymize' attribute with a 'copyControl' attribute set to "to" and 'anonymize' attribute
set to "true" are replaced with the SIP anonymous URI set to "true" are replaced with the SIP anonymous URI
"sip:anonymous@anonymous.invalid". In this entry the URI-list server "sip:anonymous@anonymous.invalid". In this entry the URI-list server
also adds the original value of the 'copyControl' attribute ("to" in also adds the original value of the 'copyControl' attribute ("to" in
our example), and it adds a 'count' attribute containing the number our example), and it adds a 'count' attribute containing the number
of anonymous entries in this group ("2" in our example). Then the of anonymous entries in this group ("2" in our example). Then the
URI-list server does the same operation to the URIs tagged with the URI-list server does the same operation to the URIs tagged with the
'copyControl' attribute set to "cc" and 'anonymize' attribute set to 'copyControl' attribute set to "cc" and 'anonymize' attribute set to
"true", adding also the 'count' attribute containing the number of "true", adding also the 'count' attribute containing the number of
anonymous attributes in this group ("1" in the example). Last, the anonymous attributes in this group ("1" in the example). Last, the
URI-list server completely removes URIs marked with the "bcc" URI-list server removes all URIs marked with the "bcc" 'copyControl'
'copyControl' attribute. The resulting recipient-history list is attribute. The resulting recipient-history list is shown in
shown in Figure 4. Figure 4.
<?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:copycontrol"> xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list> <list>
<entry uri="sip:bill@example.com" cp:copyControl="to" /> <entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to" <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to"
cp:count="2"/> cp:count="2"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" /> <entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc" <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc"
skipping to change at page 13, line 10 skipping to change at page 14, line 7
encryption mechanism. encryption mechanism.
Note that this URI-list does not indicate the actual participants in Note that this URI-list does not indicate the actual participants in
the session. It indicates only the URIs invited and that might the session. It indicates only the URIs invited and that might
accept the request. It does not assert that these parties actually accept the request. It does not assert that these parties actually
exist, that they are reachable at the given URI, or that they have exist, that they are reachable at the given URI, or that they have
accepted the invitation. No inferences about billing should be made accepted the invitation. No inferences about billing should be made
from this information. It is subject to spoofing by loading the list from this information. It is subject to spoofing by loading the list
with falsified content. with falsified content.
Issuers of SIP request use the "bcc" copy control attribute described
in Section 4 to facilitate sending SIP requests to recipients without
revealing the URIs of one or more of the other recipients.
Mishandling this use of "bcc" copy control has implications for
confidential information that might be revealed, which could
eventually lead to security problems through knowledge of even the
existence of a particular URI. For example, if using the first
method described in Section 4, where the "bcc" tagged URIs are
removed from recipient-history list, blind recipients have no
explicit indication that they have been sent a blind copy of the SIP
request, except insofar as their URI does not appear in the
recipient-history list. Because of this, one of the blind URIs could
potentially send a reply to all of the shown recipients and
accidentally reveal that the message went to the blind recipient.
When the second method from Section 4 is used, the blind recipient's
address appears in the recipient-history list of a separate copy of
the list. If the "bcc" tagged URI sent contains all of the "bcc"
tagged URIs, all of the "bcc" recipients will be seen by each "bcc"
recipient. Even if a separate message is sent to each "bcc"
recipient with only the individual's URI, implementations still need
to be careful to process replies to the message as per Section 4 so
as not to accidentally reveal the blind recipient to other
recipients.
9. IANA Considerations 9. IANA Considerations
The following sections instruct the IANA to register: a new The following sections instruct the IANA to register: a new
disposition type, a new XML namespace, and a new XML schema. disposition type, a new XML namespace, and a new XML schema.
9.1. Disposition Type Registration 9.1. Disposition Type Registration
Section 7 defines a new 'recipient-list-history' value of the Mail Section 7 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
skipping to change at page 14, line 42 skipping to change at page 16, line 12
Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org), Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org),
Miguel Garcia-Martin (miguel.an.garcia@nokia.com). Miguel Garcia-Martin (miguel.an.garcia@nokia.com).
The XML for this schema can be found as the sole content of The XML for this schema can be found as the sole content of
Section 5. Section 5.
10. Acknowledgements 10. Acknowledgements
Thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, Atsushi Sato, Thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, Atsushi Sato,
Brian Rosen, Mary Barnes, James Polk, and Brian E. Carpenter for Brian Rosen, Mary Barnes, James Polk, Brian E. Carpenter, and Chris
reviewing this document and providing helpful comments. Newman for reviewing this document and providing helpful comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Presentation Information in Internet Messages: The
skipping to change at page 15, line 45 skipping to change at page 17, line 11
[I-D.ietf-sipping-uri-services] [I-D.ietf-sipping-uri-services]
Camarillo, G. and A. Roach, "Framework and Security Camarillo, G. and A. Roach, "Framework and Security
Considerations for Session Initiation Protocol (SIP) Considerations for Session Initiation Protocol (SIP)
Uniform Resource Identifier (URI)-List Services", Uniform Resource Identifier (URI)-List Services",
draft-ietf-sipping-uri-services-07 (work in progress), draft-ietf-sipping-uri-services-07 (work in progress),
November 2007. November 2007.
11.2. Informational References 11.2. Informational References
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[I-D.ietf-sip-uri-list-conferencing] [I-D.ietf-sip-uri-list-conferencing]
Camarillo, G. and A. Johnston, "Conference Establishment Camarillo, G. and A. Johnston, "Conference Establishment
Using Request-Contained Lists in the Session Initiation Using Request-Contained Lists in the Session Initiation
Protocol (SIP)", draft-ietf-sip-uri-list-conferencing-02 Protocol (SIP)", draft-ietf-sip-uri-list-conferencing-02
(work in progress), November 2007. (work in progress), November 2007.
[I-D.ietf-sip-uri-list-message] [I-D.ietf-sip-uri-list-message]
Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient
MESSAGE Requests in the Session Initiation Protocol MESSAGE Requests in the Session Initiation Protocol
(SIP)", draft-ietf-sip-uri-list-message-02 (work in (SIP)", draft-ietf-sip-uri-list-message-03 (work in
progress), November 2007. progress), December 2007.
[I-D.ietf-sip-body-handling] [I-D.ietf-sip-body-handling]
Camarillo, G., "Message Body Handling in the Session Camarillo, G., "Message Body Handling in the Session
Initiation Protocol (SIP)", Initiation Protocol (SIP)",
draft-ietf-sip-body-handling-00 (work in progress), draft-ietf-sip-body-handling-02 (work in progress),
August 2007. May 2008.
Authors' Addresses Authors' Addresses
Miguel A. Garcia-Martin Miguel A. Garcia-Martin
Nokia Siemens Networks Ericsson
P.O.Box 6 Via de los Poblados 13
Nokia Siemens Networks, FIN 02022 Madrid 28033
Finland Spain
Email: miguel.garcia@nsn.com Email: miguel.a.garcia@ericsson.com
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 17, line 44 skipping to change at line 775
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 21 change blocks. 
56 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/