Re: AD review of msgtrk documents

[ned.freed@xxxxxxxxxxx]

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

> 	Tony

> ned.freed@xxxxxxxxxxx wrote:
> > Overall these look good. Almost all of the changes are purely editorial in
> > nature.
> > ...
> >
> > mqtp-08
> >
> > The copyright date is 1999. This seems wrong...

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




> > Section 2.4. Should say something about client timeouts and how
> > 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.

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

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

Sounds fine.

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

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

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?

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

> I'll review this.



> > Section 10. The IANA considerations should mention that 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"

Sounds right to me.


> > model-06
> >
> > Another 1999 copyright.

> oops


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

> will do.



> > That's it!

> Excellent!