At 08:27 04/10/29, Bruce Lilly wrote:
>On Thu October 28 2004 16:38, 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.
>Incidentally, Keith's message (which contains no indication that
>it was copied to Martin) is archived at
Keith forwarded it to me separately, probably after realizing
he had dropped me. Thanks for keeping an eye out for this!
>1. Comments: archived at
> The Comments field has been around since at least RFC 724
> and therefore is more likely to be displayed by existing MUAs
> than Archived-At.
I'm not sure. My email client seems to have a tendency to display
unknown headers more easily than known ones. But this is only
a single example.
> A message may contain an arbitrary number of Comments fields.
Yes. One issue is that if there are a lot of comments fields,
the user will have difficulties to choose the right one. It
also makes e.g. selection of which headers to display (in
highly configurable email agents), or assignement of a keyboard
shortcut, and so on, more difficult.
> However, it does not solve the
> problem of the incompatibility with RFC 2046 message/partial.
As far as I'm concerned, Keith's description of the (non-)deployment
of this feature has pretty much solved this issue for me.
> (archived at http://www.imc.org/ietf-822/mail-archive/msg05043.html)
> Parenthesized comments are provided for in Message-ID fields.
> This method puts the archive information in the same place as
> the message identifier,
But Message-ID wouldn't usually be shown by email clients, or would it?
(it's definitely not shown in mine, unless I choose 'display all headers)
Also, I'm concerned about the length of the field. Having separate
fields with reasonably short length seems better than having long
fields squeezing everything in.
> and is fully compatible with message/partial
> fragmentation and reassembly.
Again, as shown by Keith, a non-issue.
>Both methods use existing mechanisms explicitly designed for human
>use. As both methods involve content which is not subject to
>automatic retrieval of content, both avoid the security trap
>implicit in (possibly automated use of) Archived-At.
I hope that my writeup of the corresponding text for the security
section shows quite well that this isn't really something to be
very worried about in practice.
>> 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)
>Accessing such an archive requires access credentials, which
>would have to be communicated (probably possible within
No, not within the URI. That's a very bad practice, much more
of a security issue than your 'automatic download endless loop
denial of service' scenario. What browsers do here is that they
ask for the password on the first use, and also allow users to
store the password. That's in wide use at W3C, because we have
archives only accessible for W3C Members, or for W3C Team.
>> 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.
>There may be a more fundamental issue: IMAP (or NNTP) access
>requires either handling a URI or configuration of the necessary
>parameters which would be conveyed in a URI (host name, port,
>user credentials). Certainly MUAs that provide IMAP client
>functionality could be used without any additional design, but
>the user would need to get the parameters from somewhere and
>configure his MUA(s) accordingly. MUAs don't typically handle
>generic URIs directly (mailto URIs are a notable exception), but
>instead may hand them off to a browser (which in turn might
>invoke an MUA for an imap scheme URI).
Having the MUA invoke the browser, and the browser then invoke
the MUA, for an imap scheme, sounds really weird. Either the
MUA can handle the imap scheme, then it doesn't have to invoke
the browser, but can just handle imap: in the same way as
mailto:. On the other hand, if it doesn't handle imap:, there
is no point to configure the browser to invoke the MUA.
[this leaves the edge case of the MUA invoking the browser,
and the browser invoking another MUA]
What seems more interesting to me is the following: The MUA
finds an http: URI, and invokes the browser. The browser
resolves the http: URI, and fetches a document with media
type message/rfc882. The browser then invokes the MUA to
handle that media type. That way, the browser actually
does some work, rather than just playing ping-pong.
The alternative to that would be to implement http: HEAD
or GET requests, and a table for which application to
invoke for which content type, for the MUA. (and there is
a chance that it would download a text/html document but
would want to invoke the browser with the URI rather
than the document (essentially a local URI), which would
result in double downloads.