As the 4871bis editors worked on resolving the last sets of comments in the 4871bis document, the chairs and the editors had some discussion about other efforts that are interested in re-using portions of the DKIM signing/verifying/key-distribution mechanism outside the email context. See, for example, http://tools.ietf.org/html/draft-desruisseaux-ischedule. This would mean using a DKIM-like mechanism to secure the distribution of scheduling events. That effort is currently referencing (and updating) RFC 4871, but that includes what for them are many irrelevant and inappropriate details that have to do with email.
One way we can handle this and other use cases, as we move the DKIM specification along, is to split the specification into two documents, one that describes the underlying components, and a second that describes the email-specific bits. Note that progression along the standards track is for *specifications*, not for documents, as such, so there's no reason this split has to send us back to another cycle at Proposed Standard. What's required is that we make no changes to the actual protocol (or, at least, only changes that permit advancing to Draft). I've discussed this with the Security ADs and the Applications ADs, and they all agree that (1) such a split could be a good idea and (2) a split that affects organization but does not change the specification could still go directly to Draft Standard. The editors have done some work on this to determine whether they can split it safely, and they believe they have something suitable. The chairs have asked them to post a detailed outline of their proposal so that we can discuss whether the working group thinks a document split is a good idea. We would like the discussion to focus just on that point now, without getting to far into the details of the split, beyond what's necessary to develop consensus for or against splitting. We want to make this clear from the start: the chairs, the editors, and (to the extent that they've thought about it, which is fairly little at this point) the ADs think that splitting the document is appropriate and useful... but it's the working group that will decide whether to do it. Nothing has been decided yet, and it's up to the working group. We'll need rough consensus FOR making the change. Lacking that, 4871bis will stay as it is, as one document. Please try to keep the discussion focused. Expect a message from the document editors very soon, with the details of their proposed split. Barry (and Stephen), as chairs -- P.S. I apologize for not making sure this got posted here for discussion a month ago. The delay is my fault. [Barry] _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
