Re: IMAP URL scheme <draft-newman-url-imap-05.txt>

[I am redirecting this discussion as follows:
 1) Adding the IMAP list to get input from IMAP developers
 2) Removing the IESG to reduce their workload, a summary of the 
    conclusion can be sent to the IESG.
 I've quoted the entire context for the IMAP developers.]

On Mon, 17 Feb 1997, Keith Moore wrote:
> Larry Masinter <[email protected]>, wrote:
> > I'd like to review "draft-newman-url-imap-05.txt" against
> > "draft-masinter-url-process-00.txt", as much to ask
> > "are the criteria adequate or too restrictive" as "do imap URLs fit?".
> > 
> > 2.1: syntactic compatibility
> > The only other URL schemes that access "message in repository" are
> > "news" and "nntp". I suppose IMAP doesn't have any way to reference a
> > message by its message ID, although NNTP does by its message number
> > within a news group.
> > 
> > The section 8 exception for "relative IMAP URLs" is just unacceptable.
> > I'm skeptical that "IMAP4 permits the use of any hierarchy delimiter
> > in mailbox names" is a good idea. We avoided this in "file:" and think
> > the same arguments apply here.
> 
> I'm also skeptical about this.  The URL paradigm is to use '/' as the
> hierarchy delimiter regardless of what delimiter is used in the
> protocol itself (or on the file server).  Code that deals with
> relative URLs wants to able to be independent of URL-type.  
> 
> The IMAP URL proposal sort of solves this problem by imposing the
> restriction that you can only use mailbox-relative IMAP URLs for
> mailboxes whose hierarchy delimiter is '/', but this seems like an
> undesirable restriction.  Is this restriction preferable to having '/'
> in an IMAP URL translated to whatever hierarchy delimiter is used by
> the mailboxes?
> 
> For instance, could the IMAP hierarchy delimiter be embedded in the
> IMAP URL itself, say in the character immediately following the '/'
> after the domain name?
> 
> So:
> 
> imap://domain/.#news/comp/mail/misc/
> imap://domain//inbox/Jan97/
> imap://domain/%5COFFICE/SYSTEM/

As far as I'm concerned, URLs and mailbox names are both user interface
elements because they are almost always displayed to the user unmodified.
For this reason, human factors issues are important in URL schemes, at
least for the common formats.

With the current draft, the anonymous archive of the IMAP mailing list is
written as:

	imap://cyrus.andrew.cmu.edu/archive.imap

With Keith's proposal this would be written as:

	imap://cyrus.andrew.cmu.edu/.archive/imap

And in a (non-hierarchical) IMAP client this would appear as:

	archive.imap

The advantage to the current proposal is that the URL is cleaner and
is obvious from what appears in the non-hierarchical IMAP client.  The
advantage of Keith's proposal is that a relative URL of "acap" would
resolve to the "archive.acap" mailing list archive at the same server.

My opinion is that relative IMAP URLs will be quite rare, so the human
factors advantage of the current draft is more important than the improved  
relative URL resolution of Keith's proposal.

However, Keith's proposal is a sufficiently reasonable alternative that I
would very much appreciate input from others.