Dave Crocker wrote:
Jim Fenton wrote:
Dave Crocker wrote:
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?
The current utility is that, while extensions can be added any time,
constraints need to be added up front. So if another service besides
email
wanted to use DKIM and its key infrastructure, it wouldn't be
possible to
cause new keys created for that service to not also be used for email
unless
we define it now so that "legacy DKIM implementations" in the future
will
honor the constraint.
Actually, this all touches on the question of trying to recruit
signature verifiers into the task of enforcing a signer's internal
policies. That's what restrictions on authorization to signing are.
The same could be said about restrictions on hash and signing
algorithms, yet those are essential.
In spite of your ending statement to the contrary, your explanation
really does seem imply that the s= mechanism is useful in its current
form. An assertion that it's necessary to have it now only makes sense
if it has benefit now, even if the benefit is building a utility
"infrastructure" for later use.
At best, the benefit of having s= defined now depends on whether
people are setting s=email now. Are they? Should they? How will
they know?
Are they: I haven't seen a key with s=email yet, although I'll have to
admit that I don't look at a lot of selectors.
Should they: They should as soon as they start using DKIM for services
other than email, especially if they want to delegate keys to
parties/agents not authorized to send email on their behalf. But until
someone defines use for DKIM in a service other than email, s=email is a
tautology, so I don't think it's important to state.
My point is that the Overview document seeks to describe s= in the
most limited way it can, while at least saying something meaningful.
Deleting a discussion of s= seems inappropriate, as does having the
text say more, since it's a bit of an oddity and I doubt we (the
community) understand it very well.
I'm puzzled that you want to include text on a mechanism that we (the
community) don't understand well, because we're likely to get it wrong
in that case.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html