Comments on draft-ietf-msgtrk-mtqp-03.txt

Gregory Neil Shapiro <[email protected]> Sat, 4 Aug 2001 01:47:34 -0700
Newsgroups gmane.ietf.msgtrk
Message-ID <[email protected]>
2.  Basic Operation

The second paragraph describes how to determine tracking host to contact.
How about a host like this:

gshapiro.net	IN	SRV	mtqp tracking.gshapiro.net
		IN	MX 10	smtp.gshapiro.net
		IN	MX 20	smtp.sendmail.com

In other words, a dedicated tracking server for gshapiro.net and two MX
records.  When an SMTP message is sent, smtp.gshapiro.net happens to be
unavailable so the message goes to smtp.sendmail.com.  If an MTQP client
then tries to track the message, it will use tracking.gshapiro.net (due to
the SRV record).  However, tracking.gshapiro.net doesn't know about the
message yet (still in smtp.sendmail.com's queue).  The lookup fails.

Also, it's not clear from the paragraph that if SRV records do not exist,
do you only use the first MX returned or all of them in MX preference
order?

If I may suggest the following change:

     When an MTQP client wishes to make use of the message tracking
     service, it establishes a TCP connection with the server host.  To
     find the server host, the MTQP client first does an MX lookup for the
     server host using DNS MX records, as specified in [RFC-DNS] and
     revised by [RFC-HOSTS].  If no MX records are found, the MTQP client
     then does an A record lookup for the server host.  If MX records are
     found, for each MX record (in MX preference order -- lowest to
     highest), an SRV lookup on the MX host name using DNS SRV records,
     with a service name of "mtqp".  (See the "Usage rules" section in
     [RFC-SRV] for details.)  If a SRV host is found, the MTQP client uses
     that host for tracking.  Otherwise, it uses the MX host name for
     tracking.  Finally, the host either the SRV host (if found) or the MX
     host is contacted using MTQP.  This process is repeated for each of
     the MX records until an MTQP lookup succeeds (i.e., tracking status is
     returned).

With this new text, the DNS records might look something like:

gshapiro.net		IN	MX 10	smtp.gshapiro.net
			IN	MX 20	smtp.sendmail.com

smtp.gshapiro.net	IN	A	10.254.153.10

smtp.sendmail.com	IN	A	192.168.10.43
			IN	SRV	mtqp tracking.sendmail.com

tracking.sendmail.com	IN	A	192.168.10.45

In which case, a message sent to [email protected] would be tracked by
first contacting smtp.gshapiro.net with MTQP and if no tracking information
is available at that host (or it can not be contacted), then continue by
contacting tracking.sendmail.com with MTQP.

An example, such as the one I have given should be added to the draft.

---

3.  Initialization and Option Response

Example 5 should probably use "VND." as Option2 and Option3 are not valid
(only STARTTLS is).  A suggested replacement:

     Example #5 (options available):
     S: +OK+/MTQP MTQP server ready
     S: starttls
     S: Vnd.vendor.Option2 with parameters
     S: Vnd.vendor.Option3 with a very long
     S:  list of parameters
     S: .

---

10.  IANA Considerations

Vendor-specific options MUST be registered with IANA?  I thought the whole
point of vendor options was like that of 'X' ESMTP extensions:

RFC 2821             Simple Mail Transfer Protocol            April 2001
2.2.2 Definition and Registration of Extensions

   In addition, any EHLO keyword value starting with an upper or lower
   case "X" refers to a local SMTP service extension used exclusively
   through bilateral agreement.  Keywords beginning with "X" MUST NOT be
   used in a registered service extension.  Conversely, keyword values
   presented in the EHLO response that do not begin with "X" MUST
   correspond to a standard, standards-track, or IESG-approved
   experimental SMTP service extension registered with IANA.  A
   conforming server MUST NOT offer non-"X"-prefixed keyword values that
   are not described in a registered extension.

If that is the case, then they should not be registered with IANA.  Perhaps
we want to steal some of the above text for this document.

---

12.  Protocol Syntax

Move opt-text up as it is used by comment-command first (before
temp-response).

The response-info ABNF is incorrect.  The parens are not balanced.

---

Spelling fixes:

@@ -197 +197 @@
-parseable, case-insensitive response information giving more data about
+parsable, case-insensitive response information giving more data about
@@ -249 +249 @@
-Which option is picked is an adminstrative decision and is not further
+Which option is picked is an administrative decision and is not further
@@ -667 +667 @@
-     System port number XXXX - TBA by IANA
+     System port number XXXX - TBD by IANA
@@ -693 +693 @@
-begin with "vnd."  MUST be registered with IANA on a Firt Come First
+begin with "vnd."  MUST be registered with IANA on a First Come First
@@ -721 +721 @@
-     Both the STMP client and server must check the result of the TLS
+     Both the SMTP client and server must check the result of the TLS
@@ -725 +725 @@
-was achieved is made locally, is implementation-dependant, and is beyond
+was achieved is made locally, is implementation-dependent, and is beyond
@@ -825 +825 @@
-13.  Acknowledgements
+13.  Acknowledgments
@@ -925 +925 @@
-assist in its implmentation may be prepared, copied, published and dis-
+assist in its implementation may be prepared, copied, published and dis-
@@ -930 +930 @@
-references to the Internet Society or other Internet organisations,
+references to the Internet Society or other Internet organizations,