Evolution of the Web:References to Evolving Specifications

Editors Draft of 24 December 2011; see Overview for copyright, caveats, etc.

(as derived from [SpecUpdate])

If spec A points to spec B, and there is a new 'version or edition' of spec B: It's very hard to know in advance whether the new version should apply. The applicability needs to be examined against interoperability, security, accessbility, internationalization, and other constraints. Will the combination happen "in the wild" anyway?

Implementers must proceed "with caution". IETF "downlevel reference" rule only useful when you actually trust the target's update policy to keep in mind the requirements imposed by this document.

IETF notion of "IETF review" vs. W3C notion of "working group review" means that dependencies may not be reviewed, accepted, etc.

You might automatically accept an update to a referenced spec B from a spec A, if the update to B is done with an explicit reference to the needs of A implementation community.

Applying to MIME registration: if an organization is able to market to people to make a variant of a format or language available as a MIME type, and to get at least some readers & search engines to accept it, then it is a fait accompli, and no amount of rule-making will change them. This happened with IE and will happen with some others. The only thing we can do is suggest that the MIME registry contain the "official" definition but allow a Wikipedia-style editing of "as deployed".

Specifications and registry entries frequently include references to other specifications. Sometimes those references are intended to reference a specific version or edition of the specification; in other cases, the reference is intended to allow for update and evolution.

Specifications evolve as new editions of them are written. Standards evolve as groups agree that a particular edition of a specification represents their common agreement. Specifications may have versions, editions, and forks.

Often, one specification will reference another specification. In some cases the reference is given informally, in others it the reference consists of a URI which identifies the specification.

Discuss status, editions, versions, standards, specifications, in IETF, W3C, other organizations. IETF has internet-draft, RFC. RFC can be Informational, Standards track, Experimental. W3C has editor's draft, working draft, proposed, candidate, rec. Explain W3C spec.

Discuss considerations for what you might want to optimize: evolution, stability.

Discuss need for clarity against goals

Define "Implementation-dependent"

(following text from HT and CMSMQ needs review -- do we really want to impose this in MIME registrations? Goes against the registry rules of "put MIME reg in spec and update it there too".)

When citing a W3C specification in the normative references section of another specification or a registry care should be taken to be clear about the status of editions of the referenced specification other than the then-current one.

Left-Handed Sewer Flutes 1.0 (Second edition), P.D.Q. Bach and Peter Schickele, Editors. World Wide Consortium, 29 February 2009. The edition cited (http://www.w3.org/TR/2009/REC-lhsf-20090229/) is the earliest appropriate for use with this specification. Conformant implementations may follow the edition cited and/or any later edition(s). The latest edition of LHSF 1.0 is available at http://www.w3.org/TR/lhsf/. It is implementation-defined which editions of LHSF 1.0 are supported.

The appropriateness of this approach is based on the W3C rules regarding what constitutes an acceptable new edition of an existing W3C Recommendation. [cite]

For references to publications from other standards bodies with similar expectations regarding backwards compatibility, for example IETF or ISO, a similar approach to citation is also called for, along the following lines:

The Extension of MIME Content-Types to a New Medium, N. Borenstein and M. Linimon. Internet Engineering Task Force RFC 1437, 1 April 1993. RFC 1437 was current at the date of publication of this specification, but may be updated or obsoleted by later RFCs. Conformant implementations may follow the RFC cited and/or any later RFCs which update or obsolete it. It is implementation-defined which RFCs are supported. Intelligent transport systems -- Physical characterisation of vehicles and equipment -- International airline seat pitch measurements. Part 1: Measurement architecture. International Standard ISO 314159-1:2009, 29 February 2009. The referenced specification may from time to time be amended, replaced by a new edition, or expanded by the addition of new parts. See http://www.iso.org/iso/home.htm for up-to-date information. Conformant implementations may follow the edition cited and/or any amendments etc. It is implementation-defined which amendments etc. are supported.

Or a general caveat:

Dated references below are to the earliest known or appropriate edition of the referenced work. The referenced works may be subject to revision, and conformant implementations may follow, and are encouraged to investigate the appropriateness of following, some or all more recent editions or replacements of the works cited. It is in each case implementation-defined which editions are supported.

and then simply

Left-Handed Sewer Flutes 1.0 (Second edition), P.D.Q. Bach and Peter Schickele, Editors. World Wide Consortium, 29 February 2009 (http://www.w3.org/TR/2009/REC-lhsf-20090229/). The latest edition of LHSF 1.0 is available at http://www.w3.org/TR/lhsf/.

The Extension of MIME Content-Types to a New Medium, N. Borenstein and M. Linimon. Internet Engineering Task Force RFC 1437, 1 April 1993.

Intelligent transport systems -- Physical characterisation of vehicles and equipment -- International airline seat pitch measurements. Part 1: Measurement architecture. International Standard ISO 314159-1:2009, 29 February 2009. See http://www.iso.org/iso/home.htm for up-to-date information.