--On Saturday, 22 April, 2006 01:27 -0700 Yuri Inglikov
By the way the "ws." syntax appears "invalid" according to
every RFC I read.
Except the base DNS specs and RFC 1123, which makes accepting it
Um, actually, not only does it not say that, it says exactly the opposite.
Section 5.2.18 describes "common address formatting ERRORS" (emphasis mine).
The fourth bullet item is:
o Some systems over-qualify domain names by adding a
trailing dot to some or all domain names in addresses or
message-ids. This violates RFC-822 syntax.
So you can add RFC 1123 to the list of email-related RFCs that describe
trailing dots as a syntax error.
I can find no reference in RFC 1123 that says accepting a trailing dot
is mandatory anywhere. The closest thing to this I can find is the statement
in section 188.8.131.52 that:
If an abbreviation method is provided, then:
(a) There MUST be some convention for denoting that a name
is already complete, so that the abbreviation method(s)
are suppressed. A trailing dot is the usual method.
But this section is talking about user interfaces, not on-wire protocols. And
it goes on to say that abbreviations need to be expanded - and the exmaple is
"a mail program". Couple this with the previous assertion that trailing dots
are syntax errors in email and the clear inference is that the user interface
should remove the trailing dot if one is present.
That is, indeed, an issue. But, again, 1123 is crystal-clear on
the subject. And the 2821bis working draft is now consistent
Well, I agree that RFC 1123 is quite clear. But I think it pretty
much says the opposite of this.
Yuri, since you seem to be looking for the bottom line here, I
suggest it is:
(1) Anywhere that "Domain" is permitted as a piece of syntax,
"Domain." is permitted. Not supporting it is bad news. If you
are working on this at Microsoft, note that IE supports the
trailing dot in domain names, so failure to support it in email
would presumably violate the law of least astonishment, provide
a surprising user experience, etc.
I have no problem with supporting a trailing dot in a user interface. Indeed,
I think RFC 1123 can be read as suggesting (although not requiring) that this
However, I have a big problem with extending the on-wire syntax to include
trailing dots. This is a clear break from past usage and I do not think the
benefits are anywhere near commensurate with the costs.