[rfc-i] [IAB] Headers and Boilerplates is done.
John C Klensin
john+rfc at jck.com
Wed Nov 18 18:30:09 PST 2009
--On Thursday, November 19, 2009 10:31 +0900 Dave CROCKER
<dhc2 at dcrocker.net> wrote:
> Paul Hoffman wrote:
>> +1. That will be a lot clearer to the typical RFC reader five
>> or ten years from now than the current wording.
> The typical reader today -- nevermind 5 or 10 years from now
> -- does not know
> any of these names or acronyms, except perhaps the IETF.
> If the goal is archival precision, the proposed details will
> If the goal is to assist a reader outside of our immediate
> community -- a technician sitting in the Czech Republic,
> India, or Colombia -- then they need to be given the list of
> choices, to appreciate which one applies to the current
> Hence, for example:
> Source: IETF IRTF IAB **[Independent]**
> Source: **[IETF]** IRTF IAB Independent
> But the key point, here, is to help the reader to know that
> the alternative sources actually exist.
I'm somewhat sympathetic to where you are trying to go with
this, but I disagree with your conclusion. Consider three
(i) Most people, most of the time, ignore headers, boilerplate,
and headers that are boilerplate. For them, putting the stream
name in flashing lights, with or without other boilerplate,
would be unlikely to be noticed. That makes this whole
stream-labeling idea worthwhile for those who know enough about
what is going on to notice and dubious for anyone else. And
that "know enough about what is going on" group won't need the
(ii) I suggest that there is an intermediate group who might
notice but who would still not know what is going on. We can
disagree about the size of that group (I'm guessing "nearly
zero", but YMMD). For them
Source: IETF IRTF IAB **[Independent]**
is likely to look like some cryptic coding, without conveying
information that this is about some stream. If we had the
ability to "grey-out" or dim all but one of the stream names and
to display the relevant one in dark, bold, characters, then I
think the point would be clear. But the suggestion above is
just more coding... coding that would be understood by those who
don't need it and opaque to those who do.
(iii) In principle, the list of streams is open-ended. We may
add to it, or, in principle, delete a stream name or two,
without reissuing any RFCs (since we don't do that). If we,
RFCs that show a historic name that does not apply to the
document at hand become even more cryptic and confusing.
I can think of two ways out of this situation:
(1) Go back to not labeling individual RFCs with the stream at
all, instead inserting something like:
See the RFC Index and BCP NNN for the originating
stream for this document.
In some propitious place, and then rely on the index (which
can/does contain explanations) for stream identification, just
as we rely on it for maturity levels. I think we know how well
that works, but it is an option.
(2) The second is suggested by another remark in your note, i.e.,
> In fact, it would probably also be useful to list the entire
> set of text choices proposed on this thread, somewhere in the
> boilerplate, to map the acronym to the full name.
Given the potential volatility of the list of options, we could
(a) Replace, e.g.,
Source: Independent Submission
Originating Stream*: IETF
Originating Stream*: Independent Submission
"originating stream" is going to be a lot more clear to anyone
who notices than "source" and the asterisk in that context,
"**[[...]]**" is a well-understood (probably
universally-understood) indicator. And
(b) Add to the introductory boilerplate (ideally to the page 1,
and only page 1, footer, but we may not need that complexity),
* RFCs originate from different "streams"; see RFC 4844
I'd rather use a "current version" stable reference like "BCP
nnnn" there, but RFC 4844 is informational, so, until and unless
someone wants to write a summary of stream names that the IESG
is willing to publish as a BCP, we are probably stuck with the
RFC reference. On the other hand, that is probably ok: it will
change only very rarely, is RFC Editor material rather than
something that would appear in I-Ds, and would reflect the
stream definitions at the time the document is published.
More information about the rfc-interest