W3C home > Mailing lists > Public > public-xmlsec@w3.org > December 2009

RE: Best practice for referring to specifications which may update

From: Magnus Nystrom <mnystrom@microsoft.com>
Date: Mon, 21 Dec 2009 23:45:13 +0000
To: Frederick Hirsch <frederick.hirsch@nokia.com>, ext Thomas Roessler <tlr@w3.org>
CC: XMLSec WG Public List <public-xmlsec@w3.org>
Message-ID: <1081D4CDDC85CF4491AFD941A52242EF4B26E807@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
Why "earliest known" and not "latest known"?

-- Magnus


> -----Original Message-----
> From: public-xmlsec-request@w3.org [mailto:public-xmlsec-
> request@w3.org] On Behalf Of Frederick Hirsch
> Sent: Monday, December 21, 2009 2:52 PM
> To: ext Thomas Roessler
> Cc: Frederick Hirsch; XMLSec WG Public List
> Subject: Re: Best practice for referring to specifications which may
> update
> 
> I plan to add the following to the References section of XML Signature
> 1.1 and XML Encryption 1.1, thus applying to both the normative and
> informative sections
> 
> A. References
>    [[
> 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.
> ]]
> 
> A.1 Normative References
> ...
> A.2 Informative References
> ...
> 
> Any comment or objection?
> 
> Note that I do not believe it is readable or maintainable to have to
> make an separate statement for every individual reference.
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> 
> On Nov 12, 2009, at 3:28 AM, ext Thomas Roessler wrote:
> 
> > FYI.  Henry's proposed boilerplate reference language might make
> > sense for our specs, too, where we normatively reference moving
> > targets.  Something very similar might also make sense for some of
> > the informative references.
> >
> > Regards,
> > --
> > Thomas Roessler, W3C  <tlr@w3.org>
> >
> >
> >
> >
> >
> >
> >
> > Begin forwarded message:
> >
> >> From: ht@inf.ed.ac.uk (Henry S. Thompson)
> >> Date: 28 October 2009 15:57:48 GMT+01:00
> >> To: www-tag@w3.org
> >> Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
> >> Subject: Best practice for referring to specifications which may
> >> update
> >> archived-at:
> <http://www.w3.org/mid/f5biqdzd0r7.fsf@hildegard.inf.ed.ac.uk
> >> >
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> In the context of an extended discussion at the recent TAG f2f
> >> regarding references to potential time-varying specification URIs
> [1]
> >> I took an action [2] to suggest wording for a Best Practice in this
> >> area, based on wording developed by C. M. Sperberg-McQueen, who also
> >> reviewed and contributed to the following.
> >>
> >> Here's what I think this might look like:
> >>
> >> When citing a W3C specification in the normative references section
> >> of another specification, care should be taken to be clear about the
> >> status of editions of the referenced specification other than the
> >> then-current one.  In order to on the one hand acknowledge that
> >> implementations sometimes lag behind specifications, and on the
> >> other that implementations of new editions of referenced
> >> specifications should be encouraged, wording along the following
> >> lines should be used:
> >>
> >>   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.  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.
> >>
> >> In cases where many references require similar treatment, a blanket
> >> statement at the top of the references section may be more
> >> appropriate:
> >>
> >>   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.
> >>
> >> All of the above formulations assume a definition of
> >> 'implementation-dependent' along the following lines:
> >>
> >>   If a choice is described as 'implementation-dependent', then
> >>   conformant implementations must document which choice they make.
> >>
> >> Comments welcome.
> >>
> >> ht
> >>
> >> [1] http://www.w3.org/2001/tag/2009/09/23-minutes#item03
> >> [2] http://www.w3.org/2001/tag/group/track/actions/303
> >> - --
> >>      Henry S. Thompson, School of Informatics, University of
> >> Edinburgh
> >>                        Half-time member of W3C Team
> >>     10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131
> >> 650-4440
> >>               Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
> >>                      URL: http://www.ltg.ed.ac.uk/~ht/
> >> [mail really from me _always_ has this .sig -- mail without it is
> >> forged spam]
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.2.6 (GNU/Linux)
> >>
> >> iD8DBQFK6FvskjnJixAXWBoRAkMoAJwLt6r3r+Vv0Bafj7VXG3lTwTUZCQCbBUQt
> >> vLwTcIIeuu0opUPciRUtZ/g=
> >> =TIg8
> >> -----END PGP SIGNATURE-----
> >>
> >>
> >
> >
> 
> 
Received on Monday, 21 December 2009 23:45:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 21 December 2009 23:45:56 GMT