This is an FYI of work that's starting up on the ietf-smtp(_at_)imc(_dot_)org
--- Begin Message ---
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
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?
--- End Message ---