Subject: [abnf-discuss] New Version Notification for draft-seantek-abnf-more-core-rules-02.txt

From: Sean Leonard <[email-masked]>
Date: Thu, 8 Oct 2015 15:29:13 -0700

Hello:
rev 02 is posted. Made some ASCII terminology-related changes, and 
cleaned up the ABNF just a bit (cosmetic only). Please discuss.

Sean

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-seantek-abnf-more-core-rules-02.txt
Date: 	Thu, 08 Oct 2015 01:36:49 -0700
From: 	[email-masked]
To: 	Sean Leonard <[email-masked]>, Sean Leonard 
<[email-masked]>

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

Name:		draft-seantek-abnf-more-core-rules
Revision:	02
Title:		Comprehensive Core Rules for ABNF
Document date:	2015-10-08
Group:		Individual Submission
Pages:		5
URL:            https://www.ietf.org/internet-drafts/draft-seantek-abnf-more-core-rules-02.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-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-seantek-abnf-more-core-rules-02

Abstract:
    This document extends the base definition of ABNF (Augmented Backus-
    Naur Form) to include comprehensive support for certain symbols,
    namely the C0 control characters in ASCII.

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 9 Oct 2015 11:03:11 -0400

> cleaned up the ABNF just a bit (cosmetic only). Please discuss.

The changes are innocuous. I forget where things stand regarding the 
overall proposal.

I have mixed feelings about it. On one hand I think having standard 
names for these things, used across various drafts that want to refer to 
them, would be a good thing.

On the other hand, if these started being defined in the namespace of 
every use of ANBF then there could be backward compatibility problems. 
And in some contexts where ascii controls aren't meaningful some of 
these names might also have other natural meanings and encodings.

AFAIK it has never been clear whether the existing core rules are 
intended to be predefined whenever compiling ABNF, or if they are merely 
suggestions for users of ABNF to follow.

I think it would be good if ABNF allowed rule definitions to be defined 
in multiple namespaces, with the ability to reference a rule in a 
different namespace. E.g., core.CR.

And/or it would be good to have an explicit mechanism to import a 
selected set of rules.

	Thanks,
	Paul

> URL:
> https://www.ietf.org/internet-drafts/draft-seantek-abnf-more-core-rules-02.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-02
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-seantek-abnf-more-core-rules-02
>
> Abstract:
> _______________________________________________
> abnf-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abnf-discuss
>

---

From: Sean Leonard <[email-masked]>
Date: Fri, 9 Oct 2015 15:10:45 -0700

On Oct 9, 2015, at 8:03 AM, Paul Kyzivat <[email-masked]> wrote:

> The changes are innocuous. I forget where things stand regarding the overall proposal.
> 
> I have mixed feelings about it. On one hand I think having standard names for these things, used across various drafts that want to refer to them, would be a good thing.
> 
> On the other hand, if these started being defined in the namespace of every use of ANBF then there could be backward compatibility problems. And in some contexts where ascii controls aren't meaningful some of these names might also have other natural meanings and encodings.
> 
> AFAIK it has never been clear whether the existing core rules are intended to be predefined whenever compiling ABNF, or if they are merely suggestions for users of ABNF to follow.
> 
> I think it would be good if ABNF allowed rule definitions to be defined in multiple namespaces, with the ability to reference a rule in a different namespace. E.g., core.CR.
> 
> And/or it would be good to have an explicit mechanism to import a selected set of rules.

Thank you Paul for the feedback.

Between this and some off-list comments, I think I have a plan for the next revision. Basically it sounds like this (this = more core rules) is worth pursuing, but users who rely on RFC 5234 should not be forced to use them. We do however need to have some time where additional rules are established, and people use them, so that a track record of usage can be demonstrated.

At the same time, we have an importing issue. So, I guess look for the next draft maybe in a week or so...

Sean

---

From: Riccardo Bernardini <[email-masked]>
Date: Sat, 10 Oct 2015 07:28:19 +0200

> And/or it would be good to have an explicit mechanism to import a selected
I remember that some time ago there was a discussion about a possible
mechanism to import rules.  I am sure since I joined the discussion at the
time...  I'll try to dig it out...

Riccardo