Internet DRAFT - draft-harding-filename-preservation

draft-harding-filename-preservation



Internet Draft                                     Editor: Terry Harding
draft-harding-filename-preservation-00.txt                     Axway Inc
                                                              May 2007
Expires November 2007 
Target Category: Informational
 
                  Filename Preservation for EDIINT
 
Status of this memo
 
   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.
    
   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html
      

Harding                                                        [Page 1]

INTERNET DRAFT      Filename Preservation for EDIINT         November 2007

Keywords

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      [RFC2119].

 
Abstract
 
   The intent of this document is to be placed on the RFC track as an
   Informational RFC.
 
   The EDIINT [AS1], [AS2] and [AS3] message formats do not currently
   contain any provisions for preservation of the filename of a
   transmitted EDI business document from one Trading Partner to
   another.
   
   However,within certain trading communities, it is not uncommon for
   Trading Partners to require a specific filenames for EDI business
   documents to trigger specific backend processing. So it is
   the goal of this informational document to outline the procedures
   and mechanisms required to preserve filenames of EDI business
   documents.

 
1. Introduction
 
   This document describes a method of filename preservation utilizing
   the Content-Disposition MIME header[RFC 2183]. This document will
   further define the use of available optional parameters as described
   in RFC 2183, and any issues involved with implementing this
   informational document.
   
   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
   interpreted as described in [RFC2119].

2. Requirements
   
   An EDIINT compliant system that implements this informational 
   document MUST preserve the filename of an EDI business document 
   during packaging and transport of the EDIINT MIME message to its
   trading partner.

   The recipient of the EDIINT MIME message MUST be able to retrieve the
   filename of the MIME wrapped EDI business document and transfer the
   received file to its backend system using the received filename.

   Since there are many ways in which files can be delivered to an
   EDIINT compliant application from their backend, this document will
   only focus on preserving the filename within the EDIINT MIME message.

Harding                                                        [Page 2]

INTERNET DRAFT      Filename Preservation for EDIINT         November 2007

   Each vendor will decide on their own how the filename is preserved
   within their application and tied to a specific EDI business
   document. It is only important that the filename of an EDI business
   document is the same filename name that is linked to the EDI document
   within the EDIINT MIME message.

   The linking of a filename to an EDI business document within an
   EDIINT MIME message will be accomplished by the use of the 
   Content-Disposition MIME header.

   The Content-Disposition header will be added to the MIME bodypart
   that encapsulates the EDI business document.  If the EDIINT MIME
   message contains multiple attachments( See [MA] ) then each
   individual MIME bodypart that encapsulates an attachment will have
   its own Content-Disposition header describing the filename of the
   attachment.

   There may be times when EDI business documents are received from
   backend systems where no filename is linked to the outbound EDI
   business document or when filename preservation is not required.
   During these times, the sending system may internally generate a
   filename for the EDI business document.

   Any receiving system that receives an attachment where no
   Content-Disposition header exists MAY create its own filename for the
   attachment when it is transferred to the backend system.

   If the trading partner agreement between two trading partners
   requires filename preservation, the EDIINT application MUST ensure
   that a mechanism is available to receive files from their backend
   system that allows linking of filenames to EDI business documents.
   
 
2.1 Content-Disposition Header

   The format of the Content-Disposition header is defined in
   [RFC 2183], Section 2,  and was copied to this document for the
   convenience of the reader. If there are any discrepancies between
   this document and [RFC 2183], [RFC 2183] will be considered correct.

   In the extended BNF notation of [RFC 822], the Content-Disposition
   header field is defined as follows:

     disposition := "Content-Disposition" ":"
                    disposition-type
                    *(";" disposition-parm)

     disposition-type := "inline"
                       / "attachment"
                       / extension-token
                       ; values are not case-sensitive


Harding                                                        [Page 3]

INTERNET DRAFT      Filename Preservation for EDIINT         November 2007

     disposition-parm := filename-parm
                       / creation-date-parm
                       / modification-date-parm
                       / read-date-parm
                       / size-parm
                       / parameter

     filename-parm := "filename" "=" value

     creation-date-parm := "creation-date" "=" quoted-date-time

     modification-date-parm := "modification-date" "=" quoted-date-time

     read-date-parm := "read-date" "=" quoted-date-time

     size-parm := "size" "=" 1*DIGIT

     quoted-date-time := quoted-string
                      ; contents MUST be an RFC 822 `date-time'
                      ; numeric timezones (+HHMM or -HHMM) MUST be used

   NOTE ON PARAMETER VALUE LENGTHS: A short (length <= 78 characters)
   parameter value containing only non-`tspecials' characters SHOULD be
   represented as a single `token'.  A short parameter value containing
   only ASCII characters, but including `tspecials' characters, SHOULD
   be represented as `quoted-string'.  
   `Extension-token', `parameter', `tspecials' and `value' are defined
   according to [RFC 2045] (which references [RFC 822] in the definition
   of some of these tokens).  `quoted-string' and `DIGIT' are defined in
   [RFC 822].


   Example:  Content-Disposition: attachment; filename="myfile"

   Systems compliant with this informational document SHOULD use the
   "attachment" disposition-type and MUST use the "filename"
   disposition-parm.  Systems MAY also choose to use any other
   registered disposition-parms within the Content-Disposition header
   along with the disposition-type and filename parms. Compliant systems
   MUST also ignore any disposition-parms it does not recognize when
   parsing the Content-Disposition header.

 
