[feedback-report] Extensible Feedback Type Proposal

[Steve Atkins]

On Thu, Sep 29, 2005 at 11:26:14AM -0700, Justin Rietz wrote:
> I would like to "officially" propose that ARF allow for custom feedback
> types in addition to the standard Feedback-
> Type field as an X-Feedback-Type.
>  
> Reasons / Comments:
> 1.  Report senders may want to offer their users the ability to select from
> complaint types not already established in ARF
> 2.  Report recipients may request additional feedback data from report
> senders
> 3.  Standard feedback types would be unchanged, thus retaining all the
> original elements of the current version of ARF
> 4.  Report senders could publish definitions of their X-Feedback-Type fields
> for report recipients who wish to use the custom feedback data
> 5.  Report recipients could choose to accept all, some, or none of any
> X-Feedback-Type fields in an ARF report
> 6.  Custom feedback types that are used frequently could be "promoted" to a
> standard type through a defined process
>  
> Given the current feedback types, an email recipient cannot register
> multiple complaints/requests i.e. "opt-out" and "abuse."  While it could
> reasonably be assumed that someone who submits an "abuse" complaint also
> wants also to opt-out of the email, this may not be always the case.  There
> is real-world example of an online retailer (who shall go unamed) who sent
> too many purchase confirmations and irritated customers; however, those
> customers surely still wanted to receive original purchase confirmation.

This can be fairly easily remedied by extending the standard fields as
needed. That also means that recipients will be able to support it.

> To the comments that custom feedback types defy the idea of a standard, I
> would argue that a standard should define the format of the data, estalish
> boundaries for what is and isn't allowed, and contain common elements (i.e.
> standard Feedback-Type fields ) that everyone agrees to use.  However, I
> believe the standard should also retain enough flexibility for users to be
> able do some customization but still conform to the standard. Given the
> rapidly changing environment of phishing and spamming, I believe ARF needs
> to allow for this type of flexibility in order to remain up-to-date with
> what is occuring in the real world.

Ignoring any field on a report changes the semantics of that report.
Therefore, recipients only have two choices when they see a report with
non-standard fields.

  1) Discard unrecognised types, parsing the remainder of the report.
     This may change the meaning of the report drastically, meaning
     that the report will be mishandled, because the recipient sees
     a report that may be totally different to the report that the
     sender sent.

  2) Discard or reject the report entirely.

If you see other options I'd appreciate it if you could explain what
action my software should take when it sees non-standard headers in a
report. Simply escalating any unrecognised field to a human is not
viable.

Cheers,
  Steve