Subject: [abnf-discuss] Core Rules and References for ABNF: draft-seantek-abnf-more-core-rules-07.txt

From: Sean Leonard <[email-masked]>
Date: Wed, 28 Sep 2016 15:20:49 -0700

Hello ABNF-discuss:

A new draft of Comprehensive Core Rules and References for ABNF has been 
posted. Thanks in advance to all those who have provided feedback thus far.

In this draft-07 (and draft-06, which had some typos and unclear parts 
that have since been addressed), the syntax for a "referenced rule" is 
rulename@RULEREF, where RULEREF can be a document such as

   URI@[RFC3986]

or a path such as

name-part@<https://raw.githubusercontent.com/antlr/grammars-v4/master/abnf/examples/postal.abnf>

. The syntax has evolved a similar way to how e-mail addresses have 
evolved (e.g., from RFC 733).

There was material about doing Unicode in ABNF in draft-05 (Appendix B); 
that material has been forked to a different draft (under development).

Comments and feedback are welcome.

Best regards,

Sean

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-seantek-abnf-more-core-rules-07.txt
Date: 	Wed, 28 Sep 2016 00:50:03 -0700
From: 	[email-masked]

A new version of I-D, draft-seantek-abnf-more-core-rules-07.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-abnf-more-core-rules
Revision:	07
Title:		Comprehensive Core Rules and References for ABNF
Document date:	2016-09-28
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-seantek-abnf-more-core-rules-07.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-abnf-more-core-rules/
Htmlized:       https://tools.ietf.org/html/draft-seantek-abnf-more-core-rules-07
Diff:           https://www.ietf.org/rfcdiff?url2=draft-seantek-abnf-more-core-rules-07

Abstract:
    This document extends the base definition of ABNF (Augmented Backus-
    Naur Form) to include a reference syntax, along with core rules that
    provide comprehensive support for certain symbols related to ASCII.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Sep 2016 09:59:04 -0400

I'd like to comment on why I think this is important:

Most of the drafts I have been interested in over the years contain 
ABNF, and most of the time that ABNF is dependent on other ABNF rules 
that reside in another draft or RFC. Such cross references are indicated 
in ad-hoc fashion. When authoring or reviewing such a document, one 
would like to be able to verify that the new ABNF is correct. At the 
least this ought to be done at the time of WGLC and LC. But actually 
doing that verification is a pain. To be sure of it, one needs to 
extract the ABNF from the document in question *and* from the documents 
that contain referenced ABNF rules. This is tedious work, and in my 
experience it most often is not done.

Furthermore, when ABNF rules in other drafts are referenced informally 
this way the semantics of doing so aren't especially clear. Is it 
assumed that complete ABNF containing the referenced rule is included? 
Or should only the definition of the referenced rulename and the 
definitions of any rules thus referenced be included? Or should a 
functional definition of the referenced rule be used that doesn't drag 
along any other rules used in that definition. These distinctions are 
important because they determine what happens if the new ABNF defines 
rules with the same names as rules defined in the referenced ABNF.

Formalizing a cross-reference syntax and semantics resolves these 
issues. The semantics can be nailed down, and tools can be built to 
automatically to the extractions. This will make it feasible to automate 
ABNF syntax verification, for instance as part of IdNits.

	Thanks,
	Paul

On 9/28/16 6:20 PM, Sean Leonard wrote:
> URL:
> https://www.ietf.org/internet-drafts/draft-seantek-abnf-more-core-rules-07.txt
>
> Status:
> https://datatracker.ietf.org/doc/draft-seantek-abnf-more-core-rules/
> Htmlized:
> https://tools.ietf.org/html/draft-seantek-abnf-more-core-rules-07
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-seantek-abnf-more-core-rules-07
>
> Abstract:
> _______________________________________________
> abnf-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abnf-discuss
>

---

From: "John Levine" <[email-masked]>
Date: 29 Sep 2016 18:49:42 -0000

>name-part@<https://raw.githubusercontent.com/antlr/grammars-v4/master/abnf/examples/postal.abnf>

Yuck.  I agree it would be nice to make it easier to automatically collect, syntax check,
and use ABNF, but please don't glop up the text with it.

The IETF has already decided that the RFC format is going to be XML, so put the cross
references in the XML where parsing is trivial (given that it's already parsing the
rest of the XML) and you don't need to invent squidgy text kludges to identify
the various things you want to include.

R's,
John

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Sep 2016 17:08:37 -0400

John,

> and use ABNF, but please don't glop up the text with it.

How is:

	URI = URI@[RFC3986]

more "glopped up" than:

	URI = <URI defined in RFC3986>

(The current most concise, but semantically undefined, way to informally 
say the same thing.)

> the various things you want to include.

If you want to literally include the external ABNF, and have it 
displayed in the document, then you can use an xml include.

But the semantics we are going for here are not that. It is important 
for the *reader* to understand what is being imported, and from where. 
If you stick it in the XML then it isn't visible to the reader.

	Thanks,
	Paul

---

From: "John Levine" <[email-masked]>
Date: 29 Sep 2016 22:09:13 -0000

>	URI = <URI defined in RFC3986>

It's not.  I want the XML to say something like this:

<abnf name="URI" source="RFC3986" />

and the way it's displayed depends on the output medium.

>displayed in the document, then you can use an xml include.

I suppose so, but that's not what I was trying to say.

>If you stick it in the XML then it isn't visible to the reader.

You're making some unwarranted assumptions about the way the XML is
processed.  Most of what's in the XML is visible to the reader.

R's,
John

---

From: Julian Reschke <[email-masked]>
Date: Fri, 30 Sep 2016 07:33:43 +0200

> (The current most concise, but semantically undefined, way to informally

Concise is nice, but precision as well. The main target are people, not 
ANMF checkers, thus I think including the section number is very valuable.

> If you stick it in the XML then it isn't visible to the reader.

Taking advantage of the XML format doesn't necessarily mean that we we 
need to include the referenced ABNF.

Best regards, Julian