[ietf-smtp] Fwd: WG Action: Formed Mail Maintenance (mai lmaint)

--===============0043460950198902318==
Content-Type: multipart/alternative; boundary="000000000000b0f26a06181d371c"

--000000000000b0f26a06181d371c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

FYI

---------- Forwarded message ---------
From: IESG Secretary <[email protected]>
Date: Thu, May 9, 2024 at 1:01=E2=80=AFPM
Subject: WG Action: Formed Mail Maintenance (mailmaint)
To: IETF Announcement List <[email protected]>
Cc: <[email protected]>, <[email protected]>, <[email protected]>


A new IETF WG has been formed in the Applications and Real-Time Area. For
additional information, please contact the Area Directors or the WG Chair.

Mail Maintenance (mailmaint)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  Kenneth Murchison <[email protected]>

Assigned Area Director:
  Murray Kucherawy <[email protected]>

Applications and Real-Time Area Directors:
  Murray Kucherawy <[email protected]>
  Orie Steele <[email protected]>

Mailing list:
  Address: [email protected]
  To subscribe: https://www.ietf.org/mailman/listinfo/mailmaint
  Archive: https://mailarchive.ietf.org/arch/browse/mailmaint/

Group page: https://datatracker.ietf.org/group/mailmaint/

Charter: https://datatracker.ietf.org/doc/charter-ietf-mailmaint/

Internet Messaging (=E2=80=9Cemail=E2=80=9D) is one of the oldest applicati=
ons still
supported by the IETF.  It consists of numerous layers and extensions that
support the robust construction, transport, retrieval, and interpretation o=
f
messages.

(For the purposes of this charter, =E2=80=9Cemail=E2=80=9D starts in RFC 53=
21 which covers
transport and RFC 5322 which covers message format, and extends into
specifications based on those documents and their antecedents.  It also
includes related protocols such as IMAP [RFC 9051] and JMAP [RFC 8620, et
seq].)

>From time to time, new work in the email space is brought to the IETF for
consideration and development.  Where there is enough critical mass to
create
a working group to develop and publish the work, this is the preferred
case.
More often, however, a proposal is brought that lacks enough critical mass
to
independently support chartering of a working group, but would still be
useful to publish as a standard.  Such projects must then either seek the
assent of an Area Director willing to sponsor it as a standards track
document, or support via the Independent Stream Editor (ISE) without
standards track status.

The MAILMAINT (=E2=80=9CMail Maintenance=E2=80=9D) working group will consi=
der projects in
the email space that are too small to warrant construction of a dedicated
working group.  This will take advantage of a common community to consider
these proposals rather than forming a series of disparate but related
communities.

Work proposed for MAILMAINT may arrive via direct proposals, or it may be
referred via one or more DISPATCH-style working groups.  Recorded Calls for
Adoption are required for all work proposals.

Proponents of work that is not taken up within the IETF may, of course,
decide to bring their proposal to the Independent Stream.  The working grou=
p
should discuss such proposals with the ISE and share the results of the
working group=E2=80=99s consideration.

Further, MAILMAINT will observe the following constraints when considering
the adoption of new work directly:

* Prior to accepting any Standards Track document for development, there
must
be a commitment to implement the resulting proposed standard from at least
two independent parties, as recorded on a related IETF mailing list.

* When deciding to send any Standards Track work to the IESG, there must
first be produced a report documenting at least two (preferably more)
independent implementations with at least partial interoperation based on
the
developed specification.

* The above constraints do not apply to documents that are not intended for
the Standards Track.

* Chartering of a dedicated working group with a custom charter is strongly
preferred when engaging any work that updates any base email documents,
including but not limited to those identified above.

All work will be announced to appropriate non-WG lists such as ietf-822,
ietf-smtp, ietf-dkim, etc., at the time a Call For Adoption or Working Grou=
p
Last Call begins.

Standards work being taken up by MAILMAINT should be checked with other
relevant areas (mainly Security) to confirm appropriate oversight or
possible
assignment to that area.

Milestones will be used to track all approved work, including during
chartering and rechartering.

Milestones:

  Jul 2024 - Call For Adoption of draft-dweekly-wrong-recipient

