On Tuesday, May 05, 2015 02:24:19 PM Hector Santos wrote: > On 5/5/2015 2:01 PM, Murray S. Kucherawy wrote: > > On Tue, May 5, 2015 at 10:33 AM, Scott Kitterman <[email protected] > > > > <mailto:[email protected]>> wrote: > > Wrapping a 'somebody else's problem field' around the registration > > piece of this doesn't make it any more feasible. > > > > Is it sufficient to say something like this?: > > > > "A participating operator needs to solve the registration problem. > > "Participating Publishers ...." What has to be known is that > Receivers are willing to participate by doing a policy check with the > design presumption there will be records. > > This is normal migration, adoption considerations. > > > Different operators will have different capabilities, requirements, > > and limitations here. A very simple approach would be <List-Id magic > > here>; however, this has the following drawbacks: <List-Id anti-magic > > here>. Non-trivial solutions may or may not appear in later documents." > > Of course, it depends on the details of the magic. But yes, its a > different problem. > > > This illustrates the problem and the importance of solving it in some > > detail which would give someone "skilled in the art" enough context to > > come up with something in his or her particular environment, while not > > constraining DMARC to something that is not universally useful. > > You don't even have to say "universally useful." All that does is > keeps possible implementators away. It can be very useful to some > and to them, its universal.
It depends on the type of mechanism we're discussing registration for. If it's something receivers can do on their own with no cooperation from originators or mediators, then I agree. A scheme that doesn't require cooperation with other actors in the architecture can be 'good enough' even if it's only useful to a segment of the user based. OTOH, if there is a scheme that requires multiple actors in the architecture to cooperate, then (as I described in my utility analysis), it has to be pretty universally usable or it won't get sufficient deployment to be operationally useful. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
