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