Magnus Westerlund wrote:
General-address-literal = <Standardized-tag> ":" 1*dcontent
; Standardized-tag MUST be specified in a
; standards-track RFC and registered with IANA
However, my personal objection against this resolution of the
error is that it leaves use with a undefined rule that is
intended for future extensions.
JFTR, <dcontent> is also undefined (in 2822upd).
Thus I wonder why one can't specify it like:
Standardized-tag = ehlo-keyword
You could also say <subdomain>, same idea never ending with
a hyphen. And because the concept has nothing to do with a
<subdomain> or <ehlo-keyword> you could expand it:
| Standardized-tag = Let-dig [Ldh-str]
Is there a any problem with defining a rule for what characters
is allowed in future tag for identifying literal address
formats
It's hard to talk about potential problems with hypothetical
IPvFuture versions, but picking "IPv6" would be unwise... :-)
Frank