Looks good to me.
I have a mild reservation in that "opaque" struck me as the most
appropriate term to begin with, but I'll certainly be OK with this.
Regards,
Al Iverson
On Wed, Mar 25, 2009 at 3:56 PM, Dave CROCKER <dhc(_at_)dcrocker(_dot_)net>
wrote:
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
--
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com -- Chicago, IL, USA
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html