IETF Logo Mail Archive

Re: [rfc-i] [xml2rfc] use of sourcecode type

Carsten Bormann <cabo@tzi.org> Mon, 27 July 2020 15:43 UTC

Return-Path: <rfc-interest-bounces@rfc-editor.org>
X-Original-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Delivered-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC113A192F; Mon, 27 Jul 2020 08:43:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level:
X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C97PiIniyAPn; Mon, 27 Jul 2020 08:43:44 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B913A18AA; Mon, 27 Jul 2020 08:43:44 -0700 (PDT)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id 5D675F4071D; Mon, 27 Jul 2020 08:43:20 -0700 (PDT)
X-Original-To: rfc-interest@rfc-editor.org
Delivered-To: rfc-interest@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id CDF02F4071D for <rfc-interest@rfc-editor.org>; Mon, 27 Jul 2020 08:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GSr096SfaQW for <rfc-interest@rfc-editor.org>; Mon, 27 Jul 2020 08:43:17 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) by rfc-editor.org (Postfix) with ESMTPS id 5C95FF406D6 for <rfc-interest@rfc-editor.org>; Mon, 27 Jul 2020 08:43:16 -0700 (PDT)
Received: from [192.168.2.104] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BFkc84lXtzyYQ; Mon, 27 Jul 2020 17:43:36 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <ee45b592-7e86-799d-387e-c66609632f74@alum.mit.edu>
Date: Mon, 27 Jul 2020 17:43:36 +0200
X-Mao-Original-Outgoing-Id: 617557415.898972-efe8b1f5cd37eb1936c3f45c6afc4936
Message-Id: <080FE9EB-7622-4783-BEB4-8315805257BD@tzi.org>
References: <e13ad2a9-e460-58cb-3ffe-88acec803a8a@alum.mit.edu> <748F0BE8-5DDA-4CC1-9306-0C67F906C955@tzi.org> <1be09378-acbc-eef9-b4fd-f9b10b35988d@gmx.de> <ee45b592-7e86-799d-387e-c66609632f74@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Subject: Re: [rfc-i] [xml2rfc] use of sourcecode type
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
Cc: rfc-interest@rfc-editor.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: rfc-interest <rfc-interest-bounces@rfc-editor.org>

> […] I have never seen abnf in an ietf document that was complete on its own. Every one references rules defined somewhere else - usually in some other ietf document. These references all all informal, either stated in text before or after the abnf, or within the abnf as a comment or as a prose-val (e.g., <foo defined in RFC666>).

Well, I have started to recommend doing complete ABNF instead of ill-defined references.  E.g., see it in draft-ietf-core-dev-urn-07.txt:

   The above Augmented Backus-Naur Form (ABNF) copies the DIGIT and
   ALPHA rules originally defined in [RFC5234], exactly as defined
   there.

The general problem of composing a grammar out of parts coming from different places is now being discussed in CBOR (for CDDL), and I would expect the results copy over to ABNF as CDDL is so similar to ABNF.

> But I think *that* is a problem that we shouldn't attempt to solve here. IMO an abnf file that is intended to be syntactically correct and complete other than references to external rules should probably be tagged with type "abnf".
> 
> ABNF is particularly forgiving regarding statement ordering. So it may take further study to decide if/when marking abnf as a fragment makes sense.

If you aren’t supposed to use it on its own.
As with “bad” ABNF (CDDL, …); I would suggest a “;bad” qualifier for these.

Grüße, Carsten

_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

v2.23.0 | Report a Bug | By Email