On 14/Dec/11 20:56, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely >> >> 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.
The last two paragraphs of Section 3.1 are not related to any specific field. In addition, since you agreed to move the sentences that describe the failure-to-report relationship "to just above section 3.1" --thereby decoupling them from the A-R field-- Section 3 will host one more statement which is about the overall semantics rather than any specific field. That title is at least misleading. > 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. Yes it is. I meant the second sentence in the first paragraph of Section 3.1: A new feedback type of "auth-failure" is defined as an extension to Section 8.2 of [ARF]. See Section 3.3 for details. > I fail to see how either of these are wrong at all, let alone seriously. That quoted paragraph says that the details of "auth-failure" consist of the possible values of Auth-Failure. Isn't it wrong? BTW, Section 8.2 of [ARF] is about the *Interpretation* of the report format. You probably mean Section 7.3 (but shouldn't such reference belong to the IANA Considerations section?) After those two lines, the section continues with several fields specifications. Not all fields, just some. A reader may wander why Delivery-Result is listed here while Auth-Failure itself is not. A title of "New ARF Feedback Type" doesn't help. BTW, the specification of Delivery-Result is in Section 3.2.2, not 3.2.1. > 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. My purpose is not to delay the publication. I'm replying because I think you misunderstood what I said. If I had been nitting, I would have contested the entanglement of defining a field in Section 3.2.1 postponing the discussion of its content to Section 3.3, while it would have made for easier reading (and writing) to have that field defined and discussed in a single place. >> 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). For that to hold, you may want to add l=53 to the DKIM-Signature, or replace the following field DKIM-Canonicalized-Body: VGhpcyBpcyBhIG1lc3NhZ2UgYm9ke SB0aGF0IGdvdCBtb2RpZmllZCBpbiB0cmFuc2l0LgoKQXQgdGhlIH NhbWUgdGltZSB0aGF0IHRoZSBib2R5aGFzaCBmYWlscyB0byB2ZXJ pZnksIHRoZQptZXNzYWdlIGNvbnRlbnQgaXMgY2xlYXJseSBhYnVz aXZlIG9mIHBoaXNoeSwgYXMgdGhlClN1YmplY3QgYWxyZWFkeSBoa W50cy4gIEluZGVlZCwgdGhpcyBib2R5IGFsc28gY29udGFpbnMKdG hlIGZvbGxvd2luZyB0ZXh0CgogICBQbGVhc2UgZW50ZXIgeW91ciB mdWxsIGJhbmsgY3JlZGVudGlhbHMgYXQKICAgaHR0cDovL3d3dy5z ZW5kZXIuZXhhbXBsZS8KCldlIGFyZSBpbXBseWluZyB0aGF0LCBhb HRob3VnaCBtdWx0aXBsZSBmYWlsdXJlcwpyZXF1aXJlIG11bHRpcG xlIHJlcG9ydHMsIGEgc2luZ2xlIGZhaWx1cmUgY2FuIGJlCnJlcG9 ydGVkIGFsb25nIHdpdGggcGhpc2hpbmcgaW4gYSBzaW5nbGUgcmVw b3J0Lgo= _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
