Define a rule for inclusion/exclusion of activity and object types

[rpeinl]

Instead of deciding on every single request of including a certain activity type or object type and sometimes inconsistently arguing with possible extensions of AS2 solving the problem, I propose creating a rule based on interoperability considerations that every activity type that is needed for a valid use case to be understood correctly by a second implementation should be part of the AS2 vocabulary. Whereas every object type that can be represented as a specialization of existing object types and does not need any additional properties should be rejected for the AS2 vocabulary, since implementations can still fall back on the defined super type without losing too much information.
This covers issues: #256, #242, #235, #175 and #157
See also closed issue #239 for a discussion that already led to a decision in that direction.
Other closed issues like #228, #216, #153 just to name a few would also be covered by such a rule.
I also suggest collecting use cases with suggestions of how to implement them in non normative appendix or separate document that also includes those issues rejected for inclusion in the vocabulary and show there how to solve it with extension mechanisms in order to increase the chance of interoperability of two implementations of the same use case. This is in line with issue #261.

[jasnell]

this was discussed at the F2F.. the resolution is in the minutes. I'll try to post a detailed description later on. Closing for now tho

[jasnell]

Ok, so based on the discussion at the face to face, the general guideline on this is straightforward: At this point in time, the focus in on keeping the core vocabulary as minimal as possible. There is a high bar for things to be added. That bar would be at least two implementations of a very clear use case, otherwise the new term would likely not be considered.

[rpeinl]

What does implementation mean? An existing software that would benefit from using AS2 instead of their own mechanism and requiring the activity type or object type? Or a software that already implements AS2, although AS2 is still not stable? From my feeling the first interpretation is not a hurdle, since there are tons of software for almost every use case. The latter would mean: it doesn't make sense to propose any vocabulary terms, because there are no two independent implementations of AS2 right now, as far as I understand, and therefore there is no chance of having two implementations requiring something.

[jasnell]

@rpeinl ... I believe that's still open for interpretation. Open to suggestions :-) The main idea is that in this phase of the process, we should be limiting, as much as possible, the new things that are added to only those that are definitely needed for the most common cases.