John C Klensin wrote:
From my point of view, the IETF made its decision around ten
years ago and it is questionable whether the decision then
could sensibly have departed significantly from the definition
is RFC 822. While I didn't like the decision then and don't
like it now (perhaps the comments below will explain that), I
think it would be a serious mistake to open the question up
again.
Sorry, I don't understand this statement. If something's
wrong it has to be fixed, no matter how long it has been wrong.
From my POV it's obvious that standards based on 4234 or its
predecessor avoiding LWSP like 2822 are good examples, while
something like 2616 or 2831 not using ABNF but the #-construct
with its implicit LWSP are an interoperability nightmare.
The 2616 example is horrible. The brave folks trying to write
a 2616bis will be forced to reconstruct a syntax from scratch,
using a proper notation like 4234.
I prefer grammars that can be written as a data stream without
depending on line-ending (and indented continuation) as
important indicators.
You're free to use something like XML if you prefer that. It's
not the fault of ABNF that there's a line length limit of about
69 characters in RFCs, and it offers the usual workaround of
"folded" lines line-oriented constructs like mail headers, or
(no surprise) ABNF.
BTW, please stay away from those pseudo-IRIs in XML 1.0 3rd ed.
or worse, I'm not going to implement this anytime soon. What
I mean is "other grammars => other warts", not only LWSP can
have subtle and ugly side-effects.
It is worth noting that ABNF's line-oriented structure makes
ABNF much harder to construct in xml2rfc than is really
reasonable.
IMO that's not the case, using something like...
</t><figure><artwork type="abnf">
your-text = "here"
group-char = ALPHA / DIGIT / "-" / "+" / "_" / "."
</artwork></figure><t>
...is a no-brainer. After you found that xml2rfc forces you
to start the closing </artwork> in column one to get it right.
Otherwise simply omit the 'type="abnf"' blurb and use Bill's
validator instead of the built-in validator for 'type="abnf"'.
I'm more comfortable with either informal descriptions that
use formal grammars for clarification or explanation for
with fully-formal grammatical descriptions (including
semantics) than I am with the in-between points.
Matter of taste, I look at the syntax, if that's not clear I
look at examples, and if it's still unclear I'd never bother
to read the prose. Especially prose using MUSTard in almost
all statements is a royal pain: Try to derive a conformance
test suite or an implementation and interoperability report,
what you end up with could be writing a "requirements" memo.
This is definitely a personal idiosyncrasy: YMMD and
probably does.
Yes, If you'd prefer to write 2821bis in SDL let's try it,
nobody said that ABNF is a holy grail or the only game in
town. It's merely better than no syntax at all.
I'd encourage taking a look at ISO/IEC ISO/IEC 14977:1996
"Information technology -- Syntactic metalanguage --
Extended BNF".
Why is it that I fear that there's no URL for a plain text
or simple HTML version of this text ? If that's the EBNF
used by the W3C then it's not really "better" than ABNF, it
is only slightly different. Isn't EBNF also line-oriented ?
At the end of the day you'd want to put it into an US ASCII
Internet-Draft, and discuss your syntax on a mailing list.
this one is actually freely available, see the link from
http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/ITTF.htm
I get some frames with my browser, and none of these frames
mentions EBNF or 14977. OTOH if I type "rfc 4234" anywhere
on a command line I get what want. I can also list short
URLs for 4234, resulting in no nonsense documents with links
to the plain text RFC, errata, obsoleted RFCs, etc.:
http://purl.net/net/rfc/4234
http://tools.ietf.org/html/rfc4234
the specification itself is only ten pages long (although
one needs to adjust for smaller type and more page layout),
including examples, and defines the metalanguage three
different ways.
If you strip boilerplates, page headers, and runs of empty
lines from 4234 you'd end up with (guessing) 600 lines.
It's a short and sweet spec. ignoring the LWSP issue.
Frank
P:S.: What was the outcome of the "cosmogol" BOF ?
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf