[feedback-report] Feedback types

[Steve Atkins]

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