SMTP Service Extension for 8-bit MIME Transport
draft-ietf-yam-rfc1652bis-03

[Ballot discuss]
This is a process question for the IESG and not meant for authors of WG. So given the text of LC was clear the downref was for all of RFC 2045, RFC 2046, RFC 5321 and RFC 5322 (all Draft Standards), I think those just all got moved to Full Standard at same time. Will the IESG announce they have been move to Full Standard to as part of this announcement?

[Ballot comment]
Section 4., paragraph 1:
>    The following dialogue illustrates the use of the 8bit-MIMEtransport
>    service extension:

  Suggest to use RFC2606 example domains in this example.

[Note]: 'S. Moonesamy (sm+ietf@elandsys.com) is the Document Shepherd.
Note that all downrefs were called out during the IETF LC and are as per IESG discussion earlier this year.' added by Alexey Melnikov

IANA comments:

[Note to Authors: section 6.2 (Acknowledgements) doesn't seem to
belong in the IANA Consideration section.]

Upon approval of this document, IANA will make the following changes in
the "SMTP Service Extensions" registry at
http://www.iana.org/assignments/mail-parameters

OLD:

Keywords Description Reference Note
-------- ------------ ----------- -------------------
8BITMIME Use 8-bit data [RFC1652]

1.a. The Document Shepherd for draft-ietf-yam-rfc1652bis-03 is S.
Moonesamy. I have personally reviewed this version of the document
and I believe that this version is reading for forwarding to the IESG
for publication.

1.b. RFC 1652 was reviewed by participants of the YAM WG and a
pre-evaluation I-D (draft-ietf-yam-rfc1652bis-pre-evaluation-02) was
submitted to the IESG. This document incorporates the changes that
was identified during the pre-evaluation of RFC 1652, from the
feedback received from the IESG and during reviews by participants of
the YAM WG. I do not have any concerns about the depth or breadth of
the reviews that have been performed.

1.c. I do not believe that the document needs more review from a
particular or broader perspective as the specification is well-known
to many participants in the YAM WG and there is already significant
implementation and successful operational experience.

1.d. I do not have any specific concerns or issues with this
document. I am not aware of any IPR claims.

1.e. The WG as a whole understands and agrees to the publication of
the document.

1.f. There hasn't been any threat of appeal or any discontent about
the document.

1.g. There are three instances of non-RFC2606-compliant FQDNs in
Section 4. This is in accordance with the YAM WG
Charter. draft-ietf-yam-rfc1652bis-03 is submitted for publication
as "Full Standard".

1.h. There are only normative references in this document. RFC 2045,
RFC 2046, RFC 5321 and RFC 5322 are downward references. The YAM WG
currently has the goal of also moving these documents to Full Standard.

1.i. There is an IANA considerations section and it is consistent
with the body of the document. There is already a registration for
8BITMIME in the SMTP Service Extensions registry. The entry should be updated.

1.j. The document only contains an ABNF rule and it validates
correctly in an automated checker.

1.k. Document Announcement draft

Technical Summary

This document defines an extension to the SMTP service (8BITMIME)
whereby an SMTP content body consisting of text containing octets
outside of the US-ASCII octet range (hex 00-7F) may be relayed using SMTP.

Working Group Summary

The YAM WG adopted a two-step approach to move this document to Full
Standard. The first step was a pre-evaluation of the existing
specification to identify changes and non-changes. The YAM WG
requested feedback from the IESG on those decisions. The second step
was to incorporate the changes into the document and ensure that any
implementation that conforms to the Draft Standard version of the
specification remains compliant with this document. There was no
controversy. There is consensus to move the specification to Full Standard.

Document Quality

The document has a high degree of technical maturity. In the 16
years since publication, this specification has become an integral
part of all professional SMTP software products and is widely
supported in Internet Mail operations. Ned Freed rewrote part of the
text in Section 3 as the Draft Standard version was published prior
to the introduction of key words to indicate requirement levels.

Personnel

S. Moonesamy is the Document Shepherd for this document. Alexey
Melnikov is the Responsible Area Director.