Folks,
The following is offered to prime the discussion/decision process for the one
of
the pending Errata items, developed in the SF working group meeting. It
reflects
what I heard as the gist of the group preference. Obviously, I might have
entirely misunderstood...
So, anything that permits progress is encouraged, such as "looks good", "change
x to y", and "replace the whole thing with this different chunk of text".
There
are no doubt other constructive responses, but this ought to establish the
tone...
"Old" refers to the Errata I-D; "New" is the proffered replacement.
6. RFC4871 Section 2.9 Signing Domain Identifier (SDID)
Old:
A single, opaque value that is the mandatory payload output of
DKIM and which refers to the identity claiming responsibility for
the introduction of a message into the mail stream. It is
New:
A single domain name that is the mandatory payload output of
DKIM and that refers to the identity claiming responsibility for
introduction of a message into the mail stream. For DKIM
processing, the name has only basic domain name semantics; any
possible owner-specific semantics is outside the scope of DKIM.
7. RFC4871 Section 2.10 Agent or User Identifier (AUID)
Old:
A single, opaque value that identifies the agent or user on behalf
of whom the SDID has taken responsibility.
New:
A single domain name that identifies the agent or user on behalf
of whom the SDID has taken responsibility. For DKIM
processing, the name has only basic domain name semantics; any
possible owner-specific semantics is outside the scope of DKIM.
12. RFC4871 Section 3.9 Relationship Between SDID and AUID
Old:
Hence, DKIM delivers to receive-side Identity Assessors
responsible Identifiers that are opaque to the assessor. Their
sub-structures and particular semantics are not publicly defined
and, therefore, cannot be assumed by an Identity Assessor.
New:
Hence, DKIM's mandatory delivery to a receive-side Identity Assessor
is a single domain name. Within the scope of its use as DKIM output,
the name has only basic domain name semantics; any possible
owner-specific semantics is outside the scope of DKIM. That is,
within its role as a DKIM identifier, additional semantics cannot
be assumed by an Identity Assessor.
OK. Start shooting.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
