[feedback-report] RE: abuse-feedback-report Digest, Vol 6, Issue 7

[J.D. Falk]

On 2005-09-29 13:41, Justin Rietz wrote:

> All legitimate points.  Let me try to answer them one by one and ask for
> clarification on others.
> 
> My main point is exactly as has been pointed out by others:  report
> generators and/or report receivers WILL customize ARF for their own needs.

Are you sure?  I was working on the requirements for Yahoo!'s upcoming 
complaint feedback loop system at the same time that we were discussing 
what turned into ARF, and I don't have anything else to add to it. 
Neither did any of the other current or potential high-volume Report 
Generators who participated.

We did have a long conversation about this, though, and concluded that 
with "other" and a standard process for adding more types in the future, 
there was no need to get more specific now.

Do you have any examples of individual types that should be added?

> 1.  To Steve's point that ignoring a field would drastically alter the
> meaning of the report, I think I am missing something.  If I parse an ARF
> report, and tell my parsing application:  "ignore all x-feedback-type
> fields" or "ignore all x-feedback-type fields that don't contain complaint
> type x,y,z" everything else would still be parsed normally, saved to a
> database, etc.

Why would a Report Generator choose to generate reports that the Report 
Recipient will most likely ignore?

> To J.D.'s point about dealing with multiple feedback types in my
> aforementioned scenario, one solution off the top of my head is that there
> could be a x-feedback-type that is "don't unsubscribe."  A user would select
> "abuse"  and also select "don't unsubscribe" (all dependent on the report
> generators GUI, etc.).

How do you explain this option (or anything similar) to an end user, in 
words small enough to fit inside a mouseover/tooltip?

> 3.  Yes, there currently is a way to add new feedback-type fields.  And I'm
> not suggesting ARF should nix standard types.  But if report generators and
> receivers have to go through this approval process anytime they want to
> standardize a new type, they will just do their own one-off customization,
> with all the issues I laid out in #2.

...which is exactly what they SHOULD do, to test out any new ideas 
before going through the process for adding new standard types.

Remember, standards aren't (or shouldn't be) where fresh new ideas are 
proposed for the first time.  They're to turn existing small-scale 
practices into standard behavior, and sometimes (as in this case) 
improve upon those practices along the way.

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team