*** 537,549 ****
for signing its messages to a non-related domain in such a way
that it does not require active participation by the non-related
domain. That is, the published information MUST have a way to
! specify the domains that are allowed to sign on its behalf.
6. Practices and Expectations MUST be presented as an information
service from the sender to be consumed as an added factor to the
receiver's local policy. In particular a Practice or
! Expectation MUST NOT specify any particular disposition stance
! that the receiver should follow.
7. If the Discovery process would be shortened by publication of a
"null" practice, the protocol SHOULD provide a mechanism to
--- 542,556 ----
for signing its messages to a non-related domain in such a way
that it does not require active participation by the non-related
domain. That is, the published information MUST have a way to
! specify the domains that are allowed to sign on its behalf.
! Signatures by such delagatees SHOULD be treated like First Party
! DKIM signatures.
6. Practices and Expectations MUST be presented as an information
service from the sender to be consumed as an added factor to the
receiver's local policy. In particular a Practice or
! Expectation MUST NOT require any particular disposition stance
! that the receiver MUST follow.
7. If the Discovery process would be shortened by publication of a
"null" practice, the protocol SHOULD provide a mechanism to
***************
If we are going to have a list of designate third parties, they should be
treated like first party (that's the point of the list). I'd make it a MUST,
except that would be specifying receiver policy.
Additionally, while I agree that receiver policy should not be required by the
protocol, I think that not specifying a desired receiver policy goes to far.
I'd suggest that we MUST NOT require instead of MUST NOT specify. That
achieves the goal of not having receiver policy cause protocol failures, but
allows more freedom in design to communicate sender expectations.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html