Subject: Re: [feedback-report] RE: abuse-feedback-report Digest, Vol 6, Issue 7
From: "J.D. Falk" <[email-masked]>
To: [email-masked]
Date: Thu, 29 Sep 2005 14:26:21 -0700
List-Id: Public forum for discussion on the feedback-report draft <abuse-feedback-report.mipassoc.org>

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

From: "Justin Rietz" <[email-masked]>
To: <[email-masked]>
Date: Thu, 29 Sep 2005 13:41:24 -0700
Subject: [feedback-report] RE: abuse-feedback-report Digest, Vol 6, Issue 7

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, September 29, 2005 12:00 PM
To: [email-masked]
Subject: abuse-feedback-report Digest, Vol 6, Issue 7

Send abuse-feedback-report mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	http://mipassoc.org/mailman/listinfo/abuse-feedback-report
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of abuse-feedback-report digest..."

Today's Topics:

   1. Extensible Feedback Type Proposal (Justin Rietz)
   2. Re: Extensible Feedback Type Proposal (Steve Atkins)
   3. Re: Extensible Feedback Type Proposal (J.D. Falk)

----------------------------------------------------------------------

Message: 1
Date: Thu, 29 Sep 2005 11:26:14 -0700
From: "Justin Rietz" <[email-masked]>
Subject: [feedback-report] Extensible Feedback Type Proposal
To: <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

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.
 
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.
 
Justin Rietz
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mipassoc.org/pipermail/abuse-feedback-report/attachments/20050929/c18
e8eab/attachment-0001.html

------------------------------

Message: 2
Date: Thu, 29 Sep 2005 11:39:32 -0700
From: Steve Atkins <[email-masked]>
Subject: Re: [feedback-report] Extensible Feedback Type Proposal
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

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

------------------------------

Message: 3
Date: Thu, 29 Sep 2005 11:53:10 -0700
From: "J.D. Falk" <[email-masked]>
Subject: Re: [feedback-report] Extensible Feedback Type Proposal
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 2005-09-29 11:26, 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

So if the report sender uses a feedback type that the report recipient
doesn't know about yet...what should happen?

> 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.

If I were a report recipient, how would I know that a report with multiple
feedback types actually means "don't send so many confirmations, but keep
sending me other stuff?"

> 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.

The spec doesn't say "these are the only feedback types that there shall
ever be no matter what" -- it includes a method for adding new types, which
is compatible with existing standard methods.

And, as others have said, if a report generator & report recipient want to
set up a new type just between themselves, there's nothing stopping them
from doing so.  It's just text, after all.

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

------------------------------

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.
If ARF can encapsulate these customizations, it becomes a much more robust
standard.  It defeats the point of a standard if many users are going to
customize it anyway (more in #2  below).

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.  I could also have additional logic that says "ignore all new
x-feedback-type fields except from generators A, B, and C; else send an
email alert."

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.).

2.  Yes, report generators can (and will) extend the standard on their own -
this is EXACTLY why ARF should support it.  Instead of each report generator
having to communicate with each of its report receivers in a proprietary
manner, if a standard extensible x-feedback-type is allowed, and definitions
for these custom types are published publicly in a standard format, the
whole process becomes much easier for both the generator and receivers.
Generators don't have to communicate directly with each of their receivers,
and receivers don't have to support multiple custom fields in different
formats with different update mechanisms for each report generator.

Yes, assuming a receiver decides to accept new custom complaint types from
some report generator, some human intervention would be need. But this will
occur with ANY customization, whether it is built into ARF or not.

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.

Date: Thu, 29 Sep 2005 11:53:10 -0700
From: "J.D. Falk" <[email-masked]>
Organization: Yahoo!
To: [email-masked]
Subject: Re: [feedback-report] Extensible Feedback Type Proposal

On 2005-09-29 11:26, 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

So if the report sender uses a feedback type that the report recipient 
doesn't know about yet...what should happen?

> 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.

If I were a report recipient, how would I know that a report with 
multiple feedback types actually means "don't send so many 
confirmations, but keep sending me other stuff?"

> 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.

The spec doesn't say "these are the only feedback types that there shall 
ever be no matter what" -- it includes a method for adding new types, 
which is compatible with existing standard methods.

