Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-00.txt

From: [email-masked]
Date: Fri, 03 Feb 2012 16:14:08 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF.

	Title           : Media Type Specifications and Registration Procedures
	Author(s)       : Ned Freed
                          John C. Klensin
                          Tony Hansen
	Filename        : draft-ietf-appsawg-media-type-regs-00.txt
	Pages           : 29
	Date            : 2012-02-03

   This document defines procedures for the specification and
   registration of media types for use in HTTP, MIME and other Internet
   protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-00.txt

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 4 Feb 2012 07:38:23 +0200

Hi all,

Looking through this document again...

I don't really know whether comments from
http://www.ietf.org/mail-archive/web/happiana/current/msg00184.html have
been considered (at least, no response from authors have been received so
far), but here is what I see in the current version with respect to the
issues these comments concerned:

--citing begins (my comments in-line starting with "MY>")--

Ned, all,

Some additional (to Julian's) comments.

In Abstract, it must be mentioned that the document obsoletes RFC 4288.

MY> Still relevant.

I find the current text in Introduction very confusing (or irrelevant), as
it is very generic and not related to media types. It should be rewritten
to make clear the goal of the doc. I also concur with Julian that
Historical Note should be moved in the Introduction section.

MY> Now Introduction seems fine.

In Section 3.1: when specifying the procedures for registration media types
in Standards Tree, you mentioned (in terms of RFC 5226): IESG approval,
Specification Required, IETF Consensus, RFC Required with IESG Approval,
i.e. 4 different registration policies. Whereas they serve a variety of
possible cases, I think we would benefit from a single policy which would
cover all of them. I suppose it is "Specification Required with IESG
Approval" that would cover the following cases: (1) IESG-approved document,
(2) specification of other standards body; registration undergoing IESG
approval, (3) non-IESG-approved RFCs, registration of which also undergo
IESG approval. The possible cases may also be discussed, though.

MY> Also relevant in this version.

Section 3.3: the "vanity" naming. I may be wrong cause it may be some sort
of stylistic choice, but I actually think that "personal" is enough to
characterize this tree. Whereas English native speakers would understand
such naming, this would be frankly difficult for those who speak English as
a foreign lang. I can't manage to find Russian or Ukrainian translation of
RFC 4288 to prove, but I'm sure that the said formulation is applicable in
English language only, and isn't appropriate for the international-scoped
document.

MY> Relevant as well.

Section 3.4: this is what Julian has already mentioned for Section 4.2.
APPSAWG is obliged to bring the draft deprecating x- to BCP, so if we
revising the procedures docs, we need to take it into account. I propose
you remove Section 3.4 and naming convention from Section 4.2 but put a
note in Appendix B referring to the RFC-to-be. <later when="after reading
reply to Julian's message">I think that if we produce new version of the
doc we should take into account the current practice documented as BCP (and
I hope it will get BCP). At least you should note that their registration
is not absolutely prohibited; I also agree that in exceptional cases they
can be registered, but only if wide use is demonstrated.</later>

MY> Current WG draft on deprecating x- says nothing on this, so I think we
still should mention something in this document.  Let'as consider my above
proposal.

Section 4.2: Shouldn't it explain the differences between RFC 2045 and the
given ABNF?

Section 4.10: "Proposals for media types registered in the standards tree
by the IETF itself MUST be published as RFCs.". Do you really mean
"proposal"? Also, do we need to encourage publishing RFCs for vnd and prs
registrations?

MY> This is ok in the current version.

Section 5.1: "Registrations in other trees MAY be sent to the list for
review as well." Maybe SHOULD?

MY> Fixed; thanks.

Section 5.9: Do we need to leave mail-style lines in the template (I mean
To: and Subject:)?

MY> (Now s5.7), and fixed in the doc.

Ibid:  Please move the para about MacOS file types into Section 4.11.

MY> Now moved, I see.

Section 6: s/RFC 3978/RFC 5378/ (and in References)

MY> This is fixed.

Sections 6 and 8: As your document sets up the registry for +suffixes, it
should contain the description as required by RFC 5226, which it currently
doesn't have.

MY> This comment still applies.

--citing ends--

These are my November comments, and so I suppose there could be more while
discussing the document.

Mykyta Yevstifeyev

2012/2/4 <[email-masked]>

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Applications Area Working
> Group Working Group of the IETF.
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Ned Freed <[email-masked]>
Date: Fri, 03 Feb 2012 22:52:03 -0800 (PST)

> issues these comments concerned:

Yes, I did take them into consideration.

> In Abstract, it must be mentioned that the document obsoletes RFC 4288.

A stupid rule in my opinion, but a rule nevertheless. I forgot to add it
but will do so in the next revision.

> MY> Now Introduction seems fine.

I actually didn't change anything in response to your comment because I
couldn't figure out how to do so, so I'm a little confused as to why you think
it's OK now but not before, but as you think it's OK now I guess it's all good.

> MY> Also relevant in this version.

If I understand what you're trying to do, not going to happen. The main point
of this revision is to remove the need for the IESG to be involved in the
approval of standards tree types from other SDOs, while retaining their role in
IETF registration approval. As such, your suggestion for a single policy for
all registrations is totally inconsistent with the fundamental goal of this
revision.

> MY> Relevant as well.

I'm sorry, but I really don't see the point of removing it. It's not
like it has ever proved to be a source of confusion in the past.

> can be registered, but only if wide use is demonstrated.</later>

First of all, the WG is in no way "obliged" to do anything. It may in fact fail
to reach consensus and not do anything about x-.  The draft in question is
still being actively debated, and there appears to be some controversy. I'm
waiting to see the outcome of that before taking any action on this point, as
it's possible the whole x- thing may prove to be a lot more problematic than
some suppose.

> still should mention something in this document.  Let'as consider my above

I was thinking of going further and saying something like "the restriction
on registration of x- types that appeared in previous document has been
dropped" or something along those lines, but I really want to wait.

> Section 4.2: Shouldn't it explain the differences between RFC 2045 and the

Nope. I very intentionally chose not to get into the historical details of why
the restrictions exist. This is a document focused on getting registrations
done. The origin of the restrictions or comparisons to what they were
historically do not assist in that goal in any way that I can see.

> MY> This is ok in the current version.

I agree and not only that, I removed the word "proposal" in several other
places as well in response to your comment. (There's still one left that I
believe is necessary - I took it out but was convinced it needed to go back
in.)

> MY> (Now s5.7), and fixed in the doc.

Yeah, it was unnecessary.

> MY> Now moved, I see.

Actually, no, I didn't move the pointer to the reference out of the template,
and I should have. This is now sufficiently obscure that having it in the
template is a distraction. (Again, focus focus focus on getting registrations
done with as few distractions as possible.) I'll move it.

> MY> This comment still applies.

Description where? I do not understand this one. I also do not see the 
requirement you're talking about anywhere in RFC 5226. (The word description
appears exactly twice, and neither time in a requirement.)

