SM <sm(_at_)resistor(_dot_)net> wrote:
At 03:02 30-06-2008, Magnus Westerlund wrote:
My discuss was started due to there was a rule which wasn't a rule,
i.e. it didn't contain any elements. A clear syntax violation in
ABNF. The rule in the issue was "Standardized-tag", this can be seen
in version 10 of the draft in section 4.1.3.
Quoting the section from RFC 2821:
"For IPv6 and other forms of addressing that might eventually be
standardized, the form consists of a standardized "tag" that
identifies the address syntax, a colon, and the address itself, in a
format specified as part of the IPv6 standards [17]."
(now the first paragraph of 4.1.3)
That might have to be changed as well.
At first blush, this seems sufficient if the ABNF says what we need
(mostly how to parse the "tag").
Is there a any problem with defining a rule for what characters are
allowed in future tag for identifying literal address formats that
is large enough to motivate living with the interoperability issue?
I see no problem -- it's mostly a matter of finding a round tuit.
A point raised during the discussion was whether something is valid
because it is permitted by the syntax.
Obviously, the answer is "maybe". ;^)
Even purest garbage can be "valid". And, a lot of the time, we don't
even need to process the "address" for the mail system to function. At
first blush, I'd say it's sufficient to specify how to isolate the
string which constitutes the "address". We can punt to other document(s)
how to make sense of it.
One might have to go back all the way to 821 to fully understand the
rationale of what's in this draft. And even then, it's not that
obvious unless you talk to the people who actually wrote the text.
One shouldn't need to "fully understand the rationale" in order to
use this spec. But one _should_ find sufficient specification to know
how to parse the constituent parts.
--
John Leslie <john(_at_)jlc(_dot_)net>