John C Klensin wrote:
ultimately, ABNF (and most metalanguages like it) cannot express
semantics or conditional relationships in the syntax...
They might be unable to express *all* conditions, and there is a
border beyond that ABNF would be unreadable for humans, but it's
possible to find a god balance. Just look into RFC 2822, it's
beautiful. It took me years to find something that's (arguably)
wrong in the RFC 2822 ABNF.
Of course some concepts like NO-WS-CTL in RFC 2822 are horrible,
but that's not the fault of the ABNF. And everybody can see it,
asking why on earth there's NO-WS-CTL in the RFC 2821 construct
<General-Address-Literal>. This means NO-WS-CTL in a HELO. This
can't be what you really want, and no amount of prose can fix it,
it's a bug, made visible by the ABNF.
I think that quietly restricting the range of the second digit
in syntax with no comments in the text is a bad idea.
But it was also clear, somewhere I asked if what we want is in
fact 3DIGIT instead of [2-5][0-5][0-9]. You can use both forms,
and then either explain in the prose that not all digits are
allowed, or explain that extensions can specify other codes.
Here's the issue mentioned above:
address-literal = "[" ( IPv4-address-literal /
IPv6-address-literal /
General-address-literal ) "]"
In other words some syntax gibberish within square brackets.
General-address-literal = Standardized-tag ":" 1*dcontent
Whatever that is, SMTP servers are expected to accept it. Now
checking 2822:
dcontent = dtext / quoted-pair
Great, we get a bunch of horrible backslashes here. In the HELO
and everywhere. But it's far worse:
dtext = NO-WS-CTL / ; Non white space controls
%d33-90 / ; The rest of the US-ASCII
%d94-126 ; characters not including "[",
; "]", or "\"
This means raw ASCII 1-8, 11-12, 14-31, and 127. In a HELO and
all other places allowing <adress-literal>. Complete ESCape
sequences, NAK, SUB, DEL, etc. This can't be what you want.
And I would of course ask for a *detailed* "implementation and
interoperability report" wrt NO-WS-CTL if it's kept in 2821bis.
It took about ten months to *kill* this crap at least for the
Message-ID in RFC.ietf-usefor-usefor-12, I hope it will be a bit
faster here.
After all who needs a <General-Address-Literal>, it's certainly
not better than those 1yz codes. If we "must" have it it should
be at least exactly the same as a STD 66 <IPvFuture>, preferably
using the same name.
STD 66 like RFC 2822 and RFC.ietf-usefor-usefor-12 has a very
clear no-nonsense ABNF.
Frank