>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