> --citing ends--

You might want to look at the open issues list and consider if they are good
ideas or not.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Sat, 04 Feb 2012 09:05:05 -0500

(changing subject line because this is really a separate topic)

--On Friday, February 03, 2012 22:52 -0800 Ned Freed
<[email-masked]> wrote:

>...
> A stupid rule in my opinion, but a rule nevertheless. I forgot
> to add it but will do so in the next revision.

Actually, as co-author, I want to strongly resist this change
and therefore that putative rule (I claim that, independent of
its substantive properties, it is invalid; see below).   I have
three separate reasons, any one of which would, IMO, justify
saying "no".   

Rant follows.

(1) Abstracts are supposed to be about the content and function
of the document and are supposed to be as minimal as possible
while still covering the actual substance.  Except in unusual
cases, which this is not, mentioning the history and
relationships of a document in the Abstract is not substantively
important to someone who is simply looking at it to find the
present state of things, as would be the case with this once it
is published.   Worse, except for RFCs that are much better
known by their numbers than by their titles (there aren't many;
RFC 822 comes to mind as an example), good practice requires
citations on first use to explain what the number refers to.
But the RFC Editor's practice (and almost every style manual for
professional publications in the world) prohibits citations from
Abstracts -- they are supposed to stand on their own. Things
might be different if the sole purpose of a document were to
obsolete or reclassify another one, but that does not apply in
this case.  

