Re: AD review of msgtrk documents

[Tony Hansen <tony@xxxxxxx>]

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.

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




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



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



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