Independent Submission K. Meadors, Ed.
Request for Comments: 6017 Drummond Group Inc.
Category: Informational September 2010
ISSN: 2070-1721
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
电子数据交换.因特网集成（EDIINT）特征头字段
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.
随着AS1、AS2和AS3的电子数据交换-互联网集成（EDIINT）标准的成熟，应用程序和附加功能正在基本安全传输功能的基础上构建。并非所有EDIINT应用程序都必须支持这些功能，它们可能会导致实现中的潜在问题。EDIINT Features标头字段提供了解决这些问题并支持新功能的方法。
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.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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
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.
EDIINT应用程序提供了一种安全的有效负载文档传输方式。最初的目的是传输单个EDI或XML文档。然而，随着AS1[RFC3335]、AS2[RFC4130]和AS3[RFC4823]的成熟，其他功能和应用程序逻辑都是根据EDIINT标准实现的。由于这些功能超出了（但不违反）EDIINT的基本前提，因此需要一种与贸易伙伴沟通的方式，以了解原始用户代理所支持的功能。EDIINT Features标头表示用户代理与其贸易伙伴在无带外通信和协议的情况下支持所列功能的能力。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The EDIINT-Features header can appear in the header section of an AS1, AS2, and AS3 message. Its ABNF [RFC5234] syntax is listed below.
EDIINT Features标题可以出现在AS1、AS2和AS3消息的标题部分。其ABNF[RFC5234]语法如下所示。
Feature = "EDIINT-Features:" [WSP] Feature-Name *([WSP] "," [WSP] Feature-Name)
Feature=“EDIINT Features:”[WSP]功能名称*（[WSP]”，“[WSP]功能名称）
Feature-Name = 1*Feature-Token
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 = %d48-57 / ; 0-9
%d65-90 / ; A-Z
%d97-122 / ; a-z
"-" ; hyphen is allowed
; blank space " " is not allowed
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.
功能标记允许指定功能名称，并且只能包含字母数字字符和连字符。功能名称不区分大小写。
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.
EDIINT Features标头字段表示发起用户代理能够支持列出的功能。EDIINT Features标头字段必须出现在用户代理传输的所有消息中，而不仅仅是使用该功能的消息。在检查EDIINT Features标头字段后，贸易伙伴应假设用户代理能够使用列出的任何功能接收消息。
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.
必须在RFCs中指定使用EDIINT Features标头字段的功能。这些RFC必须描述标题中列出的功能名称及其使用方法。
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.
AS2和AS3应用程序目前分别使用版本头、AS2版本和AS3版本来表示功能支持。EDIINT Features标头字段极大地改进了旧版本标头的用途和功能。但是，要提供从旧版本标头和EDIINT功能标头字段的连接，实现EDIINT功能标头字段的AS2和AS3应用程序必须使用版本值“1.2”来指示对EDIINT功能标头字段的支持。此外，由于版本“1.1”表示实现支持压缩[RFC5402]，并且“1.2”构建在“1.1”的基础上，“1.2”的AS2版本或AS3版本必须支持压缩，无论它是否在EDIINT Features标头字段中作为功能提及。
AS1 does not use a version header and one is not required for including the EDIINT-Features header field.
AS1不使用版本标头，并且不需要包含EDIINT Features标头字段。
The EDIINT-Features header field is informational, and AS1, AS2, or AS3 trading partners who have not implemented it can safely ignore this header.
EDIINT Features标头字段是信息性字段，未实施此字段的AS1、AS2或AS3贸易伙伴可以安全地忽略此标头。
IANA has registered the following provisional header.
IANA已注册以下临时标题。
Header field name: EDIINT-Features
标题字段名称：EDIINT功能
Applicable protocol: http and mail
适用协议：http和mail
Status: provisional
现状：临时
Author/Change controller: Kyle Meadors of Drummond Group
(kyle@drummondgroup.com)
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).
相关信息：此标题将与EDIINT WG规范RFC 4130（AS2）、RFC 3335（AS1）和RFC 4823（AS3）一起使用。
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.
由于标头通常未加密，因此可能会更改EDIINT Features标头字段。贸易伙伴可咨询带外以确认功能支持。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3335] Harding, T., Drummond, R., and C. Shih, "MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet", RFC 3335, September 2002.
[RFC3335]Harding，T.，Drummond，R.，和C.Shih，“互联网上基于MIME的安全对等业务数据交换”，RFC 3335，2002年9月。
[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.
[RFC4130]Moberg，D.和R.Drummond，“使用HTTP的基于MIME的安全对等业务数据交换，适用性声明2（AS2）”，RFC 4130，2005年7月。
[RFC4823] Harding, T. and R. Scott, "FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet", RFC 4823, April 2007.
[RFC4823]Harding，T.和R.Scott，“互联网上安全对等业务数据交换的FTP传输”，RFC 4823，2007年4月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5402] Harding, T., Ed., "Compressed Data within an Internet Electronic Data Interchange (EDI) Message", RFC 5402, February 2010.
[RFC5402]Harding，T.，Ed.“互联网电子数据交换（EDI）报文中的压缩数据”，RFC 5402，2010年2月。
Author's Address
作者地址
Kyle Meadors (editor) Drummond Group Inc. Nashville, Tennessee 37221 US
Kyle Meadors（编辑）德拉蒙德集团公司，美国田纳西州纳什维尔37221
Phone: +1 (817) 709-1627
EMail: kyle@drummondgroup.com
Phone: +1 (817) 709-1627
EMail: kyle@drummondgroup.com