[yam] Issue #4 (was: Status: draft-ietf-yam-rfc1652bis-pre-evaluation-00)

SM <sm@resistor.net> Thu, 03 December 2009 03:43 UTC

Return-Path: <sm@resistor.net>
X-Original-To: yam@core3.amsl.com
Delivered-To: yam@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E02C23A682F for <yam@core3.amsl.com>; Wed, 2 Dec 2009 19:43:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level:
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-Zu85Rh3ViJ for <yam@core3.amsl.com>; Wed, 2 Dec 2009 19:43:34 -0800 (PST)
Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 23D253A67E9 for <yam@ietf.org>; Wed, 2 Dec 2009 19:43:34 -0800 (PST)
Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id nB33hFNG029927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Dec 2009 19:43:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1259811804; x=1259898204; bh=gyTMDoz2RTxvUwf42vyzdJKGq02UDMOHNmwjnissPBs=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=tyha29HqHzWOqmABJD2qJZGMjBIFvjkJYrHForKYdapWIuven3Kfv27dwswPWcbu1 HQ1B3alOLw72qWVe4jd1Rm5DgSE6Qj+pZFxJp8jYmOUir6SlNLecUpnTos7Gqfblg2 XsQZ1iEFKF+uPT6dAkdajmQEkWCfHP10KGXpOiXc=
DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=ytpk0MFSR9Jgoz77C9FaZJZOB6ohDFLjV2ByJN1JKWLQoaT3yFYdNmlLGe+oZoOVl VTYYDLrj7HSmzc6BxnZYLKe42D2/jlSPMJRHA1aeNbl/ItSxx6wFEJy6YIQ2XkV0sQG Mn05Bl2z4tyKvm8iMWK8uSIMzKKrAoBc8tbHBaY=
Message-Id: <6.2.5.6.2.20091202190648.032612b0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 02 Dec 2009 19:41:30 -0800
To: Ned Freed <ned.freed@mrochek.com>
From: SM <sm@resistor.net>
In-Reply-To: <01NFMC338P960000BI@mauve.mrochek.com>
References: <6.2.5.6.2.20091031115845.03fdeaa8@elandnews.com> <01NFMC338P960000BI@mauve.mrochek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: yam@ietf.org
Subject: [yam] Issue #4 (was: Status: draft-ietf-yam-rfc1652bis-pre-evaluation-00)
X-BeenThere: yam@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Yet Another Mail working group discussion list <yam.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/yam>
List-Post: <mailto:yam@ietf.org>
List-Help: <mailto:yam-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2009 03:43:35 -0000

Hi Ned,
At 10:45 02-11-2009, Ned Freed wrote:
>For starters, the reference to RFC 822 in RFC 1652 is for ABNF and nothing
>else, so it upgrades cleanly to RFC 5234 - already a Standard, no downref
>needed. There's no need to reference RFC 5322 for this purpose at all.

Agreed (RFC 1652 Section 2 - Item 4).

>I'll also take this opportunity to point out that this is actually an error in
>draft-ietf-yam-rfc1652bis-pre-evaluation-00, which states that what 
>needs to be
>done is update the reference to RFC 5322. So it seems that while 
>frothing about

That can be dropped from the Downward references part of that draft.

>As for the reference to RFC 821, the purpose of it is to get at the definition
>of what's allowed in a message. I don't think a credible argument can be made
>that the definition of the overall syntax of a basic message (i.e., 998
>chearacter or less CRLF delimited lines of 7bit ASCII), is ever going to
>change. Pigs will travel at lightspeed first.

The reference to RFC 821 is for compliance with SMTP (7BIT) and for 
the MAIL command.  That can be replaced with RFC 5321.

>Finally there's the reference to RFC 1651. The plan is to replace this with a
>reference to RFC 5321, which is a fine plan, but if that's a downref 
>issue then
>a reference to RFC 1651 - a Full Standard - could simply be retained.

The Full Standard is RFC 1869.  That can be replaced with RFC 5321.

>Moreover, if you're going to worry about downrefs in the context of RFC 1652,
>the thing to be looking at isn't SMTP or core message format stuff, but MIME.
>An argument that a downref to MIME could be problematic could be made a lot
>more easily. Mind you. I still don't think rises to the necessary level to
>prohibit the downref, but it's a vastly more credible arugment than one
>involving 5321/5322. So does this mean we also need to advance MIME 
>to Standard
>first?

The downref to RFC2045 and RFC2046 can be kept until 1652bis has been 
evaluated.  There is no need to advance MIME to Standard first.  The 
point is to process the document and take it out of the loop.

The reference to STD 14 can be removed.

Regards,
-sm