Hello Keith,
[I have bumped up the number in the subject to the one of the
draft I submitted yesterday.]
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.
At 05:46 05/02/22, Keith Moore wrote:
>
>> As I pointed out in a separate message, providing type information
>> with an URI is a bad idea because it inhibits future developments.
>
>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.
>more to the point, behind the desire to avoid providing type informtion
>is an implicit (and false) assumption that HTML content is usually
>sufficient.
I can very clearly tell you that this is not the case.
I'm trying to get the W3C list archives available in message/rfc822.
I hope you'll contribute to making our common vision a reality,
e.g. by working on a mailer so that it accepts message/rfc822
messages (via the 'open this file' 'protocol' of the OS) or can
download them directly.
Regards, Martin.