1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
|
