Subject: [yam] preliminary -- draft-ietf-yam-rfc1652bis-pre-evaluation

From: Dave CROCKER <[email-masked]>
Date: Thu, 13 Aug 2009 14:18:01 -0700

Folks,

Attached is a first attempt to use the RFC1652 pre-evaluation template. SM's
initial version is quite good, but trying to fill in the details did produce
motivate some changes.

I'm viewing this phase primarily as a shakedown of the form itself, although a
serious shakedown requires also treating the content seriously.  So I tried to
be thorough with the answers, but fully expect that BOTH content and form need
changing.

Please distinguish between commenting on the form versus commenting on the data
I've filled-in.

With some feedback about the form, I'll try to fold changes back into the master
xml template.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

YAM Working Group                                        D. Crocker, Ed.
Internet-Draft                               Brandenburg InternetWorking
Intended status: Informational                                 July 2009
Expires: January 2, 2010

  Preliminary Evaluation of RFC 1652 for Advancement to Full Standard
                draft-ietf-yam-rfc1652bis-pre-evaluation

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 2, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This memo is a preliminary evaluation of RFC 1652 "SMTP Service
   Extension for 8bit-MIMEtransport" for advancement from Draft to Full
   Standard.  It has been prepared by the The Yet Another Mail Working

Crocker                  Expires January 2, 2010                [Page 1]

Internet-Draft               Prelim-RFC1652                    July 2009

   Group.

   THIS INTERNET DRAFT IS WRITTEN TO FACILITATE PROCESSING WITHIN THE
   IESG.  IT IS NOT MEANT TO BE PUBLISHED AS AN RFC.

1.  Introduction

   A preliminary evaluation has been made of RFC 1652 [RFC1652] "SMTP
   Service Extension for 8bit-MIMEtransport" by the Yet Another Mail
   (YAM) Working Group for advancing it from Draft to Full Standard.
   The YAM WG requests feedback from the IESG on this decision.

1.1.  Note to RFC Editor

   This Internet-Draft is not meant to be published as an RFC.  It is
   written to facilitate processing within the IESG.

2.  Preliminary Evaluation

   Title:   SMTP Service Extension for 8bit-MIMEtransport

   Link:   http://tools.ietf.org/html/rfc1652

   Date published:   July 1994

   Confidence document meets RFC 2026 section 4.1.3 (Standard) test:

      _RFC2026 text: "significant implementation and successful
      operational experience...[with] a high degree of technical
      maturity and [] a generally held belief that the specified
      protocol or service provides significant benefit to the Internet
      community":_

      This specification was published in 1994.  In the intervening 15
      years, it has become an integral part of all professional SMTP
      software products and is widely supported [[and used?]] in
      Internet Mail operations.  There are no RFC Errata on this
      specification.

   Link to Draft Standard interoperability report:

      [[ No report appears to be on file with the IETF. /d ]]

   Proposed Changes (the YAM WG proposes making the following changes in
   a revision:

Crocker                  Expires January 2, 2010                [Page 2]

Internet-Draft               Prelim-RFC1652                    July 2009

      Add reference to [RFC5321].  [Retain reference to [RFC0821].]

      Add reference to [RFC5322].  [Retain reference to [RFC0822].]

      Add reference to [RFC2045].  [Retain reference to [RFC1521].]

      Add reference to [RFC2046].  [Retain reference to [RFC1522].]

      Remove reference to [RFC1651].  [Obsoleted by [RFC2821] and
      [RFC5321].]

   Non-Changes (the YAM WG discussed and chose not to make the following
   changes):

      None, so far.

   Downward references (At Full Standard, the following references would
   be downward references):

      [RFC5321], [RFC5322], [RFC2045], [RFC2046].

3.  IESG Feedback

   The YAM WG requests feedback from the IESG on these decisions.  In
   particular:

   o  Does the IESG believe the proposed changes are suitable during a
      move from Draft to Full Standard?

   o  Does the IESG believe any other proposed changes are necessary to
      satisfy IESG requirements to advance to Full Standard?

   o  Does the IESG consider the downward references acceptable for a
      Full Standard?

4.  Security Considerations

   This document requests IESG feedback.  There are no security
   considerations.

5.  Normative References

   [RFC0821]  Postel, J., "Simple Mail Transfer Protocol", STD 10,
              RFC 821, August 1982.

Crocker                  Expires January 2, 2010                [Page 3]

Internet-Draft               Prelim-RFC1652                    July 2009

   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982.

   [RFC1521]  Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
              Mail Extensions) Part One: Mechanisms for Specifying and
              Describing the Format of Internet Message Bodies",
              RFC 1521, September 1993.

   [RFC1522]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Two: Message Header Extensions for Non-ASCII Text",
              RFC 1522, September 1993.

   [RFC1651]  Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
              Crocker, "SMTP Service Extensions", RFC 1651, July 1994.

   [RFC1652]  Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
              Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
              RFC 1652, July 1994.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              November 1996.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

