I understand Barry - and I did re-respond specifying what I agreed with - I'm just getting used to the process
> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Barry Leiba > Sent: Wednesday, July 06, 2011 3:16 PM > To: Hilda Fontana > Cc: Message Abuse Report Format working group > Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim- > reporting draft > > 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
