Re: IESG response fixes for 2821bis

John C Klensin <john+smtp@jck.com> Tue, 08 July 2008 08:56 UTC

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m688uTqN011459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 01:56:29 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m688uTO8011458; Tue, 8 Jul 2008 01:56:29 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m688uRJj011449 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <ietf-smtp@imc.org>; Tue, 8 Jul 2008 01:56:29 -0700 (MST) (envelope-from john+smtp@jck.com)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1KG8zq-000AME-QI; Tue, 08 Jul 2008 04:56:27 -0400
Date: Tue, 08 Jul 2008 04:56:26 -0400
From: John C Klensin <john+smtp@jck.com>
To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
cc: ietf-smtp@imc.org
Subject: Re: IESG response fixes for 2821bis
Message-ID: <6490D4BD764FD198C29D8D7E@p3.JCK.COM>
In-Reply-To: <g4v0gh$hf5$1@ger.gmane.org>
References: <20080707170001.ECC4A28C0F7@core3.amsl.com> <48729A1B.7030104@att.com> <4872DC3A.70707@att.com> <g4v0gh$hf5$1@ger.gmane.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>

--On Tuesday, 08 July, 2008 08:15 +0200 Frank Ellermann
<nobody@xyzzy.claranet.de> wrote:

> 
> Tony Hansen wrote:
>  
>> dcontent = %d33-90 / ; Printable US-ASCII 
>>            %d94-126  ; excl. "[", "\", "]"
> 
> Renaming this beast to dtextSMTP consistent with qtextSMPT
> is an option.  2822upd says:
> 
>  dtext   =   %d33-90 /          ; Printable US-ASCII
>              %d94-126 /         ;  characters not including
>              obs-dtext          ;  "[", "]", or "\"
> 
> Of course a matter of taste.

Frank, especially since the IESG apparently has at least one
more <Surprise> coming for this group (watch the list), I am
strongly disinclined to make any further changes that have not
already been signed off by them, or that are direct consequences
of things they have insisted on, and that are not the result of
absolute showstoppers.  In order to maintain a consistent
position, I/we might have to insist on another IETF Last Call on
such changes, resulting in further delays that accomplish very
little.  So, while I'm willing to be talked out of it, I prefer
to not see any more editorial suggestions right now.

>  What happened with two
> suggestions at the begin and the end of this comment:
> 
> https://datatracker.ietf.org/idtracker/draft-klensin-rfc2821bi
> s/comment/80585/  

If you are referring to 

>  FYI, to compare with previous RFC try this URI:
> 
> http://tools.ietf.org/rfcdiff?url2=http://www.ietf.org/interne
> t-drafts/draft-klensin-rfc2821bis-10.txt&url1=http://www.ietf.
> org/rfc/rfc2821.txt
> 
> To be consistent with RFC 2821, this needs a header:
>   Updates: 1123 

This has been done and presumably should have been on Tony's
list.  Tony, I've fixed the change log to call this out.

and

> Suggestion: STD 66 (URI RFC 3986) defines an "IPv6address"
> rule that could be referenced or copied.  It got the ABNF
> cleaner than we got it here (and yes, that ABNF was my fault
> in RFC 2821 but I recognize when someone else does it better).

I considered this and decided to let it go and did not receive
any comments from Tony to the contrary.   The existing ABNF is
not broken and it is late to be making changes.  I'd be
especially reluctant to reference 3986 because (i) it introduces
yet another normative reference and document that people have to
have virtually open to read 2821bis and (ii) it introduces some
small amount of circularity (2821bis -> 3986 -> mailto ->
2821[bis]).  If it were six months ago, I'd immediately make
this change.

Both of these remaining comments (renaming the production and
altering the IPv6address syntax) have been noted in case there
is ever an rfc2821ter.  Please do not take that as
encouragement; I'll stop trying to keep that list if there are
many more additions to it.

    john