Subject: [newtrk] Change history in "ISD" considered not fully baked

From: Bruce Lilly <[email-masked]>
Date: Tue, 22 Mar 2005 19:21:48 -0500

The latest version of the repurposing-isd draft states:
-----------------------
   While RFCs are permanent, ISD documents are expected to evolve and
   incorporate changes over time.  However, they are also expected to
   include explicit change histories in order to make it possible for a
   reader to examine a current ISD document and determine the status of
   the relevant standard at any particular previous time.  
-----------------------
and
-----------------------
   For
   archival and external reference purposes, the formal archival form of
   the ISD will be ASCII text.
-----------------------
One wonders precisely how an ASCII text document is going to
be able to be read to determine precise status at any given
previous time, given that individual components will have status
changes and errata, and may be amended or obsoleted by other RFCs at
any time.  Looking at the companion sample-isd-00 draft (scheduled to
expire in about three weeks), one sees only
-----------------------
3.2.7  History and Tracking Information

   ...To be supplied...
-----------------------
which is hardly illuminating.

There exist version control systems which can be used to regenerate
a document (or other file) in various versions; SCCS (Source Code
Control System) is one of the earliest (M. Rochkind, IEEE Transactions
on Software Engineering, Dec. 1975), RCS and CVS are more recent
variations on the theme. All have the following characteristics:

1. a master file, in a specific format, containing all content
2. a set of programs for manipulating the master file format, e.g.
   to extract a specific version
3. a version naming (numbering) scheme.

[Re]generating a specific version requires:

a. access to the master file
b. (at least a subset of) the programs
c. the desired version name (number).

Two of the three are insufficient.  Regenerating a version of an "ISD"
document is likely to be no different.  It appears that this area has
not been sufficiently well thought out; discussion of source format,
much less schemas vs. DTDs etc. would seem to be premature.

Returning to the sample-isd draft, it has:
-----------------------
3.2.3  Extensions to the SMTP Base Specification

[...]
   RFC3030
      SMTP Service Extensions for Transmission of Large and Binary MIME
      Messages.  G.  Vaudreuil.  December 2000.
      Status: PROPOSED STANDARD
      Putative errata: The RFC Editor has a list of outstanding errata
      for RFC3030 that are unverified.  These can be found by entering
      the RFC number into the "errata" search page located from
      http://www.rfc-editor.org/.

3.2.4  Related ISDs (temporary)
[...]
3.2.5  Experimental Extensions

   These extensions are included for reference and information only.
   The IETF has not concluded that they are ready for standards-track
   treatment and deficiencies may be known but not documented formally.

   RFC1830
      SMTP Service Extensions for Transmission of Large and Binary MIME
      Messages.  G.  Vaudreuil.  August 1995.  (Obsoleted by RFC3030)
      Status: EXPERIMENTAL)
-----------------------
First, it is unclear how a reader is supposed to determine status
as of a particular date (say, December 31, 1999) without a great
deal of tedious effort flipping back and forth through the entire
document.  Even with such effort, there are difficulties with
statements that bear no timestamp or qualification and which are
not unconditionally true (see below).

Second, it is my understanding and experience (with one possible
exception) that the RFC Editor is very careful about verification
of reported errata; calling these "unverified" isn't quite correct.

Third, the statement that "The IETF has not concluded that they are
ready for standards-track treatment..." w.r.t. Large and Binary MIME
extensions is evidently untrue, as the IESG clearly has approved RFC
3030 on the Standards Track.  Now that statement may have been true
prior to RFC 3030, but the statement in the example bears no timestamp
or qualification.

Unless and until the sort of issues illustrated above can be handled
clearly and unambiguously in the ASCII text archival/reference form
of the document, discussion of source formats is premature (unless
one proposes to handle versioning via some sort of version control
system, in which case there is no ASCII text archival form -- the
version control master file would be the archival form).

P.S. a typo in the sample-isd-00 draft can be corrected by s/vh/ch/.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html