Re: [Gendispatch] I-D Action: draft-nottingham-where-does-that-come-from-00.txt

Eliot Lear <> Mon, 15 March 2021 13:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B4673A115F for <>; Mon, 15 Mar 2021 06:15:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -11.9
X-Spam-Status: No, score=-11.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id idFdsUdgoP5b for <>; Mon, 15 Mar 2021 06:14:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D07403A115E for <>; Mon, 15 Mar 2021 06:14:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=42909; q=dns/txt; s=iport; t=1615814099; x=1617023699; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=zgF767/yjKitgkjeTZTT5ZVPAJak49zCoVYsUJWw3qk=; b=DD//+9snrzmPmEvc08CMs1ue0UUxgKN4DOWVcYk0CwEMQUOwuqtZB0nn +RZJGZS02GIl3YX1YMMGHw/WgLz6iYO+/i+GmCUzz3Bm4VGFHJ9vNjWuR G7ci4taQ9fxewx7XC+waNcAI+U45WCmyjGCjob/zY8bFKmpVy3uITZOzq g=;
X-Files: PastedGraphic-1.png, signature.asc : 24330, 488
IronPort-HdrOrdr: A9a23:WtoH1qnHkrVrmR9s9oWzevNB03fpDfKu3DAbvn1ZSRFFG/Gwvc rGpoV56TbfjjENVHY83e2RIaXoex/h3LN8/IV5B9afdSb8vm/AFutfxKvkhwbtAijvstNavJ 0BT4FbBMfrBVZ3yeb2iTPUL/8FwN2KtJ+lnv3fyXAFd25XQppt5Qt4FQqXe3ceLGJ7LKE0G5 aG6s1MqyDIQwVzUu2AGnIHU+LfzuekqLvaZ3c9dnwawTjLqTup7bLgeiLouis2Yndo3aoo93 TDnkjf4Kiu2svLrCP05iv084lcnsfnx594IPG0zuIRKjnql2+TFeNcZ4E=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,249,1610409600"; d="asc'?png'150?scan'150,208,217,150";a="31766580"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Mar 2021 13:14:54 +0000
Received: from [] ([]) by (8.15.2/8.15.2) with ESMTPS id 12FDErgs000649 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Mar 2021 13:14:54 GMT
From: Eliot Lear <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_1E967CDC-4392-423A-BBFF-00A65635874B"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Mon, 15 Mar 2021 14:14:52 +0100
In-Reply-To: <>
Cc: Brian E Carpenter <>, "" <>, "Salz, Rich" <>
To: Christian Huitema <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3654.
X-Outbound-SMTP-Client:, []
Archived-At: <>
Subject: Re: [Gendispatch] I-D Action: draft-nottingham-where-does-that-come-from-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Area Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Mar 2021 13:15:02 -0000

Hi Christian,

> On 15 Mar 2021, at 05:23, Christian Huitema <> wrote:
> I am not sure that I agree with Mark. Or at least not entirely. Yes, the way we publish documents is confusing. But I am not sure that Mark's proposal is the best we can do.

I’m not sure that I agree with everything in Mark’s proposal either, but I think we have to agree that this is a problem that has been bothering many people for a long time.

> Mark proposes to distinguish the various categories of RFC based on the stream in which they were published. I think that this classification overlaps and partially conflicts with the nature of the RFC, i.e. the label as standard, BCP, informational and experimental. I think it is important to distinguish standards and BCP documents from the rest, and that Mark's suggestion of an IETF branding is certainly a good idea. But it is not obvious that informational documents and independent stream documents should       have different statuses, or even different branding. Similarly, it is not obvious that IRTF documents shall have different branding from informational or experimental documents from the IETF. It also seems that many IAB documents overlap with the BCP and informational categories, and that branding IAB and IETF documents differently may or may not be a good idea.
These documents do have different statuses.  The only real question is how they should best be distinguished.  And we have a lot of capabilities, with which to do so.  For instance, the logo of the IETF needn’t appear on non-IETF documents.  Also, one could imagine either a water mark that indicates that something isn’t a standard, or a header or a footer along those lines.  In fact, one could imagine that even being applied retroactively to HTML!

> I am particularly sensitive to the attempt to differentiate branding of informational documents coming through the IETF and through the independent stream. One important function of the independent stream is to provide "checks and balances" to the       IETF, and ensure that minority opinions are not silenced. A strong branding differentiation would weaken this function of checks and balances, by clearly marking the minority opinions as second class citizens.
I don’t think this is the distinction over which to really worry.  The bigger concern is whether or not something is an IETF standard (proposed or full).  I also don’t see the harm in indicating consensus through a visual cue such as a logo.  In fact, I could imagine some really entertaining logos to indicate obsolescence or updating.

For example, in the upper right hand corner of the display:

I’m sure that someone with more of a creative graphics sense could have even more fun.  What the logo looks like is for the IETF to decide.  That the logo can be used is for the RFC Editor process to decide. Anyway, just food for thought.  [Oh and don’t even start on the color situation! ;-]