A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May 19, 2009. Yet Another Mail (yam) ---------------------------------- Last Modified: 2009-05-12 Current Status: Proposed Working Group Chair(s): <TBD> Applications Area Director(s): Lisa Dusseault <lisa.dusseault@messagingarchitects.com> Alexey Melnikov <alexey.melnikov@isode.com> Applications Area Advisor: Alexey Melnikov <alexey.melnikov@isode.com> Mailing Lists: http://mipassoc.org/mailman/listinfo/ietf-yam Description of Working Group: The Yet Another Mail (YAM) WG will revise existing Internet Mail specifications currently at Draft Standard to advance them to Full Standard. YAM will focus strictly on advancing email-related specifications for which the community already has some years of experience with deployment and interoperability. Its function is not to reopen or reconsider protocols - if a specification is found to need significant technical work, YAM will remove it from the WG's agenda. This charter's scope of work is the set of email-related RFCs that are currently at Draft Standard. Each document will be examined, along with its errata, and a recommendation made as to whether it is suitable for advancement to Full Standard. If it is not, the WG may recommend whether it should be republished at Draft Standard, moved to Historic, or recycled to Proposed Standard. However, any actual work to facilitate publication of a document at other than Full Standard is outside the WG's scope. If the WG cannot quickly reach consensus about further work on a document, it will drop the documents from its agenda without further comment or effort. The purpose of this working group is to work on protocols that are already recognized as effectively full standards, improving their written specifications to align with that status. The working group does not intend to revise the actual protocols in any way and will avoid document changes that might even accidentally introduce protocol changes, destabilize a protocol, or introduce semantic or syntactic changes. In particular, it will avoid adding new document sections that were not previously required and making BNF grammar changes that didn't originate from interoperability problems or difficulties in comprehension by implementors. If an existing protocol implementation is conforming to the Draft Standard version of the protocol specification, it must also be conforming to the resulting Full Standard version. Hence, specification changes that create a violation of this requirement are out of scope of the working group charter. On a case by case basis, substantive changes may be considered, if they will modify text to match existing conforming implementations -- that is, implementations that are already deployed with significant use. Specifically, such changes will be permitted to relax requirements or to fix BNF bugs where the intent is and has been clear. The WG will consult with the IESG about proposed changes before it starts working on them. Once the document is done by the WG, approval proceeds using the normal IETF approval process. The two step approach is proposed in order to save both IESG and WG time and to avoid late surprises when a document is considered done by the WG. After the tasks of this charter are completed, the WG will consider rechartering to move selected mature specifications that are still at Proposed Standard to higher maturity levels, or to work on those documents previously identified as needing to be republished at Draft Standard or Proposed Standard. The underpinnings of this WG effort are: (1) Wide deployment and use of interoperable implementations of an existing standards-track protocol demonstrates a presumption that the existing specification is adequate. The burden of demonstrating the contrary lies with those who believe that they see significant technical or documentation defects. (2) It is generally in the best interest of the IETF and the Internet community to see specifications of mature protocols advance on the standards track, eliminating any uncertainty as to whether the protocols have been adequately understood and tested. To that end, YAM will avoid modification of documents simply to adjust them to match contemporary IETF notational or linguistic norms. Obviously, updating of references, boilerplate, and the equivalent are exceptions to this, but success in the WG requires that there be a good-faith commitment by both its participants and the IESG to avoid seeking changes that (a) do not contribute in a substantial and substantive way to the quality and comprehensibility of the specification, or that (b) force a change to the existing protocol. The steps to be followed by the WG are, approximately: o The WG will start work by analyzing the following email related documents which are currently Draft Standards, removing any that have significant technical defects or whose advancement may be controversial under the advancement criteria specified in RFC 2026: RFC 1652 8BITMIME RFC 1864 Content-MD5 RFC 2045, 2046, 2047, 2049 MIME base specs RFC 3282 Content-language RFC 3461 DSNs RFC 3462 Multipart/Report RFC 3463 Enhanced Status Codes RFC 3464 Message Format for DSNs RFC 3798 Message Disposition Notification RFC 4409 Message Submission RFC 5321 SMTP RFC 5322 Internet Message Format o Form review and editing teams for each document to be advanced. o Formulate a list of proposed changes (stated in general terms, rather than specific wording). o Obtain WG consensus and consult with IESG on these changes. o Post I-Ds for WG consideration and consensus formation. o Recommend resulting documents to IESG for publication processing. o Rinse and repeat. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
