[Top] [All Lists]

RFC2821b is-01 Issue 1: trailing dot in Domain (was: Re: domain name definition in RFC2821)

2007-03-23 09:13:44

--On Friday, March 23, 2007 07:30 +0100 Alex van den Bogaerdt <alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net> wrote:

Hi. As it turns out, I'm subscribed after all.  I just
didn't include the folder in my search path for new mail

Let me start by saying I have two quite different points,
not just one.  I think {allowing a tld} and {allowing
the trailing dot} are two separate issues and should not
necessarily be discussed together.  They do have one thing
in common though.

Let's start with the trailing dot:

On Fri, Mar 23, 2007 at 12:03:26AM +0100, Frank Ellermann
Ned quoted RFC 1123 5.2.18 in this thread (2006-04-22):

| 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.

Something violating RFC-822 doesn't mean 'something' is wrong.
It could also be that RFC-822 is wrong.  At the time, DNS was
a new concept and we've learned since then.

I don't think "overqualifying" is what is really happening:

Let's look at the situation at hand.  A FQDN is built by
starting at a DNS node, writing down its label, and move
to its parent.  RFC 1035 says: "Since every domain name
ends with the null label of the root,...". No doubt, the
empty label is part of the FQDN.  We use dots to separate
labels, thus there is a dot between "com" and "" (root).
This means the FQDN is "" and not "",
and it means the dot isn't even truly trailing.

Alex (and others),

Let me remind this group about earlier notes from Lisa and Tony: we have agreed to do this work as an effort to create RFC2821bis and move it to Draft. It is reasonable to oppose that effort, but the result you would be asking for would not, e.g., a WG to review and possibly alter the basic provisions of 2821 but a WG whose charter includes opening up and possibly changing fundamental mail properties.

A suggestion to revisit and revise protocol decisions made in RFC822 and affirmed in RFC2822 or made in RFC821, clarified (in this case) in RFC1123, and affirmed in RFC2821 are simply out of scope. If people are convinced that a clarifying and cleanup update to RFC 2821 is useless or harmful unless protocol changes can be made, they should, IMO, simply say so -- clearly now and loudly during any possible Last Call -- rather than trying to participate actively in this much narrower effort.

I want to also repeat something I've said in the halls this week and that someone else may already have said online (if so, I apologize for the duplication). While the 2821bis effort was not postponed for years for this reason, there have been some years since 2821 was published in which people could have introduced standalone proposals to change mail semantics at any time, gotten consensus if it was to be had, and then pushed their work through to Proposed Standard. Had that work been completed and the requirements for Draft met for it, it could be folded into 2821bis now and the whole business advanced. I've advised several people of that option over the last few years. I note a distinct absence of such proposals that updated 2821 to change its semantics in any of the areas now being raised.


<Prev in Thread] Current Thread [Next in Thread>