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

See comments below.

	Tony

Gregory Neil Shapiro wrote:
> 
> 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.

I don't know how common this usage of MX records is, but it is valid.
I'm okay with this change. Anyone else?

> ---
> 
> 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: .

sure

> ---
> 
> 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.

I meant to say that the vendor name must be registered, as is done with
MIME content types.

Another option is to go the java route and use a reversed domain name:

	vnd.com.example.option1

This avoids the IANA registration issue entirely, under the assumption
that only the owners of a domain would use their domain.

> ---
> 
> 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.

ok

> ---
> 
> 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,

ok