Last Call Review of draft-duerst-mailto-bis-
review-duerst-mailto-bis-secdir-lc-harkins-2009-12-09-00

  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.