Clarify how default MessageBodyReaders should deal with concrete implementations of interfaces

We've had a user reporting an issue to do with CXF javax.activation.DataSource provider throwing an exception after a user typed 'javax.activation.FileDataSource' in the signature.

Given that the spec requires support for java.io.File it was easy to provide a support for javax.activation.FileDataSource OOB.

Now the user asks is it against the spec for a default provider to support a type not specifically mentioned in the spec.

IMHO the spec should clarify what MessageBodyReader supporting the interfaces required to be supported by the spec should do when it sees a concrete, well-known interface implementation.

Here are 3 proposed solutions:
1\. Recommend that "Default MessageBodyReaders may support some concrete implementations" - the problem here is that we may have a portability issue between the implementations
2\. Specify some of concrete implementations such as javax.activation.FileDataSource, and a couple of known JAXP Source classes.
3\. Request that if concrete implementation class is typed in the method signature and it is different from the class MessageBodyReader uses to support a given interface then throw 500.

I think 3 may be reasonable - but may be we can relax it a bit with 2.
#### Affected Versions
[2.0]