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

--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
> anymore.
>
>
> 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
> wrote:
> > 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 "example.com." and not "example.com",
> 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.
regards,
    john