Section 3 says that all sub-elements of the <AdvancedFilter> are additive, but I'm not sure if this is exactly what is intended. For example, if I put <Username>Bob</Username> and <Username>Alice</Username> in the filter, I want jobs that are owned by Alice or Bob (not Alice and Bob). I think what we want is to say that sub-elements of different types (e.g. <Username> and <State>) are additive and sub-elements of the same type (e.g. 2 <Username>s) are "ORed". SJN: The behavior you describe is what I was after. OR for elements of the same type. AND for elements of different type. For the Username filter, I'm wondering if there are issues in a multi-credential world for which we might want to add some clarification text. For instance, are you interested in the username known to the backend resource or the username used to identify the client to the service? I presume you'd want the former, which can be different than the later. Currently, HPCBP only allows specification of the later (though there is the optional username element in the HPCPApplication). In the future something like the ActivityCredential document might be used to carry the former. Anyway, my question is whether there should be some clarification text saying something about how the client must understand the way in which the service will assign usernames to jobs in order to formulate the correct username string for the filter? The service may do this straight-forwardly by using the same username for both authentication to the web service and to the backend, but the client must understand this through out-of-band means. The other (more complicated) option is to have the service advertize something that tells the client how to construct usernames. SJN: Good questions. Part of the problem is that the execution model is not specified in sufficient detail in HPCBP - everything is an implementation detail. Minimally the token provided by the client is 'just' to authenticate themselves to the service. At no point does this have to be the token used to submit the job to the DRM. The web service could use this token to access a local account and submit the job under that identity, use the identity of the running service (i.e. all jobs are submitted as the same user) or use an ActivityCredential to define the identity used to run the job. Many models are possible - some more desirable than others - but there is no constraint. We may need two elements here - SubmittedUserName & ExecutingUserName to identify the two modes. If one mode is not supported by an implementation then an UnsupportedFeatureFault can be cleanly thrown. Should we add something about throwing an UnsupportedFeatureFault or InvalidRequestMessageFault if you send in a filter with sub-elements which a service does/can not support? My service, for example, currently uses GUIDs in its activity IDs and so the range-based ID search doesn't work well there. SJN: Of course I left faults out in the first draft!!! UnsupportedFeatureFaults for unsupported features (!) and InvalidRequestMessageFaults for badly formatted or misunderstood content make sensible additions for the next draft (post SC07). The issue about the jobID s is a significant one. Someone suggested that the ActivityEPRs should be used instead... but like GUIDs they do not necessarily have a sequences. Exposing the jobIDs like this is something I don't like... and would welcome an alternative approach if anyone has one! I believe the capability is important - how to represent it is the issue! Steven