draft-ietf-msgtrk-mtqp-09.txt   draft-ietf-msgtrk-mtqp-10.txt 
Internet Draft T. Hansen Internet Draft T. Hansen
draft-ietf-msgtrk-mtqp-09.txt AT&T Laboratories draft-ietf-msgtrk-mtqp-10.txt AT&T Laboratories
Valid for six months October 24, 2002 Valid for six months June 30, 2003
Message Tracking Query Protocol Message Tracking Query Protocol
<draft-ietf-msgtrk-mtqp-09.txt> <draft-ietf-msgtrk-mtqp-10.txt>
Authors' version: 1.20 Authors' version: 1.22
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 38 skipping to change at page 2, line 38
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-MTRK-ESMTP] or [RFC-SMTPEXT]. ABNF], [RFC-URI], [DRAFT-MTRK-ESMTP] or [RFC-SMTPEXT].
1.2. Changes Made for... 1.2. Changes Made for...
The Changes sections will be removed before publication. These Changes sections will be removed before publication.
1.2.1. Changes Made for -09 1.2.1. Changes Made for -10
Fixes for IESG comments:
Make the hostname parameter in the STARTTLS command mandatory.
Add a sentence clarifying that TLS is mandatory to implement, but
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
support is a SHOULD instead of a MAY.)
IESG: An error response of "/insecure" from the server is too late,
in that the confidential information is already exposed. (Well, the
response isn't, but an eavesdropper can then request the response
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
queries.
This implies that if the server decides that the level of auth isn't
high enough to continue, it MAY abort the connection.
Fix ABNF: fix comment characters (";", not "#")
Fix ABNF: remove trailing ) from identifier definition
1.2.2. 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 17 skipping to change at page 3, line 42
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.2. Changes Made for -08 1.2.3. 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.3. Changes Made for -07 1.2.4. 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.4. Changes Made for -06 1.2.5. Changes Made for -06
Added opt-parameter to STARTTLS and description. Added opt-parameter to STARTTLS and description.
1.2.5. Changes Made for -05 1.2.6. 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.6. Changes Made for -04 1.2.7. 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.7. Changes Made for -03 1.2.8. 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.8. Changes Made for -02 1.2.9. 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 13, line 45 skipping to change at page 14, line 22
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] CRLF "STARTTLS" WSP hostname WSP CRLF
TLS [TLS], more commonly known as SSL, is a popular mechanism for TLS [TLS], more commonly known as SSL, is a popular mechanism for
enhancing TCP communications with privacy and authentication. An MTQP enhancing TCP communications with privacy and authentication. An MTQP
server MAY support TLS. If an MTQP server supports TLS, it MUST include server SHOULD support TLS. If an MTQP server supports TLS, it MUST
"STARTTLS" in the option specifications list on protocol startup. include "STARTTLS" in the option specifications list on protocol
startup.
The optional parameter, if specified, MUST be a fully qualified Note: TLS MUST be implemented by the server, but it may be disabled
by the administrator or if there's no certificate available.
domain name. A client MAY specify the hostname it believes it is speak- The parameter MUST be a fully qualified domain name. A client MUST
ing with so that the server may respond with the proper TLS certificate. specify the hostname it believes it is speaking with so that the server
This is useful for virtual servers that provide message tracking for may respond with the proper TLS certificate. This is useful for virtual
multiple domains (i.e., virtual hosting). servers that provide message tracking for multiple domains (i.e., vir-
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" "/" "tlsinprogress"
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
skipping to change at page 14, line 35 skipping to change at page 15, line 17
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 move tion and privacy achieved. The MTQP client and server may decide to
ahead even if the TLS negotiation ended with no authentication and/or no move ahead even if the TLS negotiation ended with no authentication
privacy because most MTQP services are performed with no authentication and/or no privacy because most MTQP services are performed with no
and no privacy, but some MTQP clients or servers may want to continue authentication and no privacy, but some MTQP clients or servers may want
only if a particular level of authentication and/or privacy was to continue only if a particular level of authentication and/or privacy
achieved. was achieved.
If the MTQP client decides that the level of authentication or If the MTQP client decides that the level of authentication or
privacy is not high enough for it to continue, it SHOULD issue an MTQP privacy is not high enough for it to continue, it SHOULD issue an MTQP
QUIT command immediately after the TLS negotiation is complete. If the QUIT command immediately after the TLS negotiation is complete.
MTQP server decides that the level of authentication or privacy is not
high enough for it to continue, it SHOULD reply to every MTQP command If the MTQP server decides that the level of authentication or
from the client (other than a QUIT command) with a negative "-ERR" privacy is not high enough for it to continue, it MAY abort the connec-
response and a response code of "/insecure". tion. If it decides that the level of authentication or privacy is not
high enough for it to continue, and it does not abort the connection, it
SHOULD reply to every MTQP command from the client (other than a QUIT
command) with a negative "-ERR" response and a response code 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.
At the end of the TLS handshake, the server acts as if the connec- At the end of the TLS handshake, the server acts as if the connec-
tion had been initiated and responds with an initial status response tion had been initiated and responds with an initial status response
and, optionally, a list of server options. The list of MTQP server and, optionally, a list of server options. The list of MTQP server
options received after the TLS handshake MUST be different than the list options received after the TLS handshake MUST be different than the list
skipping to change at page 19, line 25 skipping to change at page 20, line 10
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
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
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" [WSP hostname] 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
bad-response = "-BAD" response-info opt-text CRLF bad-response = "-BAD" response-info opt-text CRLF
skipping to change at page 20, line 16 skipping to change at page 20, line 50
dataline = *998OCTET CRLF dataline = *998OCTET CRLF
dotcrlf = "." CRLF dotcrlf = "." CRLF
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 ) ) "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. Normative References 14. Normative References
skipping to change at page 20, line 50 skipping to change at page 21, line 35
[RFC-SMTPEXT] [RFC-SMTPEXT]
RFC 2554, J. Myers, "SMTP Service Extension for Authenti- RFC 2554, J. Myers, "SMTP Service Extension for Authenti-
cation", Netscape Communications, March 1999. cation", Netscape Communications, March 1999.
[DRAFT-MTRK-ESMTP] [DRAFT-MTRK-ESMTP]
draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T. Hansen, draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T. Hansen,
"SMTP Service Extension for Message Tracking", Sendmail, "SMTP Service Extension for Message Tracking", Sendmail,
Inc., AT&T Laboratories, TBD 2002. Inc., AT&T Laboratories, TBD 2002.
[DRAFT-MTRK-MODEL] [DRAFT-MTRK-MODEL]
draft-ietf-msgtrk-model-*.txt, T. Hansen, "Message draft-ietf-msgtrk-model-*.txt, T. Hansen, "Message Track-
Tracking Models and Requirements", AT&T Laboratories, TBD ing Models and Requirements", AT&T Laboratories, TBD
2002. 2002.
[DRAFT-MTRK-TSN] [DRAFT-MTRK-TSN]
draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The
Message/Tracking-Status MIME Extension", Sendmail, Inc., Message/Tracking-Status MIME Extension", Sendmail, Inc.,
TBD 2002. TBD 2002.
[RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni- [RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni-
form Resource Identifiers (URI): Generic Syntax", form Resource Identifiers (URI): Generic Syntax",
MIT/LCS, U. C. Irvine, Xerox Corporation, August 1998. MIT/LCS, U. C. Irvine, Xerox Corporation, August 1998.
skipping to change at page 22, line 45 skipping to change at page 23, line 32
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 April 24, 2003. This document expires December 30, 2003.
 End of changes. 25 change blocks. 
38 lines changed or deleted 70 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/