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

> 2.  Basic Operation
> ...
> If the host is not found, the MTQP client then does an MX lookup for the
> server host using DNS MX records.

This line needs more explanation.  How are these MX records used?  Based on
preference?  Just the first?  How about when equal preferences?

> 2.1.  Tracking Service DNS Considerations
> ...
> In both cases, note that the tracking service for a given mail
> domain MUST be able to handle the queries for all messages destined for
> that mail domain.

Is sending a referral to another MTQP server sufficient in satisfying this
MUST?

> 2.3.  Responses
> ...
> All response lines are terminated by a CRLF pair and are limited to 998
> characters before the CRLF.

Just a note that this differs from RFC821's 512 character (including CRLF)
limit.  This probably doesn't matter.

> 3.  Initialization and Option Response
> ...
>     "/" "unavailable"
>     "/" "admin"
>     "/" "unknown"
>     "/" "referral" "=" net_loc

These should be defined.  Also net_loc should be defined somewhere.

> [Command sections]

Should we add a "HELP" command?

> 4.  TRACK Command
> ...
> Mtrk-secret is the secret A described in [RFC-TRACK-ESMTP], encoded using
> base64.

Reference RFC2045 for the definition of base64?

> 6.1.  Processing After the STARTTLS Command
> ...
> After the TLS handshake has been completed

What is TLS handshake can't be successfully completed?  RFC 2487BIS says:

   After receiving a 220 response to a STARTTLS command, the client MUST
   start the TLS negotiation before giving any other SMTP commands. If,
   after having issued the STARTTLS command, the client finds out that
   some failure prevents it from actually starting a TLS handshake, then
   it SHOULD abort the connection.

> 6.1.  Processing After the STARTTLS Command
> ...
> If the 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
> from the client (other than a QUIT command) with a negative "-BAD" response
> and a response code of "/insecure".

Should also accept the STARTTLS command to renegotiate, possibly with a
different client certificate to gain an acceptable level of authentication.
I'm not convinced that this is necessarily needed or a good idea, but it
may be worth considering.

> 9.  URL Format
> ...
>      mtqp://<mserver>/track/<envid>/<mtrk-secret>
>      mtqp://<mserver>:<port>/track/<envid>/<mtrk-secret>

In both cases, the mtrk-secret appears to be open for sniffing.  Do we need
an mtqps: to indicate STARTTLS is required?

> 9.1.  MTQP URL Syntax
> ...
>      mtqp-url = "mtqp://" net_loc "/track/" envid ":" mtrk-secret

This differs from the text directly above.  Above, envid and mtrk-secret
are separated by "/", here they are separated by ":".

> 11.  Security Considerations
> ...
> Both the STMP client and server must check the result of the TLS

Replace "STMP" with "MTQP".

> 11.  Security Considerations
> ...
> The SMTP client and server should note carefully the result of the
> TLS negotiation.

Replace "SMTP" with "MTQP".  Alternatively, remove this paragraph as it
pretty much repeats what is said in the previous paragraph.

> 12.  Protocol Syntax
> ...
>      client-command = track-command / starttls-command / quit-command / comment-command
> ...
>      command-response = success-response / temp-response / error-response / bad-response

Maybe wrap these better, e.g.:

      client-command = track-command / starttls-command / quit-command /
                       comment-command

      command-response = success-response / temp-response / error-response
                         bad-response

> 16.  Full Copyright Statement
> ...
>      Copyright (C) The Internet Society (1999).  All Rights Reserved.

This should probably include 2000 and 2001.