RE: I-D ACTION:draft-ietf-ediint-as3-02.txt

I have a few comments about this draft:

Globally: Why did you skip 2 lines after each line?

2.1: Why is it that a trading application must not embed an FTP server to work without an external one?

4.2: Once again, this chapter is essential, but does not state anything. This bullet representation is not standardized, and does not clarify things. On the other hand, RFC 2119 defines how things should be litteraly described without ambiguity. EDI-INT uses subsets of RFCs. For example, this draft only uses multipart-signed for signing using S/MIME, and RFC 2634 defines a behavior about "triple wrapping". So what is an application supposed to do with the other cases that are technically valid? What does a sender MUST/MAY do, and what does a receiver MUST/MUST NOT support? To be a bit more technical, this draft is based on many other high-level standards, so how can a developper do to integrate existing libraries that have complete support of the underlying standards, and which functions does he have to restrict?
When you add "(encrypted)", does this mean that the corresponding layer encrypts, or that it may be indirectly encrypted by an outermost layer?

6.1: This is a detail, and the choice of using this word is not technically illegal, but SFTP is an existing and totally different protocol.
While talking about authentication, is there any link between FTP authentication, AS3-To, AS3-From, and certificates?

6.2: "Large files are handled correctly by the TCP layer". I agree (actually the TCP layer does not handle files, so this does not sound false), but why is this sentence here? This section looks more like a discussion about compression than about large files, doesn't it?

7.2 paragraph 2: I don't really get the diagram. What is the "[FTP Server]", for instance? From 2.1, we can guess that trading applications only embed FTP clients, using an intermediate server. So why is it that this diagram does not represent it?
By the way, the FTP cinematic is not described: how do partners "send" a message or an MDN? Which upload command do we have to use? STOR or STOU? What is the meaning of the directory tree infered from the use of URLs? What is the meaning of the STOR/STOU filename parameter? Some of these issues may not be in the scope of this draft, but at least it could be explicitely stated. This draft looks more like the specification of offline EDI-INT than like EDI-INT over FTP.

7.3 paragraph 3: Notice that the only typecode supported in the URL is "i" (see RFC 1738 section 3.2.2, and the optional "type=<typecode>" parameter of the FTP URLs).
What does the URL point to? A filename, or a directory, where the sender of the MDN chooses a filename?

7.3.1 5): The good old canonicalization issue. Are you sure that canonicalization must be performed according to RFC 1848? This RFC states: "For example, if the content to be signed contains 8bit or binary data, the content must be encoded with either the quoted-printable or base64 encoding as defined by MIME" (2.1.1 paragraph 3). On the other hand, AS3 states that "The Content-Transfer-Encoding header SHOULD NOT be used; if the header is present, it MUST have a value of binary or 8-bit" (section 6.3.2). If canonicalization is really what is supposed to be done, this operation must be done before each sending operation, then discarded to send data without encoding, AND after each receiving operation. Moreover, when handling signatures, the goal of canonicalization is not to have a valid message, but a message encoded in a unique and deterministic way. So, what is the canonicalization pro
 cess? Do we have to use quoted-printable, or base64? Where do we have to put line delimit!
 ers? Which character set do we have to use? ASCII or EBCDIC?

7.5.3 paragraph 5: Why is the word WILL in upper case (it is not referenced in RFC 2119)? What do you mean? SHOULD? MUST? MAY?

8: S/MIME specifies that when the subjectDN or the subjectAltName of the signing certificate contains an email address, it must correspond to the email address of the sender. What should be done about this in AS3?

9 paragraph 7: What is a certificate with/without URL? Does this have a link with the last question?

9 paragraph 8: What is a certification chain "included" in a certificate? Does it mean that the complete chain MUST be included in the S/MIME envelopes?
What is a verification that "chains to root"? Actually, what is a "root", when PKIX states that self-signed certificates may not exist in a chain, and self-certification may be replaced with cross-certification? If it is a trusted authority, then the question is still relevant: what is a verification that "chains to root"?


Regards

Antoine Alberti.