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" <im:johnny@example.com.invalid>
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" <im:johnny@example.com.invalid>
To: "Blue Arrow" <im:bluearrow@example.com.invalid>
To: "Daisy" <im:daisy@example.com.invalid>
Cc: "Hook" <im:doe@example.com.invalid>
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]