Hi; I have to admit that I had to read up on WS-Transfer. It makes more sense where you're coming from now. It's a very different philosophy of how resource state should be managed. Considering this I think we should still make this activity description a resource state property/element and leave it ambiguous as to how it is accessed. Unfortunately if we don't define the Activity interface we can't define the state item. ... And here is where I have the biggest problem with WS-Transfer. I think an activity's progress state should be a property that is modeled as desired (i.e. either WS-Transfer or WSRF) as long as there are multiple, popular ways to do so; but as you say, getting the entire state for one item is excessive. That's my personal opinion in general after reading about WS-Transfer. I don't think we should be sacrificing good design just because some implementation detail (I consider this implementation because it's left ambiguous in the spec) doesn't play nice. If you don't like it, don't use WS-Transfer in your implementation. Now then, there is a potentially serious problem here in that if the public state model is not standardized in the spec then how do you know what WS interface to use to manipulate it? In that case I would say we need an operation that specifically targets interop data (kind of like the FTP "FEAT" command). This is yet another reason in support of defining the activity interface. Each activity ought to be exposing via such a method what kind of public state model it uses. I agree that we should define the activity interface since we're implicitly doing so at the BES level now. Leaving the access method ambiguous unfortunately doesn't yield an interface that actual implementations can interoperate through. So the HPC profile work will need to define one or more concrete interfaces one way or the other. One approach is to reflect the schism between WSRF and WS-Transfer and define two separate (but equal :-)) interfaces that each employ one or the other approach. Unfortunately that will make interoperability in practice much harder to achieve. To interoperate with BES services in general would require that either services export both interfaces or clients implement both interfaces. We've effectively doubled the cost of creating BES interfaces, including all the interop testing that has to go with it. Consider also that currently the main development tool options support either WSRF or WS-Transfer or neither. So developers would need to implement compliant implementations of either WSRF or WS-Transfer or both on their own. If you've followed the interop workshop process that Microsoft and IBM have been using for achieving interoperable tooling and implementations of even basic Web Service concepts and protocols, you'll know that that's a seriously expensive commitment to impose on developers. When you consider that in a couple years' time the world will have converged on a merged alternative to both of these protocol suites (and associated tooling), it seems even more questionable to pursue this avenue at this point in time. The alternative that I would advocate is to define a placeholder interface for version 1 that skirts the issue altogether. That was the intent behind my straw man proposal of GetActivity and GetActivityState methods. Using these would allow BES and the HPC profile work to get off the ground quickly without requiring that all parties first create compliant implementations of both WSRF and WS-Transfer. Interoperability testing would be confined strictly to these few methods in the BES/HPC-profile context and hence would be much simpler. Whether these methods should be replaced by the convergent replacement for WSRF/WS-Transfer in a later version of BES is something that could be examined at a later time when that convergence has actually occurred and things like tooling are broadly available for it. To summarize what is essentially a counter proposal, I think we need to... 1) Expose public state as it was intended to be exposed (i.e. in state properties/elements within the state document) 2) Leave the public state model ambiguous 3) Define the Activity interface 4) Include an interop data fetch operation, say "GetInteropData", on both the BES interface and the Activity interface. The returned data should be well defined but extensible, and include what type of public state model is being used. I'm not sure I understand what you mean by "leave the public state model ambiguous". Are you referring to the fact that BES has decided to move to an extensible state model and you'd like to use your proposed GetInteropData to return - among other things - a description of which state model extensions the service implements (including, of course, the base state model)? If that's the case then I totally agree with the need for that information. So I suspect that we're in agreement that, one-way-or-the-other, an activity should expose at least the following state elements for querying by clients: * Description of which state model extensions the service implements. * Activity state. * Full (extensible) description of the activity's state. See my previous comments about not wanting to expose more than one way to retrieve the public state of an activity. Please also note that, whereas one can argue about the pros and cons of the WSRF and WS-Transfer approaches, the reality I have to deal with is that there are two camps and there is no good tooling that supports both, so the choice the HPC profile WG has to make is arguably one of the following: 1. Go with both WSRF and WS-Transfer-based versions of BES and force everyone to implement compliant versions of both. That's too expensive in my opinion. 2. Wait for the convergent follow-on specs and define BES in terms of those. That doesn't meet the time-line requirements that the HPC profile WG faces. 3. Define a single interface that employs neither WSRF nor WS-Transfer in order to get a version 1 HPC profile done now rather than in a couple of years time; then consider for version 2 whether it makes sense to move to the convergent WSRF/WS-Transfer follow-on specs. To me, option 3 seems by-far the most preferable one. Marvin.