Author's Address

   D. Crocker (editor)
   Brandenburg InternetWorking
   675 Spruce Dr.
   Sunnyvale, CA
   USA

   Email: [email-masked]
   URI:   http://bbiw.net

Crocker                  Expires January 2, 2010                [Page 4]

---

From: Tony Hansen <[email-masked]>
Date: Thu, 13 Aug 2009 18:12:36 -0400

Thanks Dave.

Template comments:

"the The"
	good catch

changing "RFC, BUT ..."
	quite reasonable -- gets the notion across better that the purpose is 
to ping the IESG, and subjugates the notion that it should not be 
published as an RFC

changing "this change" to "these changes"
	seems reasonable

I noticed that we need to add an IANA Considerations section. There 
actually may be IANA registry changes that need to be made when the RFC 
is updated, such as references to the older RFC number.

Dave, you removed the Date published section. Any particular reason?

You copied the text (trimmed down) from 2026. Do you think that should 
be a standard part of the template?

Pre-Evaluation comments:

===
     Non-Changes
	None, so far.

I think it's reasonable to actually declare that there are no 
non-changes. The WG needs to discuss such a statement before the 
evaluation is passed to the IESG, so the "so far" seems disingenuous.

===
     Link to Draft Standard interoperability report,
	[[ No report appears to be on file with the IETF. /d ]]

I'm not sure what to do here. This may be a tripping point for the IESG, 
and we may need to provide an interop report for any RFCs that are 
missing one.

Questions to the WG: Do we put in some sort of simple statement like 
what Dave has in brackets, assume that one isn't needed, and see if the 
IESG barfs? Or do we offer up front to provide an interop report in 
cases where one is missing?  We could state that one will be provided 
along with the revised draft.

	Tony Hansen
	[email-masked]

Dave CROCKER wrote:
> Folks,
> 
> Attached is a first attempt to use the RFC1652 pre-evaluation
> template. SM's initial version is quite good, but trying to fill in
> the details did produce motivate some changes.
> 
> I'm viewing this phase primarily as a shakedown of the form itself, 
> although a serious shakedown requires also treating the content
> seriously. So I tried to be thorough with the answers, but fully
> expect that BOTH content and form need changing.
> 
> Please distinguish between commenting on the form versus commenting
> on the data I've filled-in.
> 
> With some feedback about the form, I'll try to fold changes back into
> the master xml template.

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 Aug 2009 19:37:31 -0400

--On Thursday, August 13, 2009 18:12 -0400 Tony Hansen
<[email-masked]> wrote:

>...
> I'm not sure what to do here. This may be a tripping point for
> the IESG, and we may need to provide an interop report for any
> RFCs that are missing one.

I'd personally be inclined to take a hard line on this.  There
is no requirement for an interoperability report for Draft ->
Full.  None.  There is also no requirement, or even mechanism,
for a review of the prior interoperability report.  If some IESG
approved the document for Draft Standard, they made a definitive
decision that evidence of interoperability was sufficient.
There is no procedure for a current IESG to second-guess that
except by moving a Draft Standard document to Historic and
historically (sic) wide deployment and use is a bar against
doing that.

It is not YAM's job to either find documentation that the IESG
has misplaced or to generate documentation that may not have
existed in a time of more relaxed and informal procedures,
especially for something that is not subject to review as part
of YAM's work.
 
