Last Call Review of draft-duerst-mailto-bis-
|Requested revision||No specific revision (document currently at 10)|
|Type||Last Call Review|
|Team||Security Area Directorate (secdir)|
|Authors||Jamie Zawinski , Larry M Masinter , Martin J. Dürst|
|I-D last updated||2009-12-09|
Secdir Last Call review of -??
by Dan Harkins
Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors should treat these comments just like any other last call comments. This document adds support for internationalization (and internation- alized resource identifiers) to the previously defined syntax of a "mailto" URI. It will obsolete RFC 2368. This document does not introduce any new security issues. The Security Considerations describe some of the dangers inherent to using a "mailto" URI and recommend some guidelines in their use. They are illustrative and seem fine. There is some requirements language that I think could be cleaned up a little. For instance, in section 4 it says: "The user agent interpreting a 'mailto' URI SHOULD choose not to create a message if any of the header fields are considered dangerous; it may also choose to create a message with only a subset of the header fields given in the URI. "SHOULD choose not to" made me stop and read that a couple times to try to understand what behavior is being specified. I eventually decided that "SHOULD NOT" is equivalent. Is that correct? If so I suggest changing it. And should that "may also choose" become a "MAY also choose"? Section 7 has a couple of cases of "SHOULD never", such as: "A mail client SHOULD never send anything without complete disclosure to the user...." Never is pretty absolute. But then it's qualified with SHOULD. Should it be "SHOULD NOT"? I like the example in section 6 that illustrates how to provide a link in a browsable archive that will do a reply and preserve threading information. Very cool! regards, Dan.