Subject: Names of standards-track RFCs

From: John C Klensin <[email-masked]>
Date: Wed, 14 Jul 2004 12:08:27 -0400

Hi.

A question as to whether I'm the only one who is bothered by a
trend and, if not, if it is time for the community to give the
IESG and the RFC Editor some advice.

I note that my concern is _only_ about standards-track
documents: they are widely referenced and cited by title as well
as number, they are IETF work products, and the IESG presumably
has, or should have final authority about what they are called.
It seems plausible, indeed likely, that other conventions and
issues might reasonably apply to non-standards-track documents.

The RFC Editor has a policy about "abbreviations" in titles and
body text.  The title part of that policy, from 2223bis, is

" 2.9 Titles

		Abbreviations (e.g., acronyms) in a title should
		generally be expanded; the exception is abbreviations
		that are so common (like TCP, IP, SNMP, FTP, etc.) that
		every member of the IETF can be expected to recognize
		them immediately.  It is often helpful to follow the
		expansion with the parenthesized abbreviation, as in
   [...]"

While perhaps not as explicitly stated, this has been the policy
for as long as I can remember.  And, for whatever my opinion, it
is a policy I strongly support for "real" abbreviations.  In
years past, it has been applied with considerable discretion.
It appears to me that we are now going too far in the direction
of expansion.  In our industry, there are many occasions in
which a name is formed from an abbreviation, but the original
expansion rapidly loses meaning (or had a very contrived meaning
to start with).  In those cases, the string is a name, not an
"abbreviation", regardless of its origins.  The expansion of it
as an abbreviation doesn't provide significant information and
may, indeed, add to confusion.  

We have been exploiting that mechanism for years in the names of
IETF WGs: they are almost all abbreviations for something, but
some of those abbreviations are from strings that are so
contrived that many active participants in the relevant WGs
would have trouble either expanding the string or recognizing
the name of the WG if spelled out without the abbreviation.
Quick, what is "lemonade" and, based on the expansion, what does
the WG do?

I suggest that, for standards-track documents, if there are
terms that are almost always used as words, with little or no
information value in treating them as abbreviations (even if
they were derived that way), we should just treat them as words.
An explanation in the body text (not the title or abstract) as
to where the term came from might well be appropriate, but
forcing a long title is, I believe, not in IETF's best interests
in these cases.

To take an example --not because it is an especially good one,
but because it showed up in my mailbox today-- the RFC Editor
recently announced publication of RFC 3839, "MIME Type
Registrations for
3rd Generation Partnership Project (3GPP) Multimedia files".
Now, as far as I have been able to tell, everyone who has
anything to do with 3GPP or its standards knows it as "3GPP".
The RFC that defines the original cooperation agreement from
which this work presumably derives, RFC 3113, uses "3GPP" as a
name.   If one writes out "Third Generation Partnership Project"
(I believe that "3rd..." is not even correct), the active users
of those standards are likely to have to stop to think about
what one is talking about.  So we are not adding information
value by this expansion: we are being fussy (never a good
property for an engineering body) and we are making the title
much longer, which, in turn requires a short form which is a
potential source of confusion.  If we treat "3GPP" as a name,
which is how it is used, we would have had "MIME Type
Registrations for 3GPP Multimedia Files".

Our problem in this example is further illustrated by the
observation that, if it is an abbreviation, we can't figure out
what the abbreviation is.    It is "Third Generation Partnership
Project" in RFC 3314 and 3589, "3rd-Generation Partnership
Project" in RFC 3445, treated as a name in RFC 3574, and
apparently "3rd Generation Partnership Project" in the most
recent case.  Perhaps the inability of experts to agree on what
the "abbreviation" stands for is further evidence that it has
become a word.

Again, am I the only one who is bothered by this?  And, if not,
can we ask the IESG to think a bit about this matter going
forward?

thanks,
      john

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John Stracke <[email-masked]>
Date: Wed, 14 Jul 2004 12:56:14 -0400

John C Klensin wrote:

>The expansion of it
It also makes it harder to search rfc-index.txt, since names can span 
line boundaries and abbrevations can't.

>anything to do with 3GPP or its standards knows it as "3GPP".
It's also reported in the trade press as 3GPP; I don't have anything to 
do with it, but I recognize 3GPP and didn't recognize "3rd Generation 
Partnership Project".

