I see a couple things going on in this thread.
1) It's clear to me that we need to be *very* careful within the
document whenever we refer to any of the keywords to make it totally
clear whether we're talking about signature keywords or dns key
keywords. Several of the messages in this thread made mistakes of this
nature. In particular, using "signature key s=" could be misread as
either one. (There was a similar problem in the email world until we
learned to be very careful about differentiating between
rfc2821.mailfrom and rfc2822.from, etc.)
I'm going to suggest that we take a pass through the document and,
anywhere we refer to a keyword, use either signature. or dnskey. as a
prefix, as in signature.s= and dnskey.s=.
2) There's a tussle going on here between documenting how we *know*
dkim can be used today and how we think it will be used in the future.
There are certain thing's we've put in to the base spec that we think
will be useful in the future, but don't really know for certain that
they are indeed useful or will be used the way we intended. They're for
future use. Dnskey.s= is one example of this.
Now in my mind, an overview document *does* need to go into how we
expect the base spec to be used. We'd be doing a disservice to our
readers if we ignored that aspect. But at the same time we probably do
need to be careful to differentiate more clearly between the two areas.
Tony Hansen
tony(_at_)att(_dot_)com
Jim Fenton wrote:
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html