John R. Levine wrote: >>> Except that the UAID might or might not be an e-mail address. The one >>> on this messgage isn't. >>> >> So, for clarity, can you (or someone) call out what you think is >> the impact, if any, for ADSP, caused by this proposed change to >> 4871. >> > > Nothing. ADSP's attempt to force i= to be an identifier that is an e-mail > address was wrong before, and the errata doesn't change that. > > I've put a note pointing that out in the proposed next draft, with a > kludgy workaround being a second signature with no i= field. > > If it were up to me, I'd remove all the references to i= from ADSP, but > there seem to be people who believe that it will be useful. > Nevertheless, what's in the specification represents working group rough consensus, in connection with issues 1399 and 1519. There have been opportunities in WG Last Call and IETF Last Call to reconsider that decision.
In response to Stephen's question, there are several things that I see as problems relative to ADSP: The position of ADSP in the verification process hasn't been defined, which is reasonable since ADSP is an add-on. Therefore, it must be part of the Assessor rather than part of the verification process itself. This document makes the passing of the i= value (referred to as UAID) optional, which means that some verifiers will not provide a value required by the ADSP specification. Section 5, paragraph 4, "responsible Identifiers that are individual, opaque values" can be interpreted as requiring that an opaque value be chosen by the signer, which would prohibit Author Signatures as defined in ADSP. Section 5, last paragraph, argues that interpreting any structured semantics for either of the identifiers is "heuristic". To the extent that a signing domain publishes an ADSP "All" or "Discardable" record, they are making an assertion of the semantics of the i= identifier so it is not a heuristic. I have many other comments about this draft, which I will save for another message. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
