FW: Application "core protocol" BOF/WG idea

I imagine not everyone on this list is on the 'discuss@apps.ietf.org'
group; it seems there is another source of focus and input, though, on the
application-layer requirements for HTTP-NG.

-----Original Message-----
From: Ted Hardie [mailto:hardie@equinix.com]
Sent: Thursday, January 28, 1999 10:32 AM
To: Chris Newman
Cc: discuss@apps.ietf.org
Subject: Re: Application "core protocol" BOF/WG idea


Chris,
	I think a BOF on the topic is a good idea.  My first take is
that simply identifying all of the common problems that application
protocols need to solve would be a big win and a big enough task that
a short-lived working group on just that would be great.  I don't have
enough of a sense of what problems future protocols will be solving to
know whether the best approach is to create a "generic" protocol or to
provide framework elements for solving the usual problems (like the
mandatory-to-implement authentication issue).  I know that the W3C
group which is doing the "HTTP-NG" work has the view that a new common
protocol would have advantages.  Like you, they have also explictly
ruled out backwards compatibility as a design requirement (which means
their work actually doesn't have a lot to do with the current HTTP
1.1).  You might want to talk to them about participating in this
effort.  Jim Gettys would probably be the best contact there.
			regards,
				Ted Hardie







> 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.
>
>

Received on Thursday, 28 January 1999 15:25:22 UTC