|
Re: New Internet Draft: draft-duerst-archived-at-00.txt
2004-10-28 06:41:07
>> 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.
This seems to be a frequently-misunderstood phrase. The "running code"
part is supposed to happen _after_ the specification is written (as in,
before we advance to draft standard). It's often taken to mean that
IETF should standardize things that were developed on an ad hoc basis,
which I don't believe to be the intent.
>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
And I've described a couple of ways that it could be useful for email
clients.
Is there a rule that email headers have to be used by email clients?
no. But it seems suboptimal to define a header field that _could_ be
useful for email clients, in a way that is not very useful for email
clients.
>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.
"Force" is a strong word, since we have no police force. "Encourage"
or SHOULD would be more appropriate. To me the purpose of an archive
is preservation, and it makes little sense to preserve messages in a
format that takes up more space and is less functional than the
original when the original format is widely supported.
To look at it another way, part of the conflict exists because web
browsers support message/rfc822 so poorly, and part of it exists
because vanilla HTTP (as implemented in web browsers) doesn't have much
support for dealing with separate resources that are part of a
hierarchal, sequenced collection. So this stuff gets pushed to HTML,
which has several undesirable effects. One is that the original form
of the document is no longer preserved, and some of the semantic
information from that format is lost or mapped to less functional forms
such as "next in thread" buttons. or if it is preserved, it's buried
(e.g. the message/rfc822 is conveyed in a frame), and the URI of the
resource no longer refers to the actual resource. it's really a huge
limitation of the web as it is currently implemented. What I don't
want to do is to burden email with the web's limitations. (email has
enough limitations of its own to overcome)
Also the experience with use of arbitrary URIs in the List-* fields
does not seem favorable. Even though they're supported by list
software, they're not in my experience widely supported by email
readers, even when those email readers recognize URIs in other
contexts. Lots of people seem to think that "reply to list" would be a
useful function, but it's awkward to use List-Post for this purpose
because it doesn't necessarily point to an email address (though it
does seem feasible for the email reader to check: "is there a mailto:
URI that doesn't fill in the header fields or message body?" and if so,
use that for reply to list). Perhaps this doesn't bear directly on
Archived-At but it does indicate to me that just putting URIs in header
fields may not be as functional as we'd like, and part of the reason
might be that email user agents can't use them. Or maybe the problem
is just that market conditions have killed innovation in email readers
so even trivial fixes like "display List-* fields and make their URIs
clickable" don't happen.
>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?
I was thinking in terms of message/external-body support, which was
implemented in mh and is also supported by metamail. It applies to any
content-type. I'm not claiming that it's widely supported, only that
it has been implemented, so it's clearly feasible.
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.
In a way I think this is correct. But I also think that realistically
implementors will "just provide HTML" unless given guidance to do
otherwise, which will make this field far less functional in practice.
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.
My mention of a new field name comes from the following scenario:
Archived-At is implemented so widely to be "just HTML" that this
becomes the de facto expectation. Mail readers tend to not implement
it, or to just use it to launch a web browser, because it's rarely in a
format that can be used effectively by the mail reader. Eventually
someone realizes that it would be very useful to have a way for email
messages to refer to archived messages within a collection. But they
can't use Archived-At for this purpose because it's so likely to point
to an HTML document rather than an email message that supporting it
will just annoy users.
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.
Yes but that's awkward in several ways. One is that you need a
different name for the rfc822 version of the resource than for the html
version of the resource. Another is that the email reader now needs an
HTML viewer just in order to access the native version of the message.
Again, I think the real utility with this field and email readers is
being able to use that message as a starting point to browse a
collection. They are as likely to perform operations (like replies,
refiles, forwards) on other messages in that collection as they are
with the original one.
Keith
|
|