AD review of msgtrk documents

Overall these look good. Almost all of the changes are purely editorial in
nature.

smtpext-03:

This document doesn't have the required RFC 2026 copyright boilerplate.

Section 3, item (3) talks about parameters and then switches to options. I
suggest changing this to read "Future documents may extend this
specification by specifying parameters to this keyword value."

Section 3, item (4). I'm a bit concerned that this calls for piecemeal
support of the DSN extension. I guess the intent here is not to require
support for the notification aspescts of DSN. However, I think it needs to
be clearly stated that all of the semantics associated with ENVID and
ORCPT given in 1891 have to be supported as part of this extension.

Section 4.3, second paragraph. Probably should note that the MTRK=
parameter is modified to the extent that the timeout is decremented.

Section 5 title. Stupid as it sounds, this section needs to be called
"Security Considerations". I know we'll get pushback if it isn't.

This document needs an IANA considerations section. All it needs to say
is that IANA is to register the SMTP extension defined in section 3.

The RFC editor now has a policy that references need to be separated
into normative and informative groups. This document needs to follow
that convention.

trkstat-03

This document doesn't have the required RFC 2026 copyright boilerplate.

The title of this document seems off. "The Message/Tracking-Status MIME
Extension" implies that this document extends MIME. In fact it does
nothing of the sort; this document defines a format for a specific
sort of message using MIME constructs. Since it closely resembles
RFC 1894, how about "An Extensible Message Format for Message Tracking
Responses"?

Section 4 title. Same stupid thing; needs to be called "Security
considerations".

There needs to be an IANA considerations section that says the
message/tracking-status media type defined in section 3.1 is to
be registered.

References need to be split into normative and informative.

mqtp-08

The copyright date is 1999. This seems wrong...

Section 2.4. Should say something about client timeouts and how
long it is appropriate to wait for a server.

Section 4. It seems appropriate to have two qualified error
responses to TRACK: (1) An indication that TLS must be
negotiated before this message can be tracked and (2) An indication
that the search succeeded but found no result. 

The URL registration in section 9 doesn't seem to meet the
requirements set forth in RFC 2717. In particular, the
URL registration template needs to be included.

Section 10. The IANA considerations should mention that this
document registers the MQTP URL scheme.

References need to be split into normative and informative.

model-06

Another 1999 copyright.

Document needs a security considerations section. It should
summarize the security considerations raised in the protocol
documents.

That's it!

				Ned