-- 
/=============================================================\
|John Stracke      [email-masked]                      |
|Principal Engineer|http://www.centive.com                    |
|Centive           |My opinions are my own.                   |
|=============================================================|
|Q: What goes "Pieces of 7! Pieces of 7!"? A: A parroty error.|
\=============================================================/

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 14 Jul 2004 10:34:27 -0700

At 12:08 PM -0400 7/14/04, John C Klensin wrote:
>Again, am I the only one who is bothered by this?

No, not all. The RFC Editor is about to release revisions to the 
S/MIME specs where "MIME" is spelled out, for example.

>   And, if not,

I'd certainly agree to this. It makes sense that if the RFC Editor is 
going to change something as major as the title of a document, that 
the IESG should at least see that with more than 48 hours to think 
about it.

--Paul Hoffman, Director
--VPN Consortium

---

From: Daniel Senie <[email-masked]>
Date: Wed, 14 Jul 2004 14:30:36 -0400

At 12:56 PM 7/14/2004, John Stracke wrote:
>It also makes it harder to search rfc-index.txt, since names can span line 
>boundaries and abbrevations can't.
>
>It's also reported in the trade press as 3GPP; I don't have anything to do 
>with it, but I recognize 3GPP and didn't recognize "3rd Generation 
>Partnership Project".

Now a different viewpoint. When looking at drafts as they go by on 
id-announce, nothing gets me more annoyed than reading the title and 
summary, and having no idea what the document is about. The audience for 
documents spreads beyond those working in the very specific area. New 
acronyms pop up often, and frequently the same acronym means different 
things to different folks in this industry. Spelling out is essential.

In the example given, the best solution likely is to say "Third Generation 
Partnership Project (3GPP)." In that way, those searching for the acronym 
will find what they want, and those trying to figure out what a document is 
about will learn the definition of the acronym.

My test when writing the abstract for a dradft is to make things 
sufficiently clear that anyone in the IETF, and most people in the 
networking business, will be able to get some idea of what the document is, 
regardless of the reader's particular focus area.

At the very least, someone reading the title and abstract of a draft (or 
RFC) should be able to come away with enough of a sense of the document to 
know whether it's a document they want to read and is applicable to them, 
or it's not.

Dan

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 14 Jul 2004 12:13:38 -0700

Hi -

> From: "Daniel Senie" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, July 14, 2004 11:30 AM
> Subject: Re: Names of standards-track RFCs
...
> things to different folks in this industry. Spelling out is essential.
...

Agreed.  Spelling things out becomes even more important as
documents age.  Consider, for example, "IMP" in some of the
older RFCs.  I suspect many IETF participants have never seen
or used one, yet this was probably considered "well known" when
those RFCs were written.

Randy

---

From: John C Klensin <[email-masked]>
Date: Wed, 14 Jul 2004 20:52:50 -0400

--On Wednesday, 14 July, 2004 12:13 -0700 Randy Presuhn
<[email-masked]> wrote:

>> Now a different viewpoint. When looking at drafts as they go
>> by on id-announce, nothing gets me more annoyed than reading
>> the title and summary, and having no idea what the document
>> is about. The audience for documents spreads beyond those
>> working in the very specific area. New acronyms pop up often,
>> and frequently the same acronym means different things to
>> different folks in this industry. Spelling out is essential.
> ...
> 

Randy, that is actually a pretty good example of the problem.
If I tell you that something is an "Interface Message
Processor", and you have no history (direct or indirect) that
goes back to the ARPANET, what are you likely to think it is?
Something to do with email or instant messaging, perhaps?
Certainly neither you, nor any search engine you are likely to
be able to apply, are likely to assume that it is a box of the
same general class of things as "router".

I think the solution to the problem that you and Dan raise
--which I acknowledge is legitimate-- is to insist that
abstracts really reflect purpose and context.  That is in the
current rules too -- if you, or Dan, can't figure out what
something is about from the abstract, than the process has
slipped up somewhere.  Personally, I think that should be a
legitimate Last Call issue -- I don't know if the IESG would be
very happy about Last Call response notes that say "I couldn't
figure out what this was about from reading the abstract, so
didn't review the document, but the abstract ought to be fixed
and then the Last Call restarted", but it would, IMO, focus the
issue correctly.  Certainly, a "good abstracts" rule is harder
to enforce automatically or objectively than "spell out
abbreviations", but trying to put the burden of explaining the
relevancy or lack thereof to someone else's work on a document's
title, with our without abbreviations, is just not feasible, at
least IMO.

best,
    john

---

From: "Dr Harsh Verma" <[email-masked]>
Date: Wed, 14 Jul 2004 23:43:01 -0700

Hi,

Ok, many of us have set up rules to move the WG emails to the appropriate
folders, so I am wondering how these email subject lines do not show the WG
name...

Request All to include a WG name in the subject line []s like [manet]. 
(which includes this email too!!)

I would think IETF moderator should add that, but which WG??

Thanks,
Harsh

---

From: grenville armitage <[email-masked]>
Date: Thu, 15 Jul 2004 17:09:46 +1000

> I would think IETF moderator should add that, but which WG??

My mysteriously functional email filter rules appear to work
just fine without extra crud in subject lines.... (but how
amusingly ironic a request for a thread on the topic of reducing
crud in RFC titles...)

gja

---

From: David Morris <[email-masked]>
Date: Wed, 14 Jul 2004 12:39:04 -0700 (PDT)

> know whether it's a document they want to read and is applicable to them,

Best served in my opinion by expanding acronyms in the body of the
abstract and not the title.  Well more specifically, in the announcement
email subject line since that improves processing of my inbox.

Dave Morris

---

From: Scott W Brim <[email-masked]>
Date: Thu, 15 Jul 2004 09:25:17 -0400

> amusingly ironic a request for a thread on the topic of reducing

Agreed, twice.

---

From: John C Klensin <[email-masked]>
Date: Thu, 15 Jul 2004 10:35:40 -0400

Hi.

Since I'm the apparent offender...

Those little inserts are a function of list management software
(which software is chosen and how it is configured), and not the
actions of individual authors (despite the indication I manually
included in this posting).  If a change in how the IETF list
works is needed, you probably need to take it up with the
Secretariat or the IESG.

best,
    john

--On Wednesday, 14 July, 2004 23:43 -0700 Dr Harsh Verma
<[email-masked]> wrote:

> Hi,
> 
> Ok, many of us have set up rules to move the WG emails to the
> appropriate folders, so I am wondering how these email subject
> lines do not show the WG name...
> 
> Request All to include a WG name in the subject line []s like
> [manet].  (which includes this email too!!)
>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 15 Jul 2004 17:24:07 +0200

Short answer:

No.

Long answer:

This item has been discussed to death once every 3 months on this very 
list. We have never found a consensus to add these tags.

                  Harald

---

From: David Frascone <[email-masked]>
Date: Thu, 15 Jul 2004 11:37:03 -0500

Not to feed the troll, but, if I remember correctly, the overwhelming
response is always:  we don't need it.  Procmail can filter fine without
it.

So, since there's no one vehemently opposed to it (that I can remember),
why not just turn it on, to avoid the quarterly request?  Not everyone
uses procmail / nice mailers to filter their mail.  Some people are even
forced to use Windows mailers! *shudder*

-Dave

-- 
David Frascone

    Fife. n. Small shrill instrument that rhymes with wife.

---

From: grenville armitage <[email-masked]>
Date: Fri, 16 Jul 2004 10:13:24 +1000

David Frascone wrote:
	[..]
> why not just turn it on,

Finally we're a true Standards Organization.

cheers,
gja

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 17 Jul 2004 01:05:11 +0200

>list. We have never found a consensus to add these tags.

It would be illusory to have everyone (consensus) accepting to be 
nice/polite to a few/many others and to conform to a de facto standard they 
did not write.

Tiring, but so human.

---

From: [email-masked] (Kai Henningsen)
Date: 18 Jul 2004 12:11:00 +0200

> list. We have never found a consensus to add these tags.

 List-Id: IETF-Discussion <ietf.ietf.org>
 List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
 	<mailto:[email-masked]?subject=unsubscribe>
 List-Post: <mailto:[email-masked]>
 List-Help: <mailto:[email-masked]?subject=help>
 List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
 	<mailto:[email-masked]?subject=subscribe>

If that's not enough for sorting, nothing is.

MfG Kai