Subject: AD review of msgtrk documents

From: [email-masked]
Date: Wed, 21 Aug 2002 02:07:52 -0700 (PDT)

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

---

From: Tony Hansen <[email-masked]>
Date: Wed, 21 Aug 2002 16:33:57 -0400

Thank you Ned. I have a few comments below, plus some questions for the 
group.

	Tony

[email-masked] wrote:
> ...

Obviously the documents have been in the hopper for too long. :-)

> long it is appropriate to wait for a server.

I'd like to propose the following additions:

* In section 2.5 "Firewall Considerations", where it talks about the 
server doing chaining operations, add the following:

	If a server chooses to perform a chaining operation itself, it MUST 
provide a response within 2 minutes, and SHOULD return a "no further 
information is available" response if it cannot provide an answer at the 
  end of that time limit.

* In section 2.4 Optional Timers, add:

	An MTQP client MAY have an inactivity autologout timer while waiting for 
a response from the server. Since an MTQP server may be a firewall, and 
may be chaining information from other servers, such a timer MUST be at 
least 2 minutes in duration.

* I arbitrarily chose 2 minutes. If there's a better time limit, feel 
free to suggest one.

* I also plan on swapping sections 2.4 and 2.5, since Optional Timers 
now refers to firewall support.

> that the search succeeded but found no result. 

I'd like to propose the following additions to section 4:

	A negative response to the TRACK command may include these reason codes:

	"/" "tls-required"
	"/" "admin"
	"/" "unavailable"

	The reason code "/tls-required" SHOULD be used when the server has 
decided to require TLS. The reason code "/admin" SHOULD be used when the 
server has become unavailable, due to administrative reasons, since the 
connection was initialized. The reason code "/unavailable" SHOULD be 
used when the server has become unavailable, for other reasons, since 
the connection was initialized.

> URL registration template needs to be included.

I'll review this.

> document registers the MQTP URL scheme.

yup

> References need to be split into normative and informative.

I moved these to informative and left the rest in normative:

[RFC-SHA1] RFC 3184, "US Secure Hash Standard 1 (SHA1)"
[RFC-KEYWORDS] RFC 2119, "Key words for use in RFCs to Indicate 
Requirement Levels"
[RFC-SMTP-TLS] RFC2487, "SMTP Service Extension for Secure SMTP over TLS"

> Another 1999 copyright.

oops

> summarize the security considerations raised in the protocol

will do.

> That's it!

Excellent!

---

From: [email-masked]
Date: Wed, 21 Aug 2002 13:47:56 -0700 (PDT)

> information is available" response if it cannot provide an answer at the

That may be tough to guarantee, but I'm willing to give it a try.

> now refers to firewall support.

Sounds fine.

> the connection was initialized.

OK as far as it goes, but what happens when no information about the message is
found? Does this come back as an empty reponse or does it get a negative
response?

> [RFC-SMTP-TLS] RFC2487, "SMTP Service Extension for Secure SMTP over TLS"

Sounds right to me.