Alberti Antoine | 17 Nov 11:28 2003


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>               92807 Puteaux Cedex - France

Internet-Drafts | 1 Dec 21:28 2003

I-D ACTION:draft-ietf-ediint-as2-14.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Electronic Data Interchange-Internet Integration Working Group of the IETF.

	Title		: MIME-based Secure Peer-to-Peer Business Data 
			  Interchange over the Internet Using HTTP AS2
	Author(s)	: D. Moberg, R. Drummond
	Filename	: draft-ietf-ediint-as2-14.txt
	Pages		: 28
	Date		: 2003-12-1
This document describes how to exchange structured business
data securely using HTTP transfer for XML, Binary,
Electronic Data Interchange, (EDI - either the American
Standards Committee X12 or UN/EDIFACT,  Electronic Data
Interchange for Administration, Commerce and Transport) or
other data describable in MIME used for business to business
data interchange. The data is packaged using standard MIME
content-types. Authentication and privacy are obtained by
using Cryptographic Message Syntax (S/MIME) security body
parts. Authenticated acknowledgements make use of
multipart/signed replies to the original HTTP message.

A URL for this Internet-Draft is:

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ediint-as2-14.txt".

A list of Internet-Drafts directories can be found in 

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at>
In the body type:
	"FILE /internet-drafts/draft-ietf-ediint-as2-14.txt".
NOTE:	The mail server at can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Attachment: message/external-body, 134 bytes
Attachment (draft-ietf-ediint-as2-14.txt): message/external-body, 68 bytes