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 <[email protected]> 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