That may be a very long way of saying "stupid rule".

(2) Determination of what should be required or permitted in
Abstracts in published RFCs has always been an RFC Editor
matter, not something the IESG can change, any more than they
can unilaterally change page header or footer formats.  Note
that we already have a header on the first page (almost always
the same pages as the abstract since we fixed the "boilerplate
first" problem), so, stylistically, there is a "how much
overkill is needed" question.  FWIW, I don't have any problem
with the IESG imposing an "explain what this updates and why"
requirement on the body of a document, although I believe even
then that they ought to have a discussion with the RFC Editor
about placement (e.g., Introduction versus separate section or
subsection).  

I believe that the "Status of Document" section of IETF Stream
RFCs basically belongs to the IETF and IESG, so, if the IESG
wants some particular "obsoletes XXX" text there, I might still
think it was stupid, but I wouldn't consider it nearly as
inappropriate as imposing requirements on the abstract.   In
addition, I think the IESG, subject to community review, can
impose whatever requirements they think necessary on I-Ds to get
effective review of documents.  I think the rule requiring that
all IETF Stream I-Ds contain an "IANA Considerations" section
that can be removed on publication is ill-advised and have seen
a number of problems that can be attributed to the rule itself.
But, if the IESG, after careful deliberation, is convinced that
it is helpful to the review and consensus process, I'm ok with
it and will conform without saying much of anything.   The same
principle might apply here: if the IESG wants to say, e.g., that
obsoleting or reclassification relationships should be reflected
in an extra paragraph of the Abstract that is removed on
publication and hence not subject to the RFC Editor's rules
about length and content, I'll mutter into my beard, but will
comply.

(3) Although they can make suggestions and determine their own
practices, the IESG doesn't get to invent and make binding rules
for the community.  The Tools Team may incorporate what they
consider reasonable practices into checking tools (I'm strongly
in favor of that, actually), but that doesn't make those
practices binding on the community either.  In both cases, the
difference between "strong suggestion" and "requirement" has
always been community consensus.  That hasn't occurred here --
there has been no document for which community discussion has
occurred and consensus sought.  What we have is 

 (i) a statement in Section 3(1)(D) of the I-D checklist
	http://www.ietf.org/id-info/checklist.html (a fine
	document if taken as strong suggestions)
 (ii) a check in the the I-D nits tool.
 (iii) a few statements, e.g., in the checklist itself
	and the Shepherd template that effectively make the
	above normative.

There has not been an explicit consensus call on this
requirement in on any of the above contexts.

In the interest of efficiency, I'm even ok if the IESG sets
requirements and puts them into effect immediately, issuing
formal consensus calls only later or if there are objections
from the community.  Well, I'm objecting, I have objected in the
past, and, while the the IESG hasn't issued a consensus call,
they have published Standards Track documents in the IETF Stream
that do not contain "obsoleting" information in the abstract. 

And, again, even if the IESG asked for community consensus and
got it, it isn't clear that they can impose requirements on the
content of abstracts without the concurrence of the RFC Editor.

   john-the-grump

---

From: John C Klensin <[email-masked]>
Date: Sat, 04 Feb 2012 09:24:06 -0500

--On Friday, February 03, 2012 22:52 -0800 Ned Freed
<[email-masked]> wrote:

