Message-Id: <199604020633.BAA08780@wilma.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: Mark Crispin <MRC@panda.com>
cc: Keith Moore <moore@cs.utk.edu>, Dave Crocker <dcrocker@brandenburg.com>,
        drums@cs.utk.edu
Subject: Re: "." in phrase 
In-reply-to: Your message of "Mon, 01 Apr 1996 15:53:47 PST."
             <MailManager.828402827.14897.mrc@Ikkoku-Kan.Panda.COM> 
Date: Tue, 02 Apr 1996 01:33:20 -0500
Sender: moore@cs.utk.edu

> On Mon, 01 Apr 1996 18:13:34 -0500, Keith Moore wrote:
> > As to whether not allowing extra "."s was a mistake, that's no longer
> > relevant.  If extra "."s are hostile to the present-day installed base, we
> > must not allow them.  (At least, we want to have a significant and
> > demonstrable benefit to justify the cost.)
> 
> How about the fact that it becomes possible to declare both local-part and
> domain as atom and let some other standard define their internal syntax?

That's fine for parsing, and I'm all for making it easier to parse 
messages.  But it's also important that we tell people that generating 
such things will cause some existing systems to break.

> > I can only say that (a) I *have* seen addresses of
> > the form "foo.bar.@some.domain" several times in the past year or so
> > (generated by a brain-damaged gateway) and (b) that several of my local
> > users have complained about not being able to reply to such messages.
> 
> This sounds like an excellent reason to remove "." from specials and be done
> with it.  It makes previously invalid syntax valid, without making any
> previously valid syntax invalid.  It's a net win.

I don't care whether we remove "." from specials or not, so long as it's
clear that you shouldn't generate such things.  (Generating return addresses
that aren't well handled by the installed base is NOT a net win.) 

Mind you, there are lots of perfectly legal (by 822) things that aren't
well handled by the installed base either.  I'm all in favor of telling
people not to generate those things too.  (whether it's a MUST NOT or
a SHOULD NOT or whatever is still an open question)

> Let's go with the converse argument:
>   I can only say that (a) I *have* seen phrases of
>   the form ``John Q. Public'' several times in the past year or so
>   (generated by a brain-damaged MUA) and (b) that several of my local
>   users have complained about not being able to reply to such messages.
> 
> I can tell you what *my* local users would say; that the MUA that can't reply
> to these messages is broken.  

Users also think that their email addresses should be able to contain
non-ASCII characters.  Users think that apple.com should be the Apple
they have in mind, not some other company that happens to be named Apple.
Users blame the local Postmaster if mail to Timbuktu isn't delivered 
immediately, or if they can't reply to a message because the return
address on the original message lacks a fully-qualified domain name.

In short, the fact that users think something is broken, doesn't mean 
that it is broken, or that the the user understands the nature of the
problem, or that the obvious fix isn't worse than the problem itself.

That's not to say that when designing systems, that we shouldn't try
to conform to the Principle of Least Surprise.  Not allowing "."s in
phrases violated that principle, and it's worth considering relaxing
it now if we can do so without serious negative impact.

But just because we modify the protocol so that the user isn't 
surprised, doesn't mean that the user gets better service.  A 
MTA that never returns nondelivery reports seems to work better
than one that does.

> I have enough trouble quelling the protests of
> users who are enraged that double quotes were (to them) randomly applied
> around their name.  They say that blurdybloop mail doesn't do this evil thing,
> so why should my mail do it.  "Protocols, schmotocols, you're making this up."

They do indeed say such things.  But are they better off if we change the
protocols so that these users' mail cannot be replied to as often?

> We recognized this, and we're trying to fix this.  But instead of doing the
> simple, clean, easy-to-understand solution, we're acting like elitists.  And
> as the reward for our elitism we'll come up with an 822bis that will have just
> as many crummy implementations that cut corners as there are today.

Your point is well taken.  I have a very similar concern.

One kind of elitism says "users' expectations be damned, we know
what works and what doesn't and users better follow it."  That 
may be true, but it is naive to think that users will follow too
many rules that they don't understand.

Another kind of elitism says "installed base be damned, we know
a better way to do things now".  We may really know a better way, 
but it may not be worth breaking the installed base -- especially
when the installed base can hang around nearly forever. 

A third kind of elitism says "the specifications are holy and
must not be violated no matter what".

Finally, there's at least one other kind which says, "we have defined a 
wonderful language for our system that lets us describe it perfectly.  
It doesn't correspond to anything in the outside world because that
would mislead people into making incorrect assumptions.  But if 
the implementor will only take the trouble to learn our language, 
he will be able to understand our system in all of its wonderful subtlety.
Any implementor that can't or won't do this isn't fit to implement our
protocol."

I'd suggest that all of these forms of "elitism" can serve a useful
purpose.  But we need to watch out for them lest they bite us.

Keith


> > FWIW, Numeric timezones *are* in rfc 822
> 
> In the English, yes, but not in the formal syntax in Appendix D.  A case can
> be made that the formal syntax overrides the English.

Yes, it's omitted from Appendix D, but it is in the ABNF in section 5.  
I've always assumed that this was a typo.