> Questions to the WG: Do we put in some sort of simple
> statement like what Dave has in brackets, assume that one
> isn't needed, and see if the IESG barfs? Or do we offer up
> front to provide an interop report in cases where one is
> missing?  We could state that one will be provided along with
> the revised draft.

We remove the entire item from the template and point anyone who
asks to what 2026 actually says.

Just my { hard-line, sorehead } opinion.

    john

---

From: SM <[email-masked]>
Date: Thu, 13 Aug 2009 16:38:26 -0700

Hi Dave,
>With some feedback about the form, I'll try to fold changes back 

The master XML template is available for download at 
http://trac.tools.ietf.org/wg/yam/trac/wiki

Is the "Confidence document meets RFC 2026" item optional from a 
format point of view or should it be included for every pre-evaluation?

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 13 Aug 2009 18:07:43 -0700

> Dave, you removed the Date published section. Any particular reason?

Huh?  I'm looking at the third line of Section 2, of the file I sent, and it 
says "Date Published".

What are you referring to?

> be a standard part of the template?

Definitely.

Individual recall of formal IETF rules and requirements tends to be spotty, at 
best, and folks have a tendency to get inventive.  The text is short, pragmatic 
and clear.  So let's make sure everybody sees it regularly.

> evaluation is passed to the IESG, so the "so far" seems disingenuous.

I put the 'so far' in there to make it obvious I was only reporting and not 
taking a position.   I guess it was a form of inviting comment.

> I'm not sure what to do here. This may be a tripping point for the IESG, 

My question is why?  An interoperability report is a requirement to go to Draft, 
not for going to Full.

I don't think it's a problem to include one, if available, but I think that any 
belief it's important entirely misses what this stage of advancement is about.

If something has been massively deployed and use for a decade, what possible, 
legitimate argument can there be that the formal report is 'required'?

> and we may need to provide an interop report for any RFCs that are 

That, I believe, would be a strategic error, per above.

> IESG barfs? Or do we offer up front to provide an interop report in 

+1.

> along with the revised draft.

No.  IMO, it is not reasonable to have the IESG impose this kind of extra work 
on us, given that the rules do not obviously point to it.

Have a range of different folks with operational email experience offer expert 
statements that the thing is widely used and has been for a very long time.  Done.

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 13 Aug 2009 17:55:52 -0700

SM wrote:
>> the master
> Is the "Confidence document meets RFC 2026" item optional from a format 
> point of view or should it be included for every pre-evaluation?

There's no track-record of this sort of activity, for us t know what reallyh is 
required versus is optional.

On the other hand, this one entry would seem to me to be the single most 
important information for getting to Full, so I'd recommend including it in 
every template.

d/

-- 

   Dave Crocker

---

From: Tony Hansen <[email-masked]>
Date: Thu, 13 Aug 2009 21:26:52 -0400

Dave CROCKER wrote:
> Huh?  I'm looking at the third line of Section 2, of the file I sent, 
> and it says "Date Published".
> 

Sorry -- I was looking at a diff, and for some reason it showed the Date 
Published line on one side and not on the other. My mistake.

> Individual recall of formal IETF rules and requirements tends to be 
> spotty, at best, and folks have a tendency to get inventive.  The text 
> is short, pragmatic and clear.  So let's make sure everybody sees it 
> regularly.

I agree that it's worthy of adding to the template.

> I put the 'so far' in there to make it obvious I was only reporting and 
> not taking a position.   I guess it was a form of inviting comment.

no problem.

> My question is why?  An interoperability report is a requirement to go 
> to Draft, not for going to Full.
> 
> I don't think it's a problem to include one, if available, but I think 
> that any belief it's important entirely misses what this stage of 
> advancement is about.
> 
> If something has been massively deployed and use for a decade, what 
> possible, legitimate argument can there be that the formal report is 
> 'required'?
> 
> 
>> what Dave has in brackets, assume that one isn't needed, and see if 
>> the IESG barfs? Or do we offer up front to provide an interop report in 
> 
> +1.
> 
> 
> No.  IMO, it is not reasonable to have the IESG impose this kind of 
> extra work on us, given that the rules do not obviously point to it.

That's two with that view. (And, OMG, it's you and John! :-) )

Anyone else want to chime in?

> Have a range of different folks with operational email experience offer 
> expert statements that the thing is widely used and has been for a very 
> long time.  Done.

