On 13/Jan/11 18:10, Dave CROCKER wrote:
3. For authentication uses, it's unlikely that the DKIM-Signature header field
should be shared, because it is an explicit flag for specific DKIM semantics,
including the "meaning" of a signature. Any other signature scheme is going
to
have different semantics and will need a different flag for indicating it.
Perhaps a few more words on the /spirit/ of the split are in order. I
have serious difficulties at grasping it.
On the one hand, as a glance to the DOSETA draft confirms, the
generalization being sketched seems to be by far more complex than
those that a simple porting to HTTP (or similar header/content
protocol) requires. The template model introduces an extra degree of
freedom whose justification is not obvious. For example, the IANA
registry already defines a "DKIM-Signature Query Method" for the
single dns/txt entry. A client service may define additional entries.
Yet, the Key Retrieval template offers a different way to achieve a
similar effect. Why would we need that?
On the other hand, after the endless discussions about the meaning of
DKIM signatures, I had started to appreciate the current 1st paragraph
of rfc4871bis. Claiming "some responsibility" obviously alludes to
the ability of imposing any policies on the contents originating from
controlled servers. Thus, DKIM characterizes _messages_ as-if their
contents originated from a direct connection to an ADMD server. Why
would client services have to redefine that?
I think that if it were possible to design a much much simpler
generalization, opinions about the resulting split might be different.
To wit, if the only details pertaining to our client service
consisted of bindings to RFC 5322, e.g. mandatory fields, then the
split could be seen as a simplification. In particular, it would
happen to nicely insulate a controversial compliance issue that we
discussed recently.
jm2c
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html