Jim Fenton wrote:
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.
So, Jim, I commend your effort at retrieval specific references.
Certainly ADSP needs to say what string it is using.
Unfortunately your presenting citations raises the question of whether they
resolve the current question. My own conclusion is that they do not, for
several reasons:
1. 1399 received no substantive discussion and was then declared redundant
with 1519. So citing it winds up confusing the current discussion.
2. 1519 had nothing to do with the choice between d= vs. i=. It asked a
very different question about i=.
3. One could argue that all discussion "assumed" i=, but that's a very
different claim that one that says we considered d= vs. i= and chose i=.
4. If there is consensus on the proposed Errata, it well might change the
basis for applying d= vs. i= to ADSP. In fact this question, and the need to
resolve it, was the reason for pressing so hard to get the Errata text onto the
wg table. (Yeah. A lot earlier would have been a lot better, but the degree
and impact of the confusion didn't become so compellingly clear until recently.)
So I strongly suggest that folk should not rely on the relatively legalistic
claim that the choice of i= is a fait accompli. It will invite more
contentious
and unproductive debate, of the type we might recall from earlier wg history.
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.
That matches my architectural, ummmm, assessment too.
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.
Since the base specification makes the existence of the tag optional, making
its
delivery optional does not represent a change to its basic nature. It might be
there; it might not.
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.
As an incremental specification, ADSP essentially changes the definition of the
delivered string from "opaque" to "author email address". I do not see that
sort of incremental specification as problematic in any way; in fact I see it
as
a reasonable approach to adding capability.
The creator of the string is publishing additional information and the consumer
of the string can choose to use that additional information. In terms of
protocol design, that is a nicely collaborative enhancement, with no penalty to
anyone choosing not to participate. The base specification still works.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html