From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6017.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc6017.txt (limited to 'doc/rfc/rfc6017.txt') diff --git a/doc/rfc/rfc6017.txt b/doc/rfc/rfc6017.txt new file mode 100644 index 0000000..d1f6382 --- /dev/null +++ b/doc/rfc/rfc6017.txt @@ -0,0 +1,283 @@ + + + + + + +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. + + + + + +Meadors Informational [Page 1] + +RFC 6017 September 2010 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 + 2. EDIINT-Features Header Syntax . . . . . . . . . . . . . . . . . 2 + 3. Implementation and Processing . . . . . . . . . . . . . . . . . 3 + 4. EDIINT Applications . . . . . . . . . . . . . . . . . . . . . . 3 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 + 7. Normative References . . . . . . . . . . . . . . . . . . . . . 4 + +1. 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. + +1.1. 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]. + +2. 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 + + + + + +Meadors Informational [Page 2] + +RFC 6017 September 2010 + + + 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. + +3. 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. + +4. 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. + +5. IANA Considerations + + IANA has registered the following provisional header. + + Header field name: EDIINT-Features + + Applicable protocol: http and mail + + + + +Meadors Informational [Page 3] + +RFC 6017 September 2010 + + + Status: provisional + + Author/Change controller: Kyle Meadors of Drummond Group + (kyle@drummondgroup.com) + + 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). + +6. 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. + +7. 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. + + + + + + + + + + + +Meadors Informational [Page 4] + +RFC 6017 September 2010 + + +Author's Address + + Kyle Meadors (editor) + Drummond Group Inc. + Nashville, Tennessee 37221 + US + + Phone: +1 (817) 709-1627 + EMail: kyle@drummondgroup.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Meadors Informational [Page 5] + -- cgit v1.2.3