[ietf-dkim] ADSP Informative Note on parent domain signing

[Jim Fenton]

Dave CROCKER wrote:
>
>
> Jim Fenton wrote:
>> Yes, the i= value _is_ ignored when determining ADSP compliance.  The
>> text that refers to the i= value is in RFC 4871, not the ADSP spec, and
>> the point of the note is to point out that the comments about the use of
>> i= there don't apply to ADSP because ADSP doesn't use i=.
>
>
> I am getting increasingly confused about this topic.
>
> The Update substantially alters what RFC4871 says or implies about
> i=.  It could well be that when the -bis effort does a detailed review
> of RFC4871+Update it finds further clarification and removals to make
> about i=.

Chairs, correct me if I'm wrong, but I don't think we have a normative
dependence between the ADSP specification and the 4871 Update.  The ADSP
specification doesn't use any of the terminology used in the Update. 
Furthermore, the Update makes no changes to section 3.8 of 4871 which
the Informative Note is intending to address.
>
> Why, then, should ADSP make any comment about i= at all, given that
> ADSP no longer uses i=?
>
> Having tidbits of clarification language can be helpful, but providing
> them when there isn't any experience to suggest their need and
> especially when they refer to something that is not cited anywhere
> else in a specification is downright peculiar.
>
> Given how vigorously you seem to feel that it /should/ be included, I
> seem to keep missing the compelling argument that justifies it.

The Informative Note I'd like to include, of course, changes nothing.  I
just see the potential for people to read RFC 4871, and where it talks
about possible uses for i=, and then read ADSP which is otherwise
completely silent on i=, and not make the connection that ADSP is only
looking at d= and therefore the parent domain signing "feature" in 4871
doesn't satisfy the Author Domain Signature requirements of ADSP.

Yes, the ADSP specification is complete without this note (it's
informative, after all).  But the compelling argument that justifies it
is that it clarifies things in a way that may improve interoperability. 
We should be trying to write specifications that promote
interoperability, not just ones that are technically complete.

-Jim