And, as others have said, if a report generator & report recipient want 
to set up a new type just between themselves, there's nothing stopping 
them from doing so.  It's just text, after all.

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

Date: Thu, 29 Sep 2005 11:39:32 -0700
From: Steve Atkins <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] Extensible Feedback Type Proposal

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

From: "Justin Rietz" <[email-masked]>
To: <[email-masked]>
Date: Thu, 29 Sep 2005 11:26:14 -0700
Subject: [feedback-report] Extensible Feedback Type Proposal

This is a multi-part message in MIME format.

------=_NextPart_000_003C_01C5C4E8.9A4F6B40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

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.
 
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.
 
Justin Rietz

------=_NextPart_000_003C_01C5C4E8.9A4F6B40
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2722" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D310095917-29092005><FONT face=3DArial size=3D2>I =
would like to=20
"officially" propose that&nbsp;ARF allow for&nbsp;custom feedback types =
in=20
addition to&nbsp;the standard Feedback-<BR>Type field as=20
an&nbsp;X-Feedback-Type.</FONT></SPAN></DIV>
<DIV><SPAN class=3D310095917-29092005><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D310095917-29092005><FONT face=3DArial =
size=3D2>Reasons /=20
Comments:</FONT></SPAN></DIV>
<DIV><SPAN class=3D310095917-29092005><FONT face=3DArial =
size=3D2>1.&nbsp; Report=20
senders may want to offer their users the ability to select from =
complaint types=20
not already established in ARF</FONT></SPAN></DIV>
<DIV><SPAN class=3D310095917-29092005><FONT face=3DArial =
size=3D2>2.&nbsp; Report=20
recipients may request additional feedback data from report=20
senders</FONT></SPAN></DIV>
<DIV><SPAN class=3D310095917-29092005><FONT face=3DArial =
size=3D2>3.&nbsp; Standard=20
feedback types would be unchanged, thus retaining all the original =
elements of=20
the current version of ARF</FONT></SPAN></DIV>
<DIV><SPAN class=3D310095917-29092005><FONT face=3DArial =
size=3D2>4.&nbsp; Report=20
senders could publish definitions of their&nbsp;X-Feedback-Type =
fields&nbsp;for=20
report recipients who wish to use the custom feedback =
data</FONT></SPAN></DIV>
<DIV><SPAN class=3D310095917-29092005></SPAN><SPAN =
class=3D310095917-29092005><FONT=20
face=3DArial size=3D2>5.&nbsp; Report recipients could choose to accept =
all, some,=20
or none of any&nbsp;X-Feedback-Type fields in an ARF =
report</FONT></SPAN></DIV>
<DIV><SPAN class=3D310095917-29092005><FONT face=3DArial =
size=3D2>6.&nbsp; Custom=20
feedback types that are used frequently could be "promoted" to a =
standard type=20
through a defined process</FONT></SPAN></DIV>
<DIV><SPAN class=3D310095917-29092005><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D310095917-29092005><FONT face=3DArial size=3D2>Given =
the current=20
feedback types, an email recipient cannot register multiple =
complaints/requests=20
i.e. "opt-out" and "abuse."&nbsp; While it could reasonably be assumed =
that=20
someone who submits an "abuse" complaint also wants also to opt-out of =
the=20
email, this may not be always the case.&nbsp; There is =
real-world&nbsp;example=20
of an online retailer (who shall go unamed) who sent too many purchase=20
confirmations and irritated customers; however, those customers surely =
still=20
wanted to receive original purchase confirmation.</FONT></SPAN></DIV>
<DIV><SPAN class=3D310095917-29092005><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D310095917-29092005><FONT face=3DArial size=3D2>To the =
comments that=20
custom feedback types defy the idea of a standard, I would argue that a =
standard=20
should define the&nbsp;format of the data, estalish&nbsp;boundaries for =
what is=20
and isn't allowed, and contain common elements (i.e. standard =
Feedback-Type=20
fields ) that everyone agrees to use.&nbsp; However, I believe the =
standard=20
should also retain enough flexibility for users to be able do some =
customization=20
but still conform to the standard. Given the rapidly changing =
environment of=20
phishing and spamming, I believe ARF needs to allow for this type of =
flexibility=20
in order to remain up-to-date with what is occuring in the real=20
world.</FONT></SPAN></DIV>
<DIV><SPAN class=3D310095917-29092005><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D310095917-29092005><FONT face=3DArial size=3D2>Justin =

