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

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Mon, 08 March 2010 08:39 UTC

Message-ID: <4B94B7CB.3050303@it.aoyama.ac.jp>
Date: Mon, 08 Mar 2010 17:39:39 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3
MIME-Version: 1.0
To: Dan Harkins <dharkins@lounge.org>
References: <825be751fdcdc5da34213d44f5ef0b67.squirrel@www.trepanning.net>
In-Reply-To: <825be751fdcdc5da34213d44f5ef0b67.squirrel@www.trepanning.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: jwz@jwz.org, LMM@acm.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] review of draft-duerst-mailto-bis-07
Precedence: list

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:duerst@it.aoyama.ac.jp

[secdir] review of draft-duerst-mailto-bis-07 Dan Harkins
Re: [secdir] review of draft-duerst-mailto-bis-07 Martin J. Dürst