ietf-822
[Top] [All Lists]

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

2005-02-21 22:54:33

Maybe not in this mail, but in another one, I mentioned a very
concrete example of why adding type information inhibits
future developments, or inhibits tools taking advantage of
future developments. W3C currently serves archived emails
as HTML only. So with your proposal, we would send out
(X-)Archived-At headers with whatever additional parameter
(maybe no parameter) that means "HTML only". Now there are
actually some developments on making message/rfc822 available,
not only for new messages, but also for old ones.

But the headers have already gone out, and all of them say
"HTML only". This would mean that either we are no longer
very much motivated to make message rfc822 available, because
most people will 'know' that we only serve HTML, or that
we make them available, but they don't get used because
the headers tell the software not to even try (or both).

I'd very much appreciate if you could explain how your
parameter proposal addresses this case.

I would consider those parameters "hints". That is, they're assumed to be accurate at the time the Archived-At field is generated, but may not stay accurate. Implementations would be expected to gracefully handle the case where the hints aren't accurate, and they would also be allowed to "ask" the server for features (other content-types, other messages in the same archive) even when those features were inconsistent with the hints. Also, the hints would be optional.

If you want, think of the hints as a cache of certain resource metadata. They could even include expiry or TTL information.

Now consider two cases: one in which the hints are provided, another in which they're not provided.

In the second case, a client always has to "ask" before it can tell whether or not it can make use of the archived message. That question will typically involve a DNS lookup, a TCP open, and some sort of layer 7 interaction - a HEAD request being the minimum. This can easily take a few seconds on average, and minutes in corner cases where multiple servers have to be consulted. User agent implementors then have to decide whether it's worth the performance hit to offer a feature that has a dubious chance of being useful to the user.

In the first case, the client can still "ask" - but the client might have more information available to it. For instance, the client might compare the current time to the date in the message, and if there's a small delta, assume that the hint is accurate. The client might decide whether to "ask" based on some estimate of available bandwidth. That way, a client operating over a slow modem might trust the hints, whereas a client operating over a broadband connection would ask.

>and failing to provide type information along with the URI is a bad
>idea because it forces the client (and user) to set up a network
>connection before it even knows whether the resources is usable.

Well, in principle yes. But these days, a large number of network
connections are just established (in the sense that the user is
connected to the network), and making e.g. a HEAD request to a
server isn't really a big deal.

When my home DSL connection is working, I don't consider those things a terribly big deal. (though I do often find HTTP referral chains annoyingly slow even then). When my DSL connection fails (as it does fairly frequently lately) and I have to read my mail over a modem, extra HTTP connections do turn out to be a big deal.

Keith