The recent draft-ietf-marid-protocol-00.txt cites this mailing
list as one of two addresses for discussion of the draft.
I've got some technical quibbles with that draft's grammar.
Sorry if they've been brought up before; I'm new to this set
of documents.
From the ABNF:
: unknown-mechanism = name [ ":" macro-string ] *[ "/" *DIGIT ]
What's the parse tree for
foo:pi/2
? The "/2" can be parsed either as part of the "macro-string"
or as part of the [/*DIGIT] suffix. "/" and digits are valid
VCHARs, and a macro-string can contain VCHARs.
Well, this is an unknown-mechanism, so we don't really care; but
the grammars for known mechanisms suffer from the same problem.
: A = "a" [ ":" domain-spec ] [ dual-cidr-length ]
The domain-spec can expand to macro-string, and a macro-string
can end in anything %x21-7F, including "/2". This doesn't
yield a definitive parse.
The default way of resolving such conflicts would parse greedily
and pack as much as possible into the macro-string--which would
lead to nothing to ever being interpreted as a cidr-length.
..
The definition of macro-string itself doesn't make clear
that "%" must not be interpreted as a VCHAR, but as part of
a "macro-char" sequence.
: macro-string = *( macro-char / VCHAR )
: macro-char = ( "%{" ALPHA transformer *delimiter "}" )
/ "%%" / "%_" / "%-"
VCHAR also contains %. But at least here, parsing greedily
has the desired result.
..
As mentioned in the context of A, the definition of domain-spec
competes with a more generic definition:
: domain-spec = domain-name / macro-string
Since domain-names are subsets of macro-strings, this
says exactly the same as
domain-spec = macro-string
Maybe what you mean to express is "evaluate the macro string,
and the result must fit this <domain-name> grammar" -- but
that's not what the ABNF actually means.
(*Do* you mean that? That would mean that the string must not
evaluate to domain names containing "_", such as names
starting with _spf.)
..
: domain-part = as defined in [RFC 1034]
Authors can make it easier for developers by giving them the specific
token name to search for. (RFC 1034 doesn't define the token "domain-part".)
I'm guessing this is referring to a <label>:
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
..
: If the <domain> is not an FQDN, the check_host() immediately returns
: the result "Fail" and a reason of "Malformed Domain".
Again, this could really use a grammar or a specific reference to an
RFC and a token name. I'm using the first half of RFC 2821's "Domain",
excluding their "address-literal" expansion, meaning no underscores,
no trailing/leading dots, and at least two parts. If you used
RFC 1034, you'd end up allowing single-part domain names, and you'd
be just as correct.
Jutta <jutta(_at_)sendmail(_dot_)com>