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/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html