Subject: Re: [yam] WG Action: Yet Another Mail (yam)

From: Chris Newman <[email-masked]>
Date: Fri, 31 Jul 2009 18:32:11 +0200

--On May 26, 2009 14:42:28 -0700 Fred Baker <[email-masked]> wrote:
> My first thought is that the wg is not properly named. There is a place
> for "another" mail standard, and this is by definition not that. A more
> applicable name might be "Mail At Full Standard".

"Yet Another Mail WG" was designed to have a cute title and acronym, and 
the result is perhaps less clear than it could have been.  But nobody 
objected during charter last call, so that's the name.

> Something not brought out (at least that I noticed) in the charter - is
> there an interoperability testing component demonstrating multiple
> implementations from the RFCs that interoperate for each feature in
> question?

That is only a requirement when advancing from proposed to draft.  There is 
no requirement to do that when advancing from draft to Standard.  Assuming 
the WG re-charters to move things from proposed to draft in the future, the 
IETF process would require us to produce interoperability reports for those 
efforts, so I see no need to repeat that in the charter.

		- Chris

> On May 26, 2009, at 2:20 PM, IESG Secretary wrote:
>
>> A new IETF working group has been formed in the Applications Area.
>> For
>> additional information, please contact the Area Directors or the WG
>> Chairs.
>>
>> Yet Another Mail (yam)
>> ----------------------------------
>> Last Modified: 2009-05-22
>>
>> Current Status: Proposed Working Group
>>
>> Chair(s):
>>
>> Tony Hansen <[email-masked]>
>> Chris Newman <[email-masked]>
>>
>> Applications Area Director(s):
>>
>> Lisa Dusseault <[email-masked]>
>> Alexey Melnikov <[email-masked]>
>>
>> Applications Area Advisor:
>>
>> Alexey Melnikov <[email-masked]>
>>
>> Mailing Lists:
>>
>> General Discussion: [email-masked]
>> To Subscribe: [email-masked]
>> In Body: in body 'subscribe'
>> Archive: http://www.ietf.org/mail-archive/web/yam/index.html
>>
>> 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.
>>
>>
>> Goals and Milestones:
>>
>> Sep 2009 Produce the initial list of documents to consider for
>> advancement to Full Standard
>> Nov 2010 Recharter or conclude
>> _______________________________________________
>> IETF-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>
>