Rietz</FONT></SPAN></DIV></BODY></HTML>

------=_NextPart_000_003C_01C5C4E8.9A4F6B40--

Date: Mon, 19 Sep 2005 22:47:28 -0400
From: Yakov Shafranovich <[email-masked]>
Organization: SolidMatrix Technologies, Inc.
To: "Carl S. Gutekunst" <[email-masked]>
Subject: Re: [feedback-report] Feedback types
Cc: [email-masked]

Carl S. Gutekunst wrote:
> Steve Atkins wrote:
> 
>> Doug Otis wrote:
>>
>>> As this is relatively new, and there could be future requirements that
>>> invite modification, then finding some type of convention for extending
>>> the form seems useful.
>>>   
>>
>> The whole concept behind a standard reporting format is that it's, well,
>> standard. It's well-defined and can be reliably parsed and the semantics
>> of the report can be mechanically extracted and understood.
>>
>> If there are any elements of the report that my code does not
>> understand then I have no way of knowing whether my partial parse of
>> the incoming report is an accurate understanding of what the report is.
>>
> Is it reasonable to give the feedback type the same sort of rigid (and 
> restricted) definition as the MIME primary content types? That seems to 
> be what Steve is asking for; certainly the arguments are similar.
> 
> (Note this argues against fine-grained feedback types.)
> 

There is also a possibility of setting up a provision type registry and 
a permanent type registery, like the ones that exist for message headers.

What I am trying to determine among other things is whether a 4-6 week 
waiting period for permanent registration is sufficient.

Yakov

Date: Mon, 19 Sep 2005 12:49:15 -0700
From: "Carl S. Gutekunst" <[email-masked]>
To: Steve Atkins <[email-masked]>
Subject: Re: [feedback-report] Feedback types
Cc: [email-masked]

Steve Atkins wrote:

> Doug Otis wrote:
>
>>As this is relatively new, and there could be future requirements that
>>invite modification, then finding some type of convention for extending
>>the form seems useful.
>>    
>>
>The whole concept behind a standard reporting format is that it's, well,
>standard. It's well-defined and can be reliably parsed and the semantics
>of the report can be mechanically extracted and understood.
>
>If there are any elements of the report that my code does not
>understand then I have no way of knowing whether my partial parse of
>the incoming report is an accurate understanding of what the report is.
>
Is it reasonable to give the feedback type the same sort of rigid (and 
restricted) definition as the MIME primary content types? That seems to 
be what Steve is asking for; certainly the arguments are similar.

(Note this argues against fine-grained feedback types.)

<csg>

From: Douglas Otis <[email-masked]>
Subject: Re: [feedback-report] Feedback types
Date: Mon, 19 Sep 2005 12:24:52 -0700
To: Justin Rietz <[email-masked]>
Cc: [email-masked]

On Sep 19, 2005, at 11:36 AM, Justin Rietz wrote:

>
> This was my thought.  I would like to see reporters be able to use  
> custom
> types without breaking the ARF standard, but allow recipients or  
> the reports
> to choose whether or not they want to accept the non-standard  
> types.  Until
> there is significant use of ARF, it is difficult to say what  
> feedback types
> will be the most usefull. With the risk of making things more  
> complex, their
> could be a central repository where reporters could post  
> definitions of
> their custom feedback types.  Just a though.
>
> Is there a next step to take in order to make an official proposal  
> and get a
> "yea" or "nay"?

While the use of the "x-" convention would allow private bi-lateral  
extensions, there should a standards (IANA) registry that indicates  
names for defined fields in the specifications.  This registry may  
also indicate which version of the document first defined the field.

Perhaps the "x-" format could be "x-<organization>#<proposed name>"  
where this would serve as a place holder.  Perhaps maawg would have a  
series of proposed names, where this organization defines the use of  
these names.  Eventually, a proposed name could be accepted within  
the specification.  For computer peripherals, it was common for  
companies to be assigned their own codes to prevent extensions from  
being confused.  Company or organization name space collision should  
be a minor concern and could be assisted by simply have an informal  
name registry that logs the organization name space use.

-Doug