2.2 Structure of an EDI MIME bodypart

   The example below shows a MIME bodypart that encapsulates an EDI
   business document. Every MIME bodypart within an EDIINT message that
   contains an EDI business document MUST contain the
   Content-Disposition header.


   Content-Type: application/edi-x12

Harding                                                        [Page 4]

INTERNET DRAFT      Filename Preservation for EDIINT         November 2007

   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=myedifile.x12
 
   MIAGCyqGSIb3DQEJEAEJoIAwgAIBADANBgsqhkiG9w0BCRADCDCABgkqhkiG9w0BBwGgg
   Hnic7ZRdb9owFIbvK/k/5PqVYPFXGK12YYyboVFASSp1vQtZGiLRACZE49/XHoUW7S/0t
   fU5ivWnasml72XFb3gb5druui7ytN803M570nii7C5r8tfwR281hy/p/KSM3+jzH5s3+p
   P3VT3QbLusnt8WPIuN5vN/vaA2+DulnXTXkXvNTr8j8ouZmkCmGI/UW+ZS/C8zP0bz2dz
   UEk2M8mlaxjRMByAhZTj0RGYg4TvogiRASROsZgjpVcJCb1KV6QzQeDJ1XkoQ5Jm+C5Pb
   v+ORAcshOGeCcdFJyfgFxdtCdEcmOrbinc/+BBMzRThEYpwl+jEBpciSGWQkI0TSlREmD
   SGLuESm/iKUFt1y4XHBO2a5oq0IKJKWLS9kUZTA7vC5LSxYmgVL46SIWxIfWBQd6Adrnj
   vGxVibLqRCtIpp4g2qpdtqK1LiOeolpVK5wVQ5P7+QjZAlrh0cePYTx/gNZuB9Vhndtgu
   W9ogK+3rnmg3YWygnTuF5GDS+Q/jIVLnCcYZFc6Kk/+c80wKwZjwdZIqDYWRH68MuBQSX
   3CAaYOBNJMliTl0X7eV5DnoKIFSKYdj3cRpD/cK/JWTHJRe76MUXnfBW8m7Hd5zhQ4ri2
   +kV1/3AGSlJ32bFPd2BsQD8uSzIx6lObkjdz95c0AAAAAAAAAAAAAAAA

3. Filename Parameter

   Rules and restrictions on the use of the filename parameter value are
   outlined in RFC 2183, Section, 2.3 and RFCs 2822, 2045, 2046, 2047,
   2048 and 2049.

3.1 Filenames

   As stated in RFC 2183, Section 2.3, current MIME standards restrict
   the grammar of filenames and various file systems will have name
   limitations. So it will be the responsibility of the two Trading
   Partners to determine the limits imposed by their trading
   environments.

4. Issues

4.1  RFC 2184

   RFC 2184 states that parameter values longer than 78 characters, or
   which contain non-ASCII characters, MUST be encoded as specified in
   [RFC 2184].
   
   This informational document does not encourage the use of filenames
   longer than 78 characters or comprised of non-ascii characters. See
   Section 3.1.

4.2 AS3(FTP) 
 
   The filename parameter that is described in this document is for the
   embedded EDI business document and does not affect the name of the
   EDIINT message that is uploaded to a trading partner's FTP server.
   EDIINT compliant AS3 applications will follow any guidelines as
   defined by [AS3] for file naming conventions for uploaded files.

5. Security Considerations
 
   See RFC 2183, Section 5

Harding                                                        [Page 5]

INTERNET DRAFT      Filename Preservation for EDIINT         November 2007

   
Author's Addresses
 
   Terry Harding
   Axway Inc.
   Scottsdale, Arizona, USA
   tharding@us.axway.com       
 
References
 
  Normative References
  
  [AS1] T. Harding, R. Drummond, C. Shih,  MIME-Based Secure
        Peer-to-Peer Business Data Interchange over the Internet,
        RFC 3335, September 2002.

  [AS2] Moberg D., Drummond, R. MIME-Based Secure Peer-to-Peer Business
        Data Interchange Using HTTP, RFC 4130, July 2005.

  [AS3] T. Harding, R. Scott, FTP Transport for Secure Peer-to-Peer
        Business Data Interchange over the Internet, 
        draft-ietf-ediint-AS3-03.txt, July 2005.

  [MA]  K. Meadors, Multiple Attachments for EDI-INT, 
        draft-meadors-multiple-attachments-ediint-01.txt, August 2005

  [RFC2119] Key Words for Use in RFC's to Indicate Requirement Levels,
        S.Bradner, March 1997.
 
  [RFC 2183] R. Troost, S. Dorner, K. Moore, Communicating Presentation
             Information in Internet Messages: The Content-Disposition
             Header Field, RFC 2183, August 1997

  [RFC 2184] N. Freed, K. Moore, MIME Parameter Value and Encoded Word
             Extensions: Character Sets, Languages, and Continuations,
             RFC 2183, August 1997

        
Acknowledgments
 

Disclaimer









Harding                                                        [Page 6]

INTERNET DRAFT      Filename Preservation for EDIINT         November 2007

Copyright Statement

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors 
   retain all their rights.

   Copyright (C) The IETF Trust (2007).

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Expires November 2007


Harding                                                        [Page 7]