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

[nico at cryptonector.com (Nico Williams)]

On Wed, Jan 28, 2015 at 02:31:06PM -0800, Sean Leonard wrote:
> 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:

Thanks.  Those have already been noted and will be fixed before
publication.

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

Because RS isn't, and both RS and LF come from STD 80 (RFC 20).

> >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...

Yes, but I'm asking about a more specific problem.

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

But this issue (two ABNF rules with the same name) was raised earlier,
and no one thought it was a problem.  Now there's a question about ABNF
modules: must ABNF-using RFCs have a single ABNF "module" consisting of
all ABNF rules extracted from their figures??

I don't think "yes" is really the right answer, but it would be
convenient if no other RFC deviates from that.

> 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

There are no ABNF modules in *any* RFCs.  Because there are no ABNF
modules at all.

> all a bunch of plain text. I am not trying to be flippant; it's

No, there's figures.

> 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.

This is an I-D on the RFC-Editor queue.  It will soon be an RFC.

> 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

If ABNF has no modules and we don't insist on an 'RFCs contain at most
one ABNF "module"' rule, then I don't need to consider this proposal at
all.

I'd rather we defined ABNF modules.

A rule that RFCs must have at most one ABNF module does not get us past
the need to know what rules get imported from what other modules.  And
it's not elegant.

> 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.

I'm inclined to continue rejecting this proposal.

> 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.

I agree.  These should be added to RFC5234 (i.e., we should publish an
update RFC listing them).

> >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.

But I'd like to have first-class ABNF modules.  "Just a bunch of [ABNF]
text" is not enough: because we can't validate it.

> 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 like to machine-validate ABNF modules.  How should we do this as to
imported rules?

> >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
> [...]

No modules -> No need to rename the conflicting rules in draft-ietf-json-text-sequence.

Thanks,

Nico
--