Subject: [newtrk] The anomalous state STD10 is OBSOLETED

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 12 May 2005 15:06:18 -0700

> From: Bruce Lilly [mailto:[email-masked]] 

> If it's going to be called "standard" (as opposed to 
> "proposed standard" or "draft standard"), then it should 
> point to the least bad document that actually has Standard status.

Or to nothing at all. If the IETF cannot decide what the SMTP standard
is then it had better say that than send the conflicting signals it does
today.

In the specific case of RFC 282x the documents have been composted more
than enough time to simply declare them the standard and be done.
Specifications are not like wine, they do not improve with age.

The process should basically have a forcing function, if document X
makes document Y obsolete then document Y has to be moved to HISTORIC,
or perhaps a new status SUPERCEEDED any other approach results in
incoherence.

It would of course be much better to update the document itself to
reflect its new status, I find the idea that unsigned electronic
documents should be immutable to be a most peculiar fetish. 

> Had the work that produced 2821 and 2822 been confined to 
> consolidation of corrigenda, it might be reasonable to have 
> accorded them full standard status; but 2821 and 2822 
> incorporate additional requirements and restrictions, and so 
> should be held to the prescribed process for advancement on 
> the standards track. 

If the consequence of issuing RFC 282x would be that 82x would move to
supreceeded and no longer be a standard the IESG would have been forced
to consider these issues and the document would probably have been
written to reflect those constraints.

> No. The Internet Message Format preceded SMTP and has been 
> used with FTP, UUCP, POP, IMAP, NNTP, and proprietary protocols.

Yet more reason for the constraints to be made explict by the process.
Either 2822 considers the implications for these other protocols or it
does not. If the collateral effect has been considered then all is well,
if not then making 822 obsolete has mucked everything up good and proper
hasn't it?

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 12 May 2005 18:32:54 -0400

> is then it had better say that than send the conflicting signals it does

Yes, the discussion on the IETF list referenced earlier was about
the inconsistency in std-index; some STDs have a reserved placeholder
where a specification is undergoing revision (e.g. STD 12).  Presumably
the same could have been done for STDs 10 & 11.

> Specifications are not like wine, they do not improve with age.

They do if unused features are removed, errors are corrected,
problems found through implementation experience are resolved,
etc., all things that are supposed to happen during standards track
progression.
 
> makes document Y obsolete then document Y has to be moved to HISTORIC,

That is the usual procedure when a successor specification reaches
full Standard status.
 
> if not then making 822 obsolete has mucked everything up good and proper

Most transport protocols mentioned just move the bits from point A
to point B (SMTP is an exception), so the format isn't a big issue
for transport.  2822 has changed rules that affect generators and
parsers of the message format.

There's another reason why 822 is going to be around for a while. It
defined an extended BNF which has been used by a large number of
other specifications.  Until those other specifications are updated
to use some other syntax, there will be a need to reference 822.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Larry Masinter <[email-masked]>
Date: Thu, 12 May 2005 23:47:05 -0700

Maybe this belongs on the 'tools-discuss' list instead?
I wonder how much of 'newtrk' discussion is really
trying to solve problems that could be addressed
without process changes but with a few more tools?

Personally, I think we would be better to have
a (automatically generated) web page for every RFC
that will tell you about the status of that RFC:

(pointer to) errata for the RFC
Status of RFC (Standards track, historical, etc.)
Pointer to other RFCs and standards actions that affect
  this RFC (updates, obsoletes)

(possibly) pointer to any "roadmap" RFCs that put
this one in context, or ISDs.

(possibly) pointer to (charter of) working group
which developed the RFC, if any

pointer to mailing list archive for mailing list that
discussed this RFC.

pointer to any IPR statements that specifically
mention this RFC.

All of the information should be specific to THIS
RFC, not a pointer to some general list that you
have to search to figure out what does and doesn't
apply.

And then we could add to the RFC boilerplate
"for information about the status of this
RFC, please consult 
   <URI for this RFCs status>

The status pages don't have to be automatically
generated on the fly, they could easily be
batch generated whenever information changes.

Larry

.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 May 2005 14:57:20 +0200

Bruce Lilly wrote:
...
> to use some other syntax, there will be a need to reference 822.

And that's exactly why RFCs are never updated under the same number-
they can remain as stable citations for all time.

What we're arguing about in the STD/ISD debate is how to point to
coherent sets of RFCs for citation, implementation and procurement
purposes. And however people may interpreted the IESG's comments
on ISDs, the need to solve this problem somehow is, I think,
common ground.

    Brian

.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 May 2005 16:56:53 -0700

> Status of RFC (Standards track, historical, etc.)

This could be a database accessed using a parameter convention generated
from the RFC number.  Based upon the example in:
http://darkwing.uoregon.edu/~llynch/newtrk/msg00997.html

For different types of documents, the following convention could be
established to permit a standardized layer of meta-glue.

<a href="http://www.rfc-editor.org/errata/errata.html?
rfc=2821";>Errata</a>

>   this RFC (updates, obsoletes)

If the ISD is considered an XML document that associates RFCs under
general categories, then the status of this collection of documents
could be described and updated using the same conventions as used for
Errata.

Not attempting to establish new rankings over odd collections of PS,
STD, BCP, Experimental or Informational documents seems best.  Not
adding authoritative text would also avoid confusion.  That should
remain the function of the RFC.  The ISD name.number can accommodate a
broad range of efforts at consolidating which documents comprise which
applications or systems.

