[Top] [All Lists]

Advancing RFC2821 to Draft Standard -- outline of work

2007-01-22 12:59:17

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?


<Prev in Thread] Current Thread [Next in Thread>