draft-ietf-simple-message-sessions-18.txt   draft-ietf-simple-message-sessions-19.txt 
Network Working Group B. Campbell, Ed. Network Working Group B. Campbell, Ed.
Internet-Draft Estacado Systems Internet-Draft Estacado Systems
Intended status: Standards Track R. Mahy, Ed. Intended status: Standards Track R. Mahy, Ed.
Expires: June 16, 2007 Plantronics Expires: August 27, 2007 Plantronics
C. Jennings, Ed. C. Jennings, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
December 13, 2006 February 23, 2007
The Message Session Relay Protocol The Message Session Relay Protocol
draft-ietf-simple-message-sessions-18 draft-ietf-simple-message-sessions-19
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 37 skipping to change at page 1, line 37
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 16, 2007. This Internet-Draft will expire on August 27, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes the Message Session Relay Protocol, a This document describes the Message Session Relay Protocol, a
protocol for transmitting a series of related instant messages in the protocol for transmitting a series of related instant messages in the
context of a session. Message sessions are treated like any other context of a session. Message sessions are treated like any other
media stream when set up via a rendezvous or session creation media stream when set up via a rendezvous or session creation
protocol such as the Session Initiation Protocol. protocol such as the Session Initiation Protocol.
Table of Contents Table of Contents
skipping to change at page 2, line 40 skipping to change at page 2, line 40
8.1. SDP Connection and Media Lines . . . . . . . . . . . . . 28 8.1. SDP Connection and Media Lines . . . . . . . . . . . . . 28
8.2. URI Negotiations . . . . . . . . . . . . . . . . . . . . 29 8.2. URI Negotiations . . . . . . . . . . . . . . . . . . . . 29
8.3. Path Attributes with Multiple URIs . . . . . . . . . . . 30 8.3. Path Attributes with Multiple URIs . . . . . . . . . . . 30
8.4. Updated SDP Offers . . . . . . . . . . . . . . . . . . . 30 8.4. Updated SDP Offers . . . . . . . . . . . . . . . . . . . 30
8.5. Connection Negotiation . . . . . . . . . . . . . . . . . 31 8.5. Connection Negotiation . . . . . . . . . . . . . . . . . 31
8.6. Content Type Negotiation . . . . . . . . . . . . . . . . 31 8.6. Content Type Negotiation . . . . . . . . . . . . . . . . 31
8.7. Example SDP Exchange . . . . . . . . . . . . . . . . . . 33 8.7. Example SDP Exchange . . . . . . . . . . . . . . . . . . 33
8.8. MSRP User Experience with SIP . . . . . . . . . . . . . . 34 8.8. MSRP User Experience with SIP . . . . . . . . . . . . . . 34
8.9. SDP direction attribute and MSRP . . . . . . . . . . . . 35 8.9. SDP direction attribute and MSRP . . . . . . . . . . . . 35
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 35 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 35
10. Response Code Descriptions . . . . . . . . . . . . . . . . . . 38 10. Response Code Descriptions . . . . . . . . . . . . . . . . . . 37
10.1. 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.1. 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.2. 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.2. 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.3. 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.3. 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.4. 408 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.4. 408 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.5. 413 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.5. 413 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.6. 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.6. 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.7. 423 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 10.7. 423 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.8. 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 10.8. 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.9. 501 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 10.9. 501 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.10. 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 10.10. 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Basic IM Session . . . . . . . . . . . . . . . . . . . . 39 11.1. Basic IM Session . . . . . . . . . . . . . . . . . . . . 39
11.2. Message with XHTML Content . . . . . . . . . . . . . . . 42 11.2. Message with XHTML Content . . . . . . . . . . . . . . . 42
11.3. Chunked Message . . . . . . . . . . . . . . . . . . . . . 42 11.3. Chunked Message . . . . . . . . . . . . . . . . . . . . . 42
11.4. Chunked Message with message/cpim payload . . . . . . . . 42 11.4. Chunked Message with message/cpim payload . . . . . . . . 42
11.5. System Message . . . . . . . . . . . . . . . . . . . . . 43 11.5. System Message . . . . . . . . . . . . . . . . . . . . . 43
11.6. Positive Report . . . . . . . . . . . . . . . . . . . . . 44 11.6. Positive Report . . . . . . . . . . . . . . . . . . . . . 44
skipping to change at page 14, line 27 skipping to change at page 14, line 27
If an endpoint attempts to re-create a failed session in this manner, If an endpoint attempts to re-create a failed session in this manner,
it MUST NOT assume that the MSRP URIs in the SDP will be the same as it MUST NOT assume that the MSRP URIs in the SDP will be the same as
the old ones. the old ones.
A connection SHOULD NOT be closed while there are sessions associated A connection SHOULD NOT be closed while there are sessions associated
with it. with it.
6. MSRP URIs 6. MSRP URIs
URIs using the "msrp" and "msrps" schema are used to identify a URIs using the "msrp" and "msrps" schemes are used to identify a
session of instant messages at a particular MSRP device. MSRP URIs session of instant messages at a particular MSRP device, as well as
are ephemeral; an MSRP device will generally use a different MSRP URI to identify an MSRP Relay in general. This document describes the
for each distinct session. An MSRP URI generally has no meaning former usage; The latter usage is described in the MSRP Relay
outside of the associated session. specification [23]. MSRP URIs that identify sessions are ephemeral;
an MSRP device will use a different MSRP URI for each distinct
session. An MSRP URI that identifies a session has no meaning
outside the scope of that session.
An MSRP URI follows a subset of the URI syntax in Appendix A of An MSRP URI follows a subset of the URI syntax in Appendix A of
RFC3986 [10], with a scheme of "msrp" or "msrps". The syntax is RFC3986 [10], with a scheme of "msrp" or "msrps". The syntax is
described in Section 9. described in Section 9.
MSRP URIs are primarily expected to be generated and exchanged MSRP URIs are primarily expected to be generated and exchanged
between systems, and are not intended for "human consumption". between systems, and are not intended for "human consumption".
Therefore, they are encoded entirely in US-ASCII. Therefore, they are encoded entirely in US-ASCII.
The constructions for "userinfo", and "unreserved" are detailed in The constructions for "authority", "userinfo", and "unreserved" are
RFC3986 [10]. In order to allow IPV6 addressing, the construction detailed in RFC3986 [10]. URIs designating MSRP over TCP MUST
for hostport is that used for SIP in RFC3261. URIs designating MSRP include the "tcp" transport parameter.
over TCP MUST include the "tcp" transport parameter.
Since this document only specifies MSRP over TCP, all MSRP URIs Since this document only specifies MSRP over TCP, all MSRP URIs
herein use the "tcp" transport parameter. Documents that provide herein use the "tcp" transport parameter. Documents that provide
bindings on other transports should define respective parameters bindings on other transports should define respective parameters
for those transports. for those transports.
An MSRP URI hostport field identifies a participant in a particular The MSRP URI authority field identifies a participant in a particular
MSRP session. If the hostport contains a numeric IP address, it MUST MSRP session. If the authority field contains a numeric IP address,
also contain a port. The session-id part identifies a particular it MUST also contain a port. The session-id part identifies a
session of the participant. The absence of the session-id part particular session of the participant. The absence of the session-id
indicates a reference to an MSRP host device, but does not part indicates a reference to an MSRP host device, but does not refer
specifically refer to a particular session. to a particular session at that device. A particular value of
session-id is only meaningful in the context of the associated
authority; thus the authority component can be thought of as a
identifying the "authority" governing a name space for the
session-id.
A scheme of "msrps" indicates that the underlying connection MUST be A scheme of "msrps" indicates that the underlying connection MUST be
protected with TLS. protected with TLS.
MSRP has an IANA-registered recommended port defined in Section 15.4. MSRP has an IANA-registered recommended port defined in Section 15.4.
This value is not a default, as the URI negotiation process described This value is not a default, as the URI negotiation process described
herein will always include explicit port numbers. However, the URIs herein will always include explicit port numbers. However, the URIs
SHOULD be configured so that the recommended port is used whenever SHOULD be configured so that the recommended port is used whenever
appropriate. This makes life easier for network administrators who appropriate. This makes life easier for network administrators who
need to manage firewall policy for MSRP. need to manage firewall policy for MSRP.
The hostport component will typically not contain a userinfo The authority component will typically not contain a userinfo
component, but MAY do so to indicate a user account for which the component, but MAY do so to indicate a user account for which the
session is valid. Note that this is not the same thing as session is valid. Note that this is not the same thing as
identifying the session itself. If a userinfo component exists, it identifying the session itself. A userinfo part MUST NOT contain
MUST be constructed only from "unreserved" characters, to avoid a password information.
need for escape processing. Escaping MUST NOT be used in an MSRP
URI. Furthermore, a userinfo part MUST NOT contain password
information.
The limitation of userinfo to unreserved characters is an
additional restriction to the userinfo definition in RFC3986.
That version allows reserved characters. The additional
restriction is to avoid the need for escaping.
The following is an example of a typical MSRP URI: The following is an example of a typical MSRP URI:
msrp://host.example.com:8493/asfd34;tcp msrp://host.example.com:8493/asfd34;tcp
6.1. MSRP URI Comparison 6.1. MSRP URI Comparison
MSRP URI comparisons MUST be performed according to the following In the context of the MSRP protocol, MSRP URI comparisons MUST be
rules: performed according to the following rules:
1. The scheme MUST match. Scheme comparison is case insensitive. 1. The scheme MUST match. Scheme comparison is case insensitive.
2. If the hostpart contains an explicit IP address, and/or port, 2. If the authority component contains an explicit IP address,
these are compared for address and port equivalence. Otherwise, and/or port, these are compared for address and port equivalence.
hostpart is compared as a case insensitive character string. Percent-encoding normalization [10] applies; that is, any
percent-encoded nonreserved characters exist in the authority
component, they must be decoded prior to comparison. Userinfo
parts are not considered for URI comparison. Otherwise, the
authority component is compared as a case-insensitive character
string.
3. If the port exists explicitly in either URI, then it MUST match 3. If the port exists explicitly in either URI, then it MUST match
exactly. A URI with an explicit port is never equivalent to exactly. A URI with an explicit port is never equivalent to
another with no port specified. another with no port specified.
4. The session-id part is compared as case sensitive. A URI without 4. The session-id part is compared as case sensitive. A URI without
a session-id part is never equivalent to one that includes one. a session-id part is never equivalent to one that includes one.
5. URIs with different "transport" parameters never match. Two URIs 5. URIs with different "transport" parameters never match. Two URIs
that are identical except for transport are not equivalent. The that are identical except for transport are not equivalent. The
transport parameter is case-insensitive. transport parameter is case-insensitive.
6. Userinfo parts are not considered for URI comparison. Path normalization [10] is not relevant for MSRP URIs.
Path normalization is not relevant for MSRP URIs. Escape
normalization is not required due to character restrictions in the
formal syntax.
6.2. Resolving MSRP Host Device 6.2. Resolving MSRP Host Device
An MSRP host device is identified by the hostport of an MSRP URI. An MSRP host device is identified by the authority component of an
MSRP URI.
If the hostport contains a numeric IP address and port, they MUST be If the authority component contains a numeric IP address and port,
used as listed. they MUST be used as listed.
If the hostport contains a host name and a port, the connecting If the authority component contains a host name and a port, the
device MUST determine a host address by doing an A or AAAA DNS query, connecting device MUST determine a host address by doing an A or AAAA
and use the port as listed. DNS query, and use the port as listed.
If a connection attempt fails, the device SHOULD attempt to connect If a connection attempt fails, the device SHOULD attempt to connect
to the addresses returned in any additional A or AAAA records, in the to the addresses returned in any additional A or AAAA records, in the
order the records were presented. order the records were presented.
This process assumes that the connection port is always known This process assumes that the connection port is always known
prior to resolution. This is always true for the MSRP URI uses prior to resolution. This is always true for the MSRP URI uses
described in this document, that is, URIs exchanged in the SDP described in this document, that is, URIs exchanged in the SDP
offer and answer. The introduction of relays may create offer and answer. The introduction of relays creates situations
situations where this is not the case. For example, the MSRP URI where this is not the case. For example, the MSRP URI that a user
that a user enters into a client to configure it to use a relay enters into a client to configure it to use a relay may be
may be intended to be easily remembered and communicated by intended to be easily remembered and communicated by humans, and
humans, and therefore is likely to omit the port. Therefore, the therefore is likely to omit the port. Therefore, the relay
relay specification [23] may describe additional steps to resolve specification [23] describes additional steps to resolve the port
the port number. number.
MSRP devices MAY use other methods for discovering other such MSRP devices MAY use other methods for discovering other such
devices, when appropriate. For example, MSRP endpoints may use other devices, when appropriate. For example, MSRP endpoints may use other
mechanisms to discover relays, which are beyond the scope of this mechanisms to discover relays, which are beyond the scope of this
document. document.
7. Method-Specific Behavior 7. Method-Specific Behavior
7.1. Constructing Requests 7.1. Constructing Requests
skipping to change at page 36, line 4 skipping to change at page 35, line 48
pMSRP = %x4D.53.52.50 ; MSRP in caps pMSRP = %x4D.53.52.50 ; MSRP in caps
transact-id = ident transact-id = ident
method = mSEND / mREPORT / other-method method = mSEND / mREPORT / other-method
mSEND = %x53.45.4e.44 ; SEND in caps mSEND = %x53.45.4e.44 ; SEND in caps
mREPORT = %x52.45.50.4f.52.54; REPORT in caps mREPORT = %x52.45.50.4f.52.54; REPORT in caps
other-method = 1*UPALPHA other-method = 1*UPALPHA
status-code = 3DIGIT ; any code defined in this document status-code = 3DIGIT ; any code defined in this document
; or an extension document ; or an extension document
MSRP-URI = msrp-scheme "://" [userinfo "@"] hostport
MSRP-URI = msrp-scheme "://" authority
["/" session-id] ";" transport *( ";" URI-parameter) ["/" session-id] ";" transport *( ";" URI-parameter)
; userinfo as defined in RFC3986, except ; authority as defined in RFC3986
; limited to unreserved.
; hostport as defined in RFC3261
msrp-scheme = "msrp" / "msrps" msrp-scheme = "msrp" / "msrps"
session-id = 1*( unreserved / "+" / "=" / "/" ) session-id = 1*( unreserved / "+" / "=" / )
; unreserved as defined in RFC3986 ; unreserved as defined in RFC3986
transport = "tcp" / ALPHANUM transport = "tcp" / 1*ALPHANUM
URI-parameter = token ["=" token] URI-parameter = token ["=" token]
headers = To-Path CRLF From-Path CRLF 1*( header CRLF ) headers = To-Path CRLF From-Path CRLF 1*( header CRLF )
header = Message-ID header = Message-ID
/ Success-Report / Success-Report
/ Failure-Report / Failure-Report
/ Byte-Range / Byte-Range
/ Status / Status
/ ext-header / ext-header
skipping to change at page 49, line 15 skipping to change at page 49, line 15
14.1. Secrecy of the MSRP URI 14.1. Secrecy of the MSRP URI
When an endpoint sends an MSRP URI to its peer in a rendez-vous When an endpoint sends an MSRP URI to its peer in a rendez-vous
protocol, that URI is effectively a secret shared between the peers. protocol, that URI is effectively a secret shared between the peers.
If an attacker learns or guesses the URI prior to the completion of If an attacker learns or guesses the URI prior to the completion of
session setup, it may be able to impersonate one of the peers. session setup, it may be able to impersonate one of the peers.
Assuming the URI exchange in the rendez-vous protocol is sufficiently Assuming the URI exchange in the rendez-vous protocol is sufficiently
protected, it is critical that the URI remain difficult to "guess" protected, it is critical that the URI remain difficult to "guess"
via brute force methods. Most components of the URI, such as the via brute force methods. Most components of the URI, such as the
scheme and the hostport components, are common knowledge. The scheme and the authority components, are common knowledge. The
secrecy is entirely provided by the session-id component. secrecy is entirely provided by the session-id component.
Therefore, when an MSRP device generates an MSRP URI to be used in Therefore, when an MSRP device generates an MSRP URI to be used in
the initiation of an MSRP session, the session-id component MUST the initiation of an MSRP session, the session-id component MUST
contain at least 80 bits of randomness. contain at least 80 bits of randomness.
14.2. Transport Level Protection 14.2. Transport Level Protection
When using only TCP connections, MSRP security is fairly weak. If When using only TCP connections, MSRP security is fairly weak. If
host A is contacting host B, B passes its hostname and a secret to A host A is contacting host B, B passes its hostname and a secret to A
skipping to change at page 60, line 20 skipping to change at page 60, line 20
Protocol Call Control - Transfer", Protocol Call Control - Transfer",
draft-ietf-sipping-cc-transfer-07 (work in progress), draft-ietf-sipping-cc-transfer-07 (work in progress),
October 2006. October 2006.
[22] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and [22] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002. Instant Messaging", RFC 3428, December 2002.
[23] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for [23] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for
Message Sessions Relay Protocol (MSRP)", Message Sessions Relay Protocol (MSRP)",
draft-ietf-simple-msrp-relays-08 (work in progress), July 2006. draft-ietf-simple-msrp-relays-10 (work in progress),
December 2006.
[24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE [24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002. Method", RFC 3311, October 2002.
[25] Jennings, C., Peterson, J., and J. Fischl, "Certificate [25] Jennings, C., Peterson, J., and J. Fischl, "Certificate
Management Service for SIP", draft-ietf-sip-certs-01 (work in Management Service for SIP", draft-ietf-sip-certs-02 (work in
progress), June 2006. progress), October 2006.
[26] Yon, D. and G. Camarillo, "Connection-Oriented Media Transport [26] Yon, D. and G. Camarillo, "Connection-Oriented Media Transport
in SDP", RFC 4145, September 2005. in SDP", RFC 4145, September 2005.
[27] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", [27] Peterson, J., "A Common Profile for Instant Messaging (CPIM)",
RFC 3860, August 2004. RFC 3860, August 2004.
[28] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, [28] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217,
December 2001. December 2001.
skipping to change at page 62, line 7 skipping to change at page 62, line 7
170 West Tasman Dr. 170 West Tasman Dr.
MS: SJC-21/2 MS: SJC-21/2
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 421-9990 Phone: +1 408 421-9990
Email: fluffy@cisco.com Email: fluffy@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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 AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
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
 End of changes. 28 change blocks. 
71 lines changed or deleted 71 lines changed or added

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