Re: [yam] Issue #4

Ned Freed <ned.freed@mrochek.com> Thu, 10 December 2009 01:20 UTC

Return-Path: <ned.freed@mrochek.com>
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 678C13A6858 for <yam@core3.amsl.com>; Wed, 9 Dec 2009 17:20:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.928
X-Spam-Level:
X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219]
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 9ZFzKVPrxjyd for <yam@core3.amsl.com>; Wed, 9 Dec 2009 17:20:41 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 0A6493A6803 for <yam@ietf.org>; Wed, 9 Dec 2009 17:20:41 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NH272NYNJK007BRY@mauve.mrochek.com> for yam@ietf.org; Wed, 9 Dec 2009 17:20:24 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NGW7GJEZM80000BI@mauve.mrochek.com>; Wed, 09 Dec 2009 17:20:20 -0800 (PST)
Message-id: <01NH272LYRD60000BI@mauve.mrochek.com>
Date: Tue, 08 Dec 2009 11:32:27 -0800
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Sat, 05 Dec 2009 20:19:22 +0000" <4B1AC04A.5050204@isode.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset="ISO-8859-1"; format="flowed"
References: <6.2.5.6.2.20091031115845.03fdeaa8@elandnews.com> <01NFMC338P960000BI@mauve.mrochek.com> <6.2.5.6.2.20091202190648.032612b0@elandnews.com> <4B1AC04A.5050204@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1260407834; bh=1jnQqoZ1n8qFVqrg4WrjayW+8LyjZ3Hj6fYO57oIbG0=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=biMRwKw5zNb1LXrVO8gmP20IuqC6Fme9+corI6ZQ84kMJAAqmyEA5ZjXvSMUHlZLS H0s0I94eplmeLvrChTT5KRgcuJ+eh7hWU6vbTR7ZvsWIRVGmLuINfSIk85XGLXz77p GOET61rwnaBGqZ/JeVq99bbI7ruEk5nKpd77eiVI=
Cc: Ned Freed <ned.freed@mrochek.com>, yam@ietf.org
Subject: Re: [yam] Issue #4
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, 10 Dec 2009 01:20:42 -0000

> SM wrote:

> > 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

> Indeed.

> > (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.

> Yes.

> >> 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.

> I agree, as we will be advancing RFC 5321 to Full anyway.

My purpose here was to refute the notion that the downreferences to RFC
5321/5322 are worthy of attention in this context. They quite simply aren't,
and if need be they can be replaced with references to full standards.

If RFC 5321 is advacing to full first, as now seems to be the case, this is of
course a moot point. OTOH, if for whatever reason that doesn't happen, this
appproach should be back on the table.

> >> 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.

> +1. I don't see we should have a reference to RFC 1869 just because it
> is a full standard.

Again, the point was to avoid the downref to draft the IESG was complaining
about.

> >> 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.

> IESG would probably appreciate advancing MIME first, but the WG doesn't
> have to do this first.

That sort of says it all, doesn't it? To the extent this document was rejected
on the basis of its content and not because of process pother, it was because
of downrefs that weren't actually needed or relevant, but downrefs that are
needed and which could actually be relevant and which should receive scrutiny
are apparently just fine and dandy. And at least two actual errors (bogus ABNF
reference, no IANA considerations) weren't noticed.

> > The reference to STD 14 can be removed.

> Right, because it is not used.

Correct.

> The following reference is also not used:

>    [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
>        Headers", RFC 1522, University of Tennessee, September 1993.

Correct.

> Collecting all changes in one place, this is my recommendation:

> All existing References become Normative.

Correct.

> A normative reference to RFC 2119 needs to be added, as the document is
> using MAYs

There is one MAY, and it is in fact an error. The document currently says:

   Finally, although the
   content body contains arbitrary lines of octet-aligned material, the
   length of each line (number of octets between two CR-LF pairs), is
   still subject to SMTP server line length restrictions (which may
   allow as few as 1000 octets on a single line). This restriction means
   that this extension MAY provide the necessary facilities for
   transferring a MIME object with the 8BIT content-transfer-encoding,
   it DOES NOT provide a means of transferring an object with the BINARY
   content-transfer-encoding.

This was written when RFC 1521 was still in effect, and it wasn't clear what
restrictions were imposed by the 8bit encoding itself. This was clarified in
RFC 2045, which made it clear that the 1000 character limit applies to anything
with an 8bit encoding. So the weasely MAY (which, incidentally, was intended as
emphasis and is not in the form of compliance language in any case) is wrong.
This section needs to be redone to say;

   Finally, although the
   content body contains arbitrary lines of octet-aligned material, the
   length of each line (number of octets between two CR-LF pairs), is
   still subject to SMTP server line length restrictions (which may
   allow as few as 1000 octets, inclusive of the CR-LF pair, on a single
   line). This restriction means that this extension provides the necessary
   facilities for transferring a MIME object with the 8BIT
   content-transfer-encoding, it DOES NOT provide a means of transferring an
   object with the BINARY content-transfer-encoding.

And there goes the MAY and with it the need to reference RFC 2119.

> [1] RFC 821 --> 5321 (Draft) - downref, but in scope for YAM

> [2] RFC 822 --> RFC 5234 (Full)

> [3] RFC 1521 --> RFC 2045 (Draft) - downref, but in scope for YAM

> [4] - remove as unused

> [5] RFC 1651 --> RFC 5321 (Draft). Same as [1], so can be replaced with [1]

> [6] - remove as unused.

Modulo the 2119 thing, this looks right to me. However, at least one additional
change is needed - an IANA considerations section registering this extension.

				Ned