Date: Wed, 6 Jul 1994 10:47:22 -0400
From: "Steven D. Majewski" <sdm7g@elvis.med.virginia.edu>
Message-Id: <199407061447.AA19413@elvis.med.Virginia.EDU>
To: John Gardiner Myers <jgm+@cmu.edu>, imap@cac.washington.edu
Subject: Re: (long) sketch of proposed imap: URL syntax and semantics
On Jul 5, 22:51, John Gardiner Myers wrote:
sdm7g> A search string that results in a single message is treated as a list
sdm7g> containing a single message. Although access by message-id is
sdm7g> implemented by an imap SEARCH command, the different syntax indicates
sdm7g> that it is to be treated as exactly specifying one message.
sdm7g> ( i.e. the semantics of mailbox#mid:<message-id> and ( the escaped
sdm7g> 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.
>
I would *like* it to be obvious from the URL whether a message or a list
of messages was the expected return object. But I do see some possible
problems: even if the mid: scheme used is DEFINED to be unique, it is
possible that a search would turn up two or more copies. ( By
crossposting to imap and uri mailing list, and BCC-ing myself, I
managed to get 3 messages in my INBOX with ( I assume, I didn't
actually check before deleting duplicates) the same message ID.
Date *IS* the same. Will mid: URL's be defined to be more unique than
that ? )
So, perhaps it is better to leave the semantics undefined.
sdm7g> It is allowed for Multipart MIME messages to return the parts in some
sdm7g> 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.
>
Which (leaving the semantics undefined) would be in line with the
remarks I made in the previous reply about IMAP client action for
multipart MIME messages being undefined by the IMAP protocol.
I am still temped to insert *something* about "reasonable semantics"
here, but, in fact, once left undefined, it's hard to find a reasonable
hook on which to hang that temptation! There may, in fact, be reasonable
clients that, in some context will use
URL:imap://hostname/mailbox?subject%20imap
to fetch and concatenate in some view, all of the matching messages.
So: I give up on "reasonable semantics" , but I'm still resisting
giving up "mid:" and "cid:" specifiers and using ONLY search strings.
Again: the point is not to duplicate the imap protocol, but to provide
LOCATORS that *use* the imap protocol, and I think message-id and
content-id are too useful as locators to throw away.
-- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU> --
-- UVA Department of Molecular Physiology and Biological Physics --
-- Box 449 Health Science Center Charlottesville,VA 22908 --
[ "Cognitive Science is where Philosophy goes when it dies ...
if it hasn't been good!" - Jerry Fodor ]