Hi Andrew,
I think it can be generalized functional description without
specifics. Designs based on REPUTE and its users of such products,
will need some information. That may come (hopefully) from the REPUTE
product designer. I am suggesting to remind such future REPUTE product
designers of such considerations. I think it will help the technical
marketing of REPUTE products and REPUTE service providers. If a
choice has to be made between an SMTP layer filtering protocols and
some new REPUTE payload filter, then what choices are those to be
considered.
Keep in mind I would be a classic target audience new reader and user
of this document. I did not participate in the WG. We should not
expect the audience of the document to be required to visit archives
of the Repute WG to find or extract these very real and practical
integration considerations. The document should have these general
considerations summarized.
Thanks
On 8/30/2013 3:20 PM, Andrew Sullivan wrote:
On Fri, Aug 30, 2013 at 02:37:13PM -0400, Hector Santos wrote:
For example, DKIM-REPUTE product designers would need to consider
SPF reputons product models. Simple text as follows can resolve the
integration consideration with little SPF fanfare the draft
obviously tried to avoid:
Why should the framework document contain details of how various
particular reputation services interact? If you want a discussion of
reputation-service-interaction mechanisms in the draft, that's one
thing. If you want to talk about how SPF and DKIM interact, then I
think this is probably the wrong draft.
Best,
A
--
HLS