ietf-822
[Top] [All Lists]

Re: the gap regarding Archived-At

2004-10-30 12:42:35

On Fri October 29 2004 03:42, Martin Duerst wrote:

Yes. One issue is that if there are a lot of comments fields,
the user will have difficulties to choose the right one.

The same could be said of archived-at and x-archived-at.

 > 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.

Keith did not say that the feature was not deployed, he said that
he could not recall having seen individual fragments recently.

 >2. Message-ID:
 >      
<20041028163850(_dot_)32868cae(_dot_)moore(_at_)cs(_dot_)utk(_dot_)edu>
 >      (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?

That's an MUA implementation issue. Not incidentally, using
a comment associated with msg-id provides for additional
functionality (consider the comments remaining associated
with msg-ids in In-Reply-To and References fields).

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.

Why?  Overall, there is less bulk w/o the additional CRLFs and
"Archived-At:".  Fields may be folded; field length is not an
issue.

 >  and is fully compatible with message/partial
 >  fragmentation and reassembly.

Again, as shown by Keith, a non-issue.

Again, you're reading too much into his remarks.

 >Accessing such an archive requires access credentials, which
 >would have to be communicated (probably possible within
 >the URI).

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

Whoa; who said anything about a password? I was referring
to the user name which various schemes and protocols
require.

Having the MUA invoke the browser, and the browser then invoke
the MUA, for an imap scheme, sounds really weird.

Do you know of any MUAs that directly handle IMAP URIs?
Do you know of any IMAP URI-handling browsers that can
reply to messages (rather than invoking a separate MUA)?

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:.

A mailto URI specifies a new message, which is a completely
different thing from an imap URI.  So thay cannot be handled
"in the same way".

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]

Or an IRC client invoking a browser, which invokes an MUA.
It depends on how one receives the URI.
 
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.

I don't see how changing "http" to "imap" in that description
is substantively different.