The requestDataTransferInstance operation on a DTF requires the information in <dmi:AvailableProtocols> in order to determine the protocol to be used in the data transfer. The spec. currently embeds this information in a <dmi:DataEPR> which is, essentially, an EPR to the source/sink that has had the AvailableProtocol information added to it. This note discusses this area of the spec. in more detail. A client of DMI will acquire EPRs to the source/sink in ways that are outside the scope of DMI. However, when we step back it is pretty clear that either the client has these because the client created the source/sink or because the client went to a service such as RNS or GFS to acquire them. Given that the specifications for these kinds of services already exist, as well as implementations of them, it seems quite clear that the EPRs returned by these services will not have the <dmi:AvailableProtocol> information in them. Thus in order to use DMI facilities, the client will need to get a DEPR from the EPR it has in hand. One way to get this information would be for the client to go to the source/sink service and ask for a DEPR. One would imagine the service would provide an operation such as GetDEPR () which returns a DEPR for that service. The client can clearly do this since the client has an EPR to the source/sink service. This approach would retain the current DTF interface unchanged. Alternatively, one could consider moving the <dmi:AvailableProptocol> information out of the DEPR and treat as a first class parameter to the requestDataTransferInstance operation. I strongly prefer this approach as it makes the required information in <dmi:AvailableProtocols> clear in the interface - it does not bury it inside of an EPR. In this approach the source/sink services would provide an operation such as GetAvailableProtocols () which returns a <dmi:AvailableProtocols>. Again, the DMI client can clearly do this since the client has an EPR to the source/sink in hand. A key thing to note is that in either approach, successful use of DMI, in practice, is going to require that data services willing to act as a source/sink in a DMI transfer will need to implement an additional, very trivial, operation to allow the DMI client get the <dmi:AvailableProtocol> information. Once the client has that information, it needs to be passed into the DTF either via a DEPR as in the current spec. or as an explicit parameter as I suggest above. Finally, it is clear that DMI can not mandate the operations suggested above. However, the DMI spec. certainly needs to recognize the need for operations such as those suggested above and suggest that data services provide an operation that supports the DTF interface that DMI specifies. Allen Luniewski IBM Cross Brand Services IBM Silicon Valley Laboratory 555 Bailey Ave. San Jose, CA 95141 408-463-2255 408-930-1844 (mobile)