This seems worth providing as supporting evidence for the "Confidence" 
test. Providing such statements should possibly be part of the 
submission process for the final RFC, but doesn't need to be there for 
the pre-evaluation step.

	Tony Hansen
	[email-masked]

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 13 Aug 2009 18:29:09 -0700

>> extra work on us, given that the rules do not obviously point to it.

We usually agree on process issues.  It's the technical stuff he's always wrong 
about...

d/
-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Thu, 13 Aug 2009 23:22:06 -0700

At 18:26 13-08-2009, Tony Hansen wrote:
>This seems worth providing as supporting evidence for the 
>"Confidence" test. Providing such statements should possibly be part 
>of the submission process for the final RFC, but doesn't need to be 
>there for the pre-evaluation step.

The confidence is implied as the WG is recommending advancing the 
document(s).  I'm fine with having a formal statement either at this 
stage or as part of final submission.  In my opinion, it is better to 
skip the supporting evidence bit, i.e. the grounds for the
generally held belief.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 14 Aug 2009 07:42:42 -0700

Revision attached.

Added RFC 2026 for each stage, so that a reader knows the salient rule, without 
having to remember or check.

Removed the interoperability report stuff, per John's and my comments.

Added an IANA Considerations section.

d/

-- 

   Dave Crocker

Status of this Memo

Copyright Notice

Abstract



   Group.

1.  Introduction

1.1.  Note to RFC Editor

   Time in Place:

      RFC 2026: _"A specification shall remain at the Draft Standard
      level for at least four (4) months, or until at least one IETF
      meeting has occurred."_

      Published -- July 1994

      RFC2026: _"significant implementation and successful operational
      experience...[with] a high degree of technical maturity and [] a
      generally held belief that the specified protocol or service
      provides significant benefit to the Internet community":_

      In the 15 years since publication, this specification has become
      an integral part of all professional SMTP software products and is
      widely supported [[and used?]] in Internet Mail operations.  There
      are no RFC Errata on this specification.



      RFC 2026: _"Minor revisions are expected, but a significant
      revision may require that the specification accumulate more
      experience at its current maturity level before progressing."_

      Add reference to [RFC5321].  Retain reference to [RFC0821].

      Add reference to [RFC5322].  Retain reference to [RFC0822].

      Add reference to [RFC2045].  Retain reference to [RFC1521].

      Add reference to [RFC2046].  Retain reference to [RFC1522].

      Remove reference to [RFC1651].  Obsoleted by [RFC2821] and
      [RFC5321].

      None.

3.  IESG Feedback

4.  IANA Considerations

   This document contains no IANA actions.



5.  Security Considerations

6.  Normative References



Author's Address

   D. Crocker (editor)

   Email: [email-masked]
   URI:   http://bbiw.net

Crocker                  Expires January 2, 2010                [Page 5]

---

From: Tony Hansen <[email-masked]>
Date: Fri, 14 Aug 2009 13:49:04 -0400

Thank you Dave.

======

Template comments:

I think we're on the right track with not offering the IESG any 
potentially side-tracking information.

If Alexey wants to know what the status of the interoperability report 
is, we can communicate that to him as part of the discussions on the 
mailing list. Curiosity by the IESG is fine, but should not side track 
them from doing their work. Particularly with the amount of changes that 
we plan to NOT do to each of these RFCs, I don't see his example from 
EPP as arising for the YAM documents. An informal check by him doesn't 
hurt, but shouldn't need to be codified.

I think the extractions you've chosen from 2026 are just fine.

A formatting nit, though, it might look better if the 2026 excerpt were 
done as a hanging indent. This would make the excerpt stand out more 
separately from the comment below it. For example,

    Time in Place:

       RFC 2026: _"A specification shall remain at the Draft Standard
             level for at least four (4) months, or until at least one
	    IETF meeting has occurred."_

       Published -- July 1994

======

Pre-evaluation comments:

In the IANA Considerations section, you might mention that the reference 
to RFC 1652 on http://www.iana.org/assignments/mail-parameters should be 
updated.

======

You may as well post it to the internet drafts. Then we can WGLC it.

	Tony Hansen
	[email-masked]

