> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Alessandro Vesely > Sent: Wednesday, December 14, 2011 11:31 AM > To: [email protected] > Subject: Re: [marf] comments on draft-ietf-marf-authfailure-report-06 > > The proposed layout change is minimal, in spite of my lengthy > description of it. As it retains the role of A-R fields, the result is > more semantically similar to -06 than accomplishing John's move > otherwise --unless you have a better solution, of course. However, > Section 3.1's title and its reference to Section 3.3 /are/ seriously > wrong.
The creation of this new ARF type comprises a bunch of extension fields and their definitions, and little else. Therefore, "Extension ARF Fields for Authentication Failure Reporting" seems perfectly good. Similarly, the document recognizes five specific types of authentication failures about which reports can be generated, and thus the title "Authentication Failure Types" seems a perfectly good title for a section in which to enumerate them. I fail to see how either of these are wrong at all, let alone seriously. My solution is to use John's suggestion and make no other changes, absent any consensus that pushes for what you're suggesting. Otherwise, we can die nitting on this minor stuff and never get it out the door. > ARF mentions "a suspect URI that was found in the message that caused > the report to be generated", not a synthesized URI, e.g. obtained by > prepending "http://www."; to a random domain-like string :-/ The third part of the report only contains the header of the message causing the report to be generated, which RFC5965 allows. Presumably, then, the reported URI came from someplace in the body of the message, which isn't shown here (and doesn't need to be, by ARF's definitions). -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
