Message-Id: <Ei6VkXu00WBw8QtItX@andrew.cmu.edu>
Date: Tue, 5 Jul 1994 22:51:15 -0400 (EDT)
From: John Gardiner Myers <jgm+@CMU.EDU>
To: imap@cac.washington.edu
Subject: Re: (long) sketch of proposed imap: URL syntax and semantics [TRY AGAIN!]
In-Reply-To: <199407012225.AA15850@elvis.med.Virginia.EDU>
"Steven D. Majewski" <sdm7g@elvis.med.virginia.edu> writes:
> Publicly exchanged URL's would, I expect,
> typically point to mailing-list archives, and would typically
> be read-only access. Public archives might typically grow
> but not shrink, so sequence number, while not the preferred
> method, would work as well as most other URL's.
You're making a whole lot of assumptions here.
> A search string that results in a single message is treated as a list
> containing a single message. Although access by message-id is
> implemented by an imap SEARCH command, the different syntax indicates
> that it is to be treated as exactly specifying one message.
> ( i.e. the semantics of mailbox#mid:<message-id> and ( the escaped
> version of) mailbox?text message-id: <message-id> are different. )
It is possible for multiple messages in a mailbox to have the same
message-id.
The semantics of "#mid:<message-id>" is a search. It should have the
URL syntax of a search.
> It is allowed for Multipart MIME messages to return the parts in some
> symbolic form than requires further dereferencing.
If you want the symbolic form of a multpart MIME message, you should
have to ask for it explicitly. If you just ask for a message, you
should get the text of the message, be it multipart or not.
>( But it should be
> something less raw than just the S-expr returned by FETCH BODY or
> BODY.STRUCTURE. [...] something humanly readable.)
Why? You're redesigning the IMAP protocol here.
-- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up