Fwd: WG Review: Mail Maintenance (mailmaint)

--===============3673989044419095361==
Content-Type: multipart/alternative; boundary="00000000000080c78b061676847e"

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

FYI only.  Please don't discuss this here; send feedback to me directly or
to [email protected].

-MSK, ART AD


---------- Forwarded message ---------
From: The IESG <[email protected]>
Date: Fri, Apr 19, 2024 at 10:25=E2=80=AFAM
Subject: WG Review: Mail Maintenance (mailmaint)
To: IETF-Announce <[email protected]>


A new IETF WG has been proposed in the Applications and Real-Time Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send you=
r
comments to the IESG mailing list ([email protected]) by 2024-04-29.

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

Chairs:
  TBD

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

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

Mailing list:
  TBD

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 does not
include extensions to related protocols such as IMAP.)

>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.  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.  An
interoperability demonstration will be preferred.

* 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.

* Chartering of a dedicated working group with a custom charter is strongly
preferred when engaging any work that updates the base email documents (RFC
5321 and RFC 5322 and their successors).

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



_______________________________________________
IETF-Announce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-announce

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

<div dir=3D"ltr"><div>FYI only.=C2=A0 Please don&#39;t discuss this here; s=
end feedback to me directly or to <a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a>.</div><div><br></div><div>-MSK, ART AD<br></d=
iv><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"=
>---------- Forwarded message ---------<br>From: <b class=3D"gmail_senderna=
me" dir=3D"auto">The IESG</b> <span dir=3D"auto">&lt;<a href=3D"mailto:iesg=
[email protected]">[email protected]</a>&gt;</span><br>Date: Fri, A=
pr 19, 2024 at 10:25=E2=80=AFAM<br>Subject: WG Review: Mail Maintenance (ma=
ilmaint)<br>To: IETF-Announce &lt;<a href=3D"mailto:[email protected]"=
>[email protected]</a>&gt;<br></div><br><br>A new IETF WG has been pro=
posed in the Applications and Real-Time Area. The<br>
IESG has not made any determination yet. The following draft charter was<br=
>
submitted, and is provided for informational purposes only. Please send you=
r<br>
comments to the IESG mailing list (<a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a>) by 2024-04-29.<br>
<br>
Mail Maintenance (mailmaint)<br>
-----------------------------------------------------------------------<br>
Current status: Proposed WG<br>
<br>
Chairs:<br>
=C2=A0 TBD<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 TBD<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 doe=
s not<br>
include extensions to related protocols such as IMAP.)<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 Calls for Ado=
ption<br>
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.=C2=A0 =
An<br>
interoperability demonstration will be preferred.<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>
* Chartering of a dedicated working group with a custom charter is strongly=
<br>
preferred when engaging any work that updates the base email documents (RFC=
<br>
5321 and RFC 5322 and their successors).<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>
<br>
<br>
_______________________________________________<br>
IETF-Announce mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">IETF-Announce@i=
etf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/ietf-announce" rel=3D"nore=
ferrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/ietf-announ=
ce</a><br>
</div></div>

--00000000000080c78b061676847e--


--===============3673989044419095361==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ietf-smtp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-smtp

--===============3673989044419095361==--