Microsoft Patent - Re: New Internet Draft: draft-duerst-archived-at-00.txt

Martin,   I think Microsoft just patent this.

Ridiculous!

United States Patent 6,704,772
Ahmed ,   et al. March 9, 2004

Thread based email

Abstract

Systems and methods for providing electronic messaging services to multiple
users by storing a single copy of an electronic message at a central
location and notifying recipients of the stored single copy. An electronic
message includes a distribution list and a message content. A distribution
list identifying multiple recipients causes prior art systems to duplicate
the entire message for each recipient, placing potentially large demands on
both processing power and storage space. In contrast, the systems and
methods disclosed herein store a single copy or a limited number of copies
of an electronic message addressed to multiple recipients and provide each
recipient with a relatively small notification. In addition to providing
information regarding content and origin, the notification also provides
access to the stored message. Furthermore, the methods and systems also aid
in organizing replies to electronic messages. Replies are associated with an
initial message through a message identifier. The association helps to
organize electronic messages by subject and provides context without
requiring an author to duplicate the content of the initial message with the
reply.

Re: Microsoft Patent - Re: New Internet Draft: draft-duerst-archived-at-00.txt

Actually, if all the claims follow the abstract and refer to 
"electronic messaging" rather than email, then I would think netnews 
*itself* is prior art that should be reasonably easy to document!  -- 
NB

On Mar 10, 2004, at 10:00 AM, Hector Santos wrote:

>
> Martin,   I think Microsoft just patent this.
>
> Ridiculous!
>
>
> United States Patent 6,704,772
> Ahmed ,   et al. March 9, 2004
>
> Thread based email
>
> Abstract
>
> Systems and methods for providing electronic messaging services to 
> multiple
> users by storing a single copy of an electronic message at a central
> location and notifying recipients of the stored single copy. An 
> electronic
> message includes a distribution list and a message content. A 
> distribution
> list identifying multiple recipients causes prior art systems to 
> duplicate

Re: Microsoft Patent - Re: New Internet Draft: draft-duerst-archived-at-00.txt

My memory is a bit fuzzy on this, but I seem to remember at least one,
likely more systems in the early 90's that did this.   Lotus cc:Mail, Notes,
and possibly a system by Oracle of the time.   Unfortunately it has been too
long to remember details, but perhaps someone who was internal to these
organizations may be able to shed a bit more light on the subject.

Best Regards,

-- Tim

----- Original Message ----- 
From: "Nathaniel Borenstein" <nsb <at> guppylake.com>
To: "Hector Santos" <winserver.support <at> winserver.com>
Cc: "Martin Duerst" <duerst <at> w3.org>; <ietf-822 <at> imc.org>
Sent: Thursday, March 11, 2004 11:24 PM
Subject: Re: Microsoft Patent - Re: New Internet Draft:
draft-duerst-archived-at-00.txt

>
> Actually, if all the claims follow the abstract and refer to
> "electronic messaging" rather than email, then I would think netnews
> *itself* is prior art that should be reasonably easy to document!  -- 
> NB
>
> On Mar 10, 2004, at 10:00 AM, Hector Santos wrote:
>
> >
> > Martin,   I think Microsoft just patent this.
> >

Re: Microsoft Patent - Re: New Internet Draft: draft-duerst-archived-at-00.txt

Re: Microsoft Patent - Re: New Internet Draft: draft-duerst-archived-at-00.txt

Tim Kehres wrote:

>My memory is a bit fuzzy on this, but I seem to remember at least one,
>likely more systems in the early 90's that did this.   Lotus cc:Mail, Notes,
>and possibly a system by Oracle of the time.   Unfortunately it has been too
>long to remember details, but perhaps someone who was internal to these
>organizations may be able to shed a bit more light on the subject.
>  
>

All-In-1 (from Digital Equipment Corporation) is another example that 
has been around as of the late 80's which did this. IMHO M$ can't claim 
it has invented this, but maybe they are the first to patent it?

/rolf

Re: Microsoft Patent - Re: New Internet Draft: draft-duerst-archived-at-00.txt

Folks,

TK> My memory is a bit fuzzy on this, but I seem to remember at least one,
TK> likely more systems in the early 90's that did this.   Lotus cc:Mail, Notes,

Most or all of the LAN-based email products, including cc:Mail, were
based on a central, shared message store.  This was latter 1980's.

