2003-11-17 10:28:50 GMT
I may not have understood the overall goals of this draft, but I think the FTP part of the AS#3 is really too light and does not specify enough things to allow EDI peers to interact without waiting for implementations to come out to evaluate the state-of-the-art. For instance, I suppose (I have to) that the command used to send the document is STOR, but then, how should its parameter, assumed to be a filename, be considered? And what about the possible directory tree described in this parameter, about the file separator formats, and so on? How should the commands given before, like REST, should be considered? The fact is that, by reading this draft, one can assume that an FTP client, or server, is specific to AS#3. A standard product is very difficult to use, without regularly polling a directory on the server side, for instance. Or the FTP products used in an AS#3 architecture can not be used for standard FTP purpose, because they are too specific to this standard: on the contrary to SMTP or HTTP, FTP is not designed to require that a server parses the data received to retrieve a MIME header in it, and parses the rest of the document depending on fields like content-type. cgi-bin-like hooks are never provided in FTP implementations, neither. Specific treatments should be required by specific FTP commands. In other works, the cleaner, but impossible, way to use FTP as a secured EDI transport protocol would have been to pass all the AS#3 useful header fields as FTP commands (like "SITE MIME Content-Type: message/disposition-notification").
Another thing that makes me think that the product has to be specific is that a client also has to be a server, and vice-versa. The problem is not only that it is the first time I see such a requirement in a specification, but also that it raises great problems with network administration, which seems to be one of the greatest issues raised on the mailing list by the use of FTP.
FTP is rather more difficult to implement than it seems, because, among other things, of a lack of specification about the relative moments of data connections, disconnections, request, responses, and transfers, and the eterogeneity of the gateways, proxys, and bugs, encountered on the internet. In other words, an FTP implementation needs a certain maturity, and I don't think it's a good idea to require new FTP implementations.
I also think that most of these issues could be avoided by specifying a little bit more on the FTP side. For instance, by giving a role to the filename parameter: a client could "STOR" a document, and "RETR" the corresponding MDN on the same FTP session, or later. This avoids the requirement to have both implementations of FTP (client and server, which are really different) on both sides. A specific command could also be registered on the ftp-ext working group to help both peers switching between standard and AS#3 (or more generally to a MIME-parsing) modes.
I belong to these guys that will have to implement this standard in a few months, on an existing, and very complicated, FTP implementation. And I really hope that it becomes by then a standard that can be used by other people than the ones who claimed to implement a standard that did (and still does) not exist.
Thanks for the time spent on reading this. Best regards.
Antoine Alberti Axway. a Sopra Group company
Tel : +33 (0)1 47 17 24 37 XFB R&D
Fax : +33 (0)1 47 17 24 25 26 Rue des Pavillons
email: aalberti <at> axway.com 92807 Puteaux Cedex - France