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

From: SM <[email-masked]>
Date: Wed, 02 Dec 2009 19:41:30 -0800

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

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 05 Dec 2009 20:19:22 +0000

SM wrote:

> Agreed

Indeed.

> (RFC 1652 Section 2 - Item 4).

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

Yes.

> the MAIL command.  That can be replaced with RFC 5321.

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

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

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

> The reference to STD 14 can be removed.

Right, because it is not used.

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.

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

All existing References become Normative.

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

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

---

From: SM <[email-masked]>
Date: Sat, 05 Dec 2009 13:46:28 -0800

Hi Alexey,
>All existing References become Normative.

Agreed.

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

There is only one "MAY" in the document (Section 3).  I prefer not to 
have the reference to RFC 2119 to avoid getting into a discussion 
about requirement levels.

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

Agreed.

Regards,
-sm

---

From: S Moonesamy <[email-masked]>
Date: Wed, 09 Dec 2009 15:39:13 -0800

Hi Ned,

Dave Crocker posted a revised version of 
draft-ietf-yam-rfc1652bis-pre-evaluation [1].  I will close Issue #4 
unless there are any objections.

Regards,
S. Moonesamy
YAM WG Secretary

1. http://tools.ietf.org/html/draft-ietf-yam-rfc1652bis-pre-evaluation-01

---

From: Ned Freed <[email-masked]>
Date: Tue, 08 Dec 2009 11:32:27 -0800 (PST)

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

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

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

> IESG would probably appreciate advancing MIME first, but the WG doesn't

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.

> Right, because it is not used.

Correct.

>        Headers", RFC 1522, University of Tennessee, September 1993.

Correct.

> All existing References become Normative.

Correct.

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

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.

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

---

From: Ned Freed <[email-masked]>
Date: Wed, 09 Dec 2009 17:09:59 -0800 (PST)

> unless there are any objections.

It doesn't look right to me... First of all, reference [4], to RFC 1522, should
simply be dropped since it isn't referred to in the text. And the update to RFC
1522 is RFC 2047, so it makes no sense to update this reference to one to RFC
2046. And I see no reason to retain the reference to RFC 1521. The less people
look back to RFC 1521 the better off we will be.

What needs to happen is:

      Remove reference to [RFC0974].

      Add reference to [RFC5321].  Use it to replace reference to
      [RFC0821].

      Add reference to [RFC5234].  Use it to replace reference to
      [RFC0822].  This is for ABNF specification.

      Add references to [RFC2045] and [RFC2046]. Use them to replace references
      to [RFC1521].

      Remove reference to [RFC1522].

      Remove reference to [RFC1651].  Replace it with reference to
      [RFC5321].

The text involving the capitalized MAY needs to be replaced along the lines of
what I provided in my previous email on this topic.

And finally, an IANA considerations section needs to be added containing
a registration for this extension.

				Ned

---

From: S Moonesamy <[email-masked]>
Date: Thu, 10 Dec 2009 10:18:19 -0800

Hi Ned,
>look back to RFC 1521 the better off we will be.

I'm leaving Issue #4 open. I updated the tracker with your comments 
about the references.

>a registration for this extension.

I'll track the above as a separate issue with a pointer to 
http://www.ietf.org/mail-archive/web/yam/current/msg00260.html

Regards,
S. Moonesamy
YAM WG Secretary

---

From: SM <[email-masked]>
Date: Thu, 10 Dec 2009 11:05:37 -0800

Hi Ned,
>Again, the point was to avoid the downref to draft the IESG was complaining

We could take a different approach for the downrefs as you 
mentioned.  We already know the documents the WG is taking on.

>reference, no IANA considerations) weren't noticed.

On the bright side, it got the WG to discuss about these two "errors" 
now rather than at the next stage.

>emphasis and is not in the form of compliance language in any case) is wrong.

I was curious about the "DOES NOT" in that section.  Thanks for the 
explanation.

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

That sounds fine.

>change is needed - an IANA considerations section registering this extension.

The extension is registered but I don't see where it was done.  RFC 
4409 mentions 8BITMIME.  The Submit registration could go in there.

Regards,
-sm