[prev in list] [next in list] [prev in thread] [next in thread] 

List:       imap
Subject:    Re: RE: Let's standardize "smaller" protocols straw proposal
From:       jem () mystery ! milleredp ! com
Date:       1996-05-17 18:36:48
[Download RAW message or body]

Does it?

You can easily implement a bunch of separate protocol listeners in one NT
service.  You can make it modular by using OLE Automation (if you like pain) or
LoadLibrary() (if you're an old-fashioned moron like me).  It's a matter of
defining how the pieces are going to talk to one another, as much as anything,
and NT is stuffed with IPC mechanisms (so if it ain't always easy it's always
possible).  IMHO if the protocols are all related to one another (e.g. an
integrated SMTP/IMAP/delivery agent package that share common mail-store
engines, all implemented as replaceable DLLs) it makes sense to start/stop them
as a single service. 

I am agnostic on the big/little protocol issue (though I can't see many MUAs
that'd ever do message-management but not mailbox-management and, from the MUA
perspective, I think a single protocol/single connection simplifies things) but
really, really wish multiple protocols would LOOK and BEHAVE similarly so that a
single piece of standardized parser code could be used...

> One thing which remains unclear to me in your proposal - is
> gluing all of these different protocols together.  In order to exchange
> information (e.g. user is authenticated) from one protocol to another,
> you may have to implement several protocols as a single service - which
> in turn runs modularity.
> 
> >----------
> >From:        Mark Keasling[SMTP:makr@winter.airco.co.jp]
> >Sent:        Thursday, May 16, 1996 11:23 PM
> >To:  imap@cac.washington.edu
> >Subject:     Let's standardize "smaller" protocols straw proposal
> >
> >
> >On Thu, 16 May 1996 20:29:04 -0700, John Edward Miller
> ><jem@mystery.milleredp.com> wrote...
> >> It's certainly easier to define and standardize 'small' protocols. 
> >>Certainly a
> >> lot of people have gotten a lot of mileage out of SMTP, POP, etc.  But
> >> implementing a mail SYSTEM on top of small protocols creates quite an
> >>alphabet
> >> stew.  Laying out a soup-to-nuts mail system around IMAP means...let's
> >> see...IMAP4, SMTP, maybe IMSP/ACAP, maybe LDAP, most of which are
> >>syntactically
> >> different enough to require differently structured protocol-handler code,
> >> different authentication mechanisms, etc.
> >
> >This idea has a lot of merit.
> >
> >Straw proposal:
> >
> >If the current crop of protocols were broken up small enough and the
> >common parts
> >distilled and standardized, one would have several standard components
> >with which
> >to build a complete service.
> >
> >For example:
> >     IUAP:  Inet User Authentication P.   - a protocol service shell
> >     IMAP:  Interactive Mail Acess P.     - The small version Mark C in
> >dreams.
> >     IMMP:  Interactive Mail Managment P. - The other 2/3's of IMAP.
> >     ACAP:  Application Configuration Access P. - I think that's what it
> >means.
> >
> >IUAP could include the current IMAP authentication, privacy enhancement
> >and
> >session management commands plus the capability command.  As well as
> >define
> >the basic command syntax.  It would provide a shell in which the
> >service
> >protocols (IMAP, IMMP and/or ACAP) could work.
> >
> >Perhaps then IMAP or ACAP protocol spec could say, "After the session
> >is
> >established and user is authenticated using a standard protocol such as
> >IUAP,
> >these additional commands are available."
> >
> >A server builder would add the modules together to provide whatever
> >service is
> >desired.  A protocol designer could build from a basic well understood
> >base and
> >adding the new commands/functionality that she thinks is needed.
> >
> >A standard user authentication mechanism, session management and
> >command syntax
> >for interactive protocols.  Does anyone else think this would be an
> >interesting
> >development?
> >
> >Makr
> >
> >
> 

-- End original message --

[prev in list] [next in list] [prev in thread] [next in thread]