RE: AS3 Discusion - Section 6 - FTP Considerations

["Terry Harding" <tharding@xxxxxxxxxxxxxxxxxxx>]

Open for discussion

6.  FTP Considerations

6.1 FTP Security Requirements

    FTP has long been viewed as an insecure protocol primarily because
of 
    its use of cleartext authentication [FTP].  This is addressed by RFC

    2228, and the use of one of the security mechanisms described
therein 
    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
upon
    [SFTP] MAY be utilized, AUTH TLS (as described in [MURRAY]) MUST be 
    supported.

6.2 Large file transfers

   Large files are handled correctly by the TCP layer.  However, there
is 
   the mechanism for compressing data referenced in section 2.4.2.2 
   above which efficiently reduces transmission requirements for many
data 
   types (including both XML and traditional EDI data.)  Additionally,
some 
   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:

         AS3-To
         AS3-From
         Date
         Message-ID
         Content-Type
    
    An AS3 message OPTIONALLY MAY contain the following outer headers:

         Subject
         AS3-Version (assumed to be 1.0 if not present)
         Content-Length

    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
signed)

    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
(default)
   and the image type.  The Content-Transfer-Encoding header SHOULD NOT
be
   used; if the header is present, it MUST have a value of binary or
8-bit, 

Harding, Scott                                                 [Page 12]


INTERNET DRAFT       FTP Transport Data for EDIINT           April 2005

   and the absence of this header MUST NOT result in transaction
failure.
   Content transfer encoding of MIME parts within the AS3 message are 
   similarly constrained.

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 [15]: "<" 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".
*****************************************************

Terry Harding
Cyclone Commerce Inc.