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

> 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