RFC 6017

Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field

📅 published September 2010, from ietf

Title Block 💖

Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field 🎀

  • RFC number: 6017
  • Authors: K. Meadors, Ed. (Kyle Meadors, editor), Drummond Group Inc.
  • Category: Informational, published as an Independent Submission 💅
  • Date: September 2010
  • ISSN: 2070-1721
  • Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates ✨

Abstract

okay so AS1, AS2, and AS3 are the EDIINT standards for sending secure data over the transport, and they've matured SO much that people are building extra features right on top of them 🔥 the thing is, not every EDIINT app supports those extras, and that can cause real problems when you're implementing stuff. the EDIINT-Features header field is the fix. it's the way to handle those problems and roll out new functionality 🦋

Status of This Memo

this one is NOT an Internet Standards Track spec, it's just being shared for info 🌸

it's an independent contribution to the RFC Series, separate from any other RFC stream. the RFC Editor picked it to publish at their discretion and doesn't say anything about whether it's worth implementing or deploying. documents the RFC Editor approves aren't candidates for any level of Internet Standard (see Section 2 of RFC 5741) 🧚

if you want the current status, errata, or a way to leave feedback, check http://www.rfc-editor.org/info/rfc6017 💜

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

this doc is under BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. read those carefully, because they spell out your rights and restrictions for this doc 🫶

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 apps give you a secure way to transport payload documents 🔒 the original plan was just moving one EDI or XML document at a time. but then AS1 [RFC3335], AS2 [RFC4130], and AS3 [RFC4823] matured, and people started layering other features and app logic on top of EDIINT 🍓 these extras go beyond the basic EDIINT premise without breaking it, so there needs to be a way to tell trading partners which features the originating user agent supports. that's what the EDIINT-Features header does: it says what the user agent can handle with its trading partner, no out-of-band chat or separate agreement needed 💅

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 show up in the header section of an AS1, AS2, or AS3 message. here's its ABNF [RFC5234] syntax:

   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

Feature-Token is how feature names get specified, and it's giving very strict 💀 only letters, digits, and the hyphen. feature names are case insensitive, so no stress about capitals 🌸

3. Implementation and Processing 🔥

the EDIINT-Features header field tells everyone that the originating user agent can support the features it lists. the EDIINT-Features header field MUST be present in every message the user agent sends, not just the ones that use a feature 🫶 when the trading partner looks at the header, they SHOULD assume the user agent can receive messages using any of the listed features 👑

features that use the EDIINT-Features header field MUST be specified in RFCs. those RFCs MUST describe the feature name listed in the header and how it's supposed to be used ✨

4. EDIINT Applications 🦋

AS2 and AS3 apps currently use a version header to show what they can do: AS2-Version and AS3-Version. the EDIINT-Features header field is a huge upgrade on the old version header 😭 but to connect the two, AS2 and AS3 apps that implement EDIINT-Features MUST use the version value "1.2" to show they support it. also, version "1.1" means the implementation supports compression [RFC5402], and "1.2" builds on "1.1". so an AS2-Version or AS3-Version of "1.2" MUST support compression, even if the EDIINT-Features header doesn't list it as a feature 🧚

AS1 doesn't use a version header, and one isn't required for including the EDIINT-Features header field 🌈

the EDIINT-Features header is informational. AS1, AS2, or AS3 trading partners who haven't implemented it can safely ignore it 💜

5. 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
   (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 🙈

⚠️ headers are often un-encrypted, so the EDIINT-Features header field might be possible to alter. trading partners MAY check with each other 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.

Author's Address 🧸

   Kyle Meadors (editor)
   Drummond Group Inc.
   Nashville, Tennessee  37221
   US

   Phone: +1 (817) 709-1627
   EMail: kyle@drummondgroup.com
📦 where this page comes from