Subject: [Fwd: Advancing RFC2821 to Draft Standard -- outline of work]
From: Tony Hansen <[email-masked]>
To: ietf-822 mailing list <[email-masked]>, [email-masked], imapext <[email-masked]>
Cc: [email-masked]
Date: Mon, 22 Jan 2007 15:31:51 -0500
List-Id: <ietf-822.imc.org>

This is an FYI of work that's starting up on the [email-masked]
mailing list.

	Tony Hansen
	[email-masked]

Subject: Advancing RFC2821 to Draft Standard -- outline of work
From: Lisa Dusseault <[email-masked]>
To: [email-masked]
Date: Mon, 22 Jan 2007 11:40:08 -0800
List-Id: <ietf-smtp.imc.org>

I've been discussing the advancement of RFC2821 along the standards  
track with a few people, and we'd like to proceed publicly.  This  
email can be considered an informal charter and plan for initial  
work, with consensus goals for the effort, which may not need a  
formal WG.  Charter-bashing should be done *early* if you disagree.  
I'd rather avoid late-cycle suggestions to change the goals. This  
list seems like a fine place to have discussions about the goals, as  
well as to do the actual work, and I'll post pointers to a couple  
other lists to direct people here who aren't already subscribed.

1.  We want to advance RFC2821/SMTP to Draft Standard.  Thus, we  
don't want to design anything "new" or "better" for SMTP as part of  
this particular effort, which would require recycling at Proposed  
Standard -- in fact, we want to be conservative in minimizing  
changes.   As with any movement from DS to PS, changes should be  
limited to, if possible: clarifications of the spec where there are  
discrepancies, and removal of unused features. The fixing of "bugs"  
should be limited to those that have a *very strong* consensus.

Tony Hansen volunteered to keep a chair-like eye on the activity,  
progress and consensus where needed, which will be particularly  
helpful as I'll be on leave in Feb and March.

2.  We do think there are some bugs in the document that are worth  
fixing.  We don't think that those fixes are likely to cause  
significant change to the behavior of conforming implementations.   
Tony Hansen put RFC2821 into XML2RFC format, and John Klensin has a  
revision with fixes which he'll post here.

Volunteers to review, please?

3.  Some interop reporting is likely needed.  We don't think this  
requires a huge effort.  Here's one way to proceed: one step is for  
somebody to write an outline that lists the major interop areas or  
features to consider.  The next step is for a couple implementors to  
fill in that outline their experience with their code-bases and  
talking to other implementations.  Another way to try to proceed is  
to have implementors report what they *don't* implement or find  
doesn't work.  We don't believe we have to document every MUST/MAY/ 
SHOULD but can look at least one level higher (less granular).   
Either way, it shouldn't require new testing, and we definitely want  
to try to keep this lightweight so that there's hope it actually gets  
done.

Ned Freed and Alexey Melnikov have volunteered to do some work here  
-- Alexey has already begun -- and Dave Crocker outlined a "interop  
questionnaire" that would be lightweight.

Ned, Alexey and Dave can you post your proposals or status to this list?

Lisa