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

"Martin J. Dürst" <> Mon, 08 March 2010 08:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E1153A635F for <>; Mon, 8 Mar 2010 00:39:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.21
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CBEfpklIMTTe for <>; Mon, 8 Mar 2010 00:39:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 96BF93A67A3 for <>; Mon, 8 Mar 2010 00:39:56 -0800 (PST)
Received: from ( []) by (secret/secret) with SMTP id o288dxfZ029161 for <>; Mon, 8 Mar 2010 17:39:59 +0900
Received: from (unknown []) by with smtp id 7807_0878_2e1fcaa8_2a8e_11df_bbe3_001d096c5782; Mon, 08 Mar 2010 17:39:59 +0900
Received: from [IPv6:::1] ([]:60432) by with [XMail 1.22 ESMTP Server] id <S1329EFE> for <> from <>; Mon, 8 Mar 2010 17:39:57 +0900
Message-ID: <>
Date: Mon, 08 Mar 2010 17:39:39 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20090902 Eudora/3.0b3
MIME-Version: 1.0
To: Dan Harkins <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [secdir] review of draft-duerst-mailto-bis-07
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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"?


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

That's actually in use in the W3C mailing list archives. See e.g. the 
Respond link at the top of Maybe 
you can suggest implementing something similar to the IETF mailing list 

Regards,    Martin.

#-# Martin J. Dürst, Professor, Aoyama Gakuin University