Network Working Group A. Niemi Internet-Draft M. Garcia-Martin Expires: April 20, 2005 Nokia October 20, 2004 Multi-party Message Sessions using the Message Session Relay Protocol (MSRP) draft-niemi-simple-chat-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each 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 become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 20, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract The Message Session Relay Protocol (MSRP) defines a mechanism for sending session-based instant messages. The session is negotiated using the Session Initiation Protocol (SIP). This document describes how MSRP can be used to create multi-party message sessions using the tightly coupled conferencing model. It defines conventions and extensions for enabling features similar to many existing services in Niemi & Garcia-Martin Expires April 20, 2005 [Page 1] Internet-Draft Multiparty MSRP October 2004 the Internet, e.g., Internet Relay Chat (IRC) based chat rooms, such as setting up nicknames, sending private messages to a subset of the multi-party conference, etc. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Multiparty Session Based Instant Messaging Conferencing . . . 5 5.1 Creating/deleting a chat room . . . . . . . . . . . . . . 6 5.2 Sending instant messages within a chat room . . . . . . . 6 5.3 Procedures at the MSRP switch . . . . . . . . . . . . . . 7 5.4 Procedures at the recipient . . . . . . . . . . . . . . . 8 6. Nicknames . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1 Representation of a nickname . . . . . . . . . . . . . . . 10 6.2 Provision of nicknames . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 9.2 Informative References . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Niemi & Garcia-Martin Expires April 20, 2005 [Page 2] Internet-Draft Multiparty MSRP October 2004 1. Introduction The Message Session Relay Protocol (MSRP) [I-D.ietf-simple-message-sessions] defines a mechanism for sending a series of instant messages within a session. The Session Initiation Protocol (SIP) [RFC3261] allows for two peers to set up such a session. In another application of SIP, a user agent can join in a multi-party session or conference that is hosted by a specialized user agent called a conference focus [I-D.ietf-sipping-conferencing-framework]. Such a conference can naturally involve an MSRP session as media. The conference focus is responsible for relaying session-based instant messages received from one participant to all the other participants. A session-based instant messaging conference is sometimes also referred to as a chat room, and the conference focus is sometimes referred to as the chat room server. Several of these types of systems already exist in the Internet. Participants in a chat room can use a rich set of features, such as the ability of sending private instant messages to one or more participants, or to establish sub-conferences within the existing conference. The aim of this document is to define conventions, requirements and extensions for enabling features similar to many of these existing applications in the Internet, e.g., Internet Relay Chat (IRC) based chat rooms. This memo uses the SIP Conferencing Framework [I-D.ietf-sipping-conferencing-framework] as a design base to define a set of requirements for protocols such as SIP [RFC3261], SDP [RFC2327], and MSRP [I-D.ietf-simple-message-sessions] that enrich session based messaging conferences. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. This memo deals with a particular case of tightly coupled SIP conferences where the media exchanged consist of session-based instant messaging. Unless otherwise noted, we use the terminology defined in the SIP Conferencing Framework [I-D.ietf-sipping-conferencing-framework] applied to the scope of this document. In addition to that terminology, we introduce some new terms: Niemi & Garcia-Martin Expires April 20, 2005 [Page 3] Internet-Draft Multiparty MSRP October 2004 Nickname: a descriptive name associated to a participant. A nickname is non-routable pseudonym that the participant chooses for the purpose of additional identification towards the rest of the participants. Session-based instant messaging conference: a particular case of a tightly coupled conference (as defined by the SIP Conferencing Framework [I-D.ietf-sipping-conferencing-framework]) where the media exchanged between the participants consist of session based instant messages transported with MSRP [I-D.ietf-simple-message-sessions]. Typically a session based message conference is referred to as a chat room>. Chat room: a session-based instant messaging conference. MSRP switch: an MSRP endpoint that receives MSRP messages and redistributes them to each conference participant. An MSRP switch has a similar role as a mixer (as defined by the SIP Conferencing Framework [I-D.ietf-sipping-conferencing-framework]), however an MSRP switch does not combine different input media streams; it merely distributes incoming MSRP messages to the conference participants. Private instant message: a session based instant message whose intended list of destinations is explicitly signaled and is a subset of the conference participants, rather than all the participants of the conference. 3. Motivation SIP already provides a Conferencing Framework [I-D.ietf-sipping-conferencing-framework] that can be utilized in many types of conferencing applications, including session-based instant messaging conference. It seems beneficial to provide a set of features that enhance the conference in order to compete in functionality with existing session-based instant messaging conference systems. 4. Requirements A number of requirements that enrich the session based messaging conferences have already been described in Requirements for Instant Messaging in 3GPP Wireless Systems [I-D.niemi-simple-im-wireless-reqs] or the Advanced Instant Messaging Requirements for the Session Initiation Protocol [I-D.rosenberg-simple-messaging-requirements]. Niemi & Garcia-Martin Expires April 20, 2005 [Page 4] Internet-Draft Multiparty MSRP October 2004 In addition, we define the following requirements: REQ-1: A conference focus may be acting as the focus of a specialized conference where the media stream is composed of session-based instant messaging. REQ-2: It must be possible that participants join or leave a particular session-based instant messaging conference. REQ-3: The conference can host other medias than session based messaging. REQ-4: It must be possible to inform the sender of a session based messaging about the acceptance of the message for distribution. REQ-5: It must be possible to get the time-stamp at which the MSRP switch dispatched a message. REQ-6: The message sequence witnessed by different endpoints must be identical across all the participants. REQ-7: A conference participant must be able to determine the identity of the sender of the message. REQ-8: A conference participant must be able to determine the target of the received message. For instance, the message might be addressed to the whole conference, a sidebar conference or just the recipient of the message (private message). REQ-9: It must be possible to set up a sidebar session with one or more participants of the conference. REQ-10: It must be possible to send a message to one or more participants of the conference (private instant message). REQ-11: A conference participant may have a nickname or pseudonym associated to him. REQ-12: It must be possible for a participant to change his nickname during the progress of the conference. REQ-13: It must be possible that a participant only reveals his nickname to the rest of the conference participants, but it does not reveal his SIP URI. REQ-14: On sending private messages, it might be possible that the sender sends private messages to participants who have only revealed their nickname, but not their routable SIP URI. REQ-15: It must be possible that the MSRP switch is a contributor that sends messages to the participants (e.g., message of the day, welcome message, server is shutting down, etc.) REQ-16: A session based instant messaging conference or sidebar conference can be characterized with a topic whose purpose is to identify the subject of conversation. REQ-17: A user with the appropriate privileges must be able to set and modify the topic of the conference or sidebar conference. 5. Multiparty Session Based Instant Messaging Conferencing Niemi & Garcia-Martin Expires April 20, 2005 [Page 5] Internet-Draft Multiparty MSRP October 2004 5.1 Creating/deleting a chat room Since we consider a chat room a particular type of conferences where the media happens to be session based instant messaging (MSRP), the methods defined by the SIP Conference Framework [I-D.ietf-sipping-conferencing-framework]to create and delete conferences are applicable to the chat room. Once a session based message conference is created, the conference is identified by a URI, like any other conference. Participants are aware that the peer is a focus due to the presence of the "isfocus" feature tag in the Contact header field of the 2xx-class response to the INVITE request. Participants are also aware that the mixer is an MSRP switch due to the presence of the 'message' media type and the MSRP [I-D.ietf-simple-message-sessions] in the SDP [RFC2327]. In a one-to-one MSRP session, an instant message is identified by the transport connection on which they arrive and the resource identifier. The endpoint can map the MSRP transport connection and resource identifier where the message was received to the SIP URI of the sender, through the SIP session that established the MSRP session. In a chat room the problem becomes a bit more complicated. An endpoint has a single transport connection and resource identifier to the MSRP switch. The MSRP switch is sending to the endpoint any instant message received from all of the other conference participants. Therefore, an endpoint can only map the MSRP transport connection and resource identifier to the chat room URI, but the endpoint cannot identify the sender of the instant message. It becomes necessary that each session-based instant message carries in it an identifier of the sender of the message. This is accomplished by wrapping each instant message in a 'message/cpim' MIME type envelope, defined in RFC 3862 [RFC3862]. The conference focus MUST use the 'message/cpim' as the top-level wrapper type in an SDP offer or answer, as defined in MSRP [I-D.ietf-simple-message-sessions]. 5.2 Sending instant messages within a chat room MSRP provides for the existence of a SEND primitive that allows a sender to transport an instant message to the receiver. The actual data is enclosed in a body. MSRP mandates implementations to support the message/cpim format. A conference-aware participant that sends an MSRP SEND request to an MSRP switch SHOULD enclose the contents of the actual message in a message/cpim MIME-type format. The message/cpim format allows to wrap the actual instant message payload in other message formats such as text/plain, text/html, etc. Niemi & Garcia-Martin Expires April 20, 2005 [Page 6] Internet-Draft Multiparty MSRP October 2004 NOTE: Wrapping the actual contents into a message/cpim provides the session based messaging focus with better CPIM compatibility. Additionally, the focus may need to distribute copies of the messages to the rest of the participants in a message/cpim format, thus, if the sender sends the message already in message/cpim format the focus is relieved from the task of doing format conversion. A conference-aware participant that sends a session based instant message to an MSRP switch SHOULD populate the From header of the message/cpim wrapper with her nickname (see the nicknames discussion in Section Section 6. A conference-aware participant that sends a session based instant message addressed to the chat room or a sidebar chat room MUST set the To header of the message/cpim to the chat room URI or sidebar chat room, respectively. A conference-aware participant that sends a session based private instant message to one or more participants of the conference MUST include the nickname of the each of the intended receivers in either the To or Cc headers of the message/cpim. SIP URIs might not be always available to the sender, e.g., if the participant decided not to expose her SIP URI for anonymity reasons, or there might not be means to bind the participant's SIP URI to his MSRP URI. OPEN ISSUE: the paragraph above assumes that the participant receives somehow the nicknames of each of the participants. Is this assumption valid? Will the conference package have elements to include nicknames? Or shall we define that extension? 5.3 Procedures at the MSRP switch An MSRP switch can receive messages sent from either conference-aware participants or conference-unaware participants. The former will follow the procedures indicated in this document and will send message/cpim wrapped messages. It is not guaranteed that the latter will send a message/cpim message. On receiving an MSRP message, the MSRP switch MUST first inspect whether a message/cpim wrapper is inserted. If it is, the MSRP switch then checks the From header of the message/cpim wrapper. If the From header contains an IM URI scheme, then it is the nickname of the sender. Then the MSRP switch checks the To and Cc headers of the message/cpim wrapper. If the To or Cc headers contain a SIP URI, then the message is addressed to the whole chat room or a sidebar chat room. The MSRP switch MUST determine the MSRP URIs of the participants of that chat room or sidebar SIP URI, and then the MSRP Niemi & Garcia-Martin Expires April 20, 2005 [Page 7] Internet-Draft Multiparty MSRP October 2004 switch MUST generate a copy of the message/cpim message to each of those participants, including the sender of the message. This message SHOULD contain a copy of the contents of the received message/cpim message, particularly the MSRP switch MUST preserve the contents of the From and To headers. The MSRP switch SHOULD include a DateTime header in the message/cpim with an updated value of the date and time when the MSRP switch dispatched the message. Once done, the MSRP switch SHOULD create a new MSRP SEND message request for each of the addressed participants and include the message/cpim message. If the From header of the message/cpim message does not include SIP URI, but an IM URI, then the MSRP switch determines that the message is a private message intended for a few recipients only. The MSRP switch MUST examine the To and Cc headers of the message/cpim to find out the nicknames of all the intended recipients, and then the MSRP switch MUST determine from its table the MSRP URI of each of the IM URIs included in the To and Cc headers. For each of the intended recipients, the MSRP switch MUST then the MSRP switch MUST generate a copy of the message/cpim message to each of those participants, including the sender of the message. This message SHOULD contain a copy of the contents of the received message/cpim message, particularly the MSRP switch MUST preserve the contents of the From and To headers. The MSRP switch SHOULD include a DateTime header in the message/cpim with an updated value of the date and time when the MSRP switch dispatched the message. Once done, the MSRP switch SHOULD create a new MSRP SEND request for each of the addressed participants and include the message/cpim message. If the MSRP switch receives an MSRP SEND request that does not contain a message/cpim message, then it has been sent from a conference-unaware sender. The MSRP switch shall wrap the contents of the message in a message/cpim message. If The MSRP switch is aware of the sender's nickname somehow, it should populate it in the From header of message/cpim, otherwise it should populate the SIP URI of the sender. The MSRP switch SHOULD set the To header to the SIP URI of the chat room. Then the MSRP switch MUST create and send an MSRP SEND request containing the message/cpim to each of the participants of the conference, including the sender. 5.4 Procedures at the recipient Both conference-aware and conference-unaware participants will receive MSRP SEND requests that contains a message/cpim message from an MSRP switch. The From header contains the nickname of the contributor. The To and Cc headers contain the intended recipient list, which can either be the SIP URI of the chat room or sidebar chat room or sidebar chat room, o an IM URI containing the nickname Niemi & Garcia-Martin Expires April 20, 2005 [Page 8] Internet-Draft Multiparty MSRP October 2004 of the intended recipient. If the recipient is subscribed to the conference event package at the focus, he can map the nickname of the sender or intended recipients with a SIP URI, providing that such participant didn't want to remain anonymous. The DateTime header of the message/cpim contains the date and time at which the MSRP switch dispatched the message. This can be used to give an indication to the user. In other cases the received message was sent by the recipient itself. This gives the user an indication of the place in the sequence of messages where his message was inserted. 6. Nicknames A common characteristic of existing chat room servers is that participants have the ability to identify themselves with a nickname to the rest of the participants in a conference. This provides a layer of anonymity, whereby the user is authenticated and identified by the chat room server, but not by participants of the chat room. A nickname is a string of characters that serves for the purpose of identifying a participant to the rest of the participants of the conference. A nickname can match the participant name, or identify any characteristic, but it can be any other string that is not associated with the participant at all. A nickname can be also a collection of characters that do not make sense in any language, as a mechanism to provide some anonymity of the nickname. For the purpose of the chat room functionality, a nickname is also composed of a URI, which need not be a routable URI, nor it even need to be a SIP URI. The MSRP switch needs to map this kind of URIs to the actual MSRP URI of a participant. This allows to distribute private messages to participants that have not disclosed their SIP URI to the rest of the conference participants. Users are allowed to choose any nickname of their wish when they join the conference. The only prerequisite is that the nickname is not already in used by another participant. The nickname ought to be unique within the set of conference managed by the focus. This property allows a participant to join several conferences hosted by the same focus and still keep the same nickname across all those conferences. Note that we don't require a nickname to be globally unique, but just locally unique within the focus. Nicknames are non-routable identifiers. A participant of a Niemi & Garcia-Martin Expires April 20, 2005 [Page 9] Internet-Draft Multiparty MSRP October 2004 conference cannot derive the SIP or MSRP URI, or the IP address out of the nickname chosen by another participant. Certainly the MSRP switch binds nicknames with their respective MSRP URIs, however, this binding exists only in the MSRP switch and is not visible to the participants of the chat room. This property allows also a participant to send a private instant message to a second participant who is identified only by her nickname. 6.1 Representation of a nickname A nickname is syntactically defined as the combination of a display name and an IM URI. The IM URI [RFC3860] may be a non-routable URI, since the purpose of the URI is not to identify a SIP or MSRP entity. This avoids routing based on the contents of a nickname. A non routable URI may be created by appending ".invalid" to an existing domain name. We define conventions that allow to a sender to include a nickname in the From, To or Cc headers of a message/cpim document. These headers are already defined in RFC 3862 [RFC3862] with the following syntax: From-header = "From" ": " [ Formal-name ] "<" URI ">" To-header = "To" ": " [ Formal-name ] "<" URI ">" Cc-header = "cc" ": " [ Formal-name ] "<" URI ">" A non-routable IM URI follows the format of a Network Access Identifier (NAI) (RFC 2486) [RFC2486]. Appending the domain ".invalid" to a NAI can make it non-routable. We chose an IM URI rather than a SIP URI since the purpose of the URI is not to identify a SIP entity. Examples of nickname: "Prince of the snow" A nickname is scoped to be valid in the focus address space. The focus maintains a binding between nicknames and SIP URIs that allows to route private instant messages to the appropriate participant. However, this binding is not visible outside the focus, in particular, it is not visible to the participants of the conference. We represent nicknames in the From, To and Cc headers in the message/cpim. If the message is a addressed to the whole chat room, the To header of the CPIM message contains the chat room SIP URI. If the message is a private message addressed to a subset of the participants, To and Cc headers include the nicknames of each of the intended recipients. The following examples shows a CPIM private message sent from a participant to a subset of the conference Niemi & Garcia-Martin Expires April 20, 2005 [Page 10] Internet-Draft Multiparty MSRP October 2004 participants. Content-Type: message/cpim From: "Prince of the snow" To: "Blue Arrow" To: "Daisy" Cc: "Hook" DateTime: 2004-01-28T15:43:00-02:00 Content-Type: text/plain Content-ID: <092380923@foo.com> This is an example of a private instant message In any case, the sender of the instant message always follows the procedures defined in MSRP [I-D.ietf-simple-message-sessions] to compose an MSRP SEND request. 6.2 Provision of nicknames A participant of a conference controlled by a particular focus can setup his nickname by any means outside the scope of this document. For instance, the participant can log into a web page where he authenticates and sets up his nickname. OPEN ISSUE: Do we need to provide a mechanism with SIP to negotiate nicknames? 7. IANA Considerations This document does not include any IANA considerations. 8. Security Considerations In general, messages sent to a multi-party session based messaging focus are not deem to expose any security threat. Nevertheless, if a participant wants to avoid eavesdropping from non authorized entities, it should send those messages a TLS [RFC2246] transport connection, as allowed by MSRP. 9. References 9.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Niemi & Garcia-Martin Expires April 20, 2005 [Page 11] Internet-Draft Multiparty MSRP October 2004 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [RFC3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004. [RFC3860] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004. [W3C.REC-xml-20001006] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C FirstEdition REC-xml-20001006, October 2000. [I-D.ietf-sipping-conferencing-framework] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-03 (work in progress), October 2004. [I-D.ietf-simple-message-sessions] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-08 (work in progress), August 2004. Niemi & Garcia-Martin Expires April 20, 2005 [Page 12] Internet-Draft Multiparty MSRP October 2004 9.2 Informative References [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [I-D.niemi-simple-im-wireless-reqs] Niemi, A., "Requirements for Instant Messaging in 3GPP Wireless Systems", draft-niemi-simple-im-wireless-reqs-02 (work in progress), October 2003. [I-D.rosenberg-simple-messaging-requirements] Rosenberg, J., "Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP)", draft-rosenberg-simple-messaging-requirements-01 (work in progress), February 2004. Authors' Addresses Aki Niemi Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com Miguel A. Garcia-Martin Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 480 4586 EMail: miguel.an.garcia@nokia.com Niemi & Garcia-Martin Expires April 20, 2005 [Page 13] Internet-Draft Multiparty MSRP October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Niemi & Garcia-Martin Expires April 20, 2005 [Page 14]