On 4/1/11 2:08 PM, Murray S. Kucherawy wrote: > > In our conference call with Jim, Dave and I are left with three things > that need discussion in the working group before we request a working > group last call on it. > > > The first, and biggest, is the removal of “i=” that Jim has proposed > separately, so please comment on that thread. > For ADSP the d= and the From domain must match, which removes the need for i=. Nevertheless, the i= can introduce different identities that might assist when transitioning to different IDN encodings.
There is a growing use of UTF-8 DNS labels. For example use dig to resolve バスケ指導.meblog.biz or xn--rckp2e534u8jh.meblog.biz. RFC6055 should be read with an understanding there will be increased UTF-8 use in DNS. While currently RFC5321 requires email domains to use letters digits and hyphens, such a requirement will be problematic for other name services. It is also not clear whether UTF-8 aliases would be prohibited, since the only requirement appears to be resolution of necessary resources. It is too soon to know how this might be best resolved, so why toss out options that might help resolve what a signing domain hopes to permit. > > Two lesser issues are: > > 1) The document currently talks about authors signing their mail, when > authors really don’t sign their mail, ADMDs do. The point of the > objection is that it might be wiser to talk about actual uses only and > not include possible uses. The suggestion is thus to remove the idea > that an author can do signing, changing it to “authors’ organizations” > or perhaps “authors’ ADMDs”. Is there support for this, or support > against making that change, or does it not really matter? > It matters, and it should indicate the domain does the signing, while also getting rid of the g= stuff in the key. > > 2) The document has text related to “assessment”. Does an “independent > assessment service” fit into the DKIM model? Again, the issue is > whether or not we want to include discussion of uses that are possible > but uncommon. Is there support for this change, or support against > making the change, or does it not really matter? > It is likely the only sustainable assessment will be matching with known good sources, which would benefit by having a means to handle aliases and authorized paths. :^) > > The text in question is this: > > *2.3**. Identity* > > A person, role, or organization. In the context of DKIM, examples > > include the author, the author's organization, an ISP along the > > handling path, an independent trust assessment service, and a mailing > > list operator. > DKIM should make no claims about identities. DKIM only relates signed portions of a message with that of a domain that publishes the public key. Would it be right to suggest this domain _is_ an identity? Take your time. There is no rush is there? -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
