My preferred approach would be to give archived-at the same parameter
list that MIME fields have, and define a "content-type=x/y" parameter
naming a type expected to be available. For a list that provides
archives in two forms and uses fancy HTTP to provide the right one,
the field could be like this:
Archived-At: ...; content-type=message/rfc822, content-type=text/html
For a less fancy archive providing both forms under separate URLs, two
Archived-At fields could be used:
Archived-At: ...; content-type=message/rfc822
Archived-At: ...; content-type=text/html
I think this is needlessly complex. Just provide the archives in 822
format. It's not as if existing archivers are going to be used without
changes anyway - some modifications are going to be necessary in any
event to add the new header field to outgoing messages. If those
archives don't already keep a copy of the message in original format,
it's trivial to add code to do that. (sometimes they do keep a copy of
the message in original format because it's easier to rebuild "next in
thread" style links from original messages than from HTML messages).
Keith