Date: Mon, 19 Sep 2005 12:03:20 -0700
From: Steve Atkins <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] Feedback types

On Mon, Sep 19, 2005 at 11:36:44AM -0700, Justin Rietz wrote:

> > As this is relatively new, and there could be future requirements that
> invite modification, then finding some type of convention for extending the
> form seems useful.
> 
> > -Doug 
> 
> This was my thought.  I would like to see reporters be able to use custom
> types without breaking the ARF standard, but allow recipients or the reports
> to choose whether or not they want to accept the non-standard types.  Until
> there is significant use of ARF, it is difficult to say what feedback types
> will be the most usefull. With the risk of making things more complex, their
> could be a central repository where reporters could post definitions of
> their custom feedback types.  Just a though.

The whole concept behind a standard reporting format is that it's, well,
standard. It's well-defined and can be reliably parsed and the semantics
of the report can be mechanically extracted and understood.

If there are any elements of the report that my code does not
understand then I have no way of knowing whether my partial parse of
the incoming report is an accurate understanding of what the report
is.

If a particular sender of reports and a particular receiver agree
bilaterally to an extension then that's solely between those two
parties, and there's absolutely nothing to stop them using that
extension. But that's a very different case to crafting a report
that has your own custom extensions, sending it to someone who
accepts ARF reports and expecting their code to understand what
the report means and to handle it correctly.

Cheers,
  Steve

> Is there a next step to take in order to make an official proposal and get a
> "yea" or "nay"?
> 
> -Justin
> 
> 
> -----Original Message-----
> From: Yakov Shafranovich [mailto:[email-masked]] 
> Sent: Friday, September 16, 2005 1:59 PM
> To: Justin Rietz
> Cc: [email-masked]
> Subject: Re: [feedback-report] Feedback types
> 
> Justin Rietz wrote:
> > I apologize in advance if this has been discussed previously - I am 
> > new to this list and wasn't able to find anything in the archives.
> > 
> > Regarding feedback types, the spec says that these are extensible, but 
> > that new types need to be approved. Two questions:
> > 
> > **Was there consideration given to allowing custom feedback types as 
> > long as they followed the specified format? There could still be 
> > required types that everyone would have to support. This would allow 
> > for customization based upon the scenario in which the standard is 
> > being used, and an entity receiving ARF reports could chose to accept 
> > or reject custom types.
> > 
> 
> At this time there is no provision for custom types. However, I have been
> thinking to either allow "x-*" types like other IETF standards AND/OR
> mentioning in the draft that unknown types should be ignored.
> 
> > **I am unclear on how the proposal/acceptance process works for new 
> > feedback types? If someone had a type they would like to propose now, 
> > what would they need to do?
> > 
> 
> It would follow the standard IANA procedures for where a designated expert
> is used (see RFC 2434). In practice, the IESG, IANA and its appointed expert
> would decide on the proper procedure. It would probably be something like a
> public post to mailing list and a four week review, although IANA or IESG
> might decide otherwise.
> 
> To propose a new type now, the best way is to post a message here and
> describe what you have in mind. Since the specification has not been
> submitted yet to the IETF for approval, it is a bit fluid.
> 
> Yakov
> 
> _______________________________________________
> abuse-feedback-report mailing list
> [email-masked]
> http://mipassoc.org/mailman/listinfo/abuse-feedback-report

From: "Justin Rietz" <[email-masked]>
To: <[email-masked]>
Subject: RE: [feedback-report] Feedback types
Date: Mon, 19 Sep 2005 11:36:44 -0700

> As this is relatively new, and there could be future requirements that
invite modification, then finding some type of convention for extending the
form seems useful.

> -Doug 

This was my thought.  I would like to see reporters be able to use custom
types without breaking the ARF standard, but allow recipients or the reports
to choose whether or not they want to accept the non-standard types.  Until
there is significant use of ARF, it is difficult to say what feedback types
will be the most usefull. With the risk of making things more complex, their
could be a central repository where reporters could post definitions of
their custom feedback types.  Just a though.

Is there a next step to take in order to make an official proposal and get a
"yea" or "nay"?

-Justin

-----Original Message-----
From: Yakov Shafranovich [mailto:[email-masked]] 
Sent: Friday, September 16, 2005 1:59 PM
To: Justin Rietz
Cc: [email-masked]
Subject: Re: [feedback-report] Feedback types

