Hilda, when you put a "+1" at the end of a message like this, I can't tell what you're agreeing with. Murray didn't make a single statement in his message -- in the end, he gave alternatives and asked what people think.
Can you be specific about what you agree with? Barry On Tue, Jul 5, 2011 at 4:25 PM, Hilda Fontana <[email protected]> wrote: >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Murray S. Kucherawy >> Sent: Tuesday, July 05, 2011 11:48 AM >> To: [email protected] >> Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim- >> reporting draft >> >> > -----Original Message----- >> > From: [email protected] [mailto:[email protected]] On Behalf >> > Of Alessandro Vesely >> > Sent: Tuesday, July 05, 2011 11:00 AM >> > To: Hilda Fontana >> > Cc: [email protected] >> > Subject: Re: [marf] Cohesion of authfailure-report, was Split of >> > dkim-reporting draft >> > >> > Roughly, a section more or less like >> > >> > X.Y.Z. Definition and Registration of Method-Specific Extensions >> > >> > The IANA maintains a registry of Email Authentication Methods >> > along with their possible results. A "method-specific extension" >> > extends an authentication method by providing for the possibility >> > to report its result using the ARF format specified in this >> > document. Any such extension must specify: >> > >> > * which method(s) it addresses; >> > >> > * which result(s) of the addressed method(s) deserve being >> > reported; >> > >> > * a list of one or more keywords to be used in the Auth-Failure >> > field when reporting such results; and >> > >> > * the location and the syntax of the report parameters whose >> > semantic content is described in Section U.V.W. >> > >> > In addition, a method-specific extension may define further ARF >> > header fields. In case it does so, it shall also define the >> > corresponding updates to ARF header field names in its IANA >> > Considerations section. >> > >> > Section U.V.W would discuss r, rf, and ri, and possibly mention ro and >> > rs too. Not how they are syntactically encoded, just what they mean. >> > >> > Does the above make sense? >> >> We're adding DKIM and SPF reporting to ARF in this way because they both >> pre-date ARF in the official sense. I think the current approach makes > sense; >> this document extends ARF and the spf-reporting and dkim-reporting >> documents extend SPF and DKIM respectively, and they're all compatible >> with each other. >> >> I think if the working group feels this is a good idea to write down for > future >> extensions, we can produce another Informational document that explains >> the things one should consider in terms of creating a new email >> authentication method, including registering and defining reporting >> extensions both in terms of ARF and RFC5451. Or, as a lesser approach, > that >> could become an appendix of this one. >> >> > Indeed, I think authfailure-report can be written without mentioning >> > neither "dkim" nor "spf", except for possible examples. I guess that >> > would enhance comprehensibility. However, the WG should decide >> > whether to go this way _before_ delving into any finer tuning, if it's >> > not too late already. >> >> Ignoring redaction for the moment, what we have now is: >> >> - authfailure-report modifies ARF >> - dkim-reporting modifies DKIM and ADSP >> - spf-reporting modifies SPF >> >> That seems nice and clean. Your proposal changes it to: >> >> - authfailure-report modifies ARF >> - dkim-reporting modifies DKIM and ADSP, and also modifies authfailure- >> report >> - spf-reporting modifies SPF, and also modifies authfailure-report >> >> At a glance the first method seems cleaner to me. On the other hand, the >> latter is a more clear demonstration of how future email authentication >> methods will need to create reporting hooks. >> >> What do others think? And let's try to make this the last revisit of the >> arrangement of this work so that we can make some progress. >> >> Thanks, >> >> -MSK > +1 > > _______________________________________________ > marf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/marf > _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