>...
>> Section 3.3: the "vanity" naming. I may be wrong cause it may
>> be some sort of stylistic choice, but I actually think that
>> "personal" is enough to characterize this tree. Whereas
>> English native speakers would understand such naming, this
>> would be frankly difficult for those who speak English as a
>> foreign lang. I can't manage to find Russian or Ukrainian
>> translation of RFC 4288 to prove, but I'm sure that the said
>> formulation is applicable in English language only, and isn't
>> appropriate for the international-scoped document.
> 
>> MY> Relevant as well.
> 
> I'm sorry, but I really don't see the point of removing it.
> It's not like it has ever proved to be a source of confusion
> in the past.

Mykyta, slightly different (and longer) answer: I think "vanity"
is obnoxious and always have.  For reasons that have nothing to
do with this particular usage, I'd prefer that it not be there.
But such changes in wording in revisions almost always have
consequences, some of which we don't anticipate, so I'm
reluctant to make them unless there is evidence that they cause
a problem.   As Ned says, there is no evidence that this has.
If the text said "Vanity Tree, sometimes known as 'personal
tree'" or "Vanity (Personal) Tree", or if the facet designator
was "vnt" or equivalent, I'd feel differently about this.  But
"Personal or Vanity" does not require that anyone pay any
attention to the implicit "vanity" sub-branch, so the risks of
making a change that might confuse people or require an
explanation seem to me to far outweigh the problems with the
existing text, problems that seem to be limited to offending the
tastes of several of us.

>> Section 3.4: this is what Julian has already mentioned for
>> Section 4.2. APPSAWG is obliged to bring the draft
>> deprecating x- to BCP, so if we revising the procedures docs,
>> we need to take it into account. I propose you remove Section
>> 3.4 and naming convention from Section 4.2 but put a note in
>> Appendix B referring to the RFC-to-be. <later when="after
>> reading reply to Julian's message">I think that if we produce
>> new version of the doc we should take into account the
>> current practice documented as BCP (and I hope it will get
>> BCP). At least you should note that their registration is not
>> absolutely prohibited; I also agree that in exceptional cases
>> they can be registered, but only if wide use is
>> demonstrated.</later>
> 
> First of all, the WG is in no way "obliged" to do anything. It
> may in fact fail to reach consensus and not do anything about
> x-.  The draft in question is still being actively debated,
> and there appears to be some controversy. I'm waiting to see
> the outcome of that before taking any action on this point, as
> it's possible the whole x- thing may prove to be a lot more
> problematic than some suppose.

While I agree with Ned, I note that, in any event, the document
already discourages "x-" and "x." registrations.  The
newly-proposed "deprecated alias" mechanism actually provides a
path to get rid of the things, which may be far better (and, for
better or worse, more consistent with the spirit of the xdash
draft) than trying to set up criteria for "wide use" and then
enshrining them forever.

    john

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 4 Feb 2012 16:46:49 +0200

2012/2/4 Ned Freed <[email-masked]>

> it's OK now but not before, but as you think it's OK now I guess it's all

I don't remember what was "confusing" there as I'm looking at -01
individual version, so I think "I guess it's all good" is good.

> all registrations is totally inconsistent with the fundamental goal of this

I meant procedure for Standards Tree only, and in no way for all
registrations.  The four policies I listed are mentioned in Section 3.1
only, which defines Standards Tree procedures.

> like it has ever proved to be a source of confusion in the past.

I'll reply to John's response.

> it's possible the whole x- thing may prove to be a lot more problematic

That was what I saw the consensus was at the time of writing.

> dropped" or something along those lines, but I really want to wait.

Agreed, let's wait.

> historically do not assist in that goal in any way that I can see.

Having no objections to not mentioning this in the document.

> done with as few distractions as possible.) I'll move it.

And again I don't remember what I meant in November... but the current
situation is fine.

> appears exactly twice, and neither time in a requirement.)

I mean your description in Section 6 should follow Section 4.2 of RFC 5226.

> You might want to look at the open issues list and consider if they are

