draft-ietf-msgtrk-mtqp-08.txt   draft-ietf-msgtrk-mtqp-09.txt 
Internet Draft T. Hansen Internet Draft T. Hansen
draft-ietf-msgtrk-mtqp-08.txt AT&T Laboratories draft-ietf-msgtrk-mtqp-09.txt AT&T Laboratories
Valid for six months May 19, 2002 Valid for six months October 24, 2002
Message Tracking Query Protocol Message Tracking Query Protocol
<draft-ietf-msgtrk-mtqp-08.txt> <draft-ietf-msgtrk-mtqp-09.txt>
Authors' version: 1.18 Authors' version: 1.20
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 1, line 41 skipping to change at page 1, line 41
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This memo and its companions are discussed on the MSGTRK working This memo and its companions are discussed on the MSGTRK working
group mailing list, ietf-msgtrk@imc.org. To subscribe, send a message group mailing list, ietf-msgtrk@imc.org. To subscribe, send a message
with the word "subscribe" in the body (on a line by itself) to the with the word "subscribe" in the body (on a line by itself) to the
address ietf-msgtrk-request@imc.org. An archive of the mailing list may address ietf-msgtrk-request@imc.org. An archive of the mailing list may
be found at http://www.ietf.org/archive/msgtrk. be found at http://www.ietf.org/archive/msgtrk.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (%Dy%). All Rights Reserved.
Abstract Abstract
Customers buying enterprise message systems often ask: Can I track Customers buying enterprise message systems often ask: Can I track
the messages? Message tracking is the ability to find out the path that the messages? Message tracking is the ability to find out the path that
a particular message has taken through a messaging system and the a particular message has taken through a messaging system and the
current routing status of that message. This document describes the current routing status of that message. This document describes the
Message Tracking Query Protocol that is used in conjunction with exten- Message Tracking Query Protocol that is used in conjunction with exten-
sions to the ESMTP protocol to provide a complete message tracking solu- sions to the ESMTP protocol to provide a complete message tracking solu-
tion for the Internet. tion for the Internet.
1. Introduction 1. Introduction
The Message Tracking Models and Requirements document [DRAFT- The Message Tracking Models and Requirements document [DRAFT-MTRK-
TRACK-MODEL] discusses the models that message tracking solutions could MODEL] discusses the models that message tracking solutions could fol-
follow, along with requirements for a message tracking solution that can low, along with requirements for a message tracking solution that can be
be used with the Internet-wide message infrastructure. This memo and used with the Internet-wide message infrastructure. This memo and its
its companions, [DRAFT-TRACK-ESMTP] and [DRAFT-TRACK-TSN], describe a companions, [DRAFT-MTRK-ESMTP] and [DRAFT-MTRK-TSN], describe a complete
complete message tracking solution that satisfies those requirements. message tracking solution that satisfies those requirements. The memo
The memo [DRAFT-TRACK-ESMTP] defines an extension to the SMTP service [DRAFT-MTRK-ESMTP] defines an extension to the SMTP service that pro-
that provides the information necessary to track messages. This memo vides the information necessary to track messages. This memo defines a
defines a protocol that can be used to query the status of messages that protocol that can be used to query the status of messages that have been
have been transmitted on the Internet via SMTP. The memo [DRAFT-TRACK- transmitted on the Internet via SMTP. The memo [DRAFT-MTRK-TSN]
TSN] describes the message/tracking-status [RFC-MIME] media type that is describes the message/tracking-status [RFC-MIME] media type that is used
used to report tracking status information. Using the model document's to report tracking status information. Using the model document's ter-
terminology, this solution uses active enabling and active requests with minology, this solution uses active enabling and active requests with
both request and chaining referrals. both request and chaining referrals.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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-TRACK-ESMTP] or [RFC-SMTPEXT]. ABNF], [RFC-URI], [DRAFT-MTRK-ESMTP] or [RFC-SMTPEXT].
1.2. Changes Made for -07 1.2. Changes Made for...
Added hostname to STARTTLS registration information. Corrected ABNF for
STARTTLS. The Changes sections will be removed before publication.
1.2.1. Changes Made for -09
Fixes for AD comments made on 8/21/2002:
The copyright date is 1999. This seems wrong...
Section 2.4. Should say something about client timeouts and how
long it is appropriate to wait for a server.
Section 4. It seems appropriate to have two qualified error
responses to TRACK: (1) An indication that TLS must be negotiated
before this message can be tracked and (2) An indication that the search
succeeded but found no result.
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?
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-
plate needs to be included.
Section 10. The IANA considerations should mention that this docu-
ment registers the MQTP URL scheme.
References need to be split into normative and informative.
1.2.2. Changes Made for -08
Change "Option Parameters" back to "none" in STARTTLS registration
definition.
1.2.3. Changes Made for -07
Added hostname to STARTTLS registration information. Corrected
ABNF for STARTTLS.
1.2.4. Changes Made for -06
1.3. Changes Made for -06
Added opt-parameter to STARTTLS and description. Added opt-parameter to STARTTLS and description.
1.4. Changes Made for -05 1.2.5. Changes Made for -05
STARTTLS error response changed from "/unsupported" to "/unavailable".
STARTTLS error response changed from "/unsupported" to "/unavail-
able".
Fixed some minor nits in the examples and some typos. Fixed some minor nits in the examples and some typos.
1.5. Changes Made for -04 1.2.6. 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.6. Changes Made for -03 1.2.7. 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.7. Changes Made for -02 1.2.8. Changes Made for -02
This section will be removed before publication.
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 5 skipping to change at page 6, line 38
CRLF immediately follows the period, then the response from the MTQP CRLF immediately follows the period, then the response from the MTQP
server is ended and the line containing the ".CRLF" is not considered server is ended and the line containing the ".CRLF" is not considered
part of the multi-line response. part of the multi-line response.
An MTQP server MUST respond to an unrecognized, unimplemented, or An MTQP server MUST respond to an unrecognized, unimplemented, or
syntactically invalid command by responding with a negative -BAD status syntactically invalid command by responding with a negative -BAD status
indicator. A server MUST respond to a command issued when the session indicator. A server MUST respond to a command issued when the session
is in an incorrect state by responding with a negative -ERR status indi- is in an incorrect state by responding with a negative -ERR status indi-
cator. cator.
2.4. Optional Timers 2.4. Firewall Considerations
An MTQP server MAY have an inactivity autologout timer. Such a
timer MUST be of at least 10 minutes in duration. The receipt of any
command from the client during that interval should suffice to reset the
autologout timer. An MTQP server MAY limit the number of commands,
unrecognized commands, or total connection time, or MAY use other cri-
teria, to prevent denial of service attacks.
2.5. Firewall Considerations
A firewall mail gateway has two choices when receiving a tracking A firewall mail gateway has two choices when receiving a tracking
query for a host within its domain: it may return a response to the query for a host within its domain: it may return a response to the
query that says the message has been passed on, but no further informa- query that says the message has been passed on, but no further informa-
tion is available; or it may perform a chaining operation itself, gath- tion is available; or it may perform a chaining operation itself, gath-
ering information on the message from the mail hosts behind the ering information on the message from the mail hosts behind the
firewall, and returning to the MTQP client the information for each firewall, and returning to the MTQP client the information for each
behind-the-firewall hop, or possibly just the final hop information, behind-the-firewall hop, or possibly just the final hop information,
possibly also disguising the names of any hosts behind the firewall. possibly also disguising the names of any hosts behind the firewall.
Which option is picked is an administrative decision and is not further Which option is picked is an administrative decision and is not further
mandated by this document. mandated by this document.
If a server chooses to perform a chaining operation itself, it MUST
provide a response within 2 minutes, and SHOULD return a "no further
information is available" response if it cannot provide an answer at the
end of that time limit.
2.5. Optional Timers
An MTQP server MAY have an inactivity autologout timer. Such a
timer MUST be of at least 10 minutes in duration. The receipt of any
command from the client during that interval should suffice to reset the
autologout timer. An MTQP server MAY limit the number of commands,
unrecognized commands, or total connection time, or MAY use other cri-
teria, to prevent denial of service attacks.
An MTQP client MAY have an inactivity autologout timer while wait-
ing for a response from the server. Since an MTQP server may be a
firewall, and may be chaining information from other servers, such a
timer MUST be at least 2 minutes in duration.
3. Initialization and Option Response 3. Initialization and Option Response
Once the TCP connection has been opened by an MTQP client, the MTQP Once the TCP connection has been opened by an MTQP client, the MTQP
server issues an initial status response that indicates its readiness. server issues an initial status response that indicates its readiness.
If the status response is positive (+OK or +OK+), the client may proceed If the status response is positive (+OK or +OK+), the client may proceed
with other commands. with other commands.
The initial status response MUST include the response information The initial status response MUST include the response information
"/MTQP". Negative responses MUST include a reason code as response "/MTQP". Negative responses MUST include a reason code as response
information. The following reason codes are defined here; unrecognized information. The following reason codes are defined here; unrecognized
skipping to change at page 7, line 4 skipping to change at page 7, line 48
vailable for administrative reasons. The reason code "/unavailable" vailable for administrative reasons. The reason code "/unavailable"
SHOULD be used when the service is unavailable for other reasons. SHOULD be used when the service is unavailable for other reasons.
If the server has any options enabled, they are listed as the If the server has any options enabled, they are listed as the
multi-line response of the initial status response, one per line. An multi-line response of the initial status response, one per line. An
option specification consists of an identifier, optionally followed by option specification consists of an identifier, optionally followed by
option-specific parameters. An option specification may be continued option-specific parameters. An option specification may be continued
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 STARTTLS
This capability MUST be listed if the optional STARTTLS command is sup- This capability MUST be listed if the optional STARTTLS command is sup-
ported by the MTQP server. It has no parameters. ported by the MTQP server. It has no parameters.
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):
S: -ERR/MTQP/unavailable Service down S: -ERR/MTQP/unavailable Service down
Example #4 (alternative for no options): Example #4 (alternative for no options):
skipping to change at page 7, line 42 skipping to change at page 8, line 38
S: list of parameters S: list of parameters
S: . S: .
4. TRACK Command 4. TRACK Command
Syntax: Syntax:
"TRACK" 1*WSP envid 1*WSP mtrk-secret CRLF "TRACK" 1*WSP envid 1*WSP mtrk-secret CRLF
mtrk-secret = base64 mtrk-secret = base64
Envid is defined in [DRAFT-TRACK-ESMTP]. Mtrk-secret is the secret Envid is defined in [DRAFT-MTRK-ESMTP]. Mtrk-secret is the secret
A described in [DRAFT-TRACK-ESMTP], encoded using base64. A described in [DRAFT-MTRK-ESMTP], encoded using base64.
When the client issues the TRACK command, and the user is vali- When the client issues the TRACK command, and the user is vali-
dated, the MTQP server retrieves tracking information about an email dated, the MTQP server retrieves tracking information about an email
message. To validate the user, the value of mtrk-secret is hashed using message. To validate the user, the value of mtrk-secret is hashed using
SHA1, as described in [RFC-SHA1]. The hash value is then compared with SHA1, as described in [RFC-SHA1]. The hash value is then compared with
the value passed with the message when it was originally sent. If the the value passed with the message when it was originally sent. If the
hash values match, the user is validated. hash values match, the user is validated.
A successful response MUST be multi-line, consisting of a [RFC- A successful response MUST be multi-line, consisting of a [RFC-
MIME] body part. The MIME body part MUST be of type multipart/related, MIME] body part. The MIME body part MUST be of type multipart/related,
with subparts of message/tracking-status, as defined in [DRAFT-TRACK- with subparts of message/tracking-status, as defined in [DRAFT-MTRK-
TSN]. The response contains the tracking information about the email TSN]. The response contains the tracking information about the email
message that used the given tracking-id. message that used the given tracking-id.
A negative response to the TRACK command may include these reason
codes:
"/" "tls-required"
"/" "admin"
"/" "unavailable"
"/" "noinfo"
The reason code "/tls-required" SHOULD be used when the server has
decided to require TLS. The reason code "/admin" SHOULD be used when
the server has become unavailable, due to administrative reasons, since
the connection was initialized. The reason code "/unavailable" SHOULD
be used when the server has become unavailable, for other reasons, since
the connection was initialized.
If a message has not been seen by the MTQP server, the server MUST
choose between two choices: it MAY return a positive response with an
action field of "opaque" in the tracking information, or it MAY return a
negative response with a reason code of "noinfo".
4.1. Examples
In each of the examples below, the envid is "<12345- In each of the examples below, the envid is "<12345-
20010101@example.com>", the secret A is "abcdefgh", and the SHA1 hash B 20010101@example.com>", the secret A is "abcdefgh", and the SHA1 hash B
is (in hex) "734ba8b31975d0dbae4d6e249f4e8da270796c94". The message is (in hex) "734ba8b31975d0dbae4d6e249f4e8da270796c94". The message
came from example.com and the MTQP server is example2.com. came from example.com and the MTQP server is example2.com.
Example #6 Message Delivered: Example #6 Message Delivered:
C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
S: S:
skipping to change at page 14, line 25 skipping to change at page 15, line 43
8. Pipelining 8. Pipelining
The MTQP client may elect to transmit groups of MTQP commands in The MTQP client may elect to transmit groups of MTQP commands in
batches without waiting for a response to each individual command. The batches without waiting for a response to each individual command. The
MTQP server MUST process the commands in the order received. MTQP server MUST process the commands in the order received.
Specific commands may place further constraints on pipelining. For Specific commands may place further constraints on pipelining. For
example, STARTTLS must be the last command in a batch of MTQP commands. example, STARTTLS must be the last command in a batch of MTQP commands.
8.1. Examples
The following two examples are identical: The following two examples are identical:
Example #13 : Example #13 :
C: TRACK <tracking-id> YWJjZGVmZ2gK C: TRACK <tracking-id> YWJjZGVmZ2gK
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: S:
S: ... tracking details #1 go here ... S: ... tracking details #1 go here ...
S: . S: .
C: TRACK <tracking-id-2> QUJDREVGR0gK C: TRACK <tracking-id-2> QUJDREVGR0gK
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: S:
S: ... tracking details #2 go here ... S: ... tracking details #2 go here ...
S: . S: .
Example #14 : Example #14 :
C: TRACK <tracking-id> YWJjZGVmZ2gK C: TRACK <tracking-id> YWJjZGVmZ2gK
C: TRACK <tracking-id-2> QUJDREVGR0gK C: TRACK <tracking-id-2> QUJDREVGR0gK
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
skipping to change at page 15, line 5 skipping to change at page 16, line 23
C: TRACK <tracking-id-2> QUJDREVGR0gK C: TRACK <tracking-id-2> QUJDREVGR0gK
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: S:
S: ... tracking details #1 go here ... S: ... tracking details #1 go here ...
S: . S: .
S: +OK+ Tracking information follows S: +OK+ Tracking information follows
S: S:
S: ... tracking details #2 go here ... S: ... tracking details #2 go here ...
S: . S: .
9. URL Format 9. The MTQP URI Scheme
The MTQP URL scheme is used to designate MTQP servers on Internet 9.1. Intended usage
hosts accessible using the MTQP protocol. An MTQP URL takes one of the
following forms: The MTQP URI scheme is used to designate MTQP servers on Internet
hosts accessible using the MTQP protocol. It performs an MTQP query and
returns tracking status information.
9.2. URI Scheme Name
The name of the URI scheme is "mtqp".
9.3. URI Scheme Syntax
An MTQP URI takes one of the following forms:
mtqp://<mserver>/track/<envid>/<mtrk-secret> mtqp://<mserver>/track/<envid>/<mtrk-secret>
mtqp://<mserver>:<port>/track/<envid>/<mtrk-secret> mtqp://<mserver>:<port>/track/<envid>/<mtrk-secret>
The first form is used to refer to an MTQP server on the standard The first form is used to refer to an MTQP server on the standard
port, while the second form specifies a non-standard port. Both of port, while the second form specifies a non-standard port. Both of
these forms specify that the TRACK command is to be issued using the these forms specify that the TRACK command is to be issued using the
given tracking id (envid) and authorization secret (mtrk-secret). The given tracking id (envid) and authorization secret (mtrk-secret). The
path element "/track/" is case insensitive, but the envid and mtrk- path element "/track/" MUST BE treated case insensitively, but the envid
secret may not be. and mtrk-secret MUST NOT be.
9.1. MTQP URL Syntax 9.3.1. Formal Syntax
This is an ABNF description of the MTQP URL. This is an ABNF description of the MTQP URI.
mtqp-url = "mtqp://" net_loc "/track/" envid "/" mtrk-secret mtqp-uri = "mtqp://" net_loc "/track/" envid "/" mtrk-secret
9.4. Encoding Rules
The encoding of envid is discussed in [DRAFT-MTRK-ESMTP]. Mtrk-
secret is required to be base64 encoded. If the "/", "?" and "%" octets
appear in envid or mtrk-secret, they are further required to be
represented by a "%" followed by two hexadecimal characters. (The two
characters give the hexadecimal representation of that octet.)
10. IANA Considerations 10. IANA Considerations
System port number XXXX - TBD by IANA System port number XXXX - TBD by IANA
The service name to be registered with the Internet Assigned Number The service name to be registered with the Internet Assigned Number
Authority (IANA) is "MTQP". Authority (IANA) is "MTQP".
The IANA is asked to register the URI registration template found
in Appendix A in accordance with [BCP35].
This document requests that IANA maintain one new registry: MTQP This document requests that IANA maintain one new registry: MTQP
options. The registry's purpose is to register options to this proto- options. The registry's purpose is to register options to this proto-
col. Options whose names do not begin with "vnd." MUST be defined in a col. Options whose names do not begin with "vnd." MUST be defined in a
standards track or IESG approved experimental RFC. New MTQP options standards track or IESG approved experimental RFC. New MTQP options
MUST include the following information as part of their definition: MUST include the following information as part of their definition:
option identifier option identifier
option parameters option parameters
added commands added commands
standard commands affected standard commands affected
skipping to change at page 17, line 22 skipping to change at page 19, line 13
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 security level at the next hop. In a hop-by- negotiate TLS at the same (or better) security level at the next hop.
hop scenario, STARTTLS is a request for "best effort" security and In a hop-by-hop scenario, STARTTLS is a request for "best effort" secu-
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
per user. per user.
12. Protocol Syntax 12. Protocol Syntax
This is a collected ABNF description of the MTQP protocol. This is a collected ABNF description of the MTQP protocol.
conversation = command-response *( client-command command-response ) conversation = command-response *( client-command command-response )
# client side # client side
skipping to change at page 18, line 33 skipping to change at page 20, line 25
identifier = (ALPHA / "_") *NAMECHAR) identifier = (ALPHA / "_") *NAMECHAR)
response-info = *( "/" ( "admin" / "unavailable" / "unsupported" / response-info = *( "/" ( "admin" / "unavailable" / "unsupported" /
"tlsinprogress" / "insecure" / 1*NAMECHAR ) ) "tlsinprogress" / "insecure" / 1*NAMECHAR ) )
13. Acknowledgements 13. Acknowledgements
The description of STARTTLS is based on [RFC-SMTP-TLS]. The description of STARTTLS is based on [RFC-SMTP-TLS].
14. References 14. Normative References
[RFC-SHA1] RFC TBD, D. Eastlake & P. Jones, "US Secure Hash Stan-
dard 1 (SHA1)", TBD 2001.
[RFC-MIME] RFC 2045, N. Freed & N. Borenstein, "Multipurpose Inter- [RFC-MIME] RFC 2045, N. Freed & N. Borenstein, "Multipurpose Inter-
net Mail Extensions (MIME) Part One: Format of Internet Message Bodies", net Mail Extensions (MIME) Part One: Format of Internet
Innosoft, First Virtual, November 1996. Message Bodies", Innosoft, First Virtual, November 1996.
[RFC-ABNF] RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented [RFC-ABNF] RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented
BNF for Syntax Specifications: ABNF", Internet Mail Consortium, Demon BNF for Syntax Specifications: ABNF", Internet Mail Con-
Internet Ltd., November 1997. sortium, Demon Internet Ltd., November 1997.
[RFC-KEYWORDS] RFC 2119, S. Bradner, "Key words for use in RFCs to [RFC-SRV] RFC 2782, A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR
Indicate Requirement Levels", Harvard University, March 1997. for specifying the location of services (DNS SRV)" Troll
Technologies, Internet Software Consortium, Microsoft
Corp., February 2000
[RFC-SMTPEXT] RFC 2554, J. Myers, "SMTP Service Extension for [RFC-SMTPEXT]
Authentication", Netscape Communications, March 1999. RFC 2554, J. Myers, "SMTP Service Extension for Authenti-
cation", Netscape Communications, March 1999.
[RFC-SMTP-TLS] RFC2487, P. Hoffman, "SMTP Service Extension for [DRAFT-MTRK-ESMTP]
Secure SMTP over TLS", Internet Mail Consortium, January 1999. draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T. Hansen,
"SMTP Service Extension for Message Tracking", Sendmail,
Inc., AT&T Laboratories, TBD 2002.
[RFC-SRV] RFC 2782, A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR [DRAFT-MTRK-MODEL]
for specifying the location of services (DNS SRV)" Troll Technologies, draft-ietf-msgtrk-model-*.txt, T. Hansen, "Message
Internet Software Consortium, Microsoft Corp., February 2000 Tracking Models and Requirements", AT&T Laboratories, TBD
2002.
[DRAFT-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T. [DRAFT-MTRK-TSN]
Hansen, "SMTP Service Extension for Message Tracking", Sendmail, Inc., draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The
AT&T Laboratories, TBD 2001. Message/Tracking-Status MIME Extension", Sendmail, Inc.,
TBD 2002.
[DRAFT-TRACK-MODEL] draft-ietf-msgtrk-model-*.txt, T. Hansen, "Mes- [RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni-
sage Tracking Models and Requirements", AT&T Laboratories, TBD 2001. form Resource Identifiers (URI): Generic Syntax",
MIT/LCS, U. C. Irvine, Xerox Corporation, August 1998.
[DRAFT-TRACK-TSN] draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The 15. Informational References
Message/Tracking-Status MIME Extension", Sendmail, Inc., TBD 2001.
[RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni- [BCP35] BCP 35, RFC 2717, R. Petke, I. King, "Registration Pro-
form Resource Identifiers (URI): Generic Syntax", MIT/LCS, U. C. Irvine, cedures for URL Scheme Names", November 1999.
Xerox Corporation, August 1998.
15. Author's Address [RFC-SHA1]RFC 3184, D. Eastlake & P. Jones, "US Secure Hash Stan-
dard 1 (SHA1)", September 2001.
[RFC-KEYWORDS]
RFC 2119, S. Bradner, "Key words for use in RFCs to Indi-
cate Requirement Levels", Harvard University, March 1997.
[RFC-SMTP-TLS]
RFC2487, P. Hoffman, "SMTP Service Extension for Secure
SMTP over TLS", Internet Mail Consortium, January 1999.
Appendix A. MTQP URI Registration Template
Scheme name: mtqp
Scheme syntax: see section 9.1
Character encoding considerations: see section 9.4
Intended usage: see section 9.3
Applications and/or protocols which use this scheme: MTQP
Interoperability considerations: as specified for MTQP
Security considerations: see section 11.0
Relevant publications: [DRAFT-MTRK-ESMTP], [DRAFT-MTRK-MODEL],
[DRAFT-MTRK-TSN]
Contact: MSGTRK Working Group
Author/Change Controller: IESG
16. Author's Address
Tony Hansen Tony Hansen
AT&T Laboratories AT&T Laboratories
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Phone: +1.732.420.8934 Phone: +1.732.420.8934
E-Mail: tony@att.com E-Mail: tony@att.com
16. Full Copyright Statement 17. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (%Dy%). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis- assist in its implementation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all that the above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document itself may not such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or be modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations, references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
skipping to change at page 20, line 15 skipping to change at page 22, 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 November 19, 2002. This document expires April 24, 2003.
 End of changes. 46 change blocks. 
87 lines changed or deleted 217 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/