Dave CROCKER wrote:
> 
> Revision attached.
> 
> Added RFC 2026 for each stage, so that a reader knows the salient rule, 
> without having to remember or check.
>

---

From: SM <[email-masked]>
Date: Fri, 14 Aug 2009 11:23:30 -0700

At 10:49 14-08-2009, Tony Hansen wrote:
>If Alexey wants to know what the status of the interoperability 
>report is, we can communicate that to him as part of the discussions 
>on the mailing list. Curiosity by the

Agreed.

>Pre-evaluation comments:
>
>In the IANA Considerations section, you might mention that the 
>reference to RFC 1652 on 
>http://www.iana.org/assignments/mail-parameters should be updated.

Shouldn't that be in Section 2 under "Proposed changes" as it is part 
of the preliminary evaluation report?

As the I-D will not only be processed by the IESG, a IANA 
Considerations section is not a requirement.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 14 Aug 2009 11:51:56 -0700

SM wrote:
> Shouldn't that be in Section 2 under "Proposed changes" as it is part of 
> the preliminary evaluation report?

yeah, that probably makes more sense.

> As the I-D will not only be processed by the IESG, a IANA Considerations 
> section is not a requirement.

right.

d/
-- 

   Dave Crocker

---

From: Tony Hansen <[email-masked]>
Date: Fri, 14 Aug 2009 15:13:02 -0400

6 of one ....

I'm happy with either place

	Tony

---

From: Ned Freed <[email-masked]>
Date: Sun, 16 Aug 2009 09:50:41 -0700 (PDT)

> Just my { hard-line, sorehead } opinion.

Emphatic agreement on all points. I guess that makes me a hard-line sorehead
as well...

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 17 Aug 2009 15:05:11 +0100

Tony Hansen wrote:

> them from doing their work. Particularly with the amount of changes 
> that we plan to NOT do to each of these RFCs, I don't see his example 
> from EPP as arising for the YAM documents. An informal check by him 
> doesn't hurt, but shouldn't need to be codified.

Fine with me.

> A formatting nit, though, it might look better if the 2026 excerpt 
> were done as a hanging indent. This would make the excerpt stand out 
> more separately from the comment below it. For example,
>
>    Time in Place:
>

Indeed.

Other suggestions (as an individual contributor):
1). I think the extension registration needs to be updated to say that 
the extension is valid on Submission port.
2). Change 1 line ABNF in section 2 to use RFC 5234 syntax:
OLD:

body-value ::= "7BIT" / "8BITMIME"

NEW:

body-value = "7BIT" / "8BITMIME"

> You may as well post it to the internet drafts. Then we can WGLC it.

Yes please. And making it a draft-ietf-yam-... will make it slightly 
easier for tools used by IESG.

---

From: Tony Hansen <[email-masked]>
Date: Tue, 18 Aug 2009 16:06:33 -0400

> the extension is valid on Submission port.

Aren't all SMTP extensions implicitly defined for the Submission port 
unless specifically *not* allowed?

> body-value = "7BIT" / "8BITMIME"

Advantage: it's a simple update, a single line, trivial to do, and easy 
to check for accuracy.

Disadvantage: Does it set the expectation that we'll adjust 8BNF => ABNF 
in future YAM updates? How slippery is the slope?

Any other thoughts on this?

	Tony

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Aug 2009 19:07:06 +0100

Tony Hansen wrote:

>> 1). I think the extension registration needs to be updated to say 
>> that the extension is valid on Submission port.
>

Yes, but the submission document defines an updated template which is 
not used consistently.
This is not a big deal, but I think just saying that explictly would be 
a good thing.

This doesn't have to be mentioned in the pre-evaluation document though.

> Advantage: it's a simple update, a single line, trivial to do, and 
> easy to check for accuracy.
>
> Disadvantage: Does it set the expectation that we'll adjust 8BNF => 
> ABNF in future YAM updates? How slippery is the slope?

I am fine with not mentioning this change in the pre-evaluation 
document, if this helps.

As a WG contributor: I think the WG should just do this change in 
rfc1652bis. If it is little effort, we should upgrade BNF to ABNF.
I am also hoping that we wouldn't have this argument for every document 
processed. It is certainly not worth in relationship to changing/not 
chaning one line in this document.