On Tuesday, January 31, 2012 04:23:33 PM Barry Leiba wrote:
> I am re-posting this without the extra recipients; please reply to
> THIS message, and NOT to that other one. We can discuss later who,
> exactly, should get the truncheon treatment here.......
> ---
>
> Here begins a last call for the MARF working group on the subject
> document, detailed below. Please make any comments you have on this
> version no later than 10 Feb 2012. That's a week and a half, which
> should be enough for this active and vocal group, wot? Please do not
> wait until the last minute, and especially do not wait until the
> document goes to the IESG. You will be beaten with a rubber
> truncheon.
It looks good to me. Just a couple of comments:
3. The Mailbox Provider SHOULD send reports to relevant parties who
have requested to receive such reports. The reports MUST be
formatted per [RFC5965], and transmitted as an email message
([RFC5322]), typically using SMTP ([RFC5321]). The process
whereby such parties may request the reports is discussed in
Section 3.5 of [RFC6449].
Although I understad the MUST here in context, it could be misread out of
context by people trying to insist on ARF. Could we have some kind of "To
implement the recommendations of this draft, the reports MUST ..." or similar?
12. Although [RFC6449] suggests that replying to feedback is not
useful, in the case of receipt of ARF reports where no feedback
arrangement has been established, a reply might be desirable to
indicate that the complaint will result in action, heading off
more severe filtering from the report generator. Thus, a report
generator sending unsolicited reports SHOULD ensure that a reply
to such a report can be received. Where an unsolicited report
results in the establishment of contact with a responsible and
responsive party, this can be saved for future complaint
handling and possible establishment of a formal (solicited)
feedback arrangement. See Section 3.5 of [RFC6449] for a
discussion of establishment of feedback arrangements.
The SHOULD seems strong here. While I agree it's a nice idea, the odds of
this actually happening are vanishingly small in my opinion. Something
without a RFC 2119 keyword would be better here.
Scott K
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
