Java Network Programming (3rd ed) [Electronic resources] نسخه متنی

2.6 Internet Standards

This
book discusses several application-layer Internet protocols, most
notably HTTP. However, this is not a book about those protocols and
it tries not to say more than the minimum you need to know. If you
need detailed information about any protocol, the definitive source
is the standards document for the protocol.

While there are many standards organizations in the world, the two
that produce most of the standards relevant to network programming
and protocols are the
Internet
Engineering Task Force (IETF) and the
World Wide Web
Consortium (W3C). The IETF is a relatively informal, democratic body
open to participation by any interested party. Its standards are
based on "rough consensus and running
code" and tend to follow rather than lead
implementations. IETF standards include TCP/IP, MIME, and SMTP. The
W3C, by contrast, is a vendor organization, controlled by dues-paying
member corporations, that explicitly excludes participation by
individuals. For the most part, the W3C tries to define standards in
advance of implementation. W3C standards include HTTP, HTML, and XML.

2.6.1 IETF RFCs

IETF standards and near-standards are published as Internet drafts
and
requests for comments
(RFCs). RFCs and Internet drafts range from informational documents
of general interest to detailed specifications of standard Internet
protocols like FTP. RFCs that document a standard or a proposed
standard are published only with the approval of the
Internet
Engineering Steering Group (IESG) of the IETF. All IETF approved
standards are RFCs, but not all RFCs are IETF standards. RFCs are
available from many locations on the Internet, including http://www.faqs.org/rfc/ and http://www.ietf.org/rfcl. For the most
part RFCs, particularly standards-oriented RFCs, are very technical,
turgid, and nearly incomprehensible. Nonetheless, they are often the
only complete and reliable source of information about a particular
protocol.

Most proposals for a standard begin when a person or group gets an
idea and builds a prototype. The prototype is incredibly important.
Before something can become an IETF standard, it must actually exist
and work. This requirement ensures that IETF standards are at least
feasible, unlike the standards promulgated by some other
organizations. If the prototype becomes popular outside its original
developers and if other organizations begin implementing their own
versions of the protocol, a working
group may be formed under the auspices of the
IETF. This working group attempts to document the protocol in an
Internet-Draft. Internet-Drafts are working
documents and change frequently to reflect experience with the
protocol. The experimental implementations and the Internet-Draft
evolve in rough synchronization, until eventually the working group
agrees that the protocol is ready to become a formal standard. At
this point, the proposed specification is submitted to the IESG.

The proposal goes through six states or maturity levels as it follows
the standardization track:

Experimental

Proposed standard

Draft standard

Standard

Informational

Historic

For some time after the proposal is submitted, it is considered
experimental. The experimental stage does not
imply that the protocol is not solid or that it is not widely used;
unfortunately, the standards process usually lags behind de
facto acceptance of the standard. If the IESG likes the
experimental standard or it is in widespread use, the IESG will
assign it an RFC number and publish it as an experimental RFC,
generally after various changes.

If the experimental standard holds up well in further real world
testing, the IESG may advance it to the status of proposed
standard. A proposed standard is fairly loose, and
is based on the experimental work of possibly as little as one
organization. Changes may still be made to a protocol in this stage.

Once the bugs appear to have been worked out of a proposed standard
and there are at least two independent implementations, the IESG may
recommend that a proposed standard be promoted to a draft
standard. A draft standard will probably not
change too much before eventual standardization unless major flaws
are found. The primary purpose of a draft standard is to clean up the
RFC that documents the protocol and make sure the documentation
conforms to actual practice, rather than to change the standard
itself.

When a protocol completes this, it becomes an official Internet
standard. It is assigned an STD number and is
published as an STD in addition to an RFC. The absolute minimum time
for a standard to be approved as such is 10 months, but in practice,
the process almost always takes much longer. The commercial success
of the Internet hasn't helped, since standards must
now be worked out in the presence of marketers, vulture capitalists,
lawyers, NSA spooks, and others with vested interests in seeing
particular technologies succeed or fail. Therefore, many of the
"standards" that this book
references are in either the experimental, proposed, or draft stage.
As of publication, there are over 3,800 RFCs. Less than one hundred
of these have become STDs, and some of those that have are now
obsolete. RFCs relevant to this book are detailed in Table 2-2.

