RE: Application "core protocol" BOF/WG idea

All,

I think we should also look into why earlier attempts have failed.

RFC 1831 defines a working RPC mechanism, which could potentially have 
been used by multiple application protocols but wasn't.

The IPP WG looked at this as an alternative to using HTTP, but came to
the conclusion that there were few if any implementations of RFC 1831,
and it was certainly not "on everybody's desktop" like HTTP.

Do we know why RFC 1831 was never picked up by the market place, and
how we can avoid making yet another generic application protocol,
that does not get implemented?

(I expect to hear complaints from all of you who actually have 
implemented RFC 1831 :-)

Carl-Uno

> -----Original Message-----
> From: Chris Newman [mailto:Chris.Newman@INNOSOFT.COM]
> Sent: Thursday, January 28, 1999 5:03 PM
> To: discuss@apps.ietf.org
> Subject: Re: Application "core protocol" BOF/WG idea
> 
> 
> Rough concensus appears to be heading in the direction of 
> liking part or
> all of this proposal (including three voluteers for WG chair 
> or document
> editor positions) and I have yet to hear a compelling 
> negative response. 
> But rough concensus is not yet sufficiently clear, so please 
> continue to
> express your opinions.  Here are responses to the general concerns
> expressed so far: 
> 
> > The task is too big and should be constrained to the
> > problem-identification and history document.
> 
> If it's useful identifying the problem, then it's also useful 
> to propose a
> solution.  Futhermore, if you constrain the working group to the point
> that it doesn't have a product which is sufficiently compelling to
> motivate participants to work, then the effort will die.  While the
> history/problem-statement document would be interesting and useful, I
> doubt it is sufficient by itself to motivate active participation.
> 
> My motivation stems from my realization that the IETF usually 
> can't say
> "no"; it can only say "use this instead", "take your proposal 
> elsewhere"
> or "fix this problem in your proposal".  There are people who wish to
> layer unrelated new protocol services on top of a 167 page 
> HTTP protocol
> because they think it gives security and MIME labelling "for free."  I
> can't argue with an honest desire to simplify the task of 
> specifying new
> protocols, so I want to see a significantly simpler "use this instead"
> candidate.  The engineer in me is willing to expend a lot of energy so
> that future IETF protocols are simpler and cleaner.  Remove the "core
> protocol" task and you remove my motivation and probably that 
> of several
> others.
> 
> > Isn't this what HTTP-NG is doing?
> 
> No.  HTTP-NG has a much larger scope than this proposal.  On 
> the high-end,
> the HTTP-NG name implies it's a replacement for a high-level hypertext
> transfer application, and is thus out-of-scope for this 
> proposal.  On the
> low-end, HTTP-NG met as an IETF "transport area" WG, which indicates a
> focus at a much lower level than this proposal permits.  This 
> proposal is
> very narrow so it only addresses those problems we (in the 
> applications
> area) have solved before and have operational experience with.
> 
> > Isn't this a research project?
> 
> No.  The proposed charter explicitly rules out-of-scope anything that
> hasn't already been done in a deployed IETF protocol.  The fact that
> people think this might be a research project or as broad as 
> the HTTP-NG
> work suggests the proposed charter needs to be tightened up 
> further, so I
> have clarified the initial paragraph to reflect.
> 
> > Let's do this in a strict sequence of steps
> 
> I have revised the proposed charter so the "core protocol" 
> proposal can't
> go to IETF last call until the "history/problem statement" 
> document has
> been completed.  However, I think it's a bad idea to attempt to do a
> problem statement and requirements without doing a prototype 
> solution in
> parallel -- otherwise the problem statement and requirements 
> may not be 
> grounded in reality.
> 
> 
> I have also added a couple other constraints to the proposed 
> charter to
> address other concerns which were expressed. 
> 
> 		- Chris
> 
> ------APPLCORE proposed charter V2
> 
> 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 the common problems that deployed
> IETF protocols have solved, 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.
> 
> * Protocol models outside the traditional IETF client-server TCP
>   application protocol model.
>   The IETF doesn't have sufficient past experience in these areas.
> 
> * New features
>   If a problem hasn't been solved in at least two deployed IETF
>   application protocols, then it is out-of-scope for the base 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 or 
> non-public specs
>   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.
>   It must avoid normative references to any document which is not
>   freely and publicly available on the Internet.
> 
> 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 problem
>   identification draft (above) must be completed 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 20:45:09 UTC