Difference between revisions of "RFC6017"
| Line 27: | Line 27: | ||
implementation or deployment. Documents approved for publication by | implementation or deployment. Documents approved for publication by | ||
the RFC Editor are not a candidate for any level of Internet | the RFC Editor are not a candidate for any level of Internet | ||
| − | Standard; see Section 2 of RFC 5741. | + | Standard; see Section 2 of [[RFC5741|RFC 5741]]. |
Information about the current status of this document, any errata, | Information about the current status of this document, any errata, | ||
| Line 38: | Line 38: | ||
document authors. All rights reserved. | document authors. All rights reserved. | ||
| − | This document is subject to BCP 78 and the IETF Trust's Legal | + | This document is subject to [[BCP78|BCP 78]] and the IETF Trust's Legal |
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | ||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | ||
| Line 49: | Line 49: | ||
EDIINT applications provide for a secure means of payload document | EDIINT applications provide for a secure means of payload document | ||
transport. The original intent was for transport of a single EDI or | transport. The original intent was for transport of a single EDI or | ||
| − | XML document. However, as AS1 | + | XML document. However, as AS1 [[RFC3335]], AS2 [[RFC4130]], and AS3 |
| − | + | [[RFC4823]] matured, other features and application logic were | |
implemented upon EDIINT standards. Since these features go beyond | implemented upon EDIINT standards. Since these features go beyond | ||
(but do not violate) the basic premise of EDIINT, a means is needed | (but do not violate) the basic premise of EDIINT, a means is needed | ||
| Line 62: | Line 62: | ||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||
| − | document are to be interpreted as described in RFC 2119 | + | document are to be interpreted as described in [[RFC2119|RFC 2119]] [[RFC2119]]. |
== EDIINT-Features Header Syntax == | == EDIINT-Features Header Syntax == | ||
The EDIINT-Features header can appear in the header section of an | The EDIINT-Features header can appear in the header section of an | ||
| − | AS1, AS2, and AS3 message. Its ABNF | + | AS1, AS2, and AS3 message. Its ABNF [[RFC5234]] syntax is listed |
below. | below. | ||
| Line 109: | Line 109: | ||
MUST use the version value of "1.2" to indicate the support of the | MUST use the version value of "1.2" to indicate the support of the | ||
EDIINT-Features header field. Also, since version "1.1" indicates | EDIINT-Features header field. Also, since version "1.1" indicates | ||
| − | the implementation supports compression | + | the implementation supports compression [[RFC5402]] and "1.2" builds |
upon "1.1", AS2-Version or AS3-Version of "1.2" MUST support | upon "1.1", AS2-Version or AS3-Version of "1.2" MUST support | ||
compression regardless of whether it is mentioned as a feature in the | compression regardless of whether it is mentioned as a feature in the | ||
| Line 137: | Line 137: | ||
Related information: This header will be used in conjunction with the | Related information: This header will be used in conjunction with the | ||
| − | EDIINT WG specifications RFC 4130 (AS2), RFC 3335 (AS1) and RFC 4823 | + | EDIINT WG specifications [[RFC4130|RFC 4130]] (AS2), [[RFC3335|RFC 3335]] (AS1) and [[RFC4823|RFC 4823]] |
(AS3). | (AS3). | ||
| Line 148: | Line 148: | ||
== Normative References == | == Normative References == | ||
| − | + | [[RFC2119]] Bradner, S., "Key words for use in RFCs to Indicate | |
| − | Requirement Levels", BCP 14, RFC 2119, March 1997. | + | Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]], March 1997. |
| − | + | [[RFC3335]] Harding, T., Drummond, R., and C. Shih, "MIME-based Secure | |
Peer-to-Peer Business Data Interchange over the Internet", | Peer-to-Peer Business Data Interchange over the Internet", | ||
| − | RFC 3335, September 2002. | + | [[RFC3335|RFC 3335]], September 2002. |
| − | + | [[RFC4130]] Moberg, D. and R. Drummond, "MIME-Based Secure Peer-to- | |
Peer Business Data Interchange Using HTTP, Applicability | Peer Business Data Interchange Using HTTP, Applicability | ||
| − | Statement 2 (AS2)", RFC 4130, July 2005. | + | Statement 2 (AS2)", [[RFC4130|RFC 4130]], July 2005. |
| − | + | [[RFC4823]] Harding, T. and R. Scott, "FTP Transport for Secure Peer- | |
to-Peer Business Data Interchange over the Internet", RFC | to-Peer Business Data Interchange over the Internet", RFC | ||
4823, April 2007. | 4823, April 2007. | ||
| − | + | [[RFC5234]] Crocker, D. and P. Overell, "Augmented BNF for Syntax | |
| − | Specifications: ABNF", STD 68, RFC 5234, January 2008. | + | Specifications: ABNF", [[STD68|STD 68]], [[RFC5234|RFC 5234]], January 2008. |
| − | + | [[RFC5402]] Harding, T., Ed., "Compressed Data within an Internet | |
| − | Electronic Data Interchange (EDI) Message", RFC 5402, | + | Electronic Data Interchange (EDI) Message", [[RFC5402|RFC 5402]], |
February 2010. | February 2010. | ||
Latest revision as of 01:45, 22 October 2020
Independent Submission K. Meadors, Ed. Request for Comments: 6017 Drummond Group Inc. Category: Informational September 2010 ISSN: 2070-1721
Electronic Data Interchange - Internet Integration (EDIINT)
Features Header Field
Abstract
With the maturity of the Electronic Data Interchange - Internet Integration (EDIINT) standards of AS1, AS2, and AS3, applications and additional features are being built upon the basic secure transport functionality. These features are not necessarily supported by all EDIINT applications and could cause potential problems with implementations. The EDIINT-Features header field provides a means to resolve these problems and support new functionality.
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6017.
Copyright Notice
Copyright (c) 2010 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.
Contents
Introduction
EDIINT applications provide for a secure means of payload document transport. The original intent was for transport of a single EDI or XML document. However, as AS1 RFC3335, AS2 RFC4130, and AS3 RFC4823 matured, other features and application logic were implemented upon EDIINT standards. Since these features go beyond (but do not violate) the basic premise of EDIINT, a means is needed to communicate to trading partners features that are supported by the originating user agent. The EDIINT-Features header indicates the capability of the user agent to support the listed feature with its trading partner without out-of-band communication and agreement.
Requirements Language
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 RFC2119.
EDIINT-Features Header Syntax
The EDIINT-Features header can appear in the header section of an AS1, AS2, and AS3 message. Its ABNF RFC5234 syntax is listed below.
Feature = "EDIINT-Features:" [WSP] Feature-Name *([WSP] ","
[WSP] Feature-Name)
Feature-Name = 1*Feature-Token
Feature-Token = %d48-57 / ; 0-9
%d65-90 / ; A-Z
%d97-122 / ; a-z
"-" ; hyphen is allowed
; blank space " " is not allowed
The Feature-Token allows for feature names to be specified and can only contain alphanumeric characters along with the hyphen. Feature names are case insensitive.
Implementation and Processing
The EDIINT-Features header field indicates the originating user agent is capable of supporting the features listed. The EDIINT-Features header field MUST be present in all messages transmitted by the user agent and not just messages that utilize the feature. Upon examination of the EDIINT-Features header field, the trading partner SHOULD assume the user agent is capable of receiving messages utilizing any of the features listed.
Features that utilize the EDIINT-Features header field MUST be specified in RFCs. These RFCs MUST describe the feature name that is listed in the header and the means by which it should be used.
EDIINT Applications
AS2 and AS3 applications currently use a version header, AS2-Version and AS3-Version, respectively, to indicate functional support. The EDIINT-Features header field tremendously improves the purpose and function of the old version header. However, to provide a connection from the old version header and the EDIINT-Features header field, AS2 and AS3 applications that implement the EDIINT-Features header field MUST use the version value of "1.2" to indicate the support of the EDIINT-Features header field. Also, since version "1.1" indicates the implementation supports compression RFC5402 and "1.2" builds upon "1.1", AS2-Version or AS3-Version of "1.2" MUST support compression regardless of whether it is mentioned as a feature in the EDIINT-Features header field.
AS1 does not use a version header and one is not required for including the EDIINT-Features header field.
The EDIINT-Features header field is informational, and AS1, AS2, or AS3 trading partners who have not implemented it can safely ignore this header.
IANA Considerations
IANA has registered the following provisional header.
Header field name: EDIINT-Features
Applicable protocol: http and mail
Status: provisional
Author/Change controller: Kyle Meadors of Drummond Group ([email protected])
Specification document(s): this document
Related information: This header will be used in conjunction with the EDIINT WG specifications RFC 4130 (AS2), RFC 3335 (AS1) and RFC 4823 (AS3).
Security Considerations
Because headers are often un-encrypted, it may be possible for the EDIINT-Features header field to be altered. Trading partners MAY consult out-of-band to confirm feature support.
Normative References
RFC2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC3335 Harding, T., Drummond, R., and C. Shih, "MIME-based Secure
Peer-to-Peer Business Data Interchange over the Internet",
RFC 3335, September 2002.
RFC4130 Moberg, D. and R. Drummond, "MIME-Based Secure Peer-to-
Peer Business Data Interchange Using HTTP, Applicability
Statement 2 (AS2)", RFC 4130, July 2005.
RFC4823 Harding, T. and R. Scott, "FTP Transport for Secure Peer-
to-Peer Business Data Interchange over the Internet", RFC
4823, April 2007.
RFC5234 Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
RFC5402 Harding, T., Ed., "Compressed Data within an Internet
Electronic Data Interchange (EDI) Message", RFC 5402, February 2010.
Author's Address
Kyle Meadors (editor) Drummond Group Inc. Nashville, Tennessee 37221 US
Phone: +1 (817) 709-1627 EMail: [email protected]
