Create a new, open design team that focuses strictly on the Atom protocol.
There are folks who are interested in helping with the Atom publishing protocol haven't been following the Atom mailing list due to the volume of messages and the dearth of protocol discussion. Creating a design team for just the protocol gives a more focused forum for those folks while letting the main mailing list spend more time on the seemingly-difficult parts of the format document.
There has already been some discussion in the Atom community about whether the protocol should be REST-with-4-verbs, HTTP-with-2-verbs, SOAP-with-WSDL, something else, or some combination of the above with a primary and a "fallback" protocol. However, we haven't even finished getting all the required actions described in the protocol, so trying to decide protocol syntax is premature. In particular, we observe that Sixapart is moving ahead with work in the protocol area (http://sixapart.com/developers/atom/typepad/) and they envision some things that we don't have yet in our protocol drafts.
Having Working Group consensus on a fairly complete list of required actions is a good way for the proponents to start making proposals for how their favored syntax would actually look.
Create a "design team" for completing the list of all the actions that need to be in the Atom protocol. Note that there is no formal definition of design teams in the IETF, and they can be created under rules chosen by the WG chairs. For this design team, we propose a mailing list open to anyone, whose only restriction is that the only initial topic for discussion is the needed actions for the Atom protocol.
The protocol design team will propose to the WG ways of closing all open issues in the Atom protocol document. The document editors will revise the protocol document based on what they hear from the WG.
When that design team is finished and the WG has consensus on the actions for the protocol, different design teams will be started (or the same one re-used) to specify specific syntactic embodiments of the requirements for the protocol (REST-with-4-verbs, REST-with-2-verbs, SOAP-with-WSDL, and maybe others). These design teams will have the same rules as the original: open membership and a single topic for discussion.
When each of those design teams has a specific proposal finished, it will bring it to the WG. At that time, the WG will decide what to do with the proposal. In the end, the WG will also need to decide how many syntaxes we intend to support, and how they will be categorized. The WG can't do that until it has seen all of the syntaxes and see how well they embody the requirements.
See also: PaceProtocolDesignTeam2