- dan
-----Original Message-----
From: Chris Newman [mailto:Chris.Newman@innosoft.com]
Sent: Thursday, 1999-01-28 11:33
To: FoRK@xent.ICS.uci.edu
Subject: Application "core protocol" BOF/WG idea
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.
In order to keep the WG in focus, the following items are explicitly
out-of-scope:
* Backwards compatibility with existing application protocols
Backwards compatibility often compromises correct design. If this
WG is successful it will impact a great number of future protocols,
and thus the design errors which backwards compatibility might
dictate must be avoided.
* Transport layers other than TCP/IP
This has been a rathole in too many other WGs.
* New features
If a problem hasn't been solved in at least two deployed IETF
application protocols, then it doesn't need to be addressed in the
core protocol spec. This does not preclude individuals or other
groups from doing extensions to the core protocol which might be
used by multiple future application protocols; it just limits the
scope of the core spec.
* Normative references to other application protocols
The core protocol has to stand by itself. It may reference protocol
building blocks that have been used by several other application
protocols such as ABNF, language tags, UTF-8, domain names, URLs,
MIME, SASL, GSSAPI and TLS. It must avoid normative references to
full application protocols such as ACAP, HTTP, IMAP, LDAP, and SMTP.
The WG will produce the following output:
* An Informational RFC documenting the problems identified to solve,
and giving examples of existing deployed IETF protocols which
succeeded or made mistakes when solving those problems. A starting
list of problems for the WG to discuss (the WG may choose not to
address some of these) follows:
* 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)
* A simplicity litmus test to determine if a proposal is acceptably
simple. The initial litmus test will be: core protocol spec is less
than 25 pages.
* A standards track core application protocol specification which uses
the lessons learned from the informational document and fits the
litmus test above. An open source implementation of the complete
core protocol must exist prior to IETF last call.
The WG may solicit strawmen for the core application protocol from
multiple document editors and select the one which is technically
best and fits this charter.
The WG may choose to do additional standards track documents which
extend the core protocol as long as they are not new features by the
above definition.
The WG may choose to do one or more APIs for using the core protocol
and adding commands/extensions to it. These might be informational
or standards track as deemed appropriate.