MIME-Version: 1.0
Sender: barryleiba.mailing.lists@gmail.com
In-Reply-To: <53E43328.7040503@alum.mit.edu>
References: <53E3B22E.5000708@alum.mit.edu>
	<01PB3UKRBQA80000SM@mauve.mrochek.com>
	<53E43328.7040503@alum.mit.edu>
Date: Sun, 10 Aug 2014 17:15:26 -0400
Message-ID: <CAC4RtVApEjG66+xtA+y2i9vVrG0FgJQ2Erw57dkub1BJd3ez_A@mail.gmail.com>
Subject: Re: [abnf-discuss] Case-sensitive string constants in ABNF
From: Barry Leiba <barryleiba@computer.org>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Cc: Ned Freed <ned.freed@mrochek.com>, "abnf-discuss@ietf.org" <abnf-discuss@ietf.org>
Content-Type: text/plain; charset=UTF-8

>> I would suggest writing this as an extension, not a revision.
>
> I'm not opposed to that, in principle. But I am not sure what that would
> look like.
>
> Certainly the syntax changes can be done incrementally using /=.
> The result would be functionally the same, but wouldn't be as readable.
>
> I don't know how I would write the descriptive part as an extension
> document.

I think you already did, in your first message.  It's perfectly
understandable, and serves as a fine update to 5234.

> From a practical perspective, why would an extension be better? Would it be
> any easier to put the extension doc through the process to an RFC? Why?

1. A specific update for a specific purpose has a clearly defined
scope.  Opening the document as a "bis" invites every little tweak
that anyone's thought of recently (or not so recently).  Sometimes
that's good, but often it's not.

2. 5234 is such a basic document for our process, and is so widely
cited, that complete revisions to it that give it a new RFC number are
quite disruptive.  In theory, that's what STD and BCP numbers are for,
but no one references this as "STD 68" (and our citation rules don't
really allow us to).  It would be much better, for a minor extension
such as this, to keep it as RFC 5234.

> After the fact it would certainly be easier for somebody to consult a
> revised document than to consult both the base document and an extension.

For this sort of thing, I don't see that as an issue.  It doesn't
affect any documents that don't use this feature, and anyone reading
ABNF from those only has to look at 5234.  Documents that make use of
this feature would say something like, "The formal language below uses
ABNF [RFC5234] as extended by the case-sensitivity extension
[RFCpqrs]," and would include your RFCpqrs as a normative reference.

At some later point, if it turns out that a great many documents are
using this extension, we could consider a revision of 5234 then.  In
the meantime, RFCpqrs would "update" 5234, and would be added as part
of STD 68.

Seems simple.

Barry