Justin Rietz wrote:
> I apologize in advance if this has been discussed previously - I am 
> new to this list and wasn't able to find anything in the archives.
> 
> Regarding feedback types, the spec says that these are extensible, but 
> that new types need to be approved. Two questions:
> 
> **Was there consideration given to allowing custom feedback types as 
> long as they followed the specified format? There could still be 
> required types that everyone would have to support. This would allow 
> for customization based upon the scenario in which the standard is 
> being used, and an entity receiving ARF reports could chose to accept 
> or reject custom types.
> 

At this time there is no provision for custom types. However, I have been
thinking to either allow "x-*" types like other IETF standards AND/OR
mentioning in the draft that unknown types should be ignored.

> **I am unclear on how the proposal/acceptance process works for new 
> feedback types? If someone had a type they would like to propose now, 
> what would they need to do?
> 

It would follow the standard IANA procedures for where a designated expert
is used (see RFC 2434). In practice, the IESG, IANA and its appointed expert
would decide on the proper procedure. It would probably be something like a
public post to mailing list and a four week review, although IANA or IESG
might decide otherwise.

To propose a new type now, the best way is to post a message here and
describe what you have in mind. Since the specification has not been
submitted yet to the IETF for approval, it is a bit fluid.

Yakov

From: Douglas Otis <[email-masked]>
Subject: Re: [feedback-report] Feedback types
Date: Fri, 16 Sep 2005 14:57:47 -0700
To: Steve Atkins <[email-masked]>
Cc: [email-masked]

On Sep 16, 2005, at 2:26 PM, Steve Atkins wrote:

> On Fri, Sep 16, 2005 at 04:59:09PM -0400, Yakov Shafranovich wrote:
>
>>
>> At this time there is no provision for custom types. However, I have
>> been thinking to either allow "x-*" types like other IETF standards
>> AND/OR mentioning in the draft that unknown types should be ignored.
>>
>
> I think that ignoring unknown types is a bad idea. The whole idea
> behind having standardised types is so that reports can be handled
> automatically all of the time, with no confusion.
>
> Encouraging non-standard types (by doing anything other than rejecting
> any report that uses them) will reduce the chance of successful
> interoperation.
>
> One redeeming feature of supporting non-standard types would be that
> it's one step better than overloading a free text field, which is what
> some people would do otherwise. I still think that the ideal situation
> is where any up-to-date ARF receiver can receive and parse with 100%
> accuracy a report sent by any ARF sender.
>
> There's a version field in the spec. If the version of the report is
> later than the highest version that the receiver can handle it has
> several options. At _that_ point ignoring unknown types seems like
> a better thing to do than throwing up its hands and giving up.
>
> Additionally, if the sender and the receipient of a report have
> agreed on an extension then there's nothing that prevents them
> from using it. But the report is then not strictly an ARF format
> report, and shouldn't be sent to any recipient who hasn't agreed
> to that extension (and would hopefully be rejected if it were).
>
> Adding an explicit namespace for non-standard types seems reasonable
> on the surface, but I suspect it would cause people to avoid actually
> standardising something that should be standardised (look at how
> widespread use of multipart/x-www-form-url-encoded, for instance).
> Making standardisation of new types reasonably quick and easy is
> another requirement for avoiding that problem, of course.

As this is relatively new, and there could be future requirements  
that invite modification, then finding some type of convention for  
extending the form seems useful.

-Doug

Date: Fri, 16 Sep 2005 14:26:43 -0700
From: Steve Atkins <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] Feedback types

On Fri, Sep 16, 2005 at 04:59:09PM -0400, Yakov Shafranovich wrote:
> Justin Rietz wrote:
> >I apologize in advance if this has been discussed previously - I am new 
> >to this list and wasn't able to find anything in the archives.
> >
> >Regarding feedback types, the spec says that these are extensible, but 
> >that new types need to be approved. Two questions:
> >
> >**Was there consideration given to allowing custom feedback types as 
> >long as they followed the specified format? There could still be 
> >required types that everyone would have to support. This would allow for 
> >customization based upon the scenario in which the standard is being 
> >used, and an entity receiving ARF reports could chose to accept or 
> >reject custom types.
> >
> 
> At this time there is no provision for custom types. However, I have 
> been thinking to either allow "x-*" types like other IETF standards 
> AND/OR mentioning in the draft that unknown types should be ignored.

