quoted names
Mark Crispin
an address has "special" characters and will quote the address if so.
It uses double-quote quoting when possible; if not, it uses backslash
quoting (for the really hairy cases).
What could have happened is that the process which queued the mail to
MMailr (which I bet wasn't MM) misunderstood the quote application rules
and applied SMTP quoting to the address in the envelope. Since MMailr
performs this service, it was done twice. Perhaps you'll be able to tell
from the message header what mail composition program wrote the message
and its maintainers can be notified.
On a related topic, it's been two years now and people are still using
" at " in addresses (ala RFC 733). Noted culprits in the PDP-10 world
are DECmail/MS and old versions of Hermes and Babyl. Something ought
to be done to stamp this old software out!
-------
Frank J. Wancho
I'm the guilty party who sent the message in question, and I used the
latest version of BABYL to do it. I also deliberately put the double
quotes around the name "Webb Mike" as I knew BABYL doesn't handle the
unquoted case properly, and MM doesn't handle it (No such local user
as "Webb"), unless the double-quotes *are* used.
However, Mark's analysis of the mis-quoting done by BABYL in the
envelope appears correct. I will pass this exchange on to the
maintainers.
On the related topic, the current BABYL properly handles the " at "
cases, and has for quite some time. I have yet to be able to induce
HERMES to cause that form of address to slip out, yet I know one of
users on another machine was able to generate that in a header...
Still checking.
--Frank
Marshall Rose
botching. A surprisingly large number of date fields that get generated
aren't 822. Of course, you never notice these things until you try using
a routine that actually tries to *parse* the date string.
Oh well,
/mtr
Mark Crispin
date. That's because, with all the zillions of date/time syntaxes the
TOPS-20 IDTIM% system call can parse and ODTIM% can generate, RFC 822
takes great pains to pick one that isn't among those zillions. Actually,
I don't think it was really done deliberately, but one wonders.
So, the code picks a nearest approximation, and DEC has been asked to
define a new bit meaning "RFC 822 format". Where we blow it is that
we don't have a comma after the day-of-week and have a hyphen before
the timezone.
I swear, though, if after we finally get into full compliance with RFC 822
dates they change the syntax to something incompatible AGAIN, I'll get
the %&#@!
-------
Marshall Rose
Actually, I wasn't knocking TOPS-20 systems (MM, et. al., in particular),
but a few of the really obscure sites that are using something that is
completely unlike the 822 syntax. The date parser I use doesn't have any
problem with ODTIM%-generated strings, but can't pull a rabbit out of a
hat...
/mtr
Jacob_P...@qzcom.mailnet
FROM: Mark Crispin <M...@SU-SCORE.ARPA>
I swear, though, if after we finally get into full compliance
with RFC 822 dates they change the syntax to something
incompatible AGAIN, I'll get the %&#@!
Surely they will. Do you not know that there is an international
standard for calendar dates. Something like this, I believe:
1984-10-23-17.43.59
for todays date.
DESJA...@usc-isi.arpa
international standard already in existence for something, and
the standard meets the military requirements, then the standard
would be used in preference to inventing something new. I would
think that policy applies to calendar date/time strings (but I
can't verify from my own knowledge that the syntax Jacob gave is
correct). Barry Leiner or Bob Kahn could give a more definitive
statement of the policy, but this is the essence of it.
--Dick dJ
Erik E. Fair
>> From: Jacob_P...@QZCOM.MAILNET
<flame on>
The rest of the world can go screw itself with X.400 (as they are
apparently trying to) and we can pray that DoD will see the light and
ignore them. Somehow, standards that are made by a committee of people
who have never used or supported a large computer network (such as the
ARPA INTERNET) strike me as ill conceived.
For whatever glitches might be in the RFCs, they are the product of
almost 15 years of research and practical experience, and should not be
cavalierly discarded in favor of X.400.
<flame off>
internet forever,
Erik E. Fair ucbvax!fair fa...@ucb-arpa.ARPA
dual!fa...@BERKELEY.ARPA
{ihnp4,ucbvax,hplabs,decwrl,cbosgd,sun,nsc,apple,pyramid}!dual!fair
Dual Systems Corporation, Berkeley, California
Jack Hagouel
> almost 15 years of research and practical experience, and should not be
> cavalierly discarded in favor of X.400.
>
Erik has a good point that RFCs have matured over years of both thinking
and everyday use. Unfortunately, this does not guarantee standards that
are useful to everybody. RFCs developed for a particular community and
with some assumptions about the supporting environment. Early design
decisions limit the amount and quality of modifications in later versions.
Although I would hardly call myself an expert on the RFCs I find that
the X.400 standards have a level of rationality rarely found in standards.
This seems to have attracted a lot of support in the industry, a necessary
ingredient for any proposal to become a standard. Could we think of them
as a second generation standard?
Jack Hagouel
...!ittvax!hagouel
Martin Lee Schoffstall
> The rest of the world can go screw itself with X.400 (as they are
> apparently trying to) and we can pray that DoD will see the light and
> ignore them. Somehow, standards that are made by a committee of people
> who have never used or supported a large computer network (such as the
> ARPA INTERNET) strike me as ill conceived.
What happens when you want to talk to rest of the world? There
are other places in the world where people are doing interesting
things.
Then there is the question of why the DOD should be spending
upteen billions of dollars on research in mail, networking etc..
when (or if) the commercial sector has a good answer. [Didn't
you see the 60 minutes episode on the F20 Tigershark?]
You are being a bit colonial in your belief that others haven't
used or supported large computer networks. At the inception
of the Arpanet others were also experimenting. Now there are
a multitude of large X.25 networks, and yes even a internetwork
of X.25 networks.
>
> For whatever glitches might be in the RFCs, they are the product of
> almost 15 years of research and practical experience, and should not be
> cavalierly discarded in favor of X.400.
>
One of the criticism that I have heard in the past is that
the people who wrote the RFC's were RESEARCHERS, it was a
real interesting research project and they even spent some
time implementing 90% of the specification. But that
other 10% was a bit hard and left as an excersize to the
student while they go on to other interesting things,
"We do research!" they would say. The problem was that
the last 10% of the specification didn't hack it in
the real world.
If you don't want the DOD to cavalierly discard the RFC's
(they won't), why don't you take the same tack and not
cavalierly discard the work of other standards making
bodies.
marty schoffstall
cadmus!sch...@seismo.ARPA
{linus,seismo,bbncca,wivax}!cadmus!schoff