doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

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]
+