[websec] ABNF references (was RE: AppsDir review of draft-ietf-websec-strict-transport-sec)

"Murray S. Kucherawy" <msk@cloudmark.com> Wed, 02 May 2012 17:48 UTC

Return-Path: <msk@cloudmark.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 659CE21F85CC for <websec@ietfa.amsl.com>; Wed, 2 May 2012 10:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.558
X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NjQGF4hfISpH for <websec@ietfa.amsl.com>; Wed, 2 May 2012 10:48:09 -0700 (PDT)
Received: from mail.cloudmark.com (cmgw1.cloudmark.com []) by ietfa.amsl.com (Postfix) with ESMTP id C32B421F85C0 for <websec@ietf.org>; Wed, 2 May 2012 10:48:09 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com ([]) by mail.cloudmark.com with bizsmtp id 55oU1j0010ZaKgw015oUtM; Wed, 02 May 2012 10:48:34 -0700
X-CMAE-Match: 0
X-CMAE-Score: 0.00
X-CMAE-Analysis: v=2.0 cv=Dv3UCRD+ c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=5SqQFJvkn3sA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=D_u2ATCz6vtTo4ItkiYA:9 a=CjuIK1q_8ugA:10 a=_RhRFcbxBZMA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Wed, 2 May 2012 10:48:02 -0700
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: Julian Reschke <julian.reschke@gmx.de>
Thread-Topic: ABNF references (was RE: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec)
Thread-Index: AQHNKIu4kW6hhbexxk28TNX+IGDrBA==
Date: Wed, 02 May 2012 17:48:02 +0000
Message-ID: <9452079D1A51524AA5749AD23E00392810A6F1@exch-mbx901.corp.cloudmark.com>
References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de> <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> <4F9F9A8D.8080004@gmx.de> <9452079D1A51524AA5749AD23E003928107DBB@exch-mbx901.corp.cloudmark.com> <4FA03F4D.3050606@gmx.de>
In-Reply-To: <4FA03F4D.3050606@gmx.de>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335980914; bh=+P8QEJ1gvwck6EoJ+KqN2sNulfQamdFCBgaNCljwKRg=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Hof1xSL4lyfcNW3o3FWgXWj20QUA7/JLvqVDzIgGjUkZP5CAmbS6yzwzAGqUtITX1 a5kD3gXTQYC5YQrDQD5rDaDqY602Fn45I2D9RT0M+vNnDCUhYW0ffkQMS8sk6bK5y4 KpnoXwJEBhaIAjoPPhn4duCJ2Yhyex/YD0nlNpHc=
Cc: "draft-ietf-websec-strict-transport-sec@tools.ietf.org" <draft-ietf-websec-strict-transport-sec@tools.ietf.org>, "websec@ietf.org" <websec@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: [websec] ABNF references (was RE: AppsDir review of draft-ietf-websec-strict-transport-sec)
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 May 2012 17:48:10 -0000

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Tuesday, May 01, 2012 12:54 PM
> To: Murray S. Kucherawy
> Cc: apps-discuss@ietf.org; websec@ietf.org; draft-ietf-websec-strict-transport-sec@tools.ietf.org
> Subject: Re: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec
> Technically it *does* point to the authoritative definition.

The real issue here is that we don't have a (ahem) standard way to import ABNF definitions from other documents.  The specific problem in this case to me is twofold:

1) Section 4 of RFC5234 specifies that the prose-val construction is a mechanism of "last resort", which I take to mean one uses it only when the thing you need to describe is sufficiently complicated that it's easier to describe in English than in ABNF.  I don't think "1*DIGIT" qualifies, nor does an import from another document because we do it all the time with a non-ABNF sentence.  (Now, if that admonition in RFC5234 needs clarification, then let's do that.)

2) There's a common axiom that says it's safer to refer to a definition rather than to copy it.  I understand that we're up against reader convenience here, which can suffer when a copy isn't used, especially when the definitions being recycled are scattered throughout many documents.  Although I'm infinitely confident the string "1*DIGIT" was copied correctly from RFC2616 to this draft, I'm concerned that approval of this use will eventually lead to a case where some author uses prose-val to copy something more complex in the name of reader convenience, and get it wrong, and now we have two documents that don't agree on the definition of something.  That may or may not have serious side effects.

What I would prefer in this case is to say one of these:

	"delta-seconds" in defined in Section 3.3.2 of RFC2616.

	delta-seconds = <defined in Section 3.3.2 of RFC2616>

I strongly prefer the former.  I still think the latter is an improper use of prose-val, but at least the ABNF itself isn't copied there.

To address the larger question, we definitely have to have some conversation about the right way to do this in general.  Perhaps another draft that updates RFC5234 which presents a consensus view of the right, safe, convenient way to do so would be useful.  Perhaps further we just say that what you're doing here is the new official way to do so, where the ABNF inside the prose-val is a convenience copy with the understanding that the referenced definition is authoritative if somehow they diverged.
For example, we could standardize on a prose-val whose contents are of the form:

	name = < [ABNF] "from " [ "Section " 1*DIGIT *( "." 1*DIGIT) " of " ] "RFC" 1*DIGIT >

This would be interpreted as: "name" is defined in the specified RFC, possibly down to the specified Section.  If ABNF is there, it is a convenience copy; the referenced document contains the official definition of "name".  And people would just discourage the convenience copy in cases where it's non-trivial.  (We'd have to bang on this a bit to allow importing from documents that aren't RFCs, but you get the idea.)

I'd be happy to write that up as something that updates 5234 if people think that's a good idea.