Subject: Re: [newtrk] Value of reclassification

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Sep 2004 11:24:41 +0200

Bob,

Bob Braden wrote:
>   *> 
>   *> RFC 821 is listed as obsoleted by RFC 2821. So when you look for the standard
>   *> called SMTP, you should be led to 2821 not to 821. That doesn't require
> 
> Brian,
> 
> It seems to me that the phrase "when you look for the standard called
> SMTP" has little meaning.  First, what do you mean by "standard"?  A
> specification defined by a document on the standards track (conflating
> Proposed, Draft, and Standard)?  

Exactly. I mean anything on the standards track. What implementors want
is the latest version, i.e. giving priority to the most recent "obsoletes"
and "updates" rather than priority to "STD" over "DS" over "PS".

(And then there is the buried assumption
> that the Proposed/Draft/Standard attribute has no meaning for most people;
> not a totally unreasonable viewpoint, but perhaps a large change in process.)

Yes, but this WG is allowed to discuss large changes in process.

> 
> Second, "SMTP" is NOT the name of a standard.  One COULD create a new
> name space of standards (whatever that means), in which one name might
> be "SMTP", but we have not done that.  "SMTP" is the abbreviation for
> the name for a protocol (family) defined by Jon Postel in RFC 821.  We
> techies know what the string "SMTP" means, generally, but it is not the
> name of a standard.  "STD10" is the name of a Standard.  If you conflate
> all degrees of the standards track, as suggested above, then STD10
> would be the correct name for what is commonly called "SMTP".

Again, this is something that this WG can propose to change. I'd say
we should insist on having a mnemonic for every STD number, so that
people can search on either. I'd bet 99% of searches would be on
the mnemonic.

If I go to http://www.rfc-editor.org/rfcxx00.html and search on SMTP,
my first hit is RFC 821. For all practical purposes that is the *wrong*
answer; it should be RFC 2821, with the extra information from
http://www.rfc-editor.org/rfc-index2.html , i.e., (Obsoletes RFC0821,
RFC0974, RFC1869)

I think a fairly simple refactoring of those two web pages would do
what I'm asking for - the only gap seems to be that we would have to
pre-assign STD numbers and mnemonics to all PS/DS documents. Then arrange
for the first table in www.rfc-editor.org/rfcxx00.html to be the
"latest version" table and for the references to include the
obsoletes/updates information.

> 
>   *> analysis - it is already explicit in the official RFC index. Any STD document
>   *> that is obsoleted or updated by DS or PS, and any DS that is obsoleted or updated
>   *> by a PS, should be trivial to identify. The necessary hyperlinks are actually
>   *> almost there, right in the RFC index:
>   *> 
>   *> 0821 Simple Mail Transfer Protocol. J. Postel. Aug-01-1982. (Format:
>   *>       TXT=124482 bytes) (Obsoletes RFC0788) (Obsoleted by RFC2821) (Also
>   *>       STD0010) (Status: STANDARD)
>   *> 
>   *> 2821 Simple Mail Transfer Protocol. J. Klensin, Ed.. April 2001.
>   *>       (Format: TXT=192504 bytes) (Obsoletes RFC0821, RFC0974, RFC1869)
>   *>       (Status: PROPOSED STANDARD)
>   *> 
>   *> It's mechanical from that to identify 2821 as the valid document for
>   *> the protocol formerly known as STD0010. It should possible to write
>   *> a script to generate HTML with pointers to latest versions regardless
>   *> of whether they are STD, DS, or PS.
>   *> 
> 
> 
> Well, sure.  Note that our search engine (almost) does generally what
> you want; it displays obsoleted documents in a lighter font/color (but
> in this particular case, the situation is confused because 821 is an
> STD but 2821 cannot be.)  But this simple algorithmic issue is really
> secondary to the fundamental semantic problem I talked about above:
> what is a standard, what is the name of a standard, etc.
> 
> BTW, if you go one step further towards defining what you mean by
> the name of a standard, you will find you rapidly fall into big
> doo-doo. What is the name of the SNMP standard? How much is
> included within the SMTP standard? Etc., etc.  It turns out to
> be a complex world.  At the microphone during the last IETF
> newtrk session, I suggested the bare bones idea of how to get
> out of this doo-doo, but no one has picked up on it.

Yes, this is tricky in some cases for sure, but it seems to me that
if we had a rule that every PS must be assigned to an STD and a
mnemonic at birth, it would progressively resolve itself. A draft
on your bare bones idea would perhaps help us discuss it?

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 20 Sep 2004 14:40:57 +0200

> on your bare bones idea would perhaps help us discuss it?

Bob - the minutes show you saying a couple of things - these were the ones 
captured at <http://www.ietf.org/proceedings/04aug/minutes/newtrk.htm>:

> Bob Braden - standard quality may be inversely proportional to document
> length

