On Thursday, April 16, 2015 05:20:01 PM Hector Santos wrote: > On 4/16/2015 4:58 PM, Murray S. Kucherawy wrote: > > On Thu, Apr 16, 2015 at 11:34 AM, John R Levine <jo...@taugh.com> wrote: > >> At least, we need to look at what non-technical costs they push onto > >> other > >> parties. > >> > >> Some changes have insignificant non-techincal costs and are not > >> controversial, e.g., adding a List-ID header for the benefit of > >> recipients > >> who know how to use it. Changes that seem similar may have quite > >> different > >> costs, e.g., adding a List-ID and removing subject tags, forcing > >> recipients > >> to change the way they sort and organize their incoming messages. > > > > Rolf kind of said what I'm thinking here: I agree that we need to look at > > the costs. But are we willing, or not willing, to accept costs that are > > not zero? > > > > For example, asserting that all parties should have to take on zero > > non-technical cost here seems like it might leave us dead in the water > > before we even start. I don't have a good non-zero suggestion though, > > because it's hard (or maybe even impossible) to be specific. > > Murray, we don't need to go that far. > > We are talking about a IETF protocol engine that has two basic flows: > > ADID == SDID conditions > ADID != SDID conditions > > We just need to come up with the models for this and let the market > decide. > > The problem is that ATPS was short-changed as an extension to ADSP > which was being abandoned. > > The APIs were ready for this. Since DMARC replaces ADSP, you need to > update RFC6541 to have it piggy back off DMARC. Since DMARC is now > being adopted to replace ADSP in the industry, you now need to make it > market ready for the 3rd party check allowing them to learn how to > scale it too. > > If you want to do this IN-BAND stuff for those systems that can not do > DMARC+ATPS, that would be great and it would cover a wider market, > including the biggest one who can afford the additional changes to all > this. They can also afford to do both ATPS and IN-BAND as well if > they choose to so.
I don't think market share in the abstract is useful for this discussion. Per my utility analysis, the question is not percent of market (however that is defined), but breadth of market scope being sufficient to enable interoperability when it's needed. I would still appreciate solution independent discussion of how to do the utility analysis or I fear we'll continue to just argue past each other. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