As noted, other systems like DEC's all-in-one also saved on storage by
sharing central message copies.

As for Nick's reference to Notes's mid 1980's use of inter-document
dynamic links, SRI's NLS system had them operational no later than 1972,
but probably more like 1966.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

Re: Multi-message reply and "References:"

Sorry if this reply is somewhat dated, I am reading this mailing
list with a  slight  time delay.

At 06.11 +0000 03-06-07, D. J. Bernstein wrote:
>RFC 2822 is incorrect when it suggests that References has all of the
>message's ancestors. What References actually has is the start of the
>thread, followed by the most recent ancestors, ending with the parent.
>Ancient ancestors other than the start of the thread are often missing.

I remember that I pointed this out when RFC 2822 was
developed. Other people then said, that although they knew
this was done, they did not like it, and therefore did not
want it mentioned in the standards document.

Maybe this practice of omitting middle Message-IDs, but
always keeping the first and the last two or three, could
be mentioned in a revised RFC 2822 in chapter "4. Obsolete
Syntax", in the description of "obs-references". That
chapter is meant to describe syntax which occurs but which
is not recommended. It could also contain a description of
practice which is not recommended.

Since the people who wrote RFC 2822 did not want this to be
described, they obviously were of the opinion that if a
thread is 200 or 1000 messages long, all of them should be
included in the references field!
--

-- 
Jacob Palme <jpalme <at> dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Re: Multi-message reply and "References:"

In <p06020400bc7cd1043481@[130.237.157.77]> Jacob Palme <jpalme <at> dsv.su.se> writes:

>Sorry if this reply is somewhat dated, I am reading this mailing
>list with a  slight  time delay.

>At 06.11 +0000 03-06-07, D. J. Bernstein wrote:
>>RFC 2822 is incorrect when it suggests that References has all of the
>>message's ancestors. What References actually has is the start of the
>>thread, followed by the most recent ancestors, ending with the parent.
>>Ancient ancestors other than the start of the thread are often missing.

>I remember that I pointed this out when RFC 2822 was
>developed. Other people then said, that although they knew
>this was done, they did not like it, and therefore did not
>want it mentioned in the standards document.

>Maybe this practice of omitting middle Message-IDs, but
>always keeping the first and the last two or three, could
>be mentioned in a revised RFC 2822 in chapter "4. Obsolete
>Syntax", in the description of "obs-references". That
>chapter is meant to describe syntax which occurs but which
>is not recommended. It could also contain a description of
>practice which is not recommended.

In Netnews, the GNKSA suggests keeping only the last three.

However, USEFOR has taken the view that you should keep the first and the
last 20. That will probably go in the Current Practices document rather
than in the standard itself.

However, now that this topic is opened again, I would like to revisit the
original topic of this thread, namely Multi-message reply and
"References:". I said nothing on this thread at the time, because my
subscription to this list was all screwed up following an address change.

ISTM that the fundamental property required of the References header is
that messages should be placed later in the list than any message which is
a precursor of it (note that in the usual case, where the thread is a pure
tree, that is exactly equivalent to the present rule). Replying
simultaneously to two messages and adding them both to the end of the
References chain (in either order) would achieve that property.

Now when it comes to presenting the messages in a MUA, one needs the same
property, so that you will not try to read a message until you have read
all of its precursors. So it should be possible to get that effect if the
References header is constructed as I have suggested.

What may be more difficult is to reconstruct the whole graph (strictly a
DAG) from such References headers, but the question is whether it is
really necessary to do that in order to provide an adequate presentation.

Some solutions which were being propounded the last time this came up
involved additional syntax in the References header which it would be
difficult to introduce on the existing network. A solution which sticks
with the present syntax but slightly extends the semantics would have a much
better chance of smooth deployment.

This topic is also under discussion on the Usefor list - not that Usefor
has any declared intention of introducing a change at this time, but it
might if there was a simple solution that had a broad consensus.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

why spamassassin sucks

People are often asking me why I think spamassassin sucks.  Here's an example 
of a perfectly valid email that it blocks.  The email is a weekly Numerical
Analysis Digest list that uses the group syntax in the To address. 

BTW, here are the full headers of the subject message as I received it.
The space between : and ; was added by sendmail somewhere in the path.
It's such a common sendmail bug that there's no way to eradicate it, but
it shouldn't matter as it's still valid group syntax.