Some RFCs that do not become standards are considered
informational,. These include RFCs that specify
protocols that are widely used but weren't developed
within the normal Internet standards track, and
haven't been through the formal standardization
process. For example, NFS, originally developed by Sun, is described
in the informational RFC 1813. Other informational RFCs provide
useful information (like users' guides), but
don't document a protocol. For example, RFC 1635,
How to Use Anonymous FTP, is an informational
RFC.

Finally, changing technology and increasing experience renders some
protocols and their associated RFCs obsolete. These are classified as
historic. Historic protocols include IMAP3
(replaced by IMAP4), POP2 (replaced by POP3), and Remote Procedure
Call Version 1 (replaced by Remote Procedure Call Version 2).

In addition to its maturity level, a protocol has a requirement
level. The possible requirement levels are:

Should not be implemented by anyone.

May have to be implemented in certain unusual situations but
won't be needed by most hosts. Mainly these are
experimental protocols.

Can be implemented by anyone who wants to use the protocol. For
example, RFC 2045, Multipurpose Internet Mail
Extensions, is a Draft Elective Standard.

Should be implemented by Internet hosts that don't
have a specific reason not to implement it. Most protocols that you
are familiar with (like TCP and UDP, SMTP for email, Telnet for
remote login, etc.) are recommended.

Must be implemented by all Internet hosts. There are very few
required protocols. IP itself is one (RFC 791), but even protocols as
important as TCP or UDP are only recommended. A standard is only
required if it is absolutely essential to the functioning of a host
on the Internet.

Table 2-2 lists the RFCs and STDs that provide
formal documentation for the protocols discussed in this book.

The IETF has traditionally worked behind the scenes, codifying and
standardizing existing practice. Although its activities are
completely open to the public, it's traditionally
been very low-profile. There simply aren't that many
people who get excited about the details of network arcana like the
Internet Gateway Message Protocol (IGMP). The participants in the
process have mostly been engineers and computer scientists, including
many from academia as well as the corporate world. Consequently,
despite often vociferous debates about ideal implementations, most
serious IETF efforts have produced reasonable standards.

Unfortunately, that can't be said of the
IETF's efforts to produce web (as opposed to
Internet) standards. In particular, the IETF's early
effort to standardize HTML was a colossal failure. The refusal of
Netscape and other key vendors to participate or even acknowledge the
process was a crucial problem. That HTML was simple enough and
high-profile enough to attract the attention of assorted
market-droids and random flamers didn't help matters
either. Thus, in October 1994 the World Wide Web Consortium was
formed as a vendor-controlled body that might be able to avoid the
pitfalls that plagued the IETF's efforts to
standardize HTML and HTTP.

2.6.2 W3C Recommendations

Although
the W3C standardization process is similar to the IETF process (a
series of working drafts hashed out on mailing lists resulting in an
eventual specification), the W3C is a fundamentally different
organization. Whereas the IETF is open to participation by anyone,
only corporations and other organizations may become members of the
W3C. Individuals are specifically excluded. Furthermore, although
nonprofit organizations like the World Wide Web Artists Consortium
(WWWAC) may join the W3C, only the employees of these organizations
may participate in W3C activities. Their volunteer members are not
welcome. Specific individual experts are occasionally invited to
participate on a particular working group even though they are not
employees of a W3C member company. However, the number of such
individuals is quite small relative to the number of interested
experts in the broader community. Membership in the W3C costs $50,000
a year ($5,000 a year for nonprofits) with a minimum 3-year
commitment. Membership in the IETF costs $0 a year with no commitment
beyond a willingness to participate. And although many people
participate in developing W3C standards, each standard is ultimately
approved or vetoed by one individual, W3C director Tim Berners-Lee.
IETF standards are approved by a consensus of the people who worked
on the standard. Clearly, the IETF is a much more democratic (some
would say anarchic) and open organization than the W3C.

Despite the W3C's strong bias toward the corporate
members that pay its bills, it has so far managed to do a better job
of navigating the politically tricky waters of Web standardization
than the IETF. It has produced several HTML standards, as well as a
variety of others such as HTTP, PICS, XML, CSS, MathML, and more. The
W3C has had considerably less success in convincing vendors like
Netscape and Microsoft to fully and consistently implement its
standards.

The W3C has five basic levels of
standards:

A note is generally one of two things: either an unsolicited
submission by a W3C member (similar to an IETF Internet draft) or
random musings by W3C staff or related parties that do not actually
describe a full proposal (similar to an IETF informational RFC).
Notes will not necessarily lead to the formation of a working group
or a W3C recommendation.

A working draft is a reflection of the current thinking of some (not
necessarily all) members of a working group. It should eventually
lead to a proposed recommendation, but by the time it does so it may
have changed substantially.

A candidate recommendation indicates that the working draft has
reached consensus on all major issues and is ready for third-party
comment and implementations. If the implementations do not uncover
any obstructions, the spec can be promoted to a proposed
recommendation.

A proposed recommendation is mostly complete and unlikely to undergo
more than minor editorial changes. The main purpose of a proposed
recommendation is to work out bugs in the specification document
rather than in the underlying technology being documented.

A recommendation is the highest level of W3C standard. However, the
W3C is very careful not to actually call this a
"standard" for fear of running
afoul of antitrust statutes. The W3C describes a recommendation as a
"work that represents consensus within W3C and has
the Director's stamp of approval. W3C considers that
the ideas or technology specified by a Recommendation are appropriate
for widespread deployment and promote W3C's
mission."

The W3C has not been around long enough to develop a need for a
historical or informational standard status. Another difference the
IETF and the W3C is that the W3C process rarely fails to elevate a
standard to full recommendation status once work has actively
commencedthat is, once a working group has been formed. This
contrasts markedly with the IETF, which has more than a thousand
proposed and draft standards, but only a few dozen actual standards.