"Readers should be familiar with the material and terminology
discussed in [MAIL] and [EMAIL-ARCH]."
The references to RFC 5598 and RFC 5322 should be normative.
I agree; I missed that in my shepherd review. So sorry.
"A Verifier implementing both ADSP and ATPS SHOULD treat a message for
which the ATPS test described above passes as if it were signed by
the author domain. That is, a pass of ATPS means a pass for ADSP."
In plain English, this reads as an update of ADSP but this draft does not
update RFC 5617.
It does not. There's no reason that anyone implementing ADSP need pay
attention to this. *IF* you implement this, it might change your
behaviour with respect to ADSP, but information about that is
contained here. There's no reason for this to "update" 5617 in the
IETF sense.
The IANA Considerations section is unusual. If no action is required at
this time, the sub-sections are not needed.
I did call this out in my shepherd review (see the PROTO writeup:
https://datatracker.ietf.org/doc/draft-kucherawy-dkim-atps/history/
and click "show all" on the PROTO writeup entry; side point: it should
probably be easier to get to the PROTO writeup for a document).
I actually think it's clever to put the information here in this
manner, but, as I say in the writeup, it is unusual. I prefer that we
leave it here, and just make sure that the intelligent folks at IANA
do the intelligent thing. This can then serve as a template for the
IANA Considerations section for a possible revision that moves ATPS to
Standards Track, should that happen.
Barry, document shepherd
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf