Hello,
The YAM WG adopted a two-step approach to advance email-related
specifications from Draft to Full Standard. That approach has not
been successful as it was viewed as more work for the IESG. There
are also process issues, e.g. proposed changes to the Standards
Process, that have hampered the work.
During an off-list conversation, there was a comment about going back
to the basics to side-step issues that the WG cannot solve. The
questions that came up are as follows:
(i) What problems are the WG attempting to solve?
(ii) Does it have the commitment to do the work?
(iii) Can the work be completed within the defined period?
The first one, borrowed from the existing YAM Charter, is simple enough:
The Yet Another Mail (YAM) WG will revise existing Internet Mail
specifications. YAM will focus strictly on advancing email-related
specifications for which the community already has some years of
experience with deployment and interoperability.
This message is to gauge whether the editors of the RFCs are still
interested in working on the specifications. If it is, the next step
is to gauge whether the WG can commit to reviewing the drafts.
Question 3 was partly addressed in the existing charter, i.e. a less
controversial path to complete the work within an acceptable time
frame. As we haven't seen the usual fights within the last year,
that may still be doable. The failure stems from the lack of
continuous effort to drive documents through WGLC. That's the
responsibility of the WG Chairs. However, it cannot be done without
the help of the editors and WG participants.
The objective of rechartering (draft charter included below) is to
focus on the work instead of the document label or process issues
outside the control of the WG. A few comments are included in
[brackets] that would not be in the charter text.
-- draft --
The Yet Another Mail (YAM) WG will review and optionally revise existing
Internet Mail specifications. YAM will focus strictly on advancing
email-related specifications for which the community already has some years
of experience with deployment and interoperability.
The working group will avoid document changes that might accidentally
introduce protocol changes, destabilize a protocol, or introduce
semantic or syntactic changes, as protocols in scope of this WG
are usually very widely deployed.
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.
However the WG might reach consensus that certain changes have to be
done in order to remove restrictions which were proven to be problematic
in the field, or which restrict evolution of the protocols.
The WG group will consider working on the following documents which are
currently Draft Standards or BCPs:
RFC 2045, 2046, 2047, 2049 MIME base specs
RFC 3461 DSNs
RFC 3462 Multipart/Report
RFC 3464 Message Format for DSNs
RFC 3798 Message Disposition Notification
RFC 4409 Message Submission
RFC 5321 SMTP
RFC 5322 Message Format
[4409bis still has to go through Last Call. 5321bis and 5322bis could
be done "quickly" if there are cycles.]
Document reviews might conclude the some of the documents listed above
are in a reasonable state and/or are not worth reopening.
-- end draft --
Please note that the intention is not to rewrite the specifications
or encourage long discussions.
We have a 1 hour block at IETF 81 Quebec City (Tuesday, July 26, 1710
-- unfortunately opposite vcarddav) to discuss these topics.
In simple terms, do we have the spare cycles to work on the documents?
Regards,
S. Moonesamy, Tony Hansen
co-chairs, YAM
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
