Subject: Re: [secdir] review of draft-duerst-mailto-bis-07

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 08 Mar 2010 17:39:39 +0900

Hello Dan,

Many thanks for your comments. Sorry to be late with my reply.

On 2009/12/09 3:02, Dan Harkins wrote:
>
>    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.

Done, in response to somebody else who also pointed this out.

> And should that "may also choose" become a "MAY also choose"?

Done.

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

Done.

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

That's actually in use in the W3C mailing list archives. See e.g. the 
Respond link at the top of 
http://lists.w3.org/Archives/Public/public-iri/2010Mar/0000.html. Maybe 
you can suggest implementing something similar to the IETF mailing list 
archives?

Regards,    Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]