Dave CROCKER wrote:
Michael,
On 5/4/2011 7:58 AM, Michael Thomas wrote:
This is a good example of why this effort has come off the rails.
Going from 4871 to DS should have been a fairly straightforward
effort considering the high degree of interoperability we achieved.
Instead of just removing a few unused features, we've seen a
wholesale rewrite when one was manifestly not needed. Worse,
is that when that history is mentioned it is either disregarded
or sneered at by the senior editor. That is a problem.
"Wholesale rewrite"? Well, that should be easy for you to
document, given how convenient it is to point to the existing diffs.
The task when citing a problem with changes is to point to
/specific/ changes that are problematic. That requires some work.
In particular, please cite normative differences.
Its absolutely amazing how the main points are just blow away. Wow!
#1 NEW - The key difference as so many others has stated is the
MANDATORY mandate for the single output, SDID, with a MUST design
mandate for a futuristic single Trust Identity Assessor module.
#2 NEW - RFC4871bis introduces the AUID identity as a MAY for the
trust module, *yet* this optional consideration is excluded from the
RFC4871bis Output Requirements.
Incidentally, my concerns as well of many other implementors predated
RFC4871 (2007 publication) with the drafting leading to the separation
of policy and all policy related semantics from the base. This was a
major concerns cited by many including the prediction that policy will
be not be completed as a standard.
The goal was to remove the Author Domain (ODID) from DKIM and move it
to *purported* chartered proposed standard for policy, then called
SSP. We completed WG consensus built requirements SSP document
(RFC5017) and eventually ADSP (RFC5617).
In the name of protocol consistency and synergism with completed
chartered RFC work products, it is only natural to expect the ODID
MUST be part of the output identities for RFC4871BIS which should
reflect all the RFC work that was done since RFC4871. Instead we have:
#3 NEW: RFC4871BIS Output requirements that do not reflect any other
work that as done, including this so called "DKIM Service Architecture."
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html