draft-ietf-sipping-multiple-refer-01.txt   draft-ietf-sipping-multiple-refer-02.txt 
SIPPING Working Group G. Camarillo SIPPING Working Group G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: March 24, 2005 A. Niemi Expires: May 2, 2005 A. Niemi
H. Khartabil
M. Isomaki M. Isomaki
M. Garcia-Martin M. Garcia-Martin
Nokia Nokia
September 23, 2004 H. Khartabil
Telio
November 2004
Refering to Multiple Resources in the Session Initiation Protocol Refering to Multiple Resources in the Session Initiation Protocol
(SIP) (SIP)
draft-ietf-sipping-multiple-refer-01.txt draft-ietf-sipping-multiple-refer-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 March 24, 2005. This Internet-Draft will expire on May 2, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
Abstract Abstract
This document defines extensions to the SIP REFER method so that this This document defines extensions to the SIP REFER method so that this
method can be used to refer servers to multiple resources. These method can be used to refer servers to multiple resources. These
extensions include the use of pointers to Uniform Resource Identifier extensions include the use of pointers to Uniform Resource Identifier
skipping to change at page 5, line 23 skipping to change at page 5, line 23
6. Behavior of SIP REFER-Issuers 6. Behavior of SIP REFER-Issuers
As indicated in Section 4 and Section 5 a SIP REFER-Issuer that As indicated in Section 4 and Section 5 a SIP REFER-Issuer that
creates a REFER request with multiple REFER-Targets includes a creates a REFER request with multiple REFER-Targets includes a
"multiple-refer" and a "norefersub" option-tags in the Require header "multiple-refer" and a "norefersub" option-tags in the Require header
field. field.
The Refer-To header field of a REFER request with multiple The Refer-To header field of a REFER request with multiple
REFER-Targets MUST contain a pointer (i.e., a Content-ID Uniform REFER-Targets MUST contain a pointer (i.e., a Content-ID Uniform
Resource Locator (URL) [2]) that points to the body part that carries Resource Locator (URL) [2]) that points to the body part that carries
the URI-list. the URI-list. The REFER-Issuer SHOULD NOT include any particular URI
more than once in the URI-list.
7. Behavior of REFER-Recipients 7. Behavior of REFER-Recipients
The REFER-Recipient follows the rules in Section 2.4.2 of RFC 3515 The REFER-Recipient follows the rules in Section 2.4.2 of RFC 3515
[5] to determine the status code of the response to the REFER. [5] to determine the status code of the response to the REFER.
If the URI-list contains a URI more than once, the REFER-Recipient
MUST behave as if that URI appeared in the URI-list only once. The
REFER-Recipient uses the comparison rules specific to the URI scheme
of each of the URIs in the URI-list to determine if there is any URI
which appears more than once.
The REFER-Recipient follows the rules in RFC 3515 [5] to generate the The REFER-Recipient follows the rules in RFC 3515 [5] to generate the
necessary requests towards the REFER-Targets, acting as if it had necessary requests towards the REFER-Targets, acting as if it had
received a regular (no URI-list) REFER per each URI in the URI-list. received a regular (no URI-list) REFER per each URI in the URI-list.
8. Default URI-List Format 8. Default URI-List Format
The default format for URI-list bodies used in a multiple REFER The default format for URI-list bodies used in a multiple REFER
request is the resource list document specified in [6]. User agents request is the resource list document specified in [6]. User agents
able to generate or receive REFERs with multiple REFER-Targets MUST able to generate or receive REFERs with multiple REFER-Targets MUST
support this format as specified in [6] and MAY support other support this format as specified in [6] and MAY support other
skipping to change at page 6, line 24 skipping to change at page 6, line 31
<entry uri="sip:joe@example.org" /> <entry uri="sip:joe@example.org" />
<entry uri="sip:ted@example.net" /> <entry uri="sip:ted@example.net" />
</list> </list>
</resource-lists> </resource-lists>
Figure 1: URI List Figure 1: URI List
9. Example 9. Example
Figure 2 shows an example flow where a REFER-Issuer sends a Figure 2 shows an example flow where a REFER-Issuer sends a
multiple-REFER request to a REFER-Recipient. The REFER-Recipient multiple-REFER request to the focus of a conference, which acts as
generates a BYE request per REFER-Target. the REFER-Recipient. The REFER-Recipient generates a BYE request per
REFER-Target. (How to use REFER to remove participants from a
conference is specified in [10].)
+--------+ +---------+ +--------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+
| REFER | | REFER | | REFER | | REFER | | REFER | | REFER | | REFER | | REFER | | REFER | | REFER |
| issuer | |recipient| |target 1| |target 2| |target 3| | issuer | |recipient| |target 1| |target 2| |target 3|
+--------+ +---------+ +--------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+
| 1. REFER | | | | | 1. REFER | | | |
| ---------------->| | | | | ---------------->| | | |
| 2. 202 Accepted | | | | | 2. 202 Accepted | | | |
|<---------------- | 3. BYE | | | |<---------------- | 3. BYE | | |
| | ------------->| | | | | ------------->| | |
| | 4. BYE | | | | | 4. BYE | | |
skipping to change at page 9, line 36 skipping to change at page 9, line 36
Additionally, servers SHOULD only accept REFER requests within the Additionally, servers SHOULD only accept REFER requests within the
context of an application the server understands (e.g., a context of an application the server understands (e.g., a
conferencing application). This implies that servers MUST NOT accept conferencing application). This implies that servers MUST NOT accept
REFERs for methods they do not understand. The idea behind these two REFERs for methods they do not understand. The idea behind these two
rules is that servers are not used as dumb servers whose only rules is that servers are not used as dumb servers whose only
function is to fan-out random messages they do not understand. function is to fan-out random messages they do not understand.
11. IANA Considerations 11. IANA Considerations
This document defines a new SIP option-tag: "multiple-refer". This This document defines a new SIP option-tag: "multiple-refer". This
option-tag should be registered in the SIP parameter registry at: option-tag should be registered in the SIP Parameters registry.
http://www.iana.org/assignments/sip-parameters
SIP user agents that place the "multiple-refer" option-tag in a SIP user agents that place the "multiple-refer" option-tag in a
Supported header field understand REFER requests that contain Supported header field understand REFER requests that contain
resource list document describing multiple REFER-Targets. resource list document describing multiple REFER-Targets.
12. References 12. References
12.1 Normative References 12.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
skipping to change at page 10, line 18 skipping to change at page 10, line 17
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, [4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
November 2002. November 2002.
[5] Sparks, R., "The Session Initiation Protocol (SIP) Refer [5] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[6] Rosenberg, J., "Extensible Markup Language (XML) Formats for [6] Rosenberg, J., "Extensible Markup Language (XML) Formats for
Representing Resource Lists", Representing Resource Lists",
draft-ietf-simple-xcap-list-usage-03 (work in progress), July draft-ietf-simple-xcap-list-usage-04 (work in progress), October
2004. 2004.
[7] Olson, S., "REFER extensions", [7] Olson, S., "REFER extensions",
draft-olson-sipping-refer-extensions-02 (work in progress), July draft-olson-sipping-refer-extensions-02 (work in progress), July
2004. 2004.
[8] Camarillo, G., "Requirements and Framework for Session [8] Camarillo, G., "Requirements and Framework for Session
Initiation Protocol (SIP)Uniform Resource Identifier (URI)-List Initiation Protocol (SIP)Uniform Resource Identifier (URI)-List
Services", draft-ietf-sipping-uri-services-00 (work in Services", draft-ietf-sipping-uri-services-01 (work in
progress), July 2004. progress), October 2004.
12.2 Informational References 12.2 Informational References
[9] Rosenberg, J. and H. Schulzrinne, "A Session Initiation Protocol [9] Rosenberg, J. and H. Schulzrinne, "A Session Initiation
(SIP) Event Package for Conference State", Protocol (SIP) Event Package for Conference State",
draft-ietf-sipping-conference-package-05 (work in progress), draft-ietf-sipping-conference-package-06 (work in progress),
July 2004. October 2004.
[10] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-05 (work in progress),
October 2004.
Authors' Addresses Authors' Addresses
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
Aki Niemi Aki Niemi
Nokia Nokia
P.O. Box 321 P.O. Box 321
NOKIA GROUP, FIN 00045 NOKIA GROUP, FIN 00045
Finland Finland
EMail: Aki.Niemi@nokia.com EMail: Aki.Niemi@nokia.com
Hisham Khartabil
Nokia
P.O. Box 321
NOKIA GROUP, FIN 00045
Finland
EMail: Hisham.Khartabil@nokia.com
Markus Isomaki Markus Isomaki
Nokia Nokia
Itamerenkatu 11-13 Itamerenkatu 11-13
Helsinki 00180 Helsinki 00180
Finland Finland
EMail: Markus.Isomaki@nokia.com EMail: Markus.Isomaki@nokia.com
Miguel A. Garcia-Martin Miguel A. Garcia-Martin
Nokia Nokia
P.O.Box 407 P.O.Box 407
NOKIA GROUP, FIN 00045 NOKIA GROUP, FIN 00045
Finland Finland
EMail: miguel.an.garcia@nokia.com EMail: miguel.an.garcia@nokia.com
Hisham Khartabil
Telio
P.O. Box 1203
Olso 0110
Norway
EMail: Hisham.Khartabil@telio.no
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

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