| Newsgroups |
gmane.ietf.rfc822 |
| Message-ID |
<[email protected]> |
> On Wed May 11 2005 12:24, [email protected] wrote:
> > and you had a concern about being able
> > to determine from the grammar what rule a comment is attached to, which I find
> > uninteresting since I reject the notion that comment binding needs to be
> > determinable from the grammar.
> 1) that depends on the specific application. For example, topologically
> sorting rules in a ruleset -- keeping comments with the correct rules --
> requires being able to determine which rule (if any) a particular
> comment belongs to
> 2) in principle, the ABNF grammar shouldn't have such gross ambiguities
> 3) it's difficult to definitively state whether or not a particular
> implementation of ABNF parsing is fully "interoperable" (a requirement
> for Draft status) if one implementation does "comment binding"
> differently from another. Granted, the Internet won't collapse, but
> there is a principle involved, and if we're going to ignore it for this
> specification, then we ought to be even-handed and ignore it for all
> specifications.
I find none of these at all persuasive.
> > Oh, and then there was the business about line terminators used in stored
> > copies of specifications. This I also find to be of no relevance. It is well
> > understood that local storage conventions vary but CRLF is our chosen canonical
> > form for line terminators. Hopefully we can avoid another round of interminable
> > discussion of this, repeating what happened with the MIME specification over 10
> > years ago.
> The difference is that Internet Messages and MIME have a canonical form,
> whereas Internet-Drafts and RFCs are not required to use CR characters
> (and in fact do not in the IETF/RFC Editor archives). There are a
> number of ways to handle this; I've suggested one. It's just plain
> silly to require CRLF line endings on ABNF lines in an I-D or RFC whose
> other lines use only a newline.
And on the system I use lines are stored as counted strings, padded to an even
byte. The count can be either big or little endian. Care to support that as
well? Where does it end?
This is simply silly.
Ned