[rfc-i] RFC means RFC, not Request For Comment

Olaf Kolkman olaf at NLnetLabs.nl
Tue Oct 25 06:55:54 PDT 2011


Not a matter of content but a matter of timing.

You probably know that an RFC Series Editor is being hired. That person will be the person to drive the evolution of the series and be a significant stakeholder in implementing any changes. I would assume that an RSE would be (together with the community) instrumental in trying to assess the pros and cons of such proposal. The RSE would also be instrumental for the implementation.

Proposals like this are right within the purview of the future RSE and it would be nice to have discussions like this when we have a new RSE on board.

Would it be an option to stall discussion for a while and re-open in say half a year from now?

--Olaf (not necessarily wearing a hat)

On Oct 25, 2011, at 3:48 PM, Eric Burger wrote:

> Summary:
> 1. Trademark the RFC image
> 2. Mark IETF standards track documents with a RFC logo
> Background:
> Most people who have done expert witnessing or described the Internet standards process quickly learn there is confusion over what the term RFC means.  A typical exchange goes something like party A says they built something that does FOO.  The definition of FOO comes from RFC XXXX.  Party B says that party A's claim is meaningless because and RFC is a Request For Comments, and as such does not define anything. As an example, one party offered that RFC 3550, also known as *STD 64*, was only a suggestion.
> At the other extreme are independent stream documents that are meant to document existing, yet not IETF, standards.  As an example, consider RFC 3435.  No matter how much we say that an RFC is not necessarily a protocol, and a protocol published as an RFC is not necessarily endorsed or supported by the IETF, people will be confused.  In the days when an RFC number was an index to a file and only people who knew what they were knew where to get them, this distinction was fine.  However, today the term RFC is now a brand that vendors and consumers of technology look for.  To the community, the term RFC YYYY means something that has value as an independently reviewed, cross-functionally reviewed, scalable and secure protocol.  This is the very definition of a brand and brand positioning.
> There have been many proposals in the past to change the names of the various streams.  In fact, we sort of have that with STD, BCP, and FYI numbers.  However, for one reason or another, some of which are reasonable, the RFC Editor has not been able to drop the RFC side of the equation.
> I have two, related proposals.  The first proposal is to register the image, in ASCII art as well as potentially a nice PNG for HTML and PDF versions of documents, that captures the letters RFC.  Since RFC no longer means Request For Comments, let's register this special term.  This is important as it also prevents someone someplace else to start publishing things called RFC's.  So long as RFC just means Request For Comments, there is nothing we can do to protect our important brand.  [This proposal is why the IETF Trust list is on this distribution.]
> The second proposal is to include the image, and perhaps a large-scale block ASCII art version of the RFC logo on the front matter page of an IETF standards track publication.  This addresses the fact that all RFCs look alike.  Non-IETF standards documents come with a toxic waste warning well down in the weeds.  That is like a discrete health department notice saying that cigarettes might hurt you, in 6-point font, on the side of a box of cigarettes.  What this is proposing is we put a nice big gold seal that says This Is Good For You - Do Not Accept Anything Less on a real, IETF standards track document.
> Thanks.
> --
> - Eric_______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest


Olaf M. Kolkman                        NLnet Labs


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2210 bytes
Desc: not available
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20111025/26ca50ee/attachment-0001.p7s>

More information about the rfc-interest mailing list