draft-ietf-msgtrk-mtqp-11.txt   draft-ietf-msgtrk-mtqp-12.txt 
Internet Draft T. Hansen Internet Draft T. Hansen
draft-ietf-msgtrk-mtqp-11.txt AT&T Laboratories draft-ietf-msgtrk-mtqp-12.txt AT&T Laboratories
Valid for six months July 16, 2003 Valid for six months March 3, 2004
Message Tracking Query Protocol Message Tracking Query Protocol
<draft-ietf-msgtrk-mtqp-11.txt> <draft-ietf-msgtrk-mtqp-12.txt>
Authors' version: 1.25 Authors' version: 1.27
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 40 skipping to change at page 2, line 40
document are to be interpreted as described in [RFC-KEYWORDS]. document are to be interpreted as described in [RFC-KEYWORDS].
All syntax descriptions use the ABNF specified by [RFC-ABNF]. Ter- All syntax descriptions use the ABNF specified by [RFC-ABNF]. Ter-
minal nodes not defined elsewhere in this document are defined in [RFC- minal nodes not defined elsewhere in this document are defined in [RFC-
ABNF], [RFC-URI], [DRAFT-MTRK-ESMTP] or [RFC-SMTPEXT]. ABNF], [RFC-URI], [DRAFT-MTRK-ESMTP] or [RFC-SMTPEXT].
1.2. Changes Made for... 1.2. Changes Made for...
These Changes sections will be removed before publication. These Changes sections will be removed before publication.
1.2.1. Changes Made for -11 1.2.1. Changes Made for -12
More IESG comments:
Section 3: It says that if TLS is required, the server "SHOULD"
specify the "required" parameter. Why isn't that a MUST? The document
itself uses the word "required", and the previous IESG comments demon-
strated the need for such a flag.
The word "privacy" is being used when "confidentiality" is really
meant.
Section 6.1: No real guidance is provided about peer identities
exchanged within TLS. Is there some reason that they shouldn't match
the FQDN?
If the peer's use of STARTTLS is cached, you should cache the cert
identity.
1.2.2. Changes Made for -11
More IESG comments: More IESG comments:
Consider a server that requires TLS be negotiated before it will Consider a server that requires TLS be negotiated before it will
respond to any queries. A client that doesn't normally use TLS connects respond to any queries. A client that doesn't normally use TLS connects
to this server. It issues a TRACK command and gets a /tls-required to this server. It issues a TRACK command and gets a /tls-required
back, which tells it it needs to use TLS. But at this point the damage back, which tells it it needs to use TLS. But at this point the damage
has already been done: The secret has been sent in the clear to the has already been done: The secret has been sent in the clear to the
server as part of the TRACK command. The way to resolve this is to have server as part of the TRACK command. The way to resolve this is to have
an indicator on the STARTTLS option. The obvious thing would be to have an indicator on the STARTTLS option. The obvious thing would be to have
skipping to change at page 3, line 13 skipping to change at page 3, line 33
dles require TLS. dles require TLS.
There's also a bit of confusion in the present draft between the There's also a bit of confusion in the present draft between the
/tls-required error that appears in the text and the /insecure error /tls-required error that appears in the text and the /insecure error
that appears in the ABNF. that appears in the ABNF.
Finally, section 6 begins with: "TLS [TLS], more commonly known as Finally, section 6 begins with: "TLS [TLS], more commonly known as
SSL,". SSL is a somewhat different and earlier protocol; it is not the SSL,". SSL is a somewhat different and earlier protocol; it is not the
same as TLS. The reference to SSL needs to be removed. same as TLS. The reference to SSL needs to be removed.
1.2.2. Changes Made for -10 1.2.3. Changes Made for -10
Fixes for IESG comments: Fixes for IESG comments:
Make the hostname parameter in the STARTTLS command mandatory. Make the hostname parameter in the STARTTLS command mandatory.
Add a sentence clarifying that TLS is mandatory to implement, but Add a sentence clarifying that TLS is mandatory to implement, but
that administrators are free to disable it or that it might be disabled that administrators are free to disable it or that it might be disabled
if there's no certificate available. (NB. This implies also that TLS if there's no certificate available. (NB. This implies also that TLS
support is a SHOULD instead of a MAY.) support is a SHOULD instead of a MAY.)
skipping to change at page 3, line 37 skipping to change at page 4, line 9
itself.) That implies that a server that always wants TLS to be used itself.) That implies that a server that always wants TLS to be used
should indicate that at sign-on time, so that it doesn't get any non-TLS should indicate that at sign-on time, so that it doesn't get any non-TLS
queries. queries.
This implies that if the server decides that the level of auth isn't This implies that if the server decides that the level of auth isn't
high enough to continue, it MAY abort the connection. high enough to continue, it MAY abort the connection.
Fix ABNF: fix comment characters (";", not "#") Fix ABNF: fix comment characters (";", not "#")
Fix ABNF: remove trailing ) from identifier definition Fix ABNF: remove trailing ) from identifier definition
1.2.3. Changes Made for -09 1.2.4. Changes Made for -09
Fixes for AD comments made on 8/21/2002: Fixes for AD comments made on 8/21/2002:
The copyright date is 1999. This seems wrong... The copyright date is 1999. This seems wrong...
Section 2.4. Should say something about client timeouts and how Section 2.4. Should say something about client timeouts and how
long it is appropriate to wait for a server. long it is appropriate to wait for a server.
Section 4. It seems appropriate to have two qualified error Section 4. It seems appropriate to have two qualified error
responses to TRACK: (1) An indication that TLS must be negotiated responses to TRACK: (1) An indication that TLS must be negotiated
skipping to change at page 4, line 4 skipping to change at page 4, line 25
Section 2.4. Should say something about client timeouts and how Section 2.4. Should say something about client timeouts and how
long it is appropriate to wait for a server. long it is appropriate to wait for a server.
Section 4. It seems appropriate to have two qualified error Section 4. It seems appropriate to have two qualified error
responses to TRACK: (1) An indication that TLS must be negotiated responses to TRACK: (1) An indication that TLS must be negotiated
before this message can be tracked and (2) An indication that the search before this message can be tracked and (2) An indication that the search
succeeded but found no result. succeeded but found no result.
What happens when no informatio about the message is found? Does What happens when no informatio about the message is found? Does
this come back as an empty response or does it get a negative response? this come back as an empty response or does it get a negative response?
The URL registration in section 9 doesn't seem to meet the require- The URL registration in section 9 doesn't seem to meet the require-
ments set forth in RFC 2717. In particular, the URL registration tem- ments set forth in RFC 2717. In particular, the URL registration tem-
plate needs to be included. plate needs to be included.
Section 10. The IANA considerations should mention that this docu- Section 10. The IANA considerations should mention that this docu-
ment registers the MQTP URL scheme. ment registers the MQTP URL scheme.
References need to be split into normative and informative. References need to be split into normative and informative.
1.2.4. Changes Made for -08 1.2.5. Changes Made for -08
Change "Option Parameters" back to "none" in STARTTLS registration Change "Option Parameters" back to "none" in STARTTLS registration
definition. definition.
1.2.5. Changes Made for -07 1.2.6. Changes Made for -07
Added hostname to STARTTLS registration information. Corrected Added hostname to STARTTLS registration information. Corrected
ABNF for STARTTLS. ABNF for STARTTLS.
1.2.6. Changes Made for -06 1.2.7. Changes Made for -06
Added opt-parameter to STARTTLS and description. Added opt-parameter to STARTTLS and description.
1.2.7. Changes Made for -05 1.2.8. Changes Made for -05
STARTTLS error response changed from "/unsupported" to "/unavail- STARTTLS error response changed from "/unsupported" to "/unavail-
able". able".
Fixed some minor nits in the examples and some typos. Fixed some minor nits in the examples and some typos.
1.2.8. Changes Made for -04 1.2.9. Changes Made for -04
Reworked the SRV lookup description. Reworked the SRV lookup description.
Other comments from the list. Other comments from the list.
Changes to the ABNF. Changes to the ABNF.
Changed "must" to "MUST" in section 4. Changed "must" to "MUST" in section 4.
Changed "may" to "MAY" in section 4. Changed "may" to "MAY" in section 4.
More examples. More examples.
Eliminated the registry of vnd. options. Eliminated the registry of vnd. options.
Eliminated lots of unused references. Eliminated lots of unused references.
1.2.9. Changes Made for -03 1.2.10. Changes Made for -03
Changed references. Changed references.
Worked on error codes. Worked on error codes.
Made examples more real with secrets and hashes. Made examples more real with secrets and hashes.
Fixes to examples. Fixes to examples.
Added dot-stuffed example. Added dot-stuffed example.
Additional TLS info. Additional TLS info.
Better Security Considerations section. Better Security Considerations section.
1.2.10. Changes Made for -02 1.2.11. Changes Made for -02
Provided information on lookup for an MTQP server: SRV MTQP, then Provided information on lookup for an MTQP server: SRV MTQP, then
MX, then A. MX, then A.
Provided a section on firewall considerations Provided a section on firewall considerations
Provided a section on service DNS considerations Provided a section on service DNS considerations
At IANA's request, left the port number as XXXX and added more At IANA's request, left the port number as XXXX and added more
information on the option registry. information on the option registry.
skipping to change at page 6, line 32 skipping to change at page 6, line 52
ing queries to be performed on a different machine, MUST have an SRV ing queries to be performed on a different machine, MUST have an SRV
MTQP record pointing at that different machine. MTQP record pointing at that different machine.
A mail system that uses multihomed mail servers has two choices for A mail system that uses multihomed mail servers has two choices for
providing tracking services: either all mail servers must be running providing tracking services: either all mail servers must be running
tracking servers that are able to retrieve information on all messages, tracking servers that are able to retrieve information on all messages,
or the tracking service must be performed on one (or more) machine(s) or the tracking service must be performed on one (or more) machine(s)
that are able to retrieve information on all messages. In the former that are able to retrieve information on all messages. In the former
case, no additional DNS records are needed beyond the MX records already case, no additional DNS records are needed beyond the MX records already
in place for the mail system. In the latter case, SRV MTQP records are in place for the mail system. In the latter case, SRV MTQP records are
needed that point at the machine(s) that are running the tracking ser- needed that point at the machine(s) that are running the tracking
vice. In both cases, note that the tracking service MUST be able to
service. In both cases, note that the tracking service MUST be able to
handle the queries for all messages accepted by that mail system. handle the queries for all messages accepted by that mail system.
2.2. Commands 2.2. Commands
Commands in MTQP consist of a case-insensitive keyword, possibly Commands in MTQP consist of a case-insensitive keyword, possibly
followed by one or more parameters. All commands are terminated by a followed by one or more parameters. All commands are terminated by a
CRLF pair. Keywords and parameters consist of printable ASCII charac- CRLF pair. Keywords and parameters consist of printable ASCII charac-
ters. Keywords and parameters are separated by whitespace (one or more ters. Keywords and parameters are separated by whitespace (one or more
space or tab characters). A command line is limited to 998 characters space or tab characters). A command line is limited to 998 characters
before the CRLF. before the CRLF.
skipping to change at page 8, line 52 skipping to change at page 9, line 24
onto additional lines by starting the continuation lines with white onto additional lines by starting the continuation lines with white
space. The option identifier is case insensitive. Option identifiers space. The option identifier is case insensitive. Option identifiers
beginning with the characters "vnd." are reserved for vendor use. (See beginning with the characters "vnd." are reserved for vendor use. (See
below.) below.)
One option specification is defined here: One option specification is defined here:
STARTTLS [1*WSP "required"] STARTTLS [1*WSP "required"]
This capability MUST be listed if the optional STARTTLS command is This capability MUST be listed if the optional STARTTLS command is
enabled on the MQTP server and one or more certificates have been enabled on the MQTP server and one or more certificates have been prop-
erly installed.
properly installed.
It has one optional parameter: the word "required". (The parame- It has one optional parameter: the word "required". (The parame-
ters for STARTTLS are case-insensitive.) If the server requires that ters for STARTTLS are case-insensitive.) If the server requires that
TLS be used for some of the domains the server handles, the server TLS be used for some of the domains the server handles, the server MUST
SHOULD specify the "required" parameter. specify the "required" parameter.
3.1. Examples 3.1. Examples
Example #1 (no options): Example #1 (no options):
S: +OK/MTQP MTQP server ready S: +OK/MTQP MTQP server ready
Example #2 (service temporarily unavailable): Example #2 (service temporarily unavailable):
S: -TEMP/MTQP/admin Service down for admin, call back later S: -TEMP/MTQP/admin Service down for admin, call back later
Example #3 (service permanently unavailable): Example #3 (service permanently unavailable):
skipping to change at page 15, line 4 skipping to change at page 15, line 23
opt-text = [WSP *(VCHAR / WSP)] opt-text = [WSP *(VCHAR / WSP)]
When the client issues the COMMENT command, the MTQP server MUST When the client issues the COMMENT command, the MTQP server MUST
respond with a successful response (+OK or +OK+). All optional text respond with a successful response (+OK or +OK+). All optional text
provided with the COMMENT command are ignored. provided with the COMMENT command are ignored.
6. STARTTLS Command 6. STARTTLS Command
Syntax: Syntax:
"STARTTLS" 1*WSP hostname *WSP CRLF "STARTTLS" 1*WSP hostname *WSP CRLF
TLS [TLS] is a popular mechanism for enhancing TCP communications TLS [TLS] is a popular mechanism for enhancing TCP communications
with privacy and authentication. All MTQP servers MUST implement TLS. with confidentiality and authentication. All MTQP servers MUST imple-
However, TLS MAY be disabled by by a server administrator, either expli- ment TLS. However, TLS MAY be disabled by by a server administrator,
citly or by failing to install any certificates for TLS to use. If an either explicitly or by failing to install any certificates for TLS to
MTQP server supports TLS and has one or more certificates available it use. If an MTQP server supports TLS and has one or more certificates
MUST include "STARTTLS" in the option specifications list on protocol available it MUST include "STARTTLS" in the option specifications list
startup. on protocol startup.
Note: TLS SHOULD be enabled on MQTP servers whenever possible. Note: TLS SHOULD be enabled on MQTP servers whenever possible.
The parameter MUST be a fully qualified domain name. A client MUST The parameter MUST be a fully qualified domain name (FQDN). A
specify the hostname it believes it is speaking with so that the server client MUST specify the hostname it believes it is speaking with so that
may respond with the proper TLS certificate. This is useful for virtual the server may respond with the proper TLS certificate. This is useful
servers that provide message tracking for multiple domains (i.e., vir- for virtual servers that provide message tracking for multiple domains
tual hosting). (i.e., virtual hosting).
If the server returns a negative response, it MAY use one of the If the server returns a negative response, it MAY use one of the
following response codes: following response codes:
"/" "unsupported" "/" "unsupported"
"/" "unavailable" "/" "unavailable"
"/" "tls-in-progress" "/" "tls-in-progress"
"/" "bad-fqdn"
If TLS is not supported, then a response code of "/unsupported" If TLS is not supported, then a response code of "/unsupported"
SHOULD be used. If TLS is not available for some other reason, then a SHOULD be used. If TLS is not available for some other reason, then a
response code of "/unavailable" SHOULD be used. If a TLS session is response code of "/unavailable" SHOULD be used. If a TLS session is
already in progress, then it is a protocol error and "-BAD" MUST be already in progress, then it is a protocol error and "-BAD" MUST be
returned with a response code of "/tls-in-progress". returned with a response code of "/tls-in-progress". If there is a
mismatch between the supplied FQDN and the FQDN found in the dNSName
field of the subjectAltName extension of the server's certificate [RFC-
X509], then it is a protocol error and "-BAD" MUST be returned with a
response code of "/bad-fqdn".
After receiving a positive response to a STARTTLS command, the After receiving a positive response to a STARTTLS command, the
client MUST start the TLS negotiation before giving any other MTQP com- client MUST start the TLS negotiation before giving any other MTQP com-
mands. mands.
If the MTQP client is using pipelining (see below), the STARTTLS If the MTQP client is using pipelining (see below), the STARTTLS
command must be the last command in a group. command must be the last command in a group.
6.1. Processing After the STARTTLS Command 6.1. Processing After the STARTTLS Command
If the TLS handshake fails, the server SHOULD abort the connection. If the TLS handshake fails, the server SHOULD abort the connection.
After the TLS handshake has been completed, both parties MUST After the TLS handshake has been completed, both parties MUST
immediately decide whether or not to continue based on the authentica- immediately decide whether or not to continue based on the authentica-
tion and privacy achieved. The MTQP client and server may decide to tion and confidentiality achieved. The MTQP client and server may
move ahead even if the TLS negotiation ended with no authentication decide to move ahead even if the TLS negotiation ended with no authenti-
and/or no privacy because most MTQP services are performed with no cation and/or no confidentiality because most MTQP services are per-
authentication and no privacy, but some MTQP clients or servers may want formed with no authentication and no confidentiality, but some MTQP
to continue only if a particular level of authentication and/or privacy clients or servers may want to continue only if a particular level of
was achieved. authentication and/or confidentiality was achieved.
If the MTQP client decides that the level of authentication or If the MTQP client decides that the level of authentication or con-
privacy is not high enough for it to continue, it SHOULD issue an MTQP fidentiality is not high enough for it to continue, it SHOULD issue an
QUIT command immediately after the TLS negotiation is complete. MTQP QUIT command immediately after the TLS negotiation is complete.
If the MTQP server decides that the level of authentication or If the MTQP server decides that the level of authentication or con-
privacy is not high enough for it to continue, it MAY abort the connec- fidentiality is not high enough for it to continue, it MAY abort the
tion. If it decides that the level of authentication or privacy is not connection. If it decides that the level of authentication or confiden-
high enough for it to continue, and it does not abort the connection, it tiality is not high enough for it to continue, and it does not abort the
SHOULD reply to every MTQP command from the client (other than a QUIT connection, it SHOULD reply to every MTQP command from the client (other
command) with a negative "-ERR" response and a response code of than a QUIT command) with a negative "-ERR" response and a response code
"/insecure". of "/insecure".
6.2. Result of the STARTTLS Command 6.2. Result of the STARTTLS Command
Upon completion of the TLS handshake, the MTQP protocol is reset to Upon completion of the TLS handshake, the MTQP protocol is reset to
the initial state (the state in MTQP after a server starts up). The the initial state (the state in MTQP after a server starts up). The
server MUST discard any knowledge obtained from the client prior to the server MUST discard any knowledge obtained from the client prior to the
TLS negotiation itself. The client MUST discard any knowledge obtained TLS negotiation itself. The client MUST discard any knowledge obtained
from the server, such as the list of MTQP options, which was not from the server, such as the list of MTQP options, which was not
obtained from the TLS negotiation itself. obtained from the TLS negotiation itself.
skipping to change at page 19, line 40 skipping to change at page 20, line 16
The security of tracking information is dependent on the randomness The security of tracking information is dependent on the randomness
of the secret chosen for each message and the level of exposure of that of the secret chosen for each message and the level of exposure of that
secret. If different secrets are used for each message, then the max- secret. If different secrets are used for each message, then the max-
imum exposure from tracking any message will be that single message for imum exposure from tracking any message will be that single message for
the time that the tracking information is kept on any MTQP server. If the time that the tracking information is kept on any MTQP server. If
this level of exposure is too much, TLS may be used to reduce the expo- this level of exposure is too much, TLS may be used to reduce the expo-
sure further. sure further.
It should be noted that message tracking is not an end-to-end It should be noted that message tracking is not an end-to-end
mechanism. Thus, if an MTQP client/server pair decide to use TLS mechanism. Thus, if an MTQP client/server pair decide to use TLS confi-
privacy, they are not securing tracking queries with any prior or suc- dentiality, they are not securing tracking queries with any prior or
cessive MTQP servers. successive MTQP servers.
Both the MTQP client and server must check the result of the TLS Both the MTQP client and server must check the result of the TLS
negotiation to see whether acceptable authentication or privacy was negotiation to see whether acceptable authentication or confidentiality
achieved. Ignoring this step completely invalidates using TLS for secu- was achieved. Ignoring this step completely invalidates using TLS for
rity. The decision about whether acceptable authentication or privacy security. The decision about whether acceptable authentication or con-
was achieved is made locally, is implementation-dependent, and is beyond fidentiality was achieved is made locally, is implementation-dependent,
the scope of this document. and is beyond the scope of this document.
The MTQP client and server should note carefully the result of the The MTQP client and server should note carefully the result of the
TLS negotiation. If the negotiation results in no confidentiality, or
TLS negotiation. If the negotiation results in no privacy, or if it if it results in confidentiality using algorithms or key lengths that
results in privacy using algorithms or key lengths that are deemed not are deemed not strong enough, or if the authentication is not good
strong enough, or if the authentication is not good enough for either enough for either party, the client may choose to end the MTQP session
party, the client may choose to end the MTQP session with an immediate with an immediate QUIT command, or the server may choose to not accept
QUIT command, or the server may choose to not accept any more MTQP com- any more MTQP commands.
mands.
A man-in-the-middle attack can be launched by deleting the A man-in-the-middle attack can be launched by deleting the
"STARTTLS" option response from the server. This would cause the client "STARTTLS" option response from the server. This would cause the client
not to try to start a TLS session. An MTQP client can protect against not to try to start a TLS session. An MTQP client can protect against
this attack by recording the fact that a particular MTQP server offers this attack by recording the fact that a particular MTQP server offers
TLS during one session and generating an alarm if it does not appear in TLS during one session and generating an alarm if it does not appear in
an option response for a later session. an option response for a later session.
Similarly, the identity of the server as expressed in the server's
certificate should be cached, and an alarm generated if they do not
match in a later session.
If TLS is not used, a tracking request is vulnerable to replay If TLS is not used, a tracking request is vulnerable to replay
attacks, such that a snoop can later replay the same handshake again to attacks, such that a snoop can later replay the same handshake again to
potentially gain more information about a message's status. potentially gain more information about a message's status.
Before the TLS handshake has begun, any protocol interactions are Before the TLS handshake has begun, any protocol interactions are
performed in the clear and may be modified by an active attacker. For performed in the clear and may be modified by an active attacker. For
this reason, clients and servers MUST discard any knowledge obtained this reason, clients and servers MUST discard any knowledge obtained
prior to the start of the TLS handshake upon completion of the TLS prior to the start of the TLS handshake upon completion of the TLS
handshake. handshake.
If a client/server pair successfully performs a TLS handshake and If a client/server pair successfully performs a TLS handshake and
the server does chaining referrals, then the server SHOULD attempt to the server does chaining referrals, then the server SHOULD attempt to
negotiate TLS at the same (or better) security level at the next hop. negotiate TLS at the same (or better) security level at the next hop.
In a hop-by-hop scenario, STARTTLS is a request for "best effort" secu- In a hop-by-hop scenario, STARTTLS is a request for "best effort" secu-
rity and should be treated as such. rity and should be treated as such.
SASL is not used because authentication is per message rather than SASL is not used because authentication is per message rather than
skipping to change at page 22, line 49 skipping to change at page 23, line 28
dard 1 (SHA1)", September 2001. dard 1 (SHA1)", September 2001.
[RFC-KEYWORDS] [RFC-KEYWORDS]
RFC 2119, S. Bradner, "Key words for use in RFCs to Indi- RFC 2119, S. Bradner, "Key words for use in RFCs to Indi-
cate Requirement Levels", Harvard University, March 1997. cate Requirement Levels", Harvard University, March 1997.
[RFC-SMTP-TLS] [RFC-SMTP-TLS]
RFC2487, P. Hoffman, "SMTP Service Extension for Secure RFC2487, P. Hoffman, "SMTP Service Extension for Secure
SMTP over TLS", Internet Mail Consortium, January 1999. SMTP over TLS", Internet Mail Consortium, January 1999.
[RFC-X509]RFC3280, R. Housley, W. Polk, W. Ford, D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and Certifi-
cate Revocation List (CRL) Profile", RSA Laboratories,
NIST, VeriSign, Citigroup, April 2002.
Appendix A. MTQP URI Registration Template Appendix A. MTQP URI Registration Template
Scheme name: mtqp Scheme name: mtqp
Scheme syntax: see section 9.1 Scheme syntax: see section 9.1
Character encoding considerations: see section 9.4 Character encoding considerations: see section 9.4
Intended usage: see section 9.3 Intended usage: see section 9.3
Applications and/or protocols which use this scheme: MTQP Applications and/or protocols which use this scheme: MTQP
Interoperability considerations: as specified for MTQP Interoperability considerations: as specified for MTQP
skipping to change at page 24, line 12 skipping to change at page 24, line 45
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
This document expires January 16, 2004. This document expires September 3, 2004.
 End of changes. 33 change blocks. 
64 lines changed or deleted 102 lines changed or added

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