I'd recommend that both the final text of 2011-06 and the Spam FAQs
reference the new IETF proposed standard below.

On Mon 25/Jun/2012 16:15:26 +0200 Denis Walker wrote:
>
> From the proceedings we understood the requirement is to have a single
> location in the RIPE Database to store abuse contact details for any
> Internet resource and for this to be applied hierarchically to minimise
> management effort by the users and avoid unnecessary data duplication in
> the database.
>
> The reasoning behind the selection of a ROLE object for the task is
> partly based on our interaction with RIPE NCC member organisations. We
> understand that abuse handling in the real world is a role within an
> organisation. It therefore makes sense to map it directly to the ROLE
> object within the database.
>
> [...]
>
> The Abuse Finder tool available through the ripe.net website is a first
> iteration. We found it very difficult to define a proper scope for
> heuristics to identify the correct abuse contacts for any given resource
> with the current abuse contact documentation methods. A number of users
> have reported issues with this tool providing the wrong contacts. We
> held back from modifying the logic pending the outcome of the 2011-06
> proposal. If the community agrees on a new method of storing abuse
> contacts the RIPE NCC will re-write the Abuse Finder tool to use the new
> contact details. As we have recently re-implemented the RIPE Database
> query service from scratch, we can also integrate the Abuse Finder
> directly into the query logic. It will then also be available through a
> web interface and by the RESTful API.

I paste below the announce of RFC 6650.  It envisions how to transmit
solicited and unsolicited abuse reports.  In particular, it mentions
the use case of the Abuse Finder tool:

   Deciding where to send an unsolicited report will typically rely on
   heuristics.  Abuse addresses in WHOIS [RFC3912] records of the IP
   address relaying the subject message and/or of the domain name found
   in the results of a PTR ("reverse lookup") query on that address are
   likely reasonable candidates, as is the abuse@domain role address
   (see [RFC2142]) of related domains.

-------- Original Message --------
From: rfc-editor@rfc-...
Date: Mon, 25 Jun 2012 10:31:45 -0700 (PDT)
To: ietf-announce@ietf..., rfc-dist@rfc-...
Cc: marf@ietf..., rfc-editor@rfc-...
Subject: RFC 6650 on Creation and Use of Email Feedback Reports: An
Applicability Statement for the Abuse Reporting Format (ARF)
A new Request for Comments is now available in online RFC libraries.

        
        RFC 6650

        Title:      Creation and Use of Email
                    Feedback Reports: An Applicability Statement for
                    the Abuse Reporting Format (ARF)
        Author:     J. Falk, M. Kucherawy, Ed.
        Status:     Standards Track
        Stream:     IETF
        Date:       June 2012
        Mailbox:    none,
                    superuser@gmai...
        Pages:      15
        Characters: 35273
        Updates:    RFC5965

        I-D Tag:    draft-ietf-marf-as-16.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6650.txt

RFC 5965 defines an extensible, machine-readable format intended for
mail operators to report feedback about received email to other
parties.  This applicability statement describes common methods for
utilizing this format for reporting both abuse and authentication
failure events.  Mailbox Providers of any size, mail-sending
entities, and end users can use these methods as a basis to create
procedures that best suit them.  Some related optional mechanisms are
also discussed.  [STANDARDS-TRACK]

This document is a product of the Messaging Abuse Reporting Format Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.