It'd be useful for us, as chairs, to know if we have consensus around requirements for interop between implementations of 4871 and 4871bis.
Some of the discussions about things to deprecate may affect that, so if we have a clear understanding in advance it might short-cut some discussions of specific topics. (When developing 4871 from DomainKeys we did have a pretty clear set of principles we followed for this, so if we can get to a similar level of understanding it may help. For example, we required that DomainKeys key records should be usable by 4871 so as not to require folks to re-key when they moved to support 4871.) We see these as the various ways in which implementations could interop. If we had consensus on whether each of these was a MUST, SHOULD or MAY that'd be good IMO. Key Records: 1) 4871bis-compliant code [MUST|SHOULD|MAY] be able to use 4871-compliant key records 2) 4871-compliant code [MUST|SHOULD|MAY] be able to use 4871bis-compliant key records Signatures: 3) 4871-compliant code generated signatures [MUST|SHOULD|MAY] be verifiable by 4871bis-compliant code 4) 4871bis-compliant code generated signatures [MUST|SHOULD|MAY] be verifiable by 4871-compliant code If you could indicate your preferences that'd be good. Just reply to this with your MUST|SHOULD|MAY preferences for 1-4. In case it helps with interpreting this saying e.g. MUST for (3) would mean a 4871bis verifier would never reject a 4871 signer's signature just because it included some deprecated field. Saying MAY for (2) would mean that some "new" key records would not be usable with some 4871-compliant implementations. If you say SHOULD anywhere, please specify what you mean, e.g. by saying "except in the case of <<foo>>" Thanks, Stephen & Barry. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
