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

[Keith Moore <moore@xxxxxxxxxx>]

>  >The reason you haven't seen it implemented is that you are looking
>  >at 
> archives with web browsers.  Internet email readers don't currently
> have a way of accessing archives (except perhaps for read-only IMAP),
> so there aren't many archives that are set up for use by email
> readers.  But all internet email readers support message/rfc822 to
> some degree, whereas not all of them support HTML or other formats.
> 
> You are essentially just confirming what I said: It's not implemented.
> The fact that I'm using a browser isn't some kind of bias, it's just
> currently the only way it works.

That's an odd way of looking at it.  If you're trying to define a 
new extention to email, presumably to be used by email clients, 
_of course_ it's not already implemented by email clients.  This is
the normal situation when we're defining a protocol extension.

And of course native format archives _do_ exist and at least some
email clients are already able to download files using http and/or
ftp.  so the unimplemented part of this is rather small.

>  >If you are designing a way to allow email messages to reference
>  >archives, 
> it makes good sense to make those messages usable by email readers.
> 
> There is absolutely nothing in the design or description of
> Archived-At that would prevent doing that. It's all a question of
> implementation.

I see it as a question of interoperability.  If people get the idea that
it's appropriate to set Archived-At fields to point to HTML documents,
then (a) a number of email readers won't be able to read them, and (b) 
even those email readers that can read them won't be able to treat them
as email messages.  This is pretty dysfunctional - it results in yet
another new feature that is not very flexible.  Sooner or later we'll
be trying to define Yet Another Header Field that does the same
thing as Archived-At except that the archives are actually intended
to be accessible by email readers.  (And we'll be bothered by the 
fact that the Archived-At field name is already taken.)

> If you think this is that important, why don't you go and add such
> a feature to an open-source MUA, or convince somebody to do that?
> Or add such a feature to some mailing-list expander/archival software?

I'm quite willing to do so.  I just don't want to wait until that code
is written and shipped before making comments about your proposal.

(Actually if we were still using my list software here, I would have
already done the latter.)

> I think one of the major misunderstandings here is how (X-)Archived-At
> is currently used at W3C (and as Graham has confirmed again, it is
> indeed used a lot, and appreciated a lot). It is not used by MUAs, it
> is used by humans. A typical case is that during a teleconference,
> somebody mentions an email message. That person has that message in
> front of them in their MUA, but want others to look at it too, with as
> little a delay as possible. The best way to do that is to take the URI
> in the Archived-At header and paste it into the IRC channel used for
> the teleconference.
> 
> Another frequent use case is that we maintain a lot of Web pages (e.g.
> about issue resolution, or for minutes of meetings,...) with links to
> archived email messages. To update these, it's often very helpful to
> start with the URI in the Archived-At header.
> 
> In both cases, this is done by humans, not by the MUA. Apart from it
> not being implemented, there wouldn't actually be a need for an MUA
> to follow the Archived-At link, because the MUA already has the
> message itself, in raw (i.e. message/rfc822) form.

As far as I can tell, the major utility in having email readers be
able to use Archived-At would that it would enable email users to
look at other messages in the surrounding context - predecessors to that
message and replies to that message, etc.  You really want a pointer
into a folder.  This would have been immensely useful to me when
I was on IESG, because I was constantly having to dig through list
archives and try to  understand conversations that had taken place and
the circumstances that produced some message or another.

Being able to compare one's own copy of a message with the 
archived version might be marginally useful, but not very often.

There are other cases also.  For instance, a user receives a 
message that has been highly modified in transit - say some of the
attachments have been stripped off by a media filter because the
recipient's cell phone wasn't expected to be able to display 
PDF documents.  I expect this kind of filtering to become more
common in the future as more and more "nontraditional" devices
are used to access email and there is more and more use of email
technology to send faxes and voice mail.  Anyway, archived-at 
would allow the recipient to access an archived/unmodified 
copy of the message.

Thanks for providing concrete explantions of how W3C folks
use x-archived-at.

Keith