> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Alessandro Vesely > Sent: Sunday, February 05, 2012 4:40 AM > To: [email protected] > Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 > > On 05/Feb/12 06:39, Murray S. Kucherawy wrote: > >> From: ietf.org On Behalf Of Alessandro Vesely > > > >>> @@ -311,19 +324,19 @@ > >>> > >>> 10. Published abuse mailbox addresses SHOULD NOT reject > messages not > >>> in the ARF format, as generation of ARF messages can > >>> - occasionally be unavailable or not applicable. > >> > >> Paragraph 10, for receivers, should terminate here. > > > > Do you think the rest of what's there now is incorrect? > > It is not incorrect, it is in the wrong paragraph. Indeed, paragraph > 11 starts with "This is" as a want to be a continuation of #10.
So you're suggesting that the remainder of 10 be merged into 11? That seems to make sense. > >> The rest of paragraph 10 and paragraph 11 (for senders) are > confusing > >> and need additional rewording, IMHO. > > > > Please provide substitute text. > > Experience suggests use of ARF is advisable in most contexts. > Automated recipient systems can handle abuse reports sent in ARF > format at least as well as any other format such as plain text, > with or without a copy of the message attached. That holds even for > systems that didn't ask for ARF format reports, provided that > reports are generated with use by recipients not using automated > ARF parsing in mind. Anyone sending unsolicited reports in ARF > format can legitimately presume that recipients will only be able > to access the human readable (first, text/plain) part of it, and > MAY include all information needed also in this part. Further, they > MAY ensure that the report is readable when viewed as plain text, > to give low-end ticketing systems as much assistance as possible. Thanks, that works (with the warning about what might happen if you don't comply included from the previous version). > BTW, publishing a _report address /is/ opt-in, isn't it? That's a "reporting-discovery" thing, which I think we've essentially dropped now. > >> Should we say that the 3rd mime part of non-actionable reports should > >> be "text/rfc822-headers"? > > > > Why? > > To be more lightweight. I think we need to discuss it further if we want to use the word SHOULD. As it is, either message/rfc822 and text/rfc822-headers is acceptable and the report generator can choose to use either. I don't think we need to say anything normative about that. -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
