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