Independent Submission K. Meadors, Ed. Request for Comments: 6017 Drummond Group Inc. Category: Informational September 2010 ISSN: 2070-1721Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field
Meadors Informational [Page 1]
RFC 6017 September 2010
Table of Contents
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.
Meadors Informational [Page 2]
RFC 6017 September 2010 3. Implementation and ProcessingThe 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.
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.
5. IANA Considerations
IANA has registered the following provisional header.
Meadors Informational [Page 3]
RFC 6017 September 2010
Author/Change controller: Kyle Meadors of Drummond Group (kyle@drummondgroup.com)
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
Meadors Informational [Page 4]
RFC 6017 September 2010
Author's Address