Commenting on the 'open issues':

   o  The list of fields in the registration is getting long.  Should
      the fields be numbered and referred to by number in order to
      facilitate translation into other languages and similar
      activities?

Whereas I'm not a native English speaker, I can say that this won't help in
translation in any way (I can't imagine such way, at least).  Also, what
are 'similar activities' here?

   o  Currently anyone can register a vendor media type on behalf of a
      vendor but subsequent to that only the vendor can make changes.
      Do we want to retain this restriction?

I think we should allow registering vnd types by anyone with vendor's
approval (or by tacit agreement if vendor is ignoring the proposal), and to
change the registration in a similar way.

Mykyta Yevstifeyev

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 4 Feb 2012 16:54:21 +0200

2012/2/4 John C Klensin <[email-masked]>

> existing text, problems that seem to be limited to offending the

While this is really not a matter of life and death, I think retaining the
old name should be fine, and so withdrawing my concern.

> draft) than trying to set up criteria for "wide use" and then

Yes, and so let's better wait for what appsawg 'x'-deprecating draft
finishes in, and than see what we can do with this one.

Mykyta Yevstifeyev

---

From: Ned Freed <[email-masked]>
Date: Sat, 04 Feb 2012 07:13:06 -0800 (PST)

> only, which defines Standards Tree procedures.

But that's exactly the point. We're not talking about anything but standards
tree registrations here. Yet there are two completely different processes for
registering types in the standards tree. You appear to be asking for there to
be only one, and having two is the entire point of this revision.

Now, if you want to talk about there being a simpler or different set of
criteria for or the other of those processes, then you're going to have to make
a strong case for doing so. As it is I'm just not seeing any rationale for
changing anything in section 3.1.

> I mean your description in Section 6 should follow Section 4.2 of RFC 5226.

I don't actually see anything in RFC 5226 that says you have to define
a registry using a particular layout in your document - all it says is that
certain information has to be provided. And with one important exception,
all of that information is currently present, just not in that format.

That said, a thought occurs. This is a new registry that's not currently
set up, and that means we need to call out the action to create it in the
IANA considerations section of this document. So what I'm going to do is
add that action to the IANA considerations, which will appear as a list
more or less conforming to the list in section 4.2 of RFC 5226. (Most of
the list items will simply be references to other sections of the
current document.)

The sticking point is the initial registry content. I really don't want  to
clutter up an important process specification that's intended to be used for a
long period of time with this crap that's only useful once. (I've always
objected to this requirement in RFC 5226 - I think it's excessive rigidity
causes more problems than it solves.) So I'm going to try to finesse it by
saying that an initial list of the content of the registry effectively already
exists and is in IANA 's hands - it's the list of conforming suffixes in
current use in the existing media  types registry - and direct the media types
reviewers to, at the time of registry creation, extract that list and use it as
the initial registry content. This also addresses the possibility that an
additional legitimate suffix should show up and get registered under the
current rules, making having a static list in a document somewhat problematic.

> are 'similar activities' here?

Since this one is not my idea I'll let other folks respond. (It's entirely
possible I failed to describe or justify it properly.)

> change the registration in a similar way.

That approach actually sounds pretty good to me. Let's see what others think.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sat, 04 Feb 2012 07:59:47 -0800 (PST)

Initial response: *gulp*

I obviously don't feel nearly as strongly about this as John does, although I
completely agree with everything he says. So I'm going to defer to him entirely
on this point. I won't add anything to the document at the present time and
we'll see how it goes.

And with that, I actually think it's time to post -01. It should be out
in a few minutes.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Sat, 4 Feb 2012 13:12:46 -0500

> three separate reasons, any one of which would, IMO, justify

Contrary to John's rant (which, dont you know, I was shocked to see,
shocked, I tell you), the IESG does not treat this as a hard-and-fast rule,
but, in fact, more as a "strong recommendation".  ADs normally don't use
DISCUSS to comment on this, but non-blocking COMMENT.  And the PROTO
writeup can call it out and say that it's intended this way.

