ignore this message.
<wet noodle time>
Never post messages close to 2 am.
</wet noodle time>
sigh
Tony Hansen
tony(_at_)att(_dot_)com
Tony Hansen wrote:
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