> Bob Braden - we're creating a new namespace for standards, and this makes
> a lot of sense (allows version numbers). RFC numbers are document
> references, not standards references.

> Bob Braden - John Klensin pointed out that errata on standards are
> standards-track issues, so they've been pointing these to the IESG

> Bob Braden - it would be useful to separate namespace engineering from
> mechanisms for publishing, so we can make progress - is SIP a standard,
> or are there pieces? - need to be clearer about figuring out what goes in
> a STD.

> Bob Braden - don't call your new space STDs - need a new namespace.
> Haven't been able to retrain people to use STD numbers - at least take
> RFC numbers out of standards-track document - mistake to call new this
> STD, perhaps ISN (Internet Standard Number) references.

> Bob Braden - Jon Postel said "standards are forever" - moving to historic
> means "egregiously bad". Maybe this was the product of a simpler time.
> Some of the oldest STDs were grandfathered as STDs in the first place
> when the standards track was created.

I assume that you're thinking about the next-to-last of these?
I think that (not reusing the STD acronym) could be considered a minor edit 
to draft-klensin-std-repurposing..... and makes some sense to me.
I like acronyms better than numbers anyway :-)

                Harald

.

---

From: John C Klensin <[email-masked]>
Date: Mon, 20 Sep 2004 13:47:15 -0400

--On Monday, 20 September, 2004 14:40 +0200 Harald Tveit
Alvestrand <[email-masked]> wrote:

Two quick observations on part of this note...

>...
> I think that (not reusing the STD acronym) could be considered
> a minor edit to draft-klensin-std-repurposing..... and makes
> some sense to me.

It is a minor edit.  But I'm not good at these names and
acronyms, so, by default, the document will continue to say
"STD" until someone shows up with another string and gets some
critical mass around it.  Suggestions welcome.

It does seem to me that suggesting both that the use of "STD"
has never taken off (which I believe to be true) and that the
name has been used up and therefore another name must be chosen
is a weak argument, but ymmd.

I'm waiting for John to pass the document back to me (hint,
hint), but, if a good suggestions is made, either one of us
could trivially make that change.

> I like acronyms better than numbers anyway :-)

This is a rather separate discussion.  I don't, if only because,
when there are many of them, acronyms get very hard to remember,
especially if their construction involves stretch.  And they
don't really help with the problem of what things go together.
Indeed, the nice thing about numbers is that they have almost no
semantics.  Acronym strings, by contrast, can create confusion
about what they do or do not cover.

    john

.

---

From: [email-masked] (scott bradner)
Date: Mon, 20 Sep 2004 15:33:32 -0400 (EDT)

> I like acronyms better than numbers anyway :-)

as do I 

TCP
	1/ makes more sense to more people
	2/ is easier to remember
	3/ is less likely to be miswriten
	....

than STD0007

summary - names are more human frendly than numbers

imo

Scott
.

---

From: Larry Masinter <[email-masked]>
Date: Mon, 20 Sep 2004 14:47:51 -0700

(to bring a private exchange back to the list):

How many acronyms / names would we have?

If you take the example of SMTP, I'm told that
there are 29 standards-track documents related
to SMTP.

Personally, I would prefer to see one document
"IETF Standard SMTP" or
"IETF-STAN-SMTP" or whatever, which listed
all 29 RFCs and described their status and
relationship, rather than having 29 named
documents with acronyms for each.

Larry
-- 
http://larry.masinter.net

.

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Sep 2004 18:16:27 -0400

> documents with acronyms for each.

Perhaps.  But I would NOT want to have to go through an 
RFC-like revision process for that document every time 
somebody defined a new SMTP extension.  Nor would I like
to have to have months-long discussions to figure out 
whether or not an "X over Y" document needed to be described
in the X list of standards, the Y list of standards, or both.

Right now we have rfc-index.txt to describe the status of
each document.  I'm not sure how we can dispense with that,
nor do I wish to have multiple indications of document status
that can get out of sync with one another.

Keith
.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Sep 2004 11:15:14 +0200

> that can get out of sync with one another.

Certainly not - that's why I observed that the document status
markers in the RFC index can be used to generate the hyperlinks
automagically. The manual work should be limited to assigning
a new RFC to a specific standard, exactly once.

    Brian
.

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 21 Sep 2004 07:32:57 -0700

>How many acronyms / names would we have?

Bundles should have names, not acronyms. Please. These are being 
designed for public consumption, and the public does not like our 
acronyms all that well.

>documents with acronyms for each.

Agree.

A reasonable way to do this is to have an IESG (*not* IANA) registry 
that is filled in by Area Directors. They can do this when they have 
the time or delegated personpower to create and debate about the 
bundles. My guess is that, after two years, we will have bundles for 
nearly all the needed groupings because people who use a grouping 
that doesn't have a bundle name will ask for it.

--Paul Hoffman, Director
--VPN Consortium
.