Either Alexey or I will shepherd this.  I, for one, am happy to call this
out in he writeup.

Barry, as chair

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 4 Feb 2012 16:42:17 -0800

+1 to John's rant.  I really hate all of the useless status bits that we have
in the abstracts for HTTPbis.  People who read the document five years from
now don't care how many older RFCs it updates or obsoletes.

They belong in the Introduction, where we describe the history of the protocol.

....Roy

---

From: John C Klensin <[email-masked]>
Date: Sat, 04 Feb 2012 20:08:23 -0500

--On Saturday, February 04, 2012 16:42 -0800 "Roy T. Fielding"
<[email-masked]> wrote:

> +1 to John's rant.  I really hate all of the useless status
> bits that we have in the abstracts for HTTPbis.  People who
> read the document five years from now don't care how many
> older RFCs it updates or obsoletes.

Yes.  Remember that someone who already knows that RFC 9999 is a
protocol spec, and the one they are looking for, probably won't
even look at the abstract.  The abstract is much more likely to
be useful to people who are trying to figure out if they have
the right spec or should keep looking, and a sentence that says
"This obsoletes RFC NNNN." is of even less use to them.

> They belong in the Introduction, where we describe the history

Lest we substitute one bad rule for another, I wish the above
paragraph had said "They belong wherever we describe the history
of the protocol".    Sometimes -- I'd even guess "usually" --
that should be the Introduction (sometimes a separate subsection
of the Introduction), but sometimes it should be a separate
section of the document, an appendix, or even another document
with a clear citation and reference from the protocol spec.  

Even though I recognize the advantages to the community of
always having particular kinds of text in particular places or
order, that really ought to be a matter of editorial judgment
(with or without advice about defaults and preferences) rather
than one of rigid-appearing rules.

    john

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 5 Feb 2012 00:21:40 -0800

> with a clear citation and reference from the protocol spec.  

Actually, I was referring specifically to HTTPbis.  I have no need
for a rule -- it just happens to be where we describe the history.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Sun, 05 Feb 2012 11:58:29 +0100

> They belong in the Introduction, where we describe the history of the protocol.

+1

---

From: Julian Reschke <[email-masked]>
Date: Sun, 05 Feb 2012 12:16:42 +0100

> They belong in the Introduction, where we describe the history of the protocol.

Some HTTPbis context:

   <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/254>

which cites

   <http://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html>

which in fact doesn't even mention the Abstract, but it does mention the 
Introduction.

Is there another written rule around?

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Sun, 05 Feb 2012 10:48:30 -0500

--On Sunday, February 05, 2012 12:16 +0100 Julian Reschke
<[email-masked]> wrote:

> which in fact doesn't even mention the Abstract, but it does
> mention the Introduction.
> 

The cause of this particular problem is
http://www.ietf.org/id-info/checklist.html , section 3(1)(d).

   john

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 05 Feb 2012 12:46:25 -0800

On 2/4/2012 10:12 AM, Barry Leiba wrote:
>the IESG does not treat this as a hard-and-fast rule, but, in fact,
> more as a "strong recommendation".  ADs normally don't use DISCUSS to comment on
> this, but non-blocking COMMENT.  And the PROTO writeup can call it out and say
> that it's intended this way.

I just posted a note to the RFC Editor suggesting that all this points to some 
benefit in reviewing and revising the RFC Style guide.

In the current case:

1. I happen to believe that RFCs usually should not contain information that 
ceases to be interesting; that is, that has a short lifetime of usefulness.  For 
some odd reason, I think of an RFC as having a twenty-year or more span of 
utility.  From that perspective, what it obsoletes isn't useful in the Abstract, 
especially since Abstracts are supposed to be information-dense.

2. Authors should not have to guess about what is an absolute rule and what isn't.

3. The rationale for the rules should be provided.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Barry Leiba <[email-masked]>
Date: Sun, 5 Feb 2012 16:29:18 -0500

