Subject: [yam] Proposed new Charter for YAM

From: S Moonesamy <[email-masked]>
Date: Thu, 07 Jul 2011 07:26:21 -0700

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

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 07 Jul 2011 17:56:39 +0300

> RFC 4409 Message Submission
Current YAM charter implies work on RFC 3282 and RFC 1864, currently at 
DS.  Are they intentionally excluded from this list now?

Mykyta

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Jul 2011 11:09:08 -0400

> 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 think it's particularly important to do 4409, 5321, and 5322.  We
need to do 5321 and 5322 in order to finally obsolete 821 and 822, and
I think 4409 needs to be at the same level as 5321.  I'm ambivalent
about spending the time to do the others -- I'm not sure how much they
buy us.

> We have a 1 hour block at IETF 81 Quebec City (Tuesday, July 26, 1710 --
> unfortunately opposite vcarddav) to discuss these topics.

Right: I can't be in the YAM meeting because of the vCardDAV conflict.  Sorry.

I think I look at handling the other documents in the same sense that
I look at the efforts to find all the RFC that might maybe possibly
kinda-oughta be moved to Historic, and spinning around on them: there
are better things to do with our time.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 07 Jul 2011 16:52:59 +0100

Barry Leiba wrote:
 [...]

>are better things to do with our time.
I think there are some bugs in ABNFs of DSN, MDN and MIME I would like 
to see fixed. I don't remember anything else worth doing in any other 
specs, but I reserve the right to change my mind.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 07 Jul 2011 09:17:32 -0700

On 7/7/2011 8:52 AM, Alexey Melnikov wrote:
> I think there are some bugs in ABNFs of DSN, MDN and MIME I would like to see
> fixed. I don't remember anything else worth doing in any other specs, but I
> reserve the right to change my mind.

I am a bit confused.

I thought the purpose of yam was to advance some documents, but that the 
continuing flux in the formal standards process prompted a wg decision to put 
things on hold until the standards process issues were resolved.

 From what I can tell, they aren't resolved yet.

What I thought was /not/ a primary goal of yam was to become another drums 
effort, cleaning up existing specs.

Not that such an effort might not be worth considering, but rather than it was a 
non-goal for /this/ group.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 07 Jul 2011 18:57:17 +0200

On 07/Jul/11 17:09, Barry Leiba wrote:
> I think 4409 needs to be at the same level as 5321.

+1, especially since relevant issues have already been nailed.

May I ask if there is any plan to coordinate this with EAI?

---

From: S Moonesamy <[email-masked]>
Date: Thu, 07 Jul 2011 09:34:35 -0700

Hi Mykyta,
At 07:56 07-07-2011, Mykyta Yevstifeyev wrote:
>Current YAM charter implies work on RFC 3282 and RFC 1864, currently 
>at DS.  Are they intentionally excluded from this list now?

It's up to the WG participants to make a case for adding RFC 3282 and 
RFC 1864.  This means getting the commitment of the editor of the RFC 
and several participants to do the work.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Thu, 07 Jul 2011 10:33:49 -0700

Hi Alessandro,
>May I ask if there is any plan to coordinate this with EAI?

There was a message [1] posted by John Klensin, who happens to be one 
of the EAI WG co-chairs, about 4409bis.  I suggest leaving it to the 
EAI WG co-chairs to determine whether coordination with EAI should be 
mentioned in the draft charter.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/yam/current/msg00580.html

---

From: John C Klensin <[email-masked]>
Date: Thu, 07 Jul 2011 17:38:15 -0400

+1

--On Thursday, July 07, 2011 09:17 -0700 Dave CROCKER
<[email-masked]> wrote:

>> I think there are some bugs in ABNFs of DSN, MDN and MIME I
>> would like to see fixed. I don't remember anything else worth
>> doing in any other specs, but I reserve the right to change
>> my mind.
> 
> 
> I am a bit confused.
> 
> I thought the purpose of yam was to advance some documents,
> but that the continuing flux in the formal standards process
> prompted a wg decision to put things on hold until the
> standards process issues were resolved.
> 
> What I thought was /not/ a primary goal of yam was to become
> another drums effort, cleaning up existing specs.
> 
> Not that such an effort might not be worth considering, but
> rather than it was a non-goal for /this/ group.
> 
> d/

---

From: John C Klensin <[email-masked]>
Date: Thu, 07 Jul 2011 17:49:51 -0400