I think that ignoring unknown types is a bad idea. The whole idea
behind having standardised types is so that reports can be handled
automatically all of the time, with no confusion.

Encouraging non-standard types (by doing anything other than rejecting
any report that uses them) will reduce the chance of successful
interoperation.

One redeeming feature of supporting non-standard types would be that
it's one step better than overloading a free text field, which is what
some people would do otherwise. I still think that the ideal situation
is where any up-to-date ARF receiver can receive and parse with 100%
accuracy a report sent by any ARF sender.

There's a version field in the spec. If the version of the report is
later than the highest version that the receiver can handle it has
several options. At _that_ point ignoring unknown types seems like
a better thing to do than throwing up its hands and giving up.

Additionally, if the sender and the receipient of a report have
agreed on an extension then there's nothing that prevents them
from using it. But the report is then not strictly an ARF format
report, and shouldn't be sent to any recipient who hasn't agreed
to that extension (and would hopefully be rejected if it were).

Adding an explicit namespace for non-standard types seems reasonable
on the surface, but I suspect it would cause people to avoid actually
standardising something that should be standardised (look at how
widespread use of multipart/x-www-form-url-encoded, for instance).
Making standardisation of new types reasonably quick and easy is
another requirement for avoiding that problem, of course.

> >**I am unclear on how the proposal/acceptance process works for new 
> >feedback types? If someone had a type they would like to propose now, 
> >what would they need to do?
> >
> 
> It would follow the standard IANA procedures for where a designated 
> expert is used (see RFC 2434). In practice, the IESG, IANA and its 
> appointed expert would decide on the proper procedure. It would probably 
> be something like a public post to mailing list and a four week review, 
> although IANA or IESG might decide otherwise.
> 
> To propose a new type now, the best way is to post a message here and 
> describe what you have in mind. Since the specification has not been 
> submitted yet to the IETF for approval, it is a bit fluid.

Cheers,
  Steve

Date: Fri, 16 Sep 2005 16:59:09 -0400
From: Yakov Shafranovich <[email-masked]>
Organization: SolidMatrix Technologies, Inc.
To: Justin Rietz <[email-masked]>
Subject: Re: [feedback-report] Feedback types
Cc: [email-masked]

Justin Rietz wrote:
> I apologize in advance if this has been discussed previously - I am new 
> to this list and wasn't able to find anything in the archives.
> 
> Regarding feedback types, the spec says that these are extensible, but 
> that new types need to be approved. Two questions:
> 
> **Was there consideration given to allowing custom feedback types as 
> long as they followed the specified format? There could still be 
> required types that everyone would have to support. This would allow for 
> customization based upon the scenario in which the standard is being 
> used, and an entity receiving ARF reports could chose to accept or 
> reject custom types.
> 

At this time there is no provision for custom types. However, I have 
been thinking to either allow "x-*" types like other IETF standards 
AND/OR mentioning in the draft that unknown types should be ignored.

> **I am unclear on how the proposal/acceptance process works for new 
> feedback types? If someone had a type they would like to propose now, 
> what would they need to do?
> 

It would follow the standard IANA procedures for where a designated 
expert is used (see RFC 2434). In practice, the IESG, IANA and its 
appointed expert would decide on the proper procedure. It would probably 
be something like a public post to mailing list and a four week review, 
although IANA or IESG might decide otherwise.

To propose a new type now, the best way is to post a message here and 
describe what you have in mind. Since the specification has not been 
submitted yet to the IETF for approval, it is a bit fluid.

Yakov

From: "Justin Rietz" <[email-masked]>
To: <[email-masked]>
Date: Fri, 16 Sep 2005 12:24:08 -0700
Subject: [feedback-report] Feedback types

This is a multi-part message in MIME format.

------=_NextPart_000_001A_01C5BAB9.89571970
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I apologize in advance if this has been discussed previously - I am new to
this list and wasn't able to find anything in the archives.

Regarding feedback types, the spec says that these are extensible, but that
new types need to be approved. Two questions:

**Was there consideration given to allowing custom feedback types as long as
they followed the specified format? There could still be required types that
everyone would have to support. This would allow for customization based
upon the scenario in which the standard is being used, and an entity
receiving ARF reports could chose to accept or reject custom types.

