I'm trying to interpret the BES document's text on throwing errors in cases where the input vector is of length 1 (all 
that is required by HPCBP). Section 6.2 of the BES v1.0 spec says:

The GetActivityStatuses, TerminateActivities, and GetActivityDocuments operations take a vector of activity EPRs as 
input and operate on all the referenced activities. Since an input vector may contain EPRs that are either unknown to a 
BES or for which the BES cannot execute the requested operation, the following failure semantics MUST be provided by a 
compliant BES:
• If a request fails for some reason that applies to all the specified activities—e.g., due to
  an authorization fault—then the BES MUST respond with an appropriate fault response
  message.
• If a request can succeed for one or more of the specified activities then the BES MUST
  respond with a vector of response elements, where each element corresponds to the
  equivalent activity designated in the input EPR vector. Each response element MUST be
  either an element describing the results of the request, as applied to the designated
  activity, or a SOAP-1.1 fault element describing why the request could not be applied to
  the designated activity (e.g., because the EPR could not be resolved to any known
  activity within the BES).


My interpretation of this is that if one of these operations takes a vector of length 1, the first bullet says that a 
failure (which by definition applies to all specified activities) allows me to simply return a soap fault. However, 
reading the text of the actual sections for those methods (6.2.2, 6.2.3, 6.2.4) it seems that even for vectors of length
 1, I should return any fault information inside a, for example, GetActivityStatusesResponse message. 

Further, the WSDL shown in the BES spec for (we'll again use this as an example) GetActivityStatuses is:

<wsdl:operation name="GetActivityStatuses">
  <soap:operation soapAction="http://schemas.ggf.org/bes/2006/08/besfactory/BESFactoryPortType/GetActivityStatuses" />
  <wsdl:input name="GetActivityStatuses">
    <soap:body use="literal" />
  </wsdl:input>
  <wsdl:output name="GetActivityStatusesResponse">
    <soap:body use="literal" />
  </wsdl:output>
  <wsdl:fault name="UnknownActivityIdentifierFault">
    <soap:fault name="UnknownActivityIdentifierFault" use="literal" />
  </wsdl:fault>
</wsdl:operation>

To me, the <wsdl:fault> element indicates that it is legitimate to throw an UnknownActivityIdentifierFault "directly", i
.e. not inside the Fault element of a GetActivityStatusesResponse message.


So, my questions are:
1. should it be the case that the only permissible response from a BES for the GetActivityStatuses (or similar) method 
is a GetActivityStatusesResponse message (which would then contain appropriate faults)?
	- in this case, it seems that the WSDL should be changed and the text in 6.2 clarified 2. or should we allow cases 
where faults can be returned directly?
	- in which case the text of 6.2.2 (and 6.2.3 and 6.2.4) should be clarified 3. or is the UnknownActivityIdentifierFault
 special and so that one can be thrown directly, while faults of other types need to be inside a 
GetActivityStatusResponse message?
	- this seems like a strange option to me.