There is no URL in the TO address.  There are spaces in the To field, but 
not within an address - it's perfectly valid syntax to have space between
the : and ; in group syntax, or within a group name.  Satan only knows why
this message failed the OPT_HEADER test.

Keith

(begin headers)
Return-Path: <na-digest-bounces <at> cs.utk.edu>
Received: from localhost (klutz [127.0.0.1])
	by smtp.cs.utk.edu (Postfix) with ESMTP
	id 0E6FFAFD86; Sun, 28 Mar 2004 11:20:47 -0500 (EST)
Received: from smtp.cs.utk.edu ([127.0.0.1])
 by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 22342-07; Sun, 28 Mar 2004 11:20:40 -0500 (EST)
Received: from netlib2.cs.utk.edu (netlib2.cs.utk.edu [160.36.58.108])
	by smtp.cs.utk.edu (Postfix) with ESMTP
	id E2FD7AFB5D; Sun, 28 Mar 2004 11:20:36 -0500 (EST)
Received: from netlib2.cs.utk.edu (localhost [127.0.0.1])
	by netlib2.cs.utk.edu (8.12.8/8.12.3) with ESMTP id i2SGKSCn005030;
	Sun, 28 Mar 2004 11:20:28 -0500 (EST)
Received: from na-net.ornl.gov (root <at> localhost)
	by netlib2.cs.utk.edu (8.12.8/8.12.2/Submit) with SMTP id i2SGKRp6005023;
	Sun, 28 Mar 2004 11:20:27 -0500 (EST)
Received: from netlib2.cs.utk.edu (localhost [127.0.0.1])
	by netlib2.cs.utk.edu (8.12.8/8.12.3) with ESMTP id i2SElJCn000498
	for <na.send2list <at> na-net.ornl.gov>; Sun, 28 Mar 2004 09:47:19 -0500 (EST)
Received: (from moler <at> localhost)
	by netlib2.cs.utk.edu (8.12.8/8.12.2/Submit) id i2SElJ7t000497
	for na.send2list <at> na-net.ornl.gov; Sun, 28 Mar 2004 09:47:19 -0500 (EST)
Date: Sun, 28 Mar 2004 09:47:19 -0500 (EST)
From: Cleve Moler <moler <at> cs.utk.edu>
Message-Id: <200403281447.i2SElJ7t000497 <at> netlib2.cs.utk.edu>
To: na-digest list: ;
Subject: NA Digest, V. 04, # 13
Reply-To: na.digest <at> na-net.ornl.gov
(end headers)

Keith

Begin forwarded message (names of the innocent redacted):

Date: Mon, 29 Mar 2004 02:05:55 -0500 (EST)
From: XXX
To: moore <at> cs.utk.edu, XXX 
Subject: Re: NA Digest, V. 04, # 13 (fwd)

Hi, Keith and XXX -- I've heard this from several
people now.  -- XXX

---------- Forwarded message ----------
Date: Sun, 28 Mar 2004 19:14:04 -0800
From: XXX
To: XXX
Subject: Re: NA Digest, V. 04, # 13

XXX et al, the local spam filter has been filtering
out my na-net news for a few weeks now.  It looks
like you could avoid the filter by giving the list
a name that doesn't contain spaces.

Cheers,

- XXX

> From XXX Sun Mar 28 07:01:26 2004
> Date: Sun, 28 Mar 2004 09:47:19 -0500 (EST)
> From: XXX
> To: na-digest list:;
> Subject: NA Digest, V. 04, # 13
> X-UCE-Filter-Settings: XXX redirected to 90_OPT_OUT
> X-Scanned-By: MIMEDefang 2.37
> X-Scanned-By: IEEE UCE Filtering Service
> X-Spam-Flag: YES
> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on stamps.cs.ucsb.edu
> X-Spam-Level: *****
> X-Spam-Status: Yes, hits=5.9 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR,
> 	OPT_HEADER,TO_HAS_SPACES autolearn=no version=2.63
> X-Spam-Report:
> 	*  2.4 TO_HAS_SPACES To: address contains spaces
> 	*  1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email
> 	*  2.4 OPT_HEADER Headers include an "opt"ed phrase
> 	*  0.0 AWL AWL: Auto-whitelist adjustment

Re: why spamassassin sucks

followup:

They claim that these problems are already fixed in the development
version.  I still don't trust SA, but I do appreciate the fast response.

Keith

--
Power corrupts; Powerpoint corrupts absolutely. 	- Vint Cerf