Skip to main content

Special Host Requirements (shr)

WG Name Special Host Requirements
Acronym shr
State BOF Concluded
Charter charter-ietf-shr-01 Approved
Document dependencies
Personnel Chair Bob Stewart
Mailing list Address
To subscribe
Chat Room address

Charter for Working Group

    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 (anFTP 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.


Date Milestone Associated documents
May 1991 Fourth IETF meeting: review final draft and if OK, give to IESG for publication as RFC.
Apr 1991 Final draft document.
Nov 1990 Second IETF Meeting: review first draft document, determine necessary revisions. Follow up discussion on mailing list.
Oct 1990 First draft document.
Aug 1990 Third IETF Meeting: make document an Internet Draft. Continue revisions based on comments received at meeting and over e-mail.
Aug 1990 Revised document.

Done milestones

Date Milestone Associated documents
Done Mailing list discussion of Charter and collection of concerns.
Done 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.