- From: Chris Newman <Chris.Newman@innosoft.com>
- Date: Thu, 04 Feb 1999 10:40:15 -0800 (PST)
- To: Steve Hole <steve@execmail.com>
- Cc: discuss@apps.ietf.org
On Mon, 1 Feb 1999, Steve Hole wrote: > I think that the term "core protocol" is misleading in many ways. We > really don't want a complete protocol in and of itself. Seems to me > that you could organize it into two distinct classes of thing that would > be described: > > 1. A general set of design guidelines for application protocols. This > would include things like binary vs. text commands and payload, encoding > schemes, specification syntaxes, etc. > > 2. A set of protocol components that you can assemble into a specific > protocol. This would include many of the things that Chris had in his > message like authentication, ACL's, capabilities/extensions, etc. > Not unlike a set of protocol subroutines or object classes. The list of > accepted components can be quite small to begin with. In one sense, I like the idea. Personally, I'd have no trouble hunting through RFCs for good components to collect together and write up in a new protocol. But I don't mind designing protocols directly on top of TCP, either. We really need a one-stop-shopping "core protocol" so one can define a new protocol by saying "take the core protocol and AUTH command from RFC XXXX then add the following commands and run on port P". Otherwise people will just say "add these 20 methods to HTTP and you've got whiz-bang protocol" because that would be so much easier than collecting together components and subtle design choice options from several RFCs into a coherent protocol. - Chris
Received on Thursday, 4 February 1999 13:42:45 UTC