# Re: (long) sketch of proposed imap: URL syntax and semantics [TRY AGAIN!]

John Gardiner Myers (jgm+@CMU.EDU)
Tue, 5 Jul 1994 22:38:01 -0400 (EDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: pays@faugeres.inria.fr: "Re: New URC Specification is ready...."
- Previous message: John Gardiner Myers: "Re: (long) sketch of proposed imap: URL syntax and semantics [TRY AGAIN!]"
- In reply to: Steven D. Majewski: "Re: (long) sketch of proposed imap: URL syntax and semantics [TRY AGAIN!]"

    Message-Id: <oi6VY9O00WBw8QtIEQ@andrew.cmu.edu>

    Date: Tue,  5 Jul 1994 22:38:01 -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: <199407052318.AA21928@elvis.med.Virginia.EDU>

"Steven D. Majewski" <sdm7g@elvis.med.virginia.edu> writes:
> 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:]

The role of the "reference" is to allow servers to expose "relative
name" semantics to clients. The "reference" is of no interest to
URL's.

> "interpreted in an implementation-defined manner" had me worried in the
> case that <reference> is not an actual pathname, but something more
> symbolic.

Depends on what you mean by "actual pathname" and "symbolic". There
is a namespace exposed by the server, that namespace need not have any
correlation to any particular namespace (such as a filesystem) used by
the server implementation.

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

No such guarantee. LIST /PUBLIC/ mailbox can return "mailbox" or even
"blurdybloop".

> ( Also, looking at the examples, I see that
> the hierarchy separator is always the last character of the reference,

Not necessarily the case.

> Question: Is "/" a hierarchy separator in IMAP ?
> Answer: MAYBE (It depends!)

Same answer as ``Is "x" a hierarchy separator in IMAP ?''
The specific character "/" is not special in the IMAP protocol. It
might or might not be in mailbox names. It might or might not be a
hierarchy separator for some subset of mailboxes on the server.

> I would then interpret the "hierarcy delimiter, if it has one" to
> mean that "/" in a mailbox name does not need to be escaped.

I would suggest treating the last "/" (or "#" or "?", depending on
definition) as separating the mailbox name from the "selector". Leave
all characters in the mailbox name as uninterpreted.

IMAP mailboxes are also likely to have a "#" character in the name.

> Q: Does "/" need to be translated to "." in "comp/mail/misc" if
> "." is the IMAP hierarchy delimiter ?

No, just use the mailbox name "comp.mail.misc" in the URL.

> ( "imap://hostname//PUBLIC/mailbox" vs. "imap://hostname/PUBLIC/mailbox" ? )

Looks good to me, except you want a trailing "/" (or "#") to avoid
ambiguity between mailbox names and "selectors".

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

Your syntax, however, makes "message-number" the preferred form.

Message numbers are explicitly allowed to change between sessions.
They only appear to remain constant in certain limited cases. Their
use is dangerous-- if/when they do change, someone using a stale
"message-number" reference will likely get the wrong message, not an
indication that the reference is invalid.

Message numbers in IMAP URL's are analogous to FTP URL's which specify
"give me the third file in the listing for this directory".

> ( Besides the practical problem that the U.Washington imap2bis
> server does not seem to support UID

The IMAP4 document was only recently completed, not everyone has had
time to implement it. Within a year, servers which do not support UID
will be considered obsolete.

- Next message: pays@faugeres.inria.fr: "Re: New URC Specification is ready...."
- Previous message: John Gardiner Myers: "Re: (long) sketch of proposed imap: URL syntax and semantics [TRY AGAIN!]"
- In reply to: Steven D. Majewski: "Re: (long) sketch of proposed imap: URL syntax and semantics [TRY AGAIN!]"