idnits 2.17.1 draft-meadors-ediint-features-header-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 15, 2010) is 5062 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission K. Meadors, Ed. 3 Internet-Draft Drummond Group Inc. 4 Intended status: Informational June 15, 2010 5 Expires: December 17, 2010 7 EDI-INT Features Header 8 draft-meadors-ediint-features-header-09 10 Abstract 12 With the maturity of the EDI-INT standards of AS1, AS2 and AS3, 13 applications and additional features are being built upon the basic 14 secure transport functionality. These features are not necessarily 15 supported by all EDI-INT applications and could cause potential 16 problems with implementations. The EDIINT Features header provides a 17 means to resolve these problems and support new functionality. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 17, 2010. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 67 2. EDIINT Features Header Syntax . . . . . . . . . . . . . . . . . 3 68 3. Implementation and Processing . . . . . . . . . . . . . . . . . 3 69 4. EDI-INT Applications . . . . . . . . . . . . . . . . . . . . . 4 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 72 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 1. Introduction 77 EDI-INT applications provide for a secure means of payload document 78 transport. The original intent was for transport of a single EDI or 79 XML document. However, as AS1 [RFC3335], AS2 [RFC4130] and AS3 80 [RFC4823] matured, other features and application logic were 81 implemented upon EDI-INT standards. Since these features go beyond 82 but do not violate the basic premise of EDI-INT, a means is needed to 83 communicate to trading partners features which are supported by the 84 originating user agent. The EDIINT Features header indicates the 85 capability of the user agent to support the listed feature with its 86 trading partner without out-of-band communication and agreement. 88 1.1. Requirements Language 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 2. EDIINT Features Header Syntax 96 The EDIINT Features header can appear in the header section of an 97 AS1, AS2 and AS3 message. Its ABNF [RFC5234] syntax is listed below. 99 Feature = "EDIINT-Features:" [WSP] Feature-Name *([WSP] "," [WSP] 100 Feature-Name) 102 Feature-Name = 1*Feature-Token 104 Feature-Token= %d48-57 / ; 0-9 105 %d65-90 / ; A-Z 106 %d97-122 / ; a-z 107 "-" ; blank space " " is not allowed 109 The Feature-Token allows for feature names to be specified and can 110 only contain alphanumeric characters along with the hyphen. Feature 111 names are case-insensitive. 113 3. Implementation and Processing 115 The EDIINT Features header indicates the originating user agent is 116 capable of supporting the features listed. The EDIINT Features 117 header MUST be present in all messages transmitted by the user agent 118 and not just messages which utilize the feature. Upon examination of 119 the EDIINT Features header, the trading partner SHOULD assume the 120 user agent is capable of receiving messages utilizing any of the 121 features listed. 123 The features listed MUST be supported by IETF RFC standards. These 124 standards MUST describe the feature name which is listed in the 125 header and the means which it should be used. 127 4. EDI-INT Applications 129 AS2 and AS3 applications currently use a version header, AS2-Version 130 and AS3-Version, respectively, to indicate functional support. The 131 EDIINT Features header tremendously improves the purpose and function 132 of the old version header. However, to provide a connection from the 133 old version header and the EDIINT Features header, AS2 and AS3 134 applications which implement the EDIINT Features header MUST use the 135 version value of "1.2" to indicate the support of the EDIINT Features 136 header. Also, since version "1.1" indicates the implementation 137 supports compression [RFC5402] and "1.2" builds upon "1.1", AS2- 138 Version or AS3-Version of "1.2" MUST support compression regardless 139 of whether it is mentioned as a feature in the EDIINT Features 140 header. 142 AS1 does not use a version header and one is not required for 143 including the EDIINT-Features header. 145 The EDIINT Features header is informational and AS1, AS2 or AS3 146 trading partners who have not implemented it can safely ignore this 147 header. 149 5. IANA Considerations 151 This is a request for a provisional header registration. 153 Header field name: EDIINT-Features 155 Applicable protocol: http and mail 157 Status: provisional 159 Author/Change controller: Kyle Meadors of Drummond Group 160 (kyle@drummondgroup.com) 162 Specification document(s): https://datatracker.ietf.org/doc/ 163 draft-meadors-ediint-features-header/ 165 Related information: This header will be used in conjection with the 166 EDIINT WG specifications RFC 4130 (AS2), RFC 3335 (AS1) and RFC 4823 167 (AS3). 169 6. Security Considerations 171 Because headers are often un-encrypted, it may be possible for the 172 EDIINT Features header to be altered. Trading partners MAY consult 173 out-of- band to confirm feature support. 175 7. Normative References 177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 178 Requirement Levels", BCP 14, RFC 2119, March 1997. 180 [RFC3335] Harding, T., Drummond, R., and C. Shih, "MIME-based Secure 181 Peer-to-Peer Business Data Interchange over the Internet", 182 RFC 3335, September 2002. 184 [RFC4130] Moberg, D. and R. Drummond, "MIME-Based Secure Peer-to- 185 Peer Business Data Interchange Using HTTP, Applicability 186 Statement 2 (AS2)", RFC 4130, July 2005. 188 [RFC4823] Harding, T. and R. Scott, "FTP Transport for Secure Peer- 189 to-Peer Business Data Interchange over the Internet", 190 RFC 4823, April 2007. 192 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 193 Specifications: ABNF", STD 68, RFC 5234, January 2008. 195 [RFC5402] Harding, T., "Compressed Data within an Internet 196 Electronic Data Interchange (EDI) Message", RFC 5402, 197 February 2010. 199 Author's Address 201 Kyle Meadors (editor) 202 Drummond Group Inc. 203 Nashville, Tennessee 37221 204 US 206 Phone: +1 (817) 709-1627 207 Email: kyle@drummondgroup.com