Subject: c-client network mailbox syntax

From: Mark Crispin <[email-masked]>
Date: Tue, 23 Mar 1993 11:33:56 -0800 (PST)

In the present c-client, network mailboxes are accessed with the following
syntax for their names:
 {host}mailbox		mailbox on host using IMAP
 {host:port}mailbox	mailbox on host using IMAP on this port instead of 143
 *{host}bboard		bboard on host using IMAP
 *{host:port}mailbox	bboard on host using IMAP on this port instead of 143
 [host]mailbox		mailbox on host using POP (future)
 *[host]bboard		bboard on host using NNTP
The notion is that {} refers to IMAP whereas [] refers to the older protocols.

It has been proposed that the last two become instead:
 {host/POP2}mailbox
 *{host/NNTP}bboard
That is, that slash followed by a service name identify an alternative service
instead of IMAP.  The default would, of course, be IMAP.

Advantages:
 . possible elimination of confusion over the meaning of [] vs {}.  It's felt
   that if users encounter this they would be seriously confused.
 . possible future extensibility.
 . fewer special characters in mailbox names.
 . simpler top-level rules, at the cost of more complex rules for {}.

Disadvantages:
 . *{host/NNTP}bboard is arguably as mystical to users as *[host]bboard.
 . silly concepts such as *{host/POP}mailbox or {host/NNTP}bboard would exist,
   whereas they don't exist now.
 . extensibility arguments assume that anything we plan now would be at all
   suitable for a future mechanism.
 . it is necessary to state a protocol name, whereas before the protocol was
   inferred from the syntax.
 . more work for name parsers; they can't just grab things starting with { or
   [ any more.

There has been a long, drawn out argument on this that finally ended with a
general recognition that either one was arguably ``cleaner and better'' than
the other.  There is no clear technical superiority of one over the other;
also, it can be reasonably argued that it is an implementation detail that can
be hidden from users no matter what syntax is used.

I'll state flat out: I like the current scheme.  It's nice and tight with no
loose ends, and it doesn't create silly cases (those of you will remember from
the MIME WG that I *hate* silly states).  But if the majority favors a change
to the proposed format, I'll go along.

So, if you have any feelings either way (or even if you don't particularly
care), please share them.  We do need to commit one way or another soon.

-- Mark --

---

From: Terry Gray <[email-masked]>
Date: Tue, 23 Mar 1993 13:25:12 -0800 (PST)

> There has been a long, drawn out argument on this that finally ended with
> a general recognition that either one was arguably ``cleaner and better''
> than the other.  

Gosh Mark, my recollection was that there was only one person in the room
who thought using { } and []  (with/without * ) was "cleaner and better"! :)

> There is no clear technical superiority of one over the
> other; also, it can be reasonably argued that it is an implementation
> detail that can be hidden from users no matter what syntax is used. 

As John Meyers once pointed out, internal syntax has a nasty habit of
creeping out and becoming user-visible!

-teg

---

From: Bill Yeager <[email-masked]>
Date: Tue, 23 Mar 1993 14:26:26 -0800 (PST)

>I'll state flat out: I like the current scheme

I too think the current scheme is sufficient. 

Bill

---

From: "David Herron" <[email-masked]>
Date: Tue, 23 Mar 93 14:50:12 PST

IMO, using `*' to distinguish a `bboard' is pretty silly.

So why not unify on something like

	{host/access-method}mailbox-idenifier-string

Or

	{server/bboard}sf-lovers
or	{server/nntp}rec.arts.sf

This means that a mailbox-access-method would provide a `type name'
along with the function pointers.

The users shouldn't be seeing these strings anyway.  Even {host}mailbox
is pretty ugly.  The software should be encapsulating representation
details like this and providing them a way to specify "host" and "mailbox-name"
and it takes care of munging up the right strings.

To me specifying the protocol by syntax is a big disadvantage to the current
encoding.  It greatly limits the number of available protocols because for
every one you have to invent a new leading character.  With the proposal
above there is one syntax which you parse to find the appropriate server code.

<- David Herron <[email-masked]> (work) <[email-masked]> (home)
<-
<- "That's our advantage at Microsoft; we set the standards and we can change them."
<- Karen Hargrove of Microsoft quoted in the Feb 1993 Unix Review editorial.