Dave Crocker wrote:
Jim Fenton wrote:
Dave Crocker wrote:
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.
We seem to have a disconnect. You said that s= needed to be in the
protocol now. If it isn't used now, then what is the benefit of
having it in the protocol now?
(I'm not arguing for a change in the specification, but am trying to
argue for having the Overview include no more discussion than a basic
regurgitation of the specification's statement of what the option is
for. On the other hand, making no mention of the option encourages
confusion, since it is part of the current specification and failing
to refer to it leads to obvious "what is this for?" questions.)
The benefit is in order to cause verifiers to check for s= if it is
present. This enable the potantial that DKIM could be used for other
services.
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.
Because it is part of the specification. Having the Overview fail to
refer to it does not remove it from the specification.
So the Overview must mention every mechanism in the specification? It
doesn't.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html