• Aucun résultat trouvé

The EDIINT-Features header field provides a means to resolve these problems and support new functionality

N/A
N/A
Info
Télécharger
Protected

Academic year: 2022

Partager "The EDIINT-Features header field provides a means to resolve these problems and support new functionality"

Copied!
5
0
0

Chargement.... (Voir le texte intégral maintenant)

Texte intégral

(1)

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.

(2)

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

(3)

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

(4)

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.

(5)

Author’s Address

Kyle Meadors (editor) Drummond Group Inc.

Nashville, Tennessee 37221 US

Phone: +1 (817) 709-1627 EMail: kyle@drummondgroup.com

Références

Télécharger maintenant ( PDF - 5 Page - 8.64 KB )

Documents relatifs

Clear Header - The header portion of the Clear Datagram before Encapsulation

If it is decided that the DF bit should be used, then ICMP message would be returned if the Encapsulated Datagram required fragmentation across the Encapsulation Space

NEW FEATURES OF THE LANGUAGE 1

This routine utilizes the same parameters as the input call, but operates on the output stream. The TRUE/FALSE flag is not distributed by this operator. As for input, there are

The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header

If ECN-Echo is not set, the receiver claims to have received no marked packets, and can therefore compute and return the correct nonce sum.. To conceal a mark, the receiver

This information is conveyed as parameters of the Contact header field

To construct a set of Contact header field parameters that indicate capabilities, a UA constructs a feature predicate for that contact.. This process is described in terms of

These extensions include the use of pointers to Uniform Resource Identifier (URI) lists in the Refer-To header field and the "multiple-refer&#34

Consequently, a SIP REFER-Issuer generating a REFER request with multiple REFER-Targets SHOULD include the "norefersub" option-tag in a Require header field and

The extension defines a general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent

The Presentation Status of the top-most ISDN Redirecting Number information element SHOULD be used to set the value of the diversion-privacy of the bottom-most

This document describes a recommended interworking guideline between the Diversion header and the History-Info header to handle call diversion information

If the History-Info header contains other information, then only the information of concern to the diverting user must be used to create entries in the Diversion header and

The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example

The user agent processing model defined in Section 8 ("User Agent Processing Model") stipulates that a host is initially noted as a Known HSTS Host, or that updates