Date: Tue, 5 Jul 1994 19:18:30 -0400
From: "Steven D. Majewski" <sdm7g@elvis.med.virginia.edu>
Message-Id: <199407052318.AA21928@elvis.med.Virginia.EDU>
To: Chris Newman <chrisn+@CMU.EDU>, imap@cac.washington.edu
Subject: Re: (long) sketch of proposed imap: URL syntax and semantics [TRY AGAIN!]
On Jul 5, 17:03, Chris Newman wrote:
>
> My first reaction is that this seems a bit over-complicated, but I
> suppose most of that can't be helped if you want flexability and IMAP2
> compatibility. Some thoughts:
>
> 1) Since URLs are full-path strings, you should always assume that the
> reference argument to LIST is the empty string, and thus can leave it
> out of the URL grammar.
>
I'm rethinking my whole notion of representing hierarchy in the light
of current discussion on the uri@bunyip.com mailing list. And your
position is one I'm certainly considering. It looks like the easiest
solution. My only hesitation was that I wasn't quite sure what EXACTLY
a "reference" was in the draft.
My assumption was that the role of "LIST reference mailbox" was to
both handle the question of hierarchy ( for example, for clients that
might want to present folders in a hierarchical view. ) [obvious from:]
| A non-empty reference argument is the name of a mailbox or a level of
| mailbox hierarchy.
and to generalize the alternate BBOARD namespace, that, as far as I know,
went pretty much unused in IMAP2. [ implied, I interpreted, by: ]
| It identifies a context in which the mailbox name
| is interpreted in an implementation-defined manner.
"interpreted in an implementation-defined manner" had me worried in the
case that <reference> is not an actual pathname, but something more
symbolic. However, rereading the rest of the paragraph:
| The returned
| mailbox names are canonicalized to a single unambiguous left-to-right
| hierarchy with a single separator character. Any part of the
| reference included in the returned mailbox name SHOULD be in the same
| form as the reference argument and not canonicalized into some other
| form. For example, on UNIX, a reference of "~smith/Mail" should not
| be canonicalized into "/u2/users/smith/Mail".
I read that as a guarantee that 'LIST /PUBLIC/ mailbox' will
return the same thing as 'LIST "" /PUBLIC/mailbox' even if /PUBLIC
is only a symbol internal to the server, and not actually mapped
into the file store. ( Also, looking at the examples, I see that
the hierarchy separator is always the last character of the reference,
which resolves, I think, some of the ambiguities I was anticipating. )
In short: "YES - I think!"
Question: Is "/" a hierarchy separator in IMAP ?
Answer: MAYBE (It depends!)
Question: Is "/" a hierarchy separator in an IMAP URL ?
( in the sense that hierarchy is used in the URL drafts. )
Answer: MAYBE
I would then interpret the "hierarcy delimiter, if it has one" to
mean that "/" in a mailbox name does not need to be escaped.
However:
Q: Does "/" need to be translated to "." in "comp/mail/misc" if
"." is the IMAP hierarchy delimiter ?
( I'ld *like* to say "NO" here, but is that satisfactory to other ?
i.e. I'm changing the 2nd "MAYBE" to a "NO - NEVER". But, I still
don't want to require '%2f' escapes in the mailbox names, and the
uri mailing list seems to want to tighten up that requirement. )
Q: How are "/PUBLIC/mailbox" and "PUBLIC/mailbox" distinguished
in the URL ?
( "imap://hostname//PUBLIC/mailbox" vs. "imap://hostname/PUBLIC/mailbox" ? )
> 2) I suggest you drop use of the "Content-ID" to reference a MIME
> part, and instead just use the part number. By using the part number,
> you can issue a single FETCH, whereas the Content-ID requires an extra
> fetch and search of the BODYSTRUCTURE.
URL's may be constructed by a program ( my gateway, for example, will
return URL's for each message in a list returned by a SEARCH ) or by
a person. Until mail MUA's have the option to include a message by
URL reference, rather that actually inserting the message text, I
expect most will be constructed by hand. So my answer is basically
the same I made to John Gardiner Myers concerning UID's:
#<uid>#<body-part>
will be the preferred way of specifying a message part, especially
when a server/gateway constructs a reference. But
#<mid>#<cid>
should be accepted, because that is likely to be the best handle
available to someone generating a URL "by hand" .
( Besides the practical problem that the U.Washington imap2bis
server does not seem to support UID (so I may have to initially
use sequence number internally on read-only mailboxes), do any
imap user agents show the uid to the user ? )
-- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU> --
-- UVA Department of Molecular Physiology and Biological Physics --
-- Box 449 Health Science Center Charlottesville,VA 22908 --