Hello Keith,
[sorry it took me more than a day to complete this message]
At 07:27 04/10/27, Keith Moore wrote:
>> As explained in my answer to Charles, I don't want to recommend stuff
>> that I haven't seen implemented.
>
>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.
>> I think making messages available as
>> message/rfc822 is a great idea at least on paper, but in W3Cs case,
>> things are currently working quite well with serving the messages
>> just as HTML,
>
>Apparently you don't expect much from email archives. IMHO you should be
able to do anything with an archived message that you can do with a message
you received in your inbox - read it with any mail reader, reply to it,
forward it (as a message) to somewhere else, search it as if it were a
message, display or save any of its body parts, follow threads to other
messages (including those in your inbox), etc. In addition, HTML has
proven to be a poor format for use in email because of numerous security
risks associated with scripts, objects, and referenced images along with
the expectation that these are invoked or displayed without user consent.
[We are not using HTML for email.]
>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.
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?
Mind you, if I had enough free time, I'd maybe try to do it myself.
I actually agree very much with most of what you are saying, and
I have also been trying to convince our system people to help.
The responses I got so far are things like "on the someday pile,
below a lot of other stuff" and "maybe sounds cool, but we don't
have the resources for stuff that just sounds cool, but where
we don't see any actual use cases". If there were a couple
MUAs that actually could use message/rfc822, that could easily
change.
>> and I don't want to give potential users the impression
>> that they have to support message/rfc822 or they better won't use
>> Archived-At at all.
>
>That's very close to the the impression that they should get. More precisely:
>
>a) those who use archived-at should take pains to archive their messages
faithfully (meaning in the original format) and in such a way as to be
readable by the vast majority of mail readers (i.e. in message/rfc822), and
>
>b) If you want interoperability the last thing you want to do is to
burden email readers with having to support arbitrary formats for archived
messages.
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. The only case
where I can immagine the MUA going to check an archive of a message
it already has is some kind of verification scenario, but I'm not
exactly clear when that would really be needed, and whether there
are not better ways to do that (e.g. digital signatures,...). But
maybe you have some ideas.
This doesn't mean that it wouldn't be a good idea to have the message
available in message/rfc822 form. The main use case I can immagine
at the moment is to respond to a message that one sees in the archive.
Our archives currently have a [Respond] button
(see e.g. http://lists.w3.org/Archives/Public/uri/2004Oct/0017.html),
but that uses the mailto: URI, where it's practically impossible to
squeeze the whole message in. We try to do a reasonable job with
the mailto: URI; for the above message, e.g. it's
mailto:uri%40w3.org?Subject=Re%3A%20editorial%20suggestions%20for%20RFC%202396%20bis&In-Reply-To=<0I5U00G08DFGCR%40mailsj-v1.corp.adobe.com>&References=<0I5U00G08DFGCR%40mailsj-v1.corp.adobe.com>
i.e. it contains quite a bit of information that should allow to
do reasonable threading. But with better MUAs, it could certainly
work better.
I hope that these explanations helps you to understand the actual,
very much in-use and prooven use cases for Archived-At.
Regards, Martin.