draft-ietf-msgtrk-mtqp-10.txt   draft-ietf-msgtrk-mtqp-11.txt 
Internet Draft T. Hansen Internet Draft T. Hansen
draft-ietf-msgtrk-mtqp-10.txt AT&T Laboratories draft-ietf-msgtrk-mtqp-11.txt AT&T Laboratories
Valid for six months June 30, 2003 Valid for six months July 16, 2003
Message Tracking Query Protocol Message Tracking Query Protocol
<draft-ietf-msgtrk-mtqp-10.txt> <draft-ietf-msgtrk-mtqp-11.txt>
Authors' version: 1.22 Authors' version: 1.25
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 -10 1.2.1. Changes Made for -11
More IESG comments:
Consider a server that requires TLS be negotiated before it will
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
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
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 option parameter "required" that says some domains this server han-
dles require TLS.
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
that appears in the ABNF.
Finally, section 6 begins with: "TLS [TLS], more commonly known as
SSL,". SSL is a somewhat different and earlier protocol; it is not the
same as TLS. The reference to SSL needs to be removed.
1.2.2. 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 16 skipping to change at page 3, line 37
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.2. Changes Made for -09 1.2.3. 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 3, line 32 skipping to change at page 4, line 4
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.3. Changes Made for -08 1.2.4. 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.4. Changes Made for -07 1.2.5. 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.5. Changes Made for -06 1.2.6. Changes Made for -06
Added opt-parameter to STARTTLS and description. Added opt-parameter to STARTTLS and description.
1.2.6. Changes Made for -05 1.2.7. 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.7. Changes Made for -04 1.2.8. 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.8. Changes Made for -03 1.2.9. 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.9. Changes Made for -02 1.2.10. 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.
Added text on various error conditions and fixed ABNF for error Added text on various error conditions and fixed ABNF for error
skipping to change at page 8, line 30 skipping to change at page 8, line 49
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 [1*WSP "required"]
This capability MUST be listed if the optional STARTTLS command is sup- This capability MUST be listed if the optional STARTTLS command is
ported by the MTQP server. It has no parameters. enabled on the MQTP server and one or more certificates have been
properly installed.
It has one optional parameter: the word "required". (The parame-
ters for STARTTLS are case-insensitive.) If the server requires that
TLS be used for some of the domains the server handles, the server
SHOULD 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 9, line 39 skipping to change at page 10, line 17
with subparts of message/tracking-status, as defined in [DRAFT-MTRK- 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 A negative response to the TRACK command may include these reason
codes: codes:
"/" "tls-required" "/" "tls-required"
"/" "admin" "/" "admin"
"/" "unavailable" "/" "unavailable"
"/" "noinfo" "/" "noinfo"
"/" "insecure"
The reason code "/tls-required" SHOULD be used when the server has The reason code "/tls-required" SHOULD be used when the server has
decided to require TLS. The reason code "/admin" SHOULD be used when decided to require TLS. The reason code "/admin" SHOULD be used when
the server has become unavailable, due to administrative reasons, since the server has become unavailable, due to administrative reasons, since
the connection was initialized. The reason code "/unavailable" SHOULD the connection was initialized. The reason code "/unavailable" SHOULD
be used when the server has become unavailable, for other reasons, since be used when the server has become unavailable, for other reasons, since
the connection was initialized. the connection was initialized. The reason code "/insecure" is
described later.
If a message has not been seen by the MTQP server, the server MUST 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 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 action field of "opaque" in the tracking information, or it MAY return a
negative response with a reason code of "noinfo". negative response with a reason code of "noinfo".
4.1. Examples 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
skipping to change at page 14, line 22 skipping to change at page 14, line 50
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" WSP hostname WSP CRLF "STARTTLS" 1*WSP hostname *WSP CRLF
TLS [TLS] is a popular mechanism for enhancing TCP communications
TLS [TLS], more commonly known as SSL, is a popular mechanism for with privacy and authentication. All MTQP servers MUST implement TLS.
enhancing TCP communications with privacy and authentication. An MTQP However, TLS MAY be disabled by by a server administrator, either expli-
server SHOULD support TLS. If an MTQP server supports TLS, it MUST citly or by failing to install any certificates for TLS to use. If an
include "STARTTLS" in the option specifications list on protocol MTQP server supports TLS and has one or more certificates available it
MUST include "STARTTLS" in the option specifications list on protocol
startup. startup.
Note: TLS MUST be implemented by the server, but it may be disabled Note: TLS SHOULD be enabled on MQTP servers whenever possible.
by the administrator or if there's no certificate available.
The parameter MUST be a fully qualified domain name. A client MUST The parameter MUST be a fully qualified domain name. A client MUST
specify the hostname it believes it is speaking with so that the server specify the hostname it believes it is speaking with so that the server
may respond with the proper TLS certificate. This is useful for virtual may respond with the proper TLS certificate. This is useful for virtual
servers that provide message tracking for multiple domains (i.e., vir- servers that provide message tracking for multiple domains (i.e., vir-
tual hosting). tual 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"
"/" "tlsinprogress" "/" "tls-in-progress"
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 "/tlsinprogress". returned with a response code of "/tls-in-progress".
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.
skipping to change at page 20, line 17 skipping to change at page 20, line 50
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
client-command = track-command / starttls-command / quit-command / comment-command client-command = track-command / starttls-command / quit-command / comment-command
track-command = "TRACK" 1*WS envid 1*WS mtrk-secret CRLF track-command = "TRACK" 1*WS envid 1*WS mtrk-secret CRLF
mtrk-secret = base64 mtrk-secret = base64
starttls-command = "STARTTLS" [WSP hostname] CRLF starttls-command = "STARTTLS" 1*WSP hostname *WSP CRLF
quit-command = "QUIT" CRLF quit-command = "QUIT" CRLF
comment-command = "COMMENT" opt-text CRLF comment-command = "COMMENT" opt-text CRLF
; server side ; server side
command-response = success-response / temp-response / error-response / bad-response command-response = success-response / temp-response / error-response / bad-response
temp-response = "-TEMP" response-info opt-text CRLF temp-response = "-TEMP" response-info opt-text CRLF
opt-text = [WSP *(VCHAR / WSP)] opt-text = [WSP *(VCHAR / WSP)]
error-response = "-ERR" response-info opt-text CRLF error-response = "-ERR" response-info opt-text CRLF
skipping to change at page 21, line 4 skipping to change at page 21, line 36
option-list = *option-line option-list = *option-line
option-line = identifier opt-text *(CRLF WSP opt-text) CRLF option-line = identifier opt-text *(CRLF WSP opt-text) CRLF
NAMECHAR = ALPHA / DIGIT / "-" / "_" NAMECHAR = ALPHA / DIGIT / "-" / "_"
identifier = (ALPHA / "_") *NAMECHAR identifier = (ALPHA / "_") *NAMECHAR
response-info = *( "/" ( "admin" / "unavailable" / "unsupported" / response-info = *( "/" ( "admin" / "unavailable" / "unsupported" /
"tlsinprogress" / "insecure" / 1*NAMECHAR ) ) "tls-in-progress" / "insecure" / "tls-required" / 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. Normative References 14. Normative References
[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 net Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", Innosoft, First Virtual, November 1996. Message Bodies", Innosoft, First Virtual, November 1996.
skipping to change at page 23, line 32 skipping to change at page 24, line 12
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 December 30, 2003. This document expires January 16, 2004.
 End of changes. 27 change blocks. 
33 lines changed or deleted 60 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/