> "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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf