Internet Draft Editor: Terry Harding
draft-harding-ediint-filename-preservation-02.txt Axway
Expires April 2010
Target Category: Informational
Creation Date: October 02, 2009
Filename Preservation for EDIINT
Status of this memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document. Code Components extracted from this document must include
Simplified BSD License text as described in Section 4.e of the Trust
Legal Provisions and are provided without warranty as described in the
BSD License.
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.
Harding [Page 1]
INTERNET DRAFT Filename Preservation for EDIINT Protocol April 2010
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.
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
filename for the EDI business document.
Harding [Page 2]
INTERNET DRAFT Filename Preservation for EDIINT Protocol April 2010
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 5322], 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 5322 `date-time'
; numeric timezones (+HHMM or -HHMM) MUST be used
NOTE ON PARAMETER VALUE LENGTHS: A short (length <= 78 characters)
Harding [Page 3]
INTERNET DRAFT Filename Preservation for EDIINT Protocol April 2010
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 5322] in the
definition of some of these tokens). `quoted-string' and `DIGIT'
are defined in [RFC 5322].
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 5322, 2045, 2046, 2047,
2048 and 2049.
3.1 Filenames
Harding [Page 4]
INTERNET DRAFT Filename Preservation for EDIINT Protocol April 2010
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 2231
RFC 2231 states that parameter values longer than 78 characters, or
which contain non-ASCII characters, MUST be encoded as specified in
[RFC 2231].
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
Phoenix, 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.
Harding [Page 5]
INTERNET DRAFT Filename Preservation for EDIINT Protocol April 2010
[AS3] T. Harding, R. Scott, FTP Transport for Secure Peer-to-Peer
Business Data Interchange over the Internet,
RFC 4823, April 2007.
[MA] K. Meadors, Multiple Attachments for EDI-INT,
draft-meadors-multiple-attachments-ediint-08.txt, September 2009
[RFC 2045] N. Freed, N. Borenstein, Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies
RFC 2045, November 1996.
[RFC 5322] P. Resnick, Internet Message Format,
RFC 5322, October 2008
[RFC 2183] R. Troost, S. Dorner, K. Moore, Communicating Presentation
Information in Internet Messages: The Content-Disposition
Header Field, RFC 2183, August 1997
[RFC 2231] N. Freed, K. Moore, MIME Parameter Value and Encoded Word
Extensions: Character Sets, Languages, and Continuations,
RFC 2231, November 1997
Acknowledgments
Copyright Statement
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust?s Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document. Code Components extracted from this document must include
Simplified BSD License text as described in Section 4.e of the Trust
Legal Provisions and are provided without warranty as described in the
BSD License.
Disclaimer
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
Harding [Page 6]
INTERNET DRAFT Filename Preservation for EDIINT Protocol April 2010
works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English.
Expires April 2010
Harding [Page 7]