At 09:34 04/10/28, Keith Moore wrote:
>
>> >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.
Well, somewhat, but in terms of "rough consensus and running code"
not really.
>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.
It's probably only partially useful for email clients. Indeed Bruce
Lilly makes a rather good point that it is not useful at all for
email clients (he however makes the mistake of thinking that
email clients are everything that counts). It's very useful for
humans. Is there a rule that email headers have to be used by
email clients? As an example, how much is the X-Mailer: header
used my email clients?
>This is
>the normal situation when we're defining a protocol extension.
As far as I understand the way the IETF works, there is often
already some implementation experience. In the case at hand,
this is certainly true.
>And of course native format archives _do_ exist
Good. But the fact that they exist doesn't mean that we have
to try and force everybody to provide them.
>and at least some
>email clients are already able to download files using http and/or
>ftp.
But that's just files in general, yes? Or is is message/rfc882 in
particular? And if the later, what clients would that be?
>so the unimplemented part of this is rather small.
Agreed.
>> >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.)
Mentioning various media types and http content negotiation, I think
it should be quite clear from my draft that there is no particular
expectation one way or another. That's very similar to the HTML
spec not saying what type of document you should find at the end
of an anchor. There is quite some expectation in that case that
that might be another HTML document, but there are lots of other
cases.
Although W3C, as an example, currently does not serve the archived
mails in message/rfc822 format, if we did it, we would certainly
do the right thing to make sure that we would not need additional
headers (e.g. two Archived-At, one for text/html and another for
message/rfc822 format), let alone a new field name.
There is another aspect here: Assume that one of the reasons we
want a message/rfc822 format is for replies to archived messages.
In that case, having a pointer from the actual message to the
archive in order to fetch the message from the archive and then
answer to it seems heavy overkill, because the message is already
available locally and can be replied to directly. So it is possible
to immagine usage patterns where the Archived-At header points to
a HTML version, and that HTML version includes a link to the
message/rfc822 version, for use by people who don't have the
original message. Of course, this is only one possible usage
pattern, the draft doesn't require that at all.
>> 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.
Great!
>I just don't want to wait until that code
>is written and shipped before making comments about your proposal.
You don't have to. My proposal clearly allows message/rfc822 format,
and based on your comments to my -00 draft, it explicitly mentions
that.
What I don't want is to prescribe to archive maintainers how they
should serve their archived messages. If there is a good reason to
use message/rfc822, let them do it. If there is a good reason to
serve as HTML, let them do it. If there is a good reason to use
something else, let them do it. And let them use more than one
of these if they have good reasons for that, too.
>(Actually if we were still using my list software here, I would have
>already done the latter.)
Great!
>Being able to compare one's own copy of a message with the
>archived version might be marginally useful, but not very often.
Agreed.
>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.
Yes, that's another good example.
Regards, Martin.