Private Working Group Internet Draft Editor: Terry Harding draft-harding-ediint-filename-preservation-00.txt Axway Inc Expires: September 24, 2008 March 24, 2008 Target Category: Informational Filename Preservation for EDIINT Protocol 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. 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 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 RFC 2119. 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 filename for EDI business documents to trigger specific backend processing. So it is Harding [Page 1]
INTERNET DRAFT Filename Preservation for EDIINT Protocol September 2008 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. 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 Harding [Page 2]
INTERNET DRAFT Filename Preservation for EDIINT Protocol September 2008 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 2822], 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 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 2822 `date-time' ; numeric timezones (+HHMM or -HHMM) MUST be used Harding [Page 3]
INTERNET DRAFT Filename Preservation for EDIINT Protocol September 2008 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 2822] in the definition of some of these tokens). `quoted-string' and `DIGIT' are defined in [RFC 2822]. 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 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. Harding [Page 4]
INTERNET DRAFT Filename Preservation for EDIINT Protocol September 2008 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 6. IANA Considerations This document has no actions for IANA. 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. Harding [Page 5]
INTERNET DRAFT Filename Preservation for EDIINT Protocol September 2008 [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, RFC 4823, August 2007. [MA] K. Meadors, Multiple Attachments for EDI-INT, draft-meadors-multiple-attachments-ediint-05.txt, August 2007 [RFC 2822] Internet Message Format, P. Resnick, RFC 2822, April 2001 [RFC 2045] Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, N. Freed, N. Borenstein, RFC 2045, November 1996 [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 2184, August 1997 Disclaimer 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, THE IETF TRUST 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. Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Intellectual Property 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 Harding [Page 6]
INTERNET DRAFT Filename Preservation for EDIINT Protocol September 2008 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. Expires September 2008 Harding [Page 7]