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
