[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AS3 Discusion - Section 6 - FTP Considerations
Open for discussion
6. FTP Considerations
6.1 FTP Security Requirements
FTP has long been viewed as an insecure protocol primarily because
its use of cleartext authentication [FTP]. This is addressed by RFC
2228, and the use of one of the security mechanisms described
is strongly encouraged. Specifically, conforming implementations of
AS3 SHALL employ FTP client/servers that support the AUTH command
described within [SFTP]. While any authentication mechanism based
[SFTP] MAY be utilized, AUTH TLS (as described in [MURRAY]) MUST be
6.2 Large file transfers
Large files are handled correctly by the TCP layer. However, there
the mechanism for compressing data referenced in section 188.8.131.52
above which efficiently reduces transmission requirements for many
types (including both XML and traditional EDI data.) Additionally,
FTP implementations support compression as well.
6.3 MIME Considerations for FTP
6.3.1 Required/Optional Headers
An AS3 message MUST contain the following outer headers:
An AS3 message OPTIONALLY MAY contain the following outer headers:
AS3-Version (assumed to be 1.0 if not present)
An AS3 message requesting a receipt MUST contain a
Disposition-Notification-To header and MAY contain a
Disposition-Notification-Options header(if the receipt is to be
Additional headers MAY be present but are ignored.
6.3.2 Content-Transfer-Encoding Not Used
FTP defines several data structures and character encodings via the
STRU[cture] and TYPE commands. AS3 requires the file-structure
and the image type. The Content-Transfer-Encoding header SHOULD NOT
used; if the header is present, it MUST have a value of binary or
Harding, Scott [Page 12]
INTERNET DRAFT FTP Transport Data for EDIINT April 2005
and the absence of this header MUST NOT result in transaction
Content transfer encoding of MIME parts within the AS3 message are
6.3.3 Epilogue Must Be Empty
A MIME message containing an epilogue [MIME] SHALL NOT be used.
6.3.4 Message-Id and Original-Message-Id
Message-Id and Original-Message-Id are formatted as defined in
section 3.6.4 of RFC2822 : "<" id-left "@" id-right ">".
Message-Id length is a maximum of 998 characters. Message-Id
SHOULD be globally unique, id-right should be something unique
to the sending host environment (e.g. a host name). When sending
a message, always include the angle brackets. Angle brackets are
not part of the Message-Id value.
NOTE: When creating the Original-Message-Id header in an MDN,
always use the exact syntax contained in the original
message: do not strip or add "angle brackets".
Cyclone Commerce Inc.