**I am unclear on how the proposal/acceptance process works for new feedback
types? If someone had a type they would like to propose now, what would they
need to do?

Thanks,

Justin Rietz
Goodmail Systems, Inc.

------=_NextPart_000_001A_01C5BAB9.89571970
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2722" name=3DGENERATOR></HEAD>
<BODY>
<DIV>
<P><FONT size=3D2>I apologize&nbsp;<SPAN class=3D256352219-16092005>in =
advance=20
</SPAN>if this has been discussed previously - I am new to this list and =
wasn't=20
able to find anything in the archives.</FONT></P>
<P><FONT size=3D2></FONT></P>
<P><FONT size=3D2>Regarding feedback types, the spec says that these are =

extensible, but that new types need to be approved. Two =
questions:</FONT></P>
<P><FONT size=3D2>**Was there consideration given to allowing custom =
feedback=20
types as long as they followed the specified format? There could still =
be=20
required types that everyone would have to support. This would allow for =

customization based upon the scenario in which the standard is being =
used, and=20
an entity receiving ARF reports could chose to accept or reject custom=20
types.</FONT></P>
<P><FONT size=3D2></FONT></P>
<P><FONT size=3D2>**I am unclear on how the proposal/acceptance process =
works for=20
new feedback types? If&nbsp;<SPAN =
class=3D256352219-16092005>someone</SPAN> had a=20
type&nbsp;<SPAN class=3D256352219-16092005>they</SPAN> would like to =
propose now,=20
what would&nbsp;<SPAN class=3D256352219-16092005>they </SPAN>need to=20
do?</FONT></P>
<P><FONT size=3D2></FONT></P>
<P><FONT size=3D2>Thanks,</FONT></P>
<P><FONT size=3D2></FONT></P>
<P><FONT size=3D2>Justin<SPAN class=3D256352219-16092005> =
Rietz<BR>Goodmail Systems,=20
Inc.</SPAN></FONT></P></DIV></BODY></HTML>

------=_NextPart_000_001A_01C5BAB9.89571970--

Date: Thu, 15 Sep 2005 14:31:02 -0500
From: Joshua Baer <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] Testing tools

>
> Yakov Shafranovich wrote:
>
>> Is anyone interested in setting up some testing tools for ARF 
>> reports? I was thinking along the lines of:
>

We're working on some implementation libraries. For now, here are 2 
testing email addresses.

To have an abuse report sent to you, send an email message to 
[email-masked]

To validate an abuse report syntax, send the abuse report to 
[email-masked]

Please let me know if you have any problems, requests, or "feedback" 
(har har).

~Josh

Date: Sun, 11 Sep 2005 02:13:49 -0500
From: Joshua Baer <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] Testing tools

Yakov Shafranovich wrote:

> Is anyone interested in setting up some testing tools for ARF reports? 
> I was thinking along the lines of:
>
> o email address that will bounce back with an ARF report encapsulating 
> the email sent to it

>
> o reference library

We'll produce these two.

~Josh

Date: Fri, 9 Sep 2005 12:54:40 -0700
From: Steve Atkins <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] Testing tools

On Fri, Sep 09, 2005 at 03:50:00PM -0400, Yakov Shafranovich wrote:

> Is anyone interested in setting up some testing tools for ARF reports? I 
> was thinking along the lines of:
> 
> o email address that will bounce back with an ARF report encapsulating 
> the email sent to it
> o web page that an ARF report can be uploaded to and checked for validity
> o email service that can check ARF reports sent to it for validity
> o reference library

I'm working on 2 and 3 (in my copious spare time, so I don't have
a release scheduled).

Cheers,
  Steve

Date: Fri, 09 Sep 2005 15:50:00 -0400
From: Yakov Shafranovich <[email-masked]>
Organization: SolidMatrix Technologies, Inc.
To: [email-masked]
Subject: [feedback-report] Testing tools

Is anyone interested in setting up some testing tools for ARF reports? I 
was thinking along the lines of:

o email address that will bounce back with an ARF report encapsulating 
the email sent to it
o web page that an ARF report can be uploaded to and checked for validity
o email service that can check ARF reports sent to it for validity
o reference library

Yakov