Re: Application "core protocol" BOF/WG idea

At 09:31 28/01/99 -0800, Chris Newman wrote:
>I'm interested in feedback on the following BOF/WG idea.  Do you think
>this is a good/bad idea?  Any suggestions to improve the proposed charter?
>Anyone interested in being a document editor of either of the two
>proposed documents or interested in WG chair/co-chair position?
>
>		- Chris
>------
>The APPLCORE BOF will discuss the following proposed charter:
>
>Application core protocol WG  (APPLCORE)
>
>The IETF has traditionally developed application protocols directly on top
>of a raw TCP stream.  However, there is a growing set of problems which
>many application protocols have to solve regardless of what the protocols
>do.  This WG will identify these problems, identify the successes and
>failures that deployed IETF protocols made when addressing these problems
>and design a simple core protocol to address these problems.  This core
>protocol may then be used by future application protocols to simplify both
>the process of protocol design and the complexity of implementing
>multi-protocol servers.

While I applaud the general intent, I echo other concerns that the goal is
too ambitious.

Specifically, I find the idea that we can "design a simple core protocol to
address these problems" is something of a tall order.  What I do think may
be achievable is to identify a range of problems, and then make
recommendations about solutions to these.

Your reference a number of areas that may be considered:

>  * connection user authentication and privacy (e.g., SASL and STARTTLS)
>  * server capability/extension announcement (e.g., SMTP EHLO)
>  * extensible command/response syntax and structure
>  * error status tokens and human readable error text issues
>  * syntax for transfer of large (multi-line) objects (e.g., dot-stuffing,
>    length counting, chunking)
>  * multiple commands in progress at the same time (command ids or tags)
>  * unsolicited server messages
>  * command pipelining (sending multiple commands without waiting for
>    responses)
>  * Structured data representation (e.g., RFC 822-style AV pairs, IMAP
>    s-expressions, LDAP ASN.1, XDR, etc) in command/response syntax.
>  * low bandwidth support (e.g., compression layer or packed binary
>    protocol encoding)
>  * connection shutdown (QUIT/LOGOUT command)

I would add object security (e.g. S/MIME, openPGP),

For each of these there may be one or more preferred solutions.  I think
the detailed specification of technical solutions should be separated from
a document that makes recommendations about how these may be effectively
used together to create new application protocol.

To the maximum extent possible, existing protocols should be used.  With
few exceptions, what remains is, I think, a statement of how these are
combined to create a new application protocol.

So, instead of "core protocol", how about "core protocols"?

#g


------------
Graham Klyne
(GK@ACM.ORG)

Received on Friday, 29 January 1999 08:57:32 UTC