um, erm, ahem
ss 4.1 para 3 is supposed to be talking about the use of the s= selector
value to choose which signature key is being used.
But Jim mistook the paragraph to be talking about the s= service type
value that can be found *within* a signature key.
This indicates to me that our text led Jim astray.
Tony Hansen
tony(_at_)att(_dot_)com
Dave Crocker wrote:
Jim Fenton wrote:
Section 4.1 paragraph 3 talks about the service type (s=) constraint in
key records, and goes on to say that it is helpful when delegating
signing authority. s= was included to provide expansion capability
should, at some point, some service other than email decide to use
DKIM. If and when some other service does use DKIM, the ability to
constrain a key to signing email only would help delegation. In the
meanwhile, there isn't any benefit to delegation as a result of s=.
I suggest that the paragraph be deleted.
You suggest having the DKIM Overview make no comment on the s= parameter?
The signing specification's explanatory text for s= is:
"This tag is intended to constrain the use of keys for other purposes".
If there is something inaccurate in the Overview text, what is it?
As for "included to provide expansion capability", I don't understand what
this
means. The signing spec text says it was included for a different purpose,
but
that it *includes* an expansion capability, to list other services.
You further seem to indicate that s= is not currently useful but would be if
it
listed other services. (I well might be misunderstanding this part of your
text.) In any event, either the capability has currently utility, or it was
a
mistake to put it in the spec. Which are you saying?
d/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html