Special Host Requirements (shr)
|Name:||Special Host Requirements|
Bob Stewart <firstname.lastname@example.org>
The Special-purpose Host Requirements Working Group is
chartered to clarify application of the Host Requirements RFCs (1122
and 1123) to systems that are technically hosts but are not intended
to support general network applications. These special-purpose hosts
include, for example, terminal servers (a ``Telnet host''), or file
servers (an ``FTP host'' or an ``NFS host'').
The Host Requirements RFCs address the typical,
general-purpose system with a variety of applications and an open
development environment, and give only passing consideration to
special-purpose hosts. As a result, suppliers of special-purpose
hosts must bend the truth or make excuses when users evaluate their
products against the Requirements RFCs. Users must then decide
whether such a product is in fact deficient or the requirements truly
do not apply. This process creates work and confusion, and undermines
the value of the RFCs. The commercial success of the Internet
protocols and their use in increasingly unsophisticated environments
exacerbates the problem.
The Working Group must define principles and examples for
proper functional subsets of the general-purpose host and specifically
state how such subsets affect the requirements. The Working Group
must determine the balance between an exhaustive list of specific
special-purpose hosts and philosphy that remains subject to debate.
For the most part, it should be possible to base decisions on existing
experience and implementations. The special-purpose requirements will
be stated as differences from the existing RFCs, not replacements, and
will refer rather than stand alone.
Since they define strict subsets of the Host Requirements
RFCs, the Special-purpose Host Requirements appear to be an easier job
and can be developed and stabilized within 8-12 months. Most of the
Group's business can be conducted over the Internet through email.
Mailing list discussion of Charter and collection of concerns.
Third IETF Meeting: make document an Internet Draft. Continue revisions based on comments received at meeting and over e-mail.
First IETF Meeting: discussion and final approval of Charter; discussion and agreement on approach, including models, format, level and type of detail. Make writing assignments.
First draft document.
Second IETF Meeting: review first draft document, determine necessary revisions. Follow up discussion on mailing list.
Final draft document.
Fourth IETF meeting: review final draft and if OK, give to IESG for publication as RFC.