RE: Application "core protocol" BOF/WG idea

Even with Chris's excellent charter which I think does a great job of
restricting rat holes a core protocol WG would still be more appropriate for
the IRTF than the IETF. In my opinion the IETF's job is to clean up the mess
left behind by the innovators. That means we follow, we do not lead. As such
I strongly encourage outside efforts like HTTP-NG who will blaze a trail
that the IETF can later follow and standardize.

However, a WG to identify common issues and equally common solutions would
provide crucial guidance for application protocol standards writers and be
very much in line with the IETF's work. For example, such a "common issues"
WG might produce a document which made it mandatory for all new application
protocols to explicitly address issues such as: Extensibility (Provide clear
rules on what to do with unrecognized protocol elements - ignore or fail?),
NAT/Proxy/Firewall support, caching, connection oriented vs. non-connection
oriented, TCP vs. UDP, reliable vs. unreliable multicast, etc. These
requirements would be in line with current requirements regarding support
for Y2k friendly dates, internationalization and general security. Just
producing a list of the most common issues would be a great accomplishment.
It would be a valuable guide for reviewers and ADs to use when evaluating
new protocols.

			Yaron

> -----Original Message-----
> From: Michael Mealling [mailto:michael@bailey.dscga.com]
> Sent: Thursday, January 28, 1999 10:38 AM
> To: hardie@equinix.com
> Cc: Chris.Newman@INNOSOFT.COM; discuss@apps.ietf.org
> Subject: Re: Application "core protocol" BOF/WG idea
> 
> 
> Ted Hardie said this:
> > 	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 have to agree with this one. If there were a document I 
> could point to
> and say that the recommended way of doing error codes can be 
> found here
> it would save me huge amounts of time with in house one shot protocols
> in terms of educating people about what works and what doesn't work.
> 
> A good example is the constant re-use of RFC821's response codes. If
> that itself were brought up to date and re-released on its 
> own it would
> do alot to help new protocol writers....
> 
> -MM
> 
> -- 
> --------------------------------------------------------------
> ------------------
> Michael Mealling	|      Vote Libertarian!       | 
www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:
14198821
Network Solutions	|          www.lp.org          |
michaelm@netsol.com

Received on Thursday, 28 January 1999 15:46:12 UTC