[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the gap regarding Archived-At
At 05:38 04/10/29, Keith Moore wrote:
>okay, I find myself coming to some somewhat uncomfortable conclusions:
>1. There really are significant differences between
> a) how email clients would use archived-at,
> b) how humans would use it to cut-and-paste into HTML, and
> c) how web browsers would use it.
I'm not really sure about the difference between b) and c), or
about c) as such. If you put an URI into an href attribute in
HTML, then ultimately, it will be used by a browser, anyway.
> These differences are significant enough that I'm wondering if we
> really do want separate archived-at fields for web use and email use,
> or tags on the archived-at field that indicates whether the message
> is in original format and/or if other messages in the same collection
> can also be accessed.
>2. For archived-at to be useful by email clients generally requires
> one or two of the following, in addition to the obvious client
> support for the protocol and server support for the message format:
> - mail archives that support IMAP access (or possibly NNTP)
My understanding (not being an IMAP expert) is that this would
not be too difficult. However, I can't see W3C to do that any
> - a specification for making collections of mail messages available
> via HTTP (maybe WebDav) and/or FTP
I'm not sure I understand this. List-Archive: points to a full
list archive. Archived-At: points to a single message. It seems
to me you either have the two confused, or what you want is really
a format (or similar) that not only contains the actual message
(message/rfc822 or equivalent), but also some additional context
(that WebDav may be able to give you with some properties, for example).
Please note that any kind of inference from the actual URI to
other URIs should be avoided, i.e. it would be a bad idea to
say that if Archived-At contained
we may assume that things like
are somewhat related (by being in the same mailing list,
> - mail archives that follow the aforementioned specification
> and as much as I'd like to believe that email client vendors would
> enthusiastically add support for these, market conditions don't seem
> to favor supporting new functionality standards in email clients
> right now.
Sad but true.
>3. The obvious compromise that makes sense in the short term (let
> archives be in other formats besides message/rfc822, and don't
> require message/rfc822 support) is harmful in the long term.
Why? If there is uptake on mailers with such support, it's not
too difficult to also upgrade the servers.
>4. There's a real tendency for the web to degrade other services.
> Partly this is because it's easy to prototype new services using
> the web, and partly this is because once those services are
> prototyped, the limitations of web browsers, HTTP, and HTML
> impose a more significant barrier to the functionality that
> can be supported than existed in the original environment.
I'm still not sure I understand how serving a message as HTML
would inhibit serving it later as message/rfc822 (or whatever)
also. Maybe what could be pointed out in the draft is that
rather than using a full URI with (e.g. .html) extension,
a shorter URI that allows to more easily introduce
content negotiation later is preferable.
>Best compromise I see at this point: Define some sort of
>keywords for archived-at. e.g.
>Archived-at: "<" URI ">" *(";" keyword [ "=" value ] )
>where keywords might include
>"native" message available in native message/rfc822 format
> (either because that's the only format available
> at this URI or via content-negotiation)
>"collection" other messages in the same collection are also
> accessible, where the collection is defined by
> the IMAP folder, NNTP newsgroup, FTP directory,
> WebDav collection, etc. indicated by the URI.
> the value associated with this keyword would
> indicate the name of the collection associated
> with the URI (since a message might appear in
> more than one collection)
Ah, I see, so there would essentially be two URIs, one for
the message itself, and one for the collection.
>This would (a) let tools record locations of ordinary HTTP/HTML archives
>such as are (too) often the only format available today,
What would the keyword be for that case?
>archives to provide messages in their original format without requiring
>them to do so, (c) give implementors a hint that better functionality
>can be had, (d) give email readers a clue as to whether they could
>actually make use of the URI internally or whether they needed to pass
>it to a separate browser (this is a common problem in HTML also)
Well, this is solved on the level of media types, not URIs, for
>leave room for expanded functionality without needing to define a new
>header field. And if you don't use any keywords, they don't take up
>It might be better to defer the definition of any keywords to a
>separate document, because I can imagine needing to define specifics
>of how collections look within the context of various protocols.
>I can also imagine needing to define things like collections that
>consist of a directory of several mbox files, each containing
If that would mean that the only change to my current draft
would be something like "there may be keywords, but currently,
there are none defined", then I probably could live with that.
But I'm still not convinced that we need keywords, things
should work without them.