Message-Id: <Ei6gxNC00WBwMLMQU0@andrew.cmu.edu>
Date: Wed, 6 Jul 1994 11:35:53 -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: <199407060526.AA14897@elvis.med.Virginia.EDU>
"Steven D. Majewski" <sdm7g@elvis.med.virginia.edu> writes:
> On Jul 5, 22:51, John Gardiner Myers wrote:
> >
> > >( 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.
> >
>
> I'm NOT redesigning the IMAP protocol.
The IMAP protocol defines the format of the MIME structure
information. You are proposing that this information when referenced
by URL be in a different format than that designed by the IMAP
developers. Thus, you are redesigning the IMAP protocol and you are
giving no real reasons for doing so.
> Yes. Well - I know what my requirements are.
> The question is whether the mapping that I will implement
> is acceptable for a standard.
The message-number mapping you define is useful in only a very limited
subset of the possible cases and is dangerous when mis-used in other
cases. Other mechanisms, such as searching by message-id, are
sufficient for handling your requirements.
> > The semantics of "#mid:<message-id>" is a search. It should have the
> > URL syntax of a search.
>
> Again: the purpose of the URL is not to be a one to one mapping of
> the protocol. The function of both are quite different. There is no
> reason for the semantics to be identical.
The function of "#mid:<message-id>" is a search. You are searching
for a message with a given "mid". There can exist an arbitrary number
of messages which match any given criteria.
> > 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.
>
> However, I don't think you actually want to read the Base64 encoding
> of a audio file or a Gif inline.
Why not? If you ask for it, you should get it.
> In fact, current IMAP
> are not required to display the entire message.
URL's are not required to reference the entire message.
> Pine (I think) only
> displays the first part, and displays an indicator to the other parts.
Pine does this by first fetching the MIME structure information for
the message, then fetching the parts it wants.
In IMAP, if you ask for the entire text of the message, you get the
entire text of the message, be it multipart or no.
> The above is my reading of the *direction* of consensus. Early drafts
> seem to state clearly that everything after the scheme: is opaque.
> Later drafts seem to hedge and qualify this. Recent discussion on
> uri@bunyip.com seems to be favoring making more of the syntax globally
> defined. ( e.g. "?" ALWAYS indicates a query string. )
Well, I'm not a URL weenie, but I certainly think having the syntax be
globally defined instead of opaque is insanity. Why bother having
different "scheme:"s, then? Conventions are one thing, absolute
requirements are another.
It is possible to define IMAP URLs such that the mailbox name is
completely opaque and no characters in there need to be escaped. One
just needs to define selectors such that they can be unambiguously
parsed by searching from the right.
> But I still think they are acceptable with the proper caveats.
Loaded guns with the safties removed are acceptable with the proper
caveats. People ignore the caveats and end up shooting themselves in
the foot anyway.
message-number based URL's are an attractive nuisance.
> I would, though, consider the fact that *I* need sequence numbers
> right *NOW* as a weak argument for writing them into a standard,
You could use message-id searches instead. They're a lot safer than
message-numbers.
-- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up