[rfc-i] v3imp #8 Fragment tagging on sourcecode

[dev+ietf at seantek.com (Sean Leonard)]

On 1/28/2015 9:32 AM, Nico Williams wrote:
> On Tue, Jan 27, 2015 at 09:16:37PM -0800, Sean Leonard wrote:
>> Overall I still stand by my proposition that the RFC is the module
>> for ABNF purposes. Honestly it just makes things a lot simpler. To
>> the extent that you need to split things inside the RFC, you can
>> refer to specific sections. Specific comments below.
> Well, draft-ietf-json-text-sequence-13 will break this proposition.

Hello--I took a look at draft-ietf-json-text-sequence-13.

There are two typos:
Abstract:

    ASCII Record Separator (0x1E), and each ending with an ASCII Line
    Feed character (0x1A).
                   ^^^^^^

should be 0x0A.

Section 2.2

    Note that on some systems it's possible to input RS by typing
    'ctrl-^'; on some system or applications the correct sequence may be
    'ctrl-v crtl-^'.  This is helpful when constructing a sequence
            ^^^^^^

should be ctrl-^.



An editorial point: why define LF in this I-D when it's already defined 
in RFC 5234 Appendix B? Just sayin'.

> It's on the RFC-Editor queue.  We could "fix" the "problem" in AUTH48,
> but I've no intention to.

Well you might want to look at the problems above...

> I doubt it's the first RFC that will break your assumption.
It's not an RFC yet. :-)

First of all, I don't see a "problem" because there are no "modules" in 
draft-ietf-json-text-sequence, or any other Internet-Draft. It's all a 
bunch of plain text. I am not trying to be flippant; it's simply the way 
it is. I-Ds are just large reams of plain text punctuated with FF codes. 
That is why extracting data out of RFCs is convoluted and fraught with 
error.

I am not stating an assumption so much as I am stating a workable 
proposition that makes sense for authoring future RFCs in a structured 
format, i.e., a format where ABNF is clearly distinguished from 
specification text or other things.

I too dealt with this exact problem in draft-josefsson-pkix-textual-10 
(also in the RFC-Editor queue, btw). In that soon-to-be-RFC, I renamed 
the rules to:
textualmsg              ; what most extant parsers and generators will 
work with
stricttextualmsg     ; what compliant generators SHOULD emit
laxtextualmsg         ; the most relaxed input that parsers MAY accept


Thus, consider renaming the rules to distinguish between inputs and 
outputs, such as {JSON-sequence-in} and {JSON-sequence-out}. It is 
clearer and more accurate. I note that the "meat" parts are named 
differently: {possible-JSON} vs. {JSON-text}, presumably to indicate the 
difference in strictness between generators and parsers.


As a broader useful point (not directed specifically to 
draft-ietf-json-text-sequence-13), I think it would be nice if future 
RFC ABNF can assume that the symbols in RFC 20 for %x00-20 / %x7F are 
rules that can be used as-is. Hence NUL = %x00, SUB = %x1A, DEL = %x7F, etc.


> Not that it matters.  Suppose all RFCs with ABNF only had a *single*
> ABNF module, so that each module could be said to be named rfc1234.abnf.
> Now what?  You'd still be missing the machine-readable imports.

Uh I already laid this out...I no longer ascribe to the premise of "ABNF 
modules". It's just a bunch of ABNF text.

You know, other symbolic systems such as ASN.1 have modules...and ASN.1 
is seen as way too complicated. I doubt that anyone is going to 
"compile" the ABNF in draft-ietf-json-text-sequence-13 anyway--they are 
just going to hunt for RS bytes, which is the whole point.

> We could say that every module exports every rule by default, so we
> could get away with not having exports.  But imports are absolutely
> necessary in order to validate ABNF modules that import rules from
> others.

Unless you don't have ABNF modules...

> We already have a mess on our hands.  ABNF needs a module system.  An
> ad-hoc module system won't do.

No modules = no messes. I would say that all the crazy importing and 
exporting in ASN.1 modules (an in particular, the fact that the 
definitions have changed over time, witness PKCS #7 1.0 -> PKCS #7 1.5 
-> CMS '99 -> CMS '02 -> CMS '04 -> CMS '09) is much messier. 
Significant tool support is required, which is one significant reason 
why people hate on ASN.1 and are trying to do things with JSON instead.

Sean