On Fri, 13 Feb 2009, Ellen Siegel wrote:
In other words, I think the intent is that messages using the same
UAID MUST be intended to be evaluated as sharing the same sphere of
responsibility (this is a mandate on the sender's usage, not on the
receiver's interpretation); senders SHOULD thus label messages
intended to be evaluated as being within that sphere with the same
UAID (but aren't required to). I don't think that's a
contradiction....
Can you explain why you think this makes it impossible to use i= in an
arbitrary way? I don't see that that usage is excluded. If it's not intended
to be stable, there is no constraint at all except that it can't use an
identical identifier for unrelated groupings. And even if it is intended to
be stable, there is only a SHOULD for using the same identifier.
I think your analysis contains the answer. The minute you say "except
that", it's no longer able to be arbitrary. I can no longer use the
local-part of the UAID to encode the sending date, or a count of viruses
found in the message outbound, or a random number from one to 1000, if I
want to do any of those for some reason.
A normative SHOULD means "have to unless you have a really good reason not
to". It leaves less wiggle room than I'm comfortable with here.
I prefer the option of a DKIM extension by which a signer announces that
the UAID is stable. It imposes no new semantics on the base spec and
doesn't mess with any existing implementations that might do something
funky with "i=", but also makes it possible for a signer to restrict
itself in that way if it deems such to be appropriate or useful.
We SHOULD NOT (in 2119 terms) make any changes to the base spec, which is
followed by a growing deployed base, via erratum or a full revision in a
way which establishes any new constraints.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html