----- Original Message -----
From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
True, at least to the present... See RFC 3696
Degenerated into <toplabel>, starting with a letter, ending
with letter or digit, otherwise also hyphen. Something we
could improve in 2821bis. The SPF-spec. needed <toplabel>.
Only ALPHA isn't good enough for any future xn-- etc. TLD.
if ICANN goes crazy
After their ".net" suicide prepare for the worst :-( Bye
I'm hope Klensin is following the thread for consideration, insight,
perspective on the SMTP entities, the syntax, compliance, issues, the
possible security aspects, etc, to basically remove ambiguity and also
strengthen the entity, in particular HELO, where so many extended
applications will be dependent on as well as making sure that it works in
backward compatibility mode.
So we have the domain-literal, for 2821bis, we need to make sure it clearly
defines what are all the possibilities.
Claus raised a valid point, how do you know it is not a domain? I think
1123 clears that up. Something for John to include in 2826bis.
However, if that could change, then I would like to see how and is this
"possibility" enough to ignore any syntax/value issues?
If ICANN do allow for numeric TLDs, in order to comply with RFC 2821 Today,
it could be allowed for number values over 255.
So for example, .911 will the following be possible:
miami.911
newyork.911
houston.911
without violation the specifications?
Remember, in my view, for proposals, like SPF and CSV to have any hope of
success in the future, the client domain name will have to be clearly worked
out, with some level of enforcement. For example, before I can make the
presumption the client domain is CSV or SPF ready, I need to make sure it is
syntax/value ready first.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com