Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

Brian Dickson <> Tue, 17 June 2008 06:36 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id AC9443A6A2A; Mon, 16 Jun 2008 23:36:13 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA6193A6A2A for <>; Mon, 16 Jun 2008 23:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.995
X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O6k0Tstf37U6 for <>; Mon, 16 Jun 2008 23:36:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D2EDF3A68E1 for <>; Mon, 16 Jun 2008 23:36:10 -0700 (PDT)
Received: from ([]) by with esmtp (Exim 4.22) id 1K8UoG-0001Zu-VG; Tue, 17 Jun 2008 02:36:53 -0400
Message-ID: <>
Date: Tue, 17 Jun 2008 02:36:46 -0400
From: Brian Dickson <>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
To: Frank Ellermann <>
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
References: <><><p06250116c47c330c7dd0@[]> <> <g36r20$bgq$>
In-Reply-To: <g36r20$bgq$>
X-SA-Exim-Scanned: No; SAEximRunCond expanded to false
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Frank Ellermann wrote:
> Brian E Carpenter wrote:
>> That's my opinion; I'm not asserting that it's an IETF
>> consensus or that it necessarily applies to 2821bis.
> +1
> Some things I'd consider:
> RFC 821 used and similar examples, and it won't
> surprise me if the author knew precisely why this can
> never have any undesirable side-effects.
> As explained by John RFC 2821 switched to  All
> address harvesters looking for strings with an "@" have
> found it years ago, nothing 2821bis will do can fix it.
> Or the opposite effect, the RFCs listed in RFC 3092 might
> have contributed to a better page rank of, maybe
> the current owner has no problem with the overall effect.
> Whatever 2821bis does, it cannot change the good or bad
> caused by RFC 2821 and other RFCs.  Therefore the issue
> is at first glance purely editorial.
> *BUT* 2821bis will be one of the most important RFCs for
> many years - assuming it goes "as is" to STD - and many
> readers, who will take it as gospel.  They will see the
> examples, and use similar constructs for their
> own examples.  They won't know or read RFC 2606, and if
> they get push back they can say "but 5821 also does it".
> Of course I'd ignore red lights when there's no traffic,
> and I just want to cross the street.  And I'd be upset
> if some "authority" tells me that I shouldn't do this.
> But is it really necessary to ignore red lights in the
> presence of kids who have no clue what can go wrong ?

The issue at hand (the DISCUSS and appeal) is at odds with the AD's view,
regarding updating names used in examples versus RFC2606.

In the interests of resolving the issue while respecting both the desire 
to preserve
the text between 2821 and 2821bis, and to acknowledge that the examples used
aren't 2606-compliant and preserved only to avoid making too many changes to
a document with a long history/ancestry, what about a minor compromise by
both parties?

Here's my suggestion:

List 2606 in the informative references, and footnote the examples used 
to indicate
that they are "grandfathered" non-2606 examples.

So, in text that previously read "", it might read 
" [*]",
with the references section having "[*] Note - non-RFC2606 examples 
used. Please read RFC2606."

Something along those lines, should hopefully be enough to keep both 
sides happy, and resolve the DISCUSS,
and hopefully both set a suitable precedent *and* make moot the appeal.


Brian Dickson
IETF mailing list