In Mario's example, the sink might very well support ftp within the firewall. But for security reasons it is not allowed to cross the firewall. At the same time one might conjecture that some other protocol was valid across the firewall. Since the DTI is created to execute a particular protocol, all it can do in this case is report failure when the FTP fails. The DTI has no means to negotiate another protocol that might work - that is the job of the DTF. So reporting failure is all that it can do.
At this point the client is in a difficult position. If it just reinvokes the DTF, we will just go around this loop again since nothing has changed. If the error reported by the DTF has enough information, the client could edit the DEPRs to remove the protocol that does not work. This will eventually lead to a successful transfer (assuming that the transfer is possible) but seems to obviate one of the key reasons that DMI exists - ease of use/simplicity for the client. So, I regard this as an unacceptable solution.
So what might work and retain the desirable properties of DMI?
1. The DTF could test the protocol to see if it works. I am nervous about this as it raises questions about what data is transferred, where is it stored, how is the test undone, are there security issues, etc.
2. One could take a tact that says that when the DTF does protocol negotiation, it informs the source (sink) as to the identity of the other party involved in the transfer. This then puts the onus on the source (sink) to declare a protocol as unworkable. Unfortunately, this reintroduces protocol negation into DMI which is something that we have gotten away from (as I understand things, right now we basically assume that the DTF just does matches based upon what it finds in the DEPRs). This becomes, I think, just an implementation issue (assuming that we were to choose to not architect the negotiation process) but one that we would need to comment on in the document.
3. We could have the DTI go back to the DTF to choose a different protocol. The problem with this is that this will result in a new DTI (since DTIs are protocol specific) and there is no way to communicate this new DTI back to the client who requested the transfer.
I lean towards option #2. It addresses the problem at DTF time which is when it seems most appropriate to address. It is a natural part of protocol negotiation (which I have always felt was the proper way to architect this and not via the current DEPR based approach). It is also something that is easy to explain to DMI clients.
Allen Luniewski
IBM Cross Brand Services
IBM Silicon Valley Laboratory
555 Bailey Ave.
San Jose, CA 95141
408-463-2255
408-930-1844 (mobile)