--000000000000b0f26a06181d371c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">FYI<br><div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">---------- Forwarded message ---------<br>From: <b c=
lass=3D"gmail_sendername" dir=3D"auto">IESG Secretary</b> <span dir=3D"auto=
">&lt;<a href=3D"mailto:[email protected]">[email protected]</a=
>&gt;</span><br>Date: Thu, May 9, 2024 at 1:01=E2=80=AFPM<br>Subject: WG Ac=
tion: Formed Mail Maintenance (mailmaint)<br>To: IETF Announcement List &lt=
;<a href=3D"mailto:[email protected]">[email protected]</a>&gt;<b=
r>Cc:  &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt;,  &lt;<a =
href=3D"mailto:[email protected]">[email protected]</a>&gt;=
,  &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt;<br>=
</div><br><br>A new IETF WG has been formed in the Applications and Real-Ti=
me Area. For<br>
additional information, please contact the Area Directors or the WG Chair.<=
br>
<br>
Mail Maintenance (mailmaint)<br>
-----------------------------------------------------------------------<br>
Current status: Proposed WG<br>
<br>
Chairs:<br>
=C2=A0 Kenneth Murchison &lt;<a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a>&gt;<br>
<br>
Assigned Area Director:<br>
=C2=A0 Murray Kucherawy &lt;<a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a>&gt;<br>
<br>
Applications and Real-Time Area Directors:<br>
=C2=A0 Murray Kucherawy &lt;<a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a>&gt;<br>
=C2=A0 Orie Steele &lt;[email protected]&gt;<br>
<br>
Mailing list:<br>
=C2=A0 Address: <a href=3D"mailto:[email protected]" target=3D"_blank">mai=
[email protected]</a><br>
=C2=A0 To subscribe: <a href=3D"https://www.ietf.org/mailman/listinfo/mailm=
aint" rel=3D"noreferrer" target=3D"_blank">https://www.ietf.org/mailman/lis=
tinfo/mailmaint</a><br>
=C2=A0 Archive: <a href=3D"https://mailarchive.ietf.org/arch/browse/mailmai=
nt/" rel=3D"noreferrer" target=3D"_blank">https://mailarchive.ietf.org/arch=
/browse/mailmaint/</a><br>
<br>
Group page: <a href=3D"https://datatracker.ietf.org/group/mailmaint/" rel=
=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/group/mailma=
int/</a><br>
<br>
Charter: <a href=3D"https://datatracker.ietf.org/doc/charter-ietf-mailmaint=
/" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/doc/ch=
arter-ietf-mailmaint/</a><br>
<br>
Internet Messaging (=E2=80=9Cemail=E2=80=9D) is one of the oldest applicati=
ons still<br>
supported by the IETF.=C2=A0 It consists of numerous layers and extensions =
that<br>
support the robust construction, transport, retrieval, and interpretation o=
f<br>
messages.<br>
<br>
(For the purposes of this charter, =E2=80=9Cemail=E2=80=9D starts in RFC 53=
21 which covers<br>
transport and RFC 5322 which covers message format, and extends into<br>
specifications based on those documents and their antecedents.=C2=A0 It als=
o<br>
includes related protocols such as IMAP [RFC 9051] and JMAP [RFC 8620, et<b=
r>
seq].)<br>
<br>
&gt;From time to time, new work in the email space is brought to the IETF f=
or<br>
consideration and development.=C2=A0 Where there is enough critical mass to=
 create<br>
a working group to develop and publish the work, this is the preferred case=
. <br>
More often, however, a proposal is brought that lacks enough critical mass =
to<br>
independently support chartering of a working group, but would still be<br>
useful to publish as a standard.=C2=A0 Such projects must then either seek =
the<br>
assent of an Area Director willing to sponsor it as a standards track<br>
document, or support via the Independent Stream Editor (ISE) without<br>
standards track status.<br>
<br>
The MAILMAINT (=E2=80=9CMail Maintenance=E2=80=9D) working group will consi=
der projects in<br>
the email space that are too small to warrant construction of a dedicated<b=
r>
working group.=C2=A0 This will take advantage of a common community to cons=
ider<br>
these proposals rather than forming a series of disparate but related<br>
communities.<br>
<br>
Work proposed for MAILMAINT may arrive via direct proposals, or it may be<b=
r>
referred via one or more DISPATCH-style working groups.=C2=A0 Recorded Call=
s for<br>
Adoption are required for all work proposals.<br>
<br>
Proponents of work that is not taken up within the IETF may, of course,<br>
decide to bring their proposal to the Independent Stream.=C2=A0 The working=
 group<br>
should discuss such proposals with the ISE and share the results of the<br>
working group=E2=80=99s consideration.<br>
<br>
Further, MAILMAINT will observe the following constraints when considering<=
br>
the adoption of new work directly:<br>
<br>
* Prior to accepting any Standards Track document for development, there mu=
st<br>
be a commitment to implement the resulting proposed standard from at least<=
br>
two independent parties, as recorded on a related IETF mailing list.<br>
<br>
* When deciding to send any Standards Track work to the IESG, there must<br=
>
first be produced a report documenting at least two (preferably more)<br>
independent implementations with at least partial interoperation based on t=
he<br>
developed specification.<br>
<br>
* The above constraints do not apply to documents that are not intended for=
<br>
the Standards Track.<br>
<br>
* Chartering of a dedicated working group with a custom charter is strongly=
<br>
preferred when engaging any work that updates any base email documents,<br>
including but not limited to those identified above.<br>
<br>
All work will be announced to appropriate non-WG lists such as ietf-822,<br=
>
ietf-smtp, ietf-dkim, etc., at the time a Call For Adoption or Working Grou=
p<br>
Last Call begins.<br>
<br>
Standards work being taken up by MAILMAINT should be checked with other<br>
relevant areas (mainly Security) to confirm appropriate oversight or possib=
le<br>
assignment to that area.<br>
<br>
Milestones will be used to track all approved work, including during<br>
chartering and rechartering.<br>
<br>
Milestones:<br>
<br>
=C2=A0 Jul 2024 - Call For Adoption of draft-dweekly-wrong-recipient<br>
<br>
</div></div></div>

--000000000000b0f26a06181d371c--


--===============0043460950198902318==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KaWV0Zi1zbXRw
IG1haWxpbmcgbGlzdCAtLSBpZXRmLXNtdHBAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBh
biBlbWFpbCB0byBpZXRmLXNtdHAtbGVhdmVAaWV0Zi5vcmcK

--===============0043460950198902318==--