Perhaps a Status document (database entry) includes 5 star ratings for
stability, adoption, and recommendations for future use, and related IPR
declarations.  By making the Status portion of the ISD XML document be a
reference to a dynamic database, as well as the Errata, this component
would not need to be created prior to the publication of the ISD
document. 

<a href="http://isd.ietf.org/isd/isd-status.html?
isd=smtp">Status</a>
 
Rather than describing ISD as a roadmap, or a standard, perhaps a less
charged term could be used.  RFC meta structure, RMS, could be safer
terminology. : ) 

> this one in context, or ISDs.

The structure of the ISD joining together related documents via
hyper-links would be describing the ISD.  The ISD could distill down to
a generalized description with categories of links to related documents
as little more than an outline:

 - System or Application simple description
 - Core
 - Extension
 - Experimental
 - Prior Conventions
 - related ISDs

> pointer to any IPR statements that specifically

These items are more ephemeral and would increase the difficulty
maintaining an already complex list of links.  Perhaps there could be
accommodations made for such items within the Status portion of the ISD.

> have to search to figure out what does and doesn't

That would be a function of a HTTP parameter, as in the example given.

> batch generated whenever information changes.

Status would follow behind the ISD documents, just as Errata follows
behind RFCs. The act of creating the ISD would highlight useful
documents, much like an RFC index, while offering far greater utility.
An exhaustive effort to cover all useful documents using the ISD
mechanism would permit people to see past the cruft.  Don't burden the
ISD document as being applicable only for mature standards, as the ISD
mechanism could benefit emerging efforts equally well.  Having the ISD
structure as a means to document associations would make RFCs seem less
impenetrable.

After some experience is gained as to what is useful within Status, then
this component could be formalized.  Starting with less formalized
specifications for Status may be beneficial.  One rule that should
apply, would be that Status not attempt to alter content of any RFC, and
must not be authoritative from the aspect of protocol. A Status document
should not be used for making changes.

-Doug

.

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 13 May 2005 21:16:15 -0400

On Fri May 13 2005 08:57, Brian E Carpenter wrote:
> purposes.

But isn't there an inherent conflict:

o errata may be found and published at any time; error have been known to
  occur in errata, and 
o RFCs' status may change
o RFCs may be updated by other RFCs, at any time such a subsequent
  RFC is published (and *that* RFC may itself be updated, ad infinitum)
o extensions may be specified in some RFCs; said extensions may be
  applicable only to a subset of cases covered by the base RFC; worse,
  there may be multiple conflicting extensions (Experimental/Informational)

whereas for procurement purposes (probably for citation and implementation
also) one would like a stable specification which covers sufficient
detail but no more -- and depending on the specific case, different sets
of extensions may be needed.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 14 May 2005 10:49:17 -0400

Hi Doug,

I very much like what you are describing, but I am not sure that this 
is really a document series...  It is more like a better web 
structure for accessing RFCs than we have today.  I agree that this 
is badly needed, and that such a structure would be highly beneficial 
to the community.

Margaret

.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 14 May 2005 20:13:24 -0700

> is badly needed, and that such a structure would be highly beneficial 

A simple XML document pulling together current RFCs under a system or
application category would be more than just a better presentation.  A
new application Foo at iteration 1, pulls together a set of inter-
related RFCs, such as core and extensions, where this aggregation is
defined as ISD foo.001.  Such should be seen as a document series.
Ensuring this association process does not change RFC content, or
directly indicate its own stature, avoids many problems. 

It would not be a document series that, by itself, indicates underlying
documents have achieved any specific stature.  Such information is
obtained by reference to a related (dynamic) Status document to indicate
these achievements.  Whether Status eventually supplants a standard
series process, is not something that needs to be decided now.

The Status information could become a formalized process, while allowing
an ISD XML document to bring together evolving RFCs into a coherent
structure.  Such organization of information should occur well before
the underlying RFCs are dubbed standards (or components of a standard).
This ISD structure could assist work-in-progress, rather than relegated
as a means to bestow stature.  Including the aspect of stature or
authoritative content into the ISD document seems destine to prolonged
this process that will ultimately constrain its utilization.

Documents that achieve stature and recognition, are likely incorporated
into comprehensive literature or are obsolete.  I would rather see an
ISD system acting to assist the genesis of change, than limit the
suitability of the ISD structure.  Although excluding authoritative
content (beyond the aggregation of documents) and status may seem to
lessen the value of the ISD document, it does ensure this project can be
completed to encompasses ALL significant RFCs.

Status or stature is something that happens over time, why visit this
lengthy process on the ISD document?  Make stature a function similar to
the errata effort.

-Doug

 

.

---

From: Joe Touch <[email-masked]>
Date: Mon, 16 May 2005 14:51:40 -0700

>is badly needed, and that such a structure would be highly beneficial

IMO, it'd be more useful to have an XML version of "protocol
informatics" than to worry about whether individual RFCs are XML-ized or
whether an XML document presents that information. I.e., I'd like to
know which protocols depend on which others, which dependencies are
normative, etc. - the way bioinformatics databases log genetic
relationships, or chemoinformatics logs molecular structure.

That's a structure that isn't expressed in the RFC XML schema. That's
not a document; it's information structure that can be loaded into a
database which could be used by a document, a web page, or a web
front-end to the database.

Joe
.