> I just posted a note to the RFC Editor suggesting that all this points to
> some benefit in reviewing and revising the RFC Style guide.

Agreed; and then we need to reflect those changes into the I-D checklist.

> From that perspective, what it obsoletes isn't useful in the
> Abstract, especially since Abstracts are supposed to be information-dense.

It's particularly not useful because the abstract is, at least with
the current template, on the same page as the header information,
which already contains the obsoletes/updates information.  To my mind,
that makes it 100% useless to include that in the abstract.  I would
support a recommendation that specs SHOULD explain in the introduction
*why* this document obsoletes another if the reason is not blazingly
obvious (obvious as when, for example, RFC 5321 obsoleted RFC 2821).

> 2. Authors should not have to guess about what is an absolute rule and what

Clearly right.

> 3. The rationale for the rules should be provided.

I think explaining rationale is usually valuable, and am curious when
I see various reviewers push back on such things, saying that they
don't see the need for it.

Barry

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 5 Feb 2012 16:31:19 -0500

On Feb 5, 2012, at 3:46 PM, Dave CROCKER wrote:

> I just posted a note to the RFC Editor suggesting that all this points to some benefit in reviewing and revising the RFC Style guide.

Although as John noted, this rule is actually from the IESG. Barry suggests that it might not always be enforced; I would hope that the document that John linked to (as compared to the RFC Style Guide) could be updated as well.

--Paul Hoffman

---

From: Julian Reschke <[email-masked]>
Date: Sun, 05 Feb 2012 22:48:05 +0100

On 2012-02-05 21:46, Dave CROCKER wrote:
> I just posted a note to the RFC Editor suggesting that all this points
> to some benefit in reviewing and revising the RFC Style guide.
>
> In the current case:
>
> 1. I happen to believe that RFCs usually should not contain information
> that ceases to be interesting; that is, that has a short lifetime of
> usefulness. For some odd reason, I think of an RFC as having a
> twenty-year or more span of utility. From that perspective, what it
> obsoletes isn't useful in the Abstract, especially since Abstracts are
> supposed to be information-dense.
>

+1

I can see that it's useful for the RFC Editor to be able to easily find 
out what changes to the RFC Editor database are required. Maybe just 
introduce something similar to the "IANA Considerations"?

---

From: John C Klensin <[email-masked]>
Date: Sun, 05 Feb 2012 17:28:50 -0500

--On Sunday, February 05, 2012 22:48 +0100 Julian Reschke
<[email-masked]> wrote:

> I can see that it's useful for the RFC Editor to be able to
> easily find out what changes to the RFC Editor database are
> required. Maybe just introduce something similar to the "IANA
> Considerations"?

Julian,

I think it would help this discussion if we avoided conflating
too many issues.  But, fwiw, there isn't a lot of information in
the database or information needed to construct/ update it.
Unless that changes, 100% of the information that is needed for
"obsoletes" is contained in the "updates" header at the top of
the page.   As Barry pointed out, if the "updates" header is
there an almost-content-free sentence in the abstract that says
"this updates that" is pretty close to 100% useless.

FWIW, and generalizing a bit from an earlier comment, I think it
would be worthwhile for the community and the IESG to explore
types of information that are really useful in the review and
publication process, including updating databases of various
sorts but that fall somewhere on the spectrum between "useless"
and "actively confusing" in the long term.    If the IESG wants
some additional information in a specific form in I-Ds to help
with reviews, I think  that is fine.  Similarly, I think putting
the entire desired contents of a new (and potentially large)
registry as part of instructions to IANA is useful.  But either
should be carried into an RFC is an open question and, while I
think there are lots of edge cases and places where careful
consideration is going to be necessary, a translation of Dave's
comment into a "will this be useful in 20 years or just a
distraction" criterion seems quite useful to me.

