idnits 2.17.1 draft-ietf-msgtrk-mtqp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 16 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1, 2000) is 8700 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'POP3' is mentioned on line 86, but not defined == Missing Reference: 'NNTP' is mentioned on line 86, but not defined == Unused Reference: 'RFC-821' is defined on line 318, but no explicit reference was found in the text == Unused Reference: 'RFC-822' is defined on line 322, but no explicit reference was found in the text == Unused Reference: 'RFC-ESMTP' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'RFC-MD5' is defined on line 335, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2234 (ref. 'RFC-ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1651 (ref. 'RFC-ESMTP') (Obsoleted by RFC 1869) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'RFC-MD5') == Outdated reference: A later version (-07) exists of draft-ietf-msgtrk-model-02 ** Downref: Normative reference to an Informational draft: draft-ietf-msgtrk-model (ref. 'RFC-TRACK-MODEL') -- No information found for draft-ietf-msgtrk-smtpext- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RFC-TRACK-ESMTP' == Outdated reference: A later version (-05) exists of draft-ietf-msgtrk-trkstat-00 ** Obsolete normative reference: RFC 1808 (ref. 'RFC-URL') (Obsoleted by RFC 3986) Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft T. Hansen 3 draft-ietf-msgtrk-mtqp-00.txt AT&T Laboratories 4 Valid for six months 5 July 1, 2000 7 Message Tracking Query Protocol 9 11 Authors' version: 1.3 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents at 24 any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This memo and its companions are discussed on the MSGTRK working 34 group mailing list, ietf-msgtrk@imc.org. To subscribe, send a message 35 with the word "subscribe" in the body (on a line by itself) to the 36 address ietf-msgtrk-request@imc.org. An archive of the mailing list may 37 be found at http://www.ietf.org/archive/msgtrk. 39 Copyright Notice 41 Copyright (C) The Internet Society (1999). All Rights Reserved. 43 Abstract 45 Customers buying enterprise message systems often ask: Can I track 46 the messages? Message tracking is the ability to find out the path that 47 a particular message has taken through a messaging system and the 48 current routing status of that message. This document describes the 49 Message Tracking Query Protocol that is used in conjunction with exten- 50 sions to the ESMTP protocol to provide a complete message tracking solu- 51 tion for the Internet. 53 NOTE: This is a straw proposal for the Message Tracking Query Pro- 54 tocol. 56 1. Introduction 58 The Message Tracking Models and Requirements document [RFC-TRACK- 59 MODEL] discusses the models that message tracking solutions could fol- 60 low, along with requirements for a message tracking solution that can be 61 used with the Internet-wide message infrastructure. This memo and its 62 companions, [RFC-TRACK-ESMTP] and [RFC-TRACK-TSN], describe a complete 63 message tracking solution that satisfies those requirements. The memo 64 [RFC-TRACK-ESMTP] defines an extension to the SMTP service that provides 65 the information necessary to track messages. This memo defines a proto- 66 col that can be used to query the status of messages that have been 67 transmitted on the Internet via SMTP. The memo [RFC-TRACK-TSN] 68 describes the message/tracking-status MIME media type that is used to 69 report tracking status information. Using the model document's termi- 70 nology, this solution uses active enabling and active requests with both 71 request and chaining referrals. 73 1.1. Terminology 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC-KEYWORDS]. 79 All syntax descriptions use the ABNF specified by [RFC-ABNF]. 80 Unless otherwise noted, any terminal nodes not defined here are defined 81 in [RFC-ABNF]. 83 2. Basic Operation 85 The Message Tracking Query Protocol (MTQP) is similar to many other 86 line-oriented Internet protocols, such as [POP3] and [NNTP]. Initially, 87 the server host starts the MTQP service by listening on TCP port ????. 88 When a client wishes to make use of the service, it establishes a TCP 89 connection with the server host. When the connection is established, 90 the MTQP SERVER SENDS A GREETING. The client and MTQP server then 91 exchange commands and responses (respectively) until the connection is 92 closed or aborted. 94 Commands in MTQP consist of a case-insensitive keyword, possibly 95 followed by one or more parameters. All commands are terminated by a 96 CRLF pair. Keywords and parameters consist of printable ASCII charac- 97 ters. Keywords and parameters are separated by whitespace (one or more 98 space or tab characters). A command line is limited to 998 characters 99 before the CRLF. 101 Responses in MTQP consist of a status indicator that indicates suc- 102 cess or failure, possibly followed by whitespace and additional informa- 103 tion. Successful commands may also be followed by additional lines of 104 data. All response lines are terminated by a CRLF pair and are limited 105 to 998 characters before the CRLF. There are several status indicators: 106 "+OK" indicates success; "+OK+" indicates a success followed by addi- 107 tional lines of data, a multi-line success response; "-TEMP" indicates a 108 temporary failure; "-ERR" indicates a permanent failure; and "-BAD" 109 indicates a protocol error (such as for unrecognized commands). 111 A multi-line success response may take one of two forms. If the 112 end of the +OK+ line contains the character "{", a number, and the char- 113 acter "}" before the CRLF, then the rest of the response consists of 114 that number of characters. 116 If the multi-line success response does not end with "{number}", 117 each subsequent line is terminated by a CRLF pair and limited to 998 118 characters before the CRLF. When all lines of the response have been 119 sent, a final line is sent consisting of a single period (".", decimal 120 code 046) and a CRLF pair. If any line of the multi-line response 121 begins with a period, the line is "dot-stuffed" by prepending the period 122 with a second period. When examining a multi-line response, the client 123 checks to see if the line begins with a period. If so, and other octets 124 other than CRLF follow, the first octet of the line (the period) is 125 stripped away. If so, and if CRLF immediately follows the period, then 126 the response from the MTQP server is ended and the line containing the 127 ".CRLF" is not considered part of the multi-line response. 129 An MTQP server MUST respond to an unrecognized, unimplemented, or 130 syntactically invalid command by responding with a negative -BAD status 131 indicator. A server MUST respond to a command issued when the session 132 is in an incorrect state by responding with a negative -ERR status indi- 133 cator. 135 An MTQP server MAY have an inactivity autologout timer. Such a 136 timer MUST be of at least 10 minutes' duration. The receipt of any com- 137 mand from the client during that interval should suffice to reset the 138 autologout timer. 140 3. Initialization 142 Once the TCP connection has been opened by an MTQP client, the MTQP 143 server issues an initial status response indicates its readiness. If 144 the status response is positive (+OK or +OK+), the client may proceed 145 with other commands. 147 If the server has any options enabled, they are listed as the 148 multi-line response of the initial status response, one per line. An 149 option specification consists of an identifier, optionally followed by 150 option-specific parameters. An option specification may be continued 151 onto additional lines by starting the continuation lines with white 152 space. 154 No options are defined in this document. 156 Example #1 (no options): 157 S: +OK MTQ server ready 159 Example #2 (service temporarily unavailable): 160 S: -TEMP Service down for admin, call back later 162 Example #3 (service permanently unavailable): 163 S: -ERR Service down 165 Example #4 (alternative for no options): 166 S: +OK+ MTQ server ready 167 S: . 169 Example #5 (options available): 170 S: +OK+ MTQ server ready 171 S: Option1 parameters 172 S: Option2 173 S: Option3 a very long 174 S: list of parameters 175 S: . 177 4. TRACK Command 179 Syntax: 180 "TRACK" 1*WS tracking-id 1*WS authorization-cookie *WS CRLF 182 tracking-id = TBD 184 authorization-cookie = TBD 186 When the client issues the TRACK command, the MTQP server retrieves 187 tracking information about an email message. A successful response MUST 188 be multi-line, consisting of a [MIME] mail message whose default 189 content-type is message/tracking-status, as defined in [RFC-TRACK-TSN]. 190 This message contains the tracking information about the email message 191 that used the given tracking-id. The tracking-id and authorization- 192 cookie are defined in [RFC-TRACK-ESMTP]. The authorization-cookie is 193 expressed in hexadecimal. 195 Example #6 196 C: TRACK 1234567890ABCDEF 197 S: +OK+ Tracking information follows 198 S: Content-Type: message/tracking-status 199 S: 200 S: ... details go here ... 201 S: . 203 5. NOOP Command 205 Syntax: 206 "NOOP" opt-text CRLF 208 When the client issues the NOOP command, the MTQP server resets the 209 inactivity autologout timer. The server MUST respond with a successful 210 response (+OK or +OK+). All parameters to the NOOP command are ignored. 212 6. QUIT Command 214 Syntax: 215 "QUIT" *WS CRLF 217 When the client issues the QUIT command, the MTQP session ter- 218 minates. The QUIT command has no parameters. The server MUST respond 219 with a successful response. The client may close the session from its 220 end immediately after issuing this command. 222 7. Pipelining 224 The MTQP client may elect to transmit groups of MTQP commands in 225 batches without waiting for a response to each individual command. The 226 MTQP server MUST process the commands in the order received. The fol- 227 lowing two examples are identical: 229 Example #7 230 C: TRACK 1234567890ABCDEF 231 S: +OK+ Tracking information follows 232 S: 233 S: ... details go here ... 234 S: . 235 C: NOOP 236 S: +OK Status okay 238 Example #8 239 C: TRACK 1234567890ABCDEF 240 C: NOOP 241 S: +OK+ Tracking information follows 242 S: 243 S: ... details go here ... 244 S: . 245 S: +OK Status okay 247 8. URL Format 249 The MTQP URL scheme is used to designate MTQP servers on Internet 250 hosts accessible using the MTQP protocol. An MTQP URL takes one of the 251 following forms: 253 mtqp:///track/: 254 mtqp://:/track/: 256 The first form is used to refer to an MTQP server on the standard 257 port, while the second form specifies a non-standard port. Both of 258 these forms specify that the TRACK command is to be issued using the 259 given tracking id and authorization cookie. The path element "/track/" 260 is case insensitive, but the tracking id may not be. 262 8.1. MTQP URL Syntax 264 This is an ABNF description of the MTQP URL. Terminal nodes not 265 defined here are defined in either [RFC-URL] or [RFC-ABNF]. 267 mtqp-url = "mtqp://" net_loc "/track/" tracking-id ":" cookie 269 tracking-id = TBD 271 cookie = 16HEXDIG 273 9. IANA Considerations 275 TBD - registering extensions 277 10. Security Considerations 279 Security considerations discussed in [RFC-TRACK-MODEL] and [RFC- 280 TRACK-ESMTP] are relevant. 282 11. Protocol Syntax 284 This is an ABNF description of MTQP. 285 command-response = success-response / temp-response / error-response / bad-response 287 temp-response = "-TEMP" opt-text CRLF 288 opt-text = [WSP *(VCHAR / WSP)] 290 error-response = "-ERR" opt-text CRLF 292 bad-response = "-BAD" opt-text CRLF 294 success-response = single-line-success / multi-line-success / multi-char-success 296 single-line-success = "+OK" opt-text CRLF 298 multi-char-success = "+OK+" opt-text "{" 1*DIGIT "}" *WSP CRLF *OCTET 299 ; the number of characters specified by {number} ; must be 300 sent 302 multi-line-success = "+OK+" opt-text CRLF *dataline dotcrlf 304 dataline = *998OCTET CRLF 306 dotcrlf = "." CRLF 308 option-list = *option-line 310 option-line = rulename opt-text *[CRLF WSP opt-text] CRLF 312 12. References 314 [MIME] RFC 2045, N. Freed & N. Borenstein, "Multipurpose Internet 315 Mail Extensions (MIME) Part One: Format of Internet Message Bodies", 316 November 1996. 318 [RFC-821] STD 10, RFC 821, J. Postel, "Simple Mail Transfer Proto- 319 col", University of Southern California / Information Sciences Insti- 320 tute, August 1982. 322 [RFC-822] STD 11, RFC 822, D. Crocker, "Standard for the Format of 323 ARPA Internet Text Messages", University of Delaware, August 1982. 325 [RFC-ABNF] RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented 326 BNF for Syntax Specifications: ABNF", November 1997. 328 [RFC-ESMTP] RFC 1651, J. Klensin, N. Freed, M. Rose, E. Stefferud, 329 and D. Crocker, "SMTP Service Extensions", Silicon Graphics, Inc., July 330 1994. 332 [RFC-KEYWORDS] RFC 2119, S. Bradner, "Key words for use in RFCs to 333 Indicate Requirement Levels", March 1997. 335 [RFC-MD5] RFC 1321, R. Rivest, "The MD5 Message-Digest Algorithm", 336 April 1992. 338 [RFC-TRACK-MODEL] draft-ietf-msgtrk-model-02.txt, T. Hansen, K. 339 Lin, "Message Tracking Models and Requirements", AT&T Laboratories, 340 Lotus Development Corporation, ???? 2000. 342 [RFC-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-*.txt, E. Allman, "SMTP 343 Service Extension for Message Tracking", Sendmail, Inc., ???? 2000. 345 [RFC-TRACK-TSN] draft-ietf-msgtrk-trkstat-00.txt, E. Allman, "The 346 Message/Tracking-Status MIME Extension", Sendmail, Inc., ???? 2000. 348 [RFC-URL] RFC 1808, R. Fielding, "Relative Uniform Resource Loca- 349 tors", June 1995. 351 13. Authors' Addresses 353 Tony Hansen 354 AT&T Laboratories 355 Lincroft, NJ 07738 356 USA 358 Phone: +1.732.576.3207 359 E-Mail: tony@att.com 361 14. Full Copyright Statement 363 Copyright (C) The Internet Society (1999). All Rights Reserved. 365 This document and translations of it may be copied and furnished to 366 others, and derivative works that comment on or otherwise explain it or 367 assist in its implmentation may be prepared, copied, published and dis- 368 tributed, in whole or in part, without restriction of any kind, provided 369 that the above copyright notice and this paragraph are included on all 370 such copies and derivative works. However, this document itself may not 371 be modified in any way, such as by removing the copyright notice or 372 references to the Internet Society or other Internet organisations, 373 except as needed for the purpose of developing Internet standards in 374 which case the procedures for copyrights defined in the Internet Stan- 375 dards process must be followed, or as required to translate it into 376 languages other than English. 378 The limited permissions granted above are perpetual and will not be 379 revoked by the Internet Society or its successors or assigns. 381 This document and the information contained herein is provided on 382 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 383 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 384 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 385 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 386 FITNESS FOR A PARTICULAR PURPOSE. 388 This document expires January 1, 2001.