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,