So, just as I'd like to see any suggestions about "updates"
sentences in an I-D Abstract either dropped entirely or having
that text dropped before RFC publication, I'd much rather see
the published version of "IANA Considerations" (where it is
included at all) reduced to a summary description of what IANA
was asked to do and did, with a pointer to the registry if
appropriate, rather than the listing of code points and
descriptions that might be entirely reasonable in an
I-D/proposal.

My guess is that a thoughtful examination of what we are doing
to and with the RFC Series (IETF Stream and more generally)
might yield more examples of the underlying principle that
implies.

   john

---

From: SM <[email-masked]>
Date: Sun, 05 Feb 2012 13:48:03 -0800

Hi Julian,
>Is there another written rule around?

See Section 4.1.1 of 
http://www.rfc-editor.org/rfc-style-guide/rfc-style  I read it as a guideline.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 05 Feb 2012 15:03:16 -0800

> Although as John noted, this rule is actually from the IESG.

Existing documentation still has remnants of confusion about what is IETF stream 
policy versus, for example, overall RFC Editor policy.  These are items to 
reconcile as they are discovered.

I suppose the larger question for the IETF stream is whether its RFC-related 
policies should be set by the IESG or by the IETF...

d/

-- 

   Dave Crocker

---

From: Ned Freed <[email-masked]>
Date: Sun, 05 Feb 2012 16:17:14 -0800 (PST)

> which already contains the obsoletes/updates information.

Well, the theory, as I understand it, is that the Abstract is actually a
separable entity designed to be extracted and use elsewhered. Therefore it
needs to be self-contained, to the point where it duplicates stuff that's on
the same page.

There are two problems with this theory, however. The first is that separable
Abstracts make all sorts of sense when the full document is not readily
accessible (only in print journal, behind a paywall, blah blah blah.). But
that's not the case for RFCs. It might have made sense even for RFCs when data
transfer was expensive, but these days pulling out the Abstract is more trouble
than it's worth - why not just send the whole thing? The only remaining
use-case I can think would be some sort of index, and any such index done
competently will include much more extensive forward and backwards pointers of
its own. (And it is axiomatic that the far more important forward pointers, 
that is, "this document is obsoleted/updated by RFC N", cannot possibly appear
in the Abstract.) 

The second problem is really an extension of my point about forward pointers.
Simple backwards pointers just don't give enough context to justify cluttering
what should be a straightforward statement of what *this* document does..

> To my mind,

Agreed. And in the process it adds the context these simple statements in the
Abstract lack.

				Ned

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 06 Feb 2012 09:49:41 -0800

> that is, "this document is obsoleted/updated by RFC N", cannot possibly appear

There's a big difference between sending out a notice that includes 
one-paragraph summary (the Abstract) versus automatically including the entire 
document of 20-100 pages.

The exercise of producing a one-paragraph summary requires some discipline and 
understanding of the work that was done.  I see this as a meaningful value-add, 
over the full detail of that work which is the entire document.

d/
-- 

   Dave Crocker

---

From: Ned Freed <[email-masked]>
Date: Mon, 06 Feb 2012 10:05:26 -0800 (PST)

> document of 20-100 pages.

Actually, Dave, my point is that I actually disagree with this assessment. It
used to be true. Not anymore. Bandwidth being what it is, nowadays people are
lazy and just sent the whole thing. In fact people forward groups of articles
to me - sometimes very large groups - fairly regularly and of late the only
time I can recall them bothering to just send the abstract is when that's all
they have.

This is even, and perhaps especially, true when the article is a PDF. (Adobe
seems to be making it harder and harder to extract portions of the text.)
People just don't care about size any more.

> over the full detail of that work which is the entire document.

I think that the abstract's value has dropped exponentially for RFCs - and I
also think it's reflected in the quality of the abstracts we see these days.
(When I-D announcements come out I increasingly find myself having to click on
the link to find out what the draft is actually about.) I also think it is a
problem not worth spending time solving, for reasons that should be obvious.

				Ned