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

"Dan Harkins" <dharkins@lounge.org> Tue, 08 December 2009 18:02 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 65CEF3A68F6; Tue, 8 Dec 2009 10:02:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id gxkh1XantVf6; Tue, 8 Dec 2009 10:02:28 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net []) by core3.amsl.com (Postfix) with ESMTP id AD4263A67A7; Tue, 8 Dec 2009 10:02:27 -0800 (PST)
Received: from www.trepanning.net (localhost []) by colo.trepanning.net (Postfix) with ESMTP id 9EB65102240AE; Tue, 8 Dec 2009 10:02:16 -0800 (PST)
Received: from (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 8 Dec 2009 10:02:16 -0800 (PST)
Message-ID: <825be751fdcdc5da34213d44f5ef0b67.squirrel@www.trepanning.net>
Date: Tue, 8 Dec 2009 10:02:16 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: secdir@ietf.org
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: duerst@it.aoyama.ac.jp, jwz@jwz.org, LMM@acm.org, iesg@ietf.org
Subject: [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: Tue, 08 Dec 2009 18:02:29 -0000


  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

  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!