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

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E1153A635F for <secdir@core3.amsl.com>; Mon, 8 Mar 2010 00:39:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.21
X-Spam-Level:
X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBEfpklIMTTe for <secdir@core3.amsl.com>; Mon, 8 Mar 2010 00:39:57 -0800 (PST)
Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id 96BF93A67A3 for <secdir@ietf.org>; Mon, 8 Mar 2010 00:39:56 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp (scmse02.scbb.aoyama.ac.jp [133.2.253.159]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id o288dxfZ029161 for <secdir@ietf.org>; Mon, 8 Mar 2010 17:39:59 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 7807_0878_2e1fcaa8_2a8e_11df_bbe3_001d096c5782; Mon, 08 Mar 2010 17:39:59 +0900
Received: from [IPv6:::1] ([133.2.210.1]:60432) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S1329EFE> for <secdir@ietf.org> from <duerst@it.aoyama.ac.jp>; Mon, 8 Mar 2010 17:39:57 +0900
Message-ID: <4B94B7CB.3050303@it.aoyama.ac.jp>
Date: Mon, 08 Mar 2010 17:39:39 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <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
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Mar 2010 08:39:59 -0000

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