W3C home > Mailing lists > Public > ietf-discuss@w3.org > February 1999

Re: Application "core protocol" BOF/WG idea

From: Chris Newman <chris@innosoft.com>
Date: Thu, 11 Feb 1999 14:27:35 -0800 (PST)
To: spreitze@parc.xerox.com
Cc: discuss@apps.ietf.org
Message-id: <Pine.SOL.3.95.990211140512.1858N-100000@elwood.innosoft.com>
On Thu, 11 Feb 1999 spreitze@parc.xerox.com wrote:
> > I'd say it would be an option for ...
> > ... new services that are not an explicitly documented
> > purpose of an IETF standards track protocol.
> 
> Is it aimed at new IETF protocols, new non-IETF protocols, or both?

I'd target APPLCORE towards new simple engineered application protocols
akin to past IETF success stories.  I wouldn't try to design for people
who want the latest
Active/Java/Open/Object-Oriented/Push-technology/Jini/Trendy Protocol.  A
new core protocol won't stop them from making a mess. 

> > What does this have to do with the proposed charter?  Are you suggesting
> > the charter needs explicit efficiency constraints?    I can't predict what
> > people who attend the BOF/WG will find to be important constraints.
> 
> Well, I certainly can't claim to be an authority on how to write a
> successful charter, but I was thinking that a useful part of the
> chartering process would be to look into the question of what, if
> anything, is the consensus on efficiency requirements.

Efficiency brings in all sorts of tradeoffs.  One can make a protocol use
a few fewer bytes on the wire by using a binary encoding, but this has the
expense of requiring significant additional programmer time to develop
debugging and testing suites since "telnet" doesn't work any more.  One
can make binary encodings smaller by packing them (akin to OSI's PER) at
the expense of making it hopeless to ever have a human interpret the data
and make machine parsing and debugging thereof much harder.  One can use a
compression layer (e.g. the one in TLS or secure shell) which may chew up
more CPU at the ends, but will pack both the protocol encoding and data
payload regardless of text/binary encoding issues.

I can't predict what a careful study of IETF protocol history and
comparison of candidate solutions will suggest.  If you have ideas on what
a charter should say to constrain the problem space, please suggest
wording. Otherwise I think it's adequate for the proposed charter to
mention this is an issue to consider. 

		- Chris
Received on Thursday, 11 February 1999 17:30:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:59 UTC