Subject: [ietf-dkim] requirements clarifications: Listed third parties treated like first party and must not require/specify

From: Scott Kitterman <[email-masked]>
Date: Wed, 9 Aug 2006 13:14:48 -0400

*** 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

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 10 Aug 2006 00:31:01 +0200

Scott Kitterman wrote:

> 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.

In other words it cannot say "receiver SHOULD reject", but it
could say "if receivers decide to reject they SHOULD [...]",
where that helps.

I still miss a similar detail lost on the way to 4408 2.5.4 <g>