--On Thursday, July 07, 2011 11:09 -0400 Barry Leiba
<[email-masked]> wrote:

>> 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 think it's particularly important to do 4409, 5321, and
> 5322.  We need to do 5321 and 5322 in order to finally
> obsolete 821 and 822, and I think 4409 needs to be at the same
> level as 5321.  I'm ambivalent about spending the time to do
> the others -- I'm not sure how much they buy us.

I note that we tried to process 4409 and that the result was
requests for a number of clean-up requests about the nature of
the spec, not just the document, and that went beyond what had
been agreed on in our pre-evaluation phase.  See Dave Crocker's
comments about YAM, DRUMS, and clean-up efforts.  

>From my point of view, whether 5321bis and 5322bis can be
completely and processed still depends on the question around
which YAM was organized, i.e., whether both the WG and IESG can
exercise restraint about "clean up" and "wouldn't it be nice"
changes as well as actual protocol modifications.  To me,
4409bis is an interesting test case: if we cannot process that
relatively short and uncontroversial spec without significant
effort, there are real questions about whether taking on the
much longer, more complex, and more controversial 5321bis is
really the best use of the time of the people who would have to
be involved.   And, while 5322bis almost certainly involves less
work than 5321bis, I know what Pete has to do with his
IETF-related time these days and I'm absolutely certain his AD
responsibilities should be higher priority.

And, of course, that leaves aside the question of the motivation
for doing a lightweight "advance the document so we can finally
and definitively retire 821 and 822" update if the "two maturity
level" discussion eliminates the problem.

> I think I look at handling the other documents in the same
> sense that I look at the efforts to find all the RFC that
> might maybe possibly kinda-oughta be moved to Historic, and
> spinning around on them: there are better things to do with
> our time.

My opinion as to whether 5321bis and 5322bis themselves fall
above or below that line depends on the amount of aggravation
needed to move them forward.

best,
   john

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 08 Jul 2011 15:21:53 +0100

Dave (and John),

Dave CROCKER wrote:

> I thought the purpose of yam was to advance some documents, but that 
> the continuing flux in the formal standards process prompted a wg 
> decision to put things on hold until the standards process issues were 
> resolved.
>
> What I thought was /not/ a primary goal of yam was to become another 
> drums effort, cleaning up existing specs.
>
> Not that such an effort might not be worth considering, but rather 
> than it was a non-goal for /this/ group.

Firstly, what I proposed above is fixing specs to align with what is 
already in wide use. For example, the latest MDN spec removed some 
implementation choices (due to lack of deployments), however its ABNF 
was broken in the process by only partially removing unused productions. 
So the ABNF is actually more broken than in the previous version of the 
spec.

Secondly, we are talking about rechartering and any agreements about the 
purpose of the WG that were reached before don't have to apply. Many 
IETF WGs when recharter end up doing things specifically prohibited by 
their previous Charters. So your comment about "non-goal for this group" 
doesn't make any sense to me.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 08 Jul 2011 07:39:23 -0700

On 7/8/2011 7:21 AM, Alexey Melnikov wrote:
> Firstly, what I proposed above is fixing specs to align with what is already in
> wide use.

Right.  I understood that.  And it's a reasonable goal.

But it was not the reason for starting YAM.  And as stated, it is broader than 
the similar, derivative goal that YAM did have, to make the "easy" changes.

In other words, you are targeting a goal that is serious work and actually has 
little to do with the reason that YAM was pursued.  As stated, I believe your 
goal is close to that of DRUMS.

>  Many IETF WGs when
> recharter end up doing things specifically prohibited by their previous
> Charters. So your comment about "non-goal for this group" doesn't make any sense
> to me.

This is not a 'continuation' of YAM.  If your suggestion is rechartering, then 
it essentially re-uses a working group name for a significantly different task.

Besides a slight taste of bait-and-switch, the deeper question is whether the 
considerable effort to do this revision effort is viewed as worth the 
considerable effort it will take, especially in comparison with other email 
tasks the IETF might pursue?

d/

-- 

   Dave Crocker

---

From: S Moonesamy <[email-masked]>
Date: Wed, 20 Jul 2011 07:18:26 -0700

At 07:39 AM 7/8/2011, Dave CROCKER wrote:
>Besides a slight taste of bait-and-switch, the deeper question is 
>whether the considerable effort to do this revision effort is viewed 
>as worth the considerable effort it will take, especially in 
>comparison with other email tasks the IETF might pursue?

The latest round of discussions has highlighted that some of the YAM 
work intersects with work being carried out in other working groups.

Mykyta Yevstifeyev asked a question [1] about RFC 3282 and RFC 
1864.  Nobody made a case for taking them up as work items.

Barry Leiba mentioned [2] that:

  "it's particularly important to do 4409, 5321, and 5322.  We
   need to do 5321 and 5322 in order to finally obsolete 821 and 822, and
   I think 4409 needs to be at the same level as 5321.  I'm ambivalent
   about spending the time to do the others -- I'm not sure how much they
   buy us."

Alexey Melnikov would like to see some bugs in ABNFs of DSN, MDN and 
MIME fixed [3].

Dave Crocker mentioned [4] that the purpose of yam was to advance 
some documents, but that the continuing flux in the formal standards 
process prompted a wg decision to put things on hold until the 
standards process issues were resolved.  John Klensin was in agreement [5].

I'll include some of the discussion about updating multipart/report 
that was brought up by Murray Kucherawy [6].  Ned Freed has no 
opinion about the venue for the work [7].  John Klensin suggested a 
focused review discussion and get out a document that
updates the base MIME specification if someone has the motivation and 
time to invest in such an effort [8].  Ned Freed would like to see 
such changes lifted in separate documents [9].  Murray Kucherawy 
raised a concern about such an approach as it leaves two versions of 
multipart/report around [10].  He also stated that he is in favor of 
a charter that allows the following:

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

Please read the above as a rough summary.  As usual, if your comments 
are misinterpreted, post a message to the mailing list.

Regards,
S. Moonesamy
YAM WG co-chair

1. http://www.ietf.org/mail-archive/web/yam/current/msg00648.html
2. http://www.ietf.org/mail-archive/web/yam/current/msg00644.html
3. http://www.ietf.org/mail-archive/web/yam/current/msg00645.html
4. http://www.ietf.org/mail-archive/web/yam/current/msg00646.html
5. http://www.ietf.org/mail-archive/web/yam/current/msg00650.html
6. http://www.ietf.org/mail-archive/web/yam/current/msg00659.html
7. http://www.ietf.org/mail-archive/web/yam/current/msg00661.html
8. http://www.ietf.org/mail-archive/web/yam/current/msg00663.html
9. http://www.ietf.org/mail-archive/web/yam/current/msg00670.html
10. http://www.ietf.org/mail-archive/web/yam/current/msg00673.html

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 22 Jul 2011 09:30:43 +0200

On 20/Jul/11 16:18, S Moonesamy wrote:
> that was brought up by Murray Kucherawy [6].  Ned Freed has no opinion
> about the venue for the work [7].  John Klensin suggested a focused
> review discussion and get out a document that
> multipart/report around [10].  He also stated that he is in favor of a
> charter that allows the following:
> 

FWIW, my opinion on this is that no changes are needed:  Since RFC
3462 says

   When used to send a report, the Multipart/Report content-type must
   be the top-level MIME content type for any report message

it obviously implies that the Multipart/Report content-type can also
be used to send something else, possibly not at top level.  I think
that the "report" mentioned there is what Ned called an "active" DSN
or MDN.  He also pointed out that's how the top-level requirement was
understood by application designers.  Hence, clarifications for any
obscure sentence are not modifications of the protocol, and could be
filed as errata of the relevant DSs.

jm2c.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 22 Jul 2011 07:33:56 -0700

Hi Alessandro,
>filed as errata of the relevant DSs.

As a general comment, the burden of demonstrating that a 
clarification is necessary as a sentence is obscure is on the person 
requesting the change.

Regards,
S. Moonesamy
YAM WG co-chair

---

From: Ned Freed <[email-masked]>
Date: Fri, 22 Jul 2011 07:54:10 -0700 (PDT)

> be used to send something else, possibly not at top level.

The problem is the term "report" here is too general - any multipart/report
object is in some sense a "report" - it's what the name implies. 

In fact because of this the sentence as written really doesn't pass muster in
terms of clarity. It's obviously trying to talk about some subset of
multipart/report usage, but then it muddies things up by using terms that
don't really define a proper subset.

> I think

Now that's an interesting idea. I agree that implementors seem to have
interpreted this correctly, so maybe we could treat it as an errata.

				Ned