SM wrote:
At 10:29 03-02-2009, Tony Hansen wrote:
Its utility is outside of DKIM. The DKIM base spec says the value is
opaque. Other specs can expose its structure.
According to informative note in RFC 4871, the Local-part of the "i="
tag is optional
because in some cases a signer may not be able to establish a
verified individual identity. That means that it's the Local-part
which is opaque and not the
domain part of the address.
Not really.
Opaque does not mean that the signer had no intent behind the choices they made
in doing the encoding. And in the case of domain name strings, it doesn't mean
that the recipient side can't know it's a domain name. It means that they
cannot know the scheme the signer used for choosing sub-domain names.
At 11:47 03-02-2009, Dave CROCKER wrote:
ps. FWIW, my intent in included SDID was that the particular naming scheme is
outside of DKIM semantics. So marketing.example.com and
hq.example.com, versus
newsletter.example.org and invoices.example.org are significantly different
naming schemes, but the semantics behind them is opaque to DKIM
semantics and,
therefore, to the Identity Assessor.
That makes the domain part opaque too. The corrected text in the
Errata changes the introduction to "permitting a person, role or
organization that owns the signing domain to claim
responsibility". I don't see how anyone can claim responsibility
when we cannot identify the signing domain.
There is a difference between being able to use the d= signing domain versus
having deep knowledge about the underlying intent behind encoding choices for
it.
You know my name is David. You do not know why my parents chose that name, and
it doesn't matter for your use of it as an identifier.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html