From owner-ietf-ediint@mail.imc.org Mon Mar 06 16:50:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGNb4-0007vp-EN for ediint-archive@lists.ietf.org; Mon, 06 Mar 2006 16:50:30 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGNMx-0008EU-2l for ediint-archive@lists.ietf.org; Mon, 06 Mar 2006 16:35:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGNHZ-0005LW-Bz for ediint-archive@lists.ietf.org; Mon, 06 Mar 2006 16:30:26 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k26LIsOn027347; Mon, 6 Mar 2006 14:18:54 -0700 (MST) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k26LIsW6027346; Mon, 6 Mar 2006 14:18:54 -0700 (MST) (envelope-from owner-ietf-ediint@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from cypress.neustar.com (cypress.neustar.com [209.173.57.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k26LIrjP027321 for ; Mon, 6 Mar 2006 14:18:53 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k26LIl0e011764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Mar 2006 21:18:47 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGN6N-0007fG-EL; Mon, 06 Mar 2006 16:18:47 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ediint mailing list , ediint chair Subject: Document Action: 'FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet' to Informational RFC Message-Id: Date: Mon, 06 Mar 2006 16:18:47 -0500 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: -2.6 (--) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 The IESG has approved the following document: - 'FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet ' as an Informational RFC This document is the product of the Electronic Data Interchange-Internet Integration Working Group. The IESG contact persons are Scott Hollenbeck and Ted Hardie. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ediint-as3-04.txt Technical Summary This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content-types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message. Working Group Summary This document was once considered a candidate for Proposed Standard status. It is instead being evaluated for publication as an Informational RFC to document existing implementations as the level of participation in the EDIINT working group has decreased significantly over time. Protocol Quality Scott Hollenbeck has reviewed this specification for the IESG. Multiple implementations have been described in working group mailing list discussions. Note to the RFC Editor Please add a normative reference to RFC 2119. Please cite this reference at the end of section 1. Please replace the citation and normative reference to [MURRAY] with a normative reference to RFC 4217. Please replace citations and references to RFCs 2630, 2632, and 2633 with citations and references to RFCs 3852, 3850, and 3851, respectively. Please replace all occurrences of "S/MIME Version 3" with "S/MIME Version 3.1". Please add a definition to section 2.3.1: AS3: Applicability Statement 3. This is the third applicability statement produced by the IETF EDIINT working group. From owner-ietf-ediint@mail.imc.org Tue Mar 07 12:26:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfxS-0001YE-UW for ediint-archive@lists.ietf.org; Tue, 07 Mar 2006 12:26:50 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGfxS-00038G-2I for ediint-archive@lists.ietf.org; Tue, 07 Mar 2006 12:26:50 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k27HBNkY087968; Tue, 7 Mar 2006 10:11:23 -0700 (MST) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k27HBN8g087967; Tue, 7 Mar 2006 10:11:23 -0700 (MST) (envelope-from owner-ietf-ediint@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from mail1.cyclonecommerce.com (mail1.cyclonecommerce.com [216.138.89.185]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k27HBKbV087947 for ; Tue, 7 Mar 2006 10:11:20 -0700 (MST) (envelope-from dmoberg@cyclonecommerce.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6420A.23ACCB7F" Subject: AS2 Reliability and an issue for comment. Date: Tue, 7 Mar 2006 10:11:14 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AS2 Reliability and an issue for comment. Thread-Index: AcZCCiOZdU8GRSf+Suqouz7/J9OgNg== From: "Dale Moberg" To: Cc: Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: 2f46977da373544777a750d5247d6ccc This is a multi-part message in MIME format. ------_=_NextPart_001_01C6420A.23ACCB7F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are several residual Internet-Drafts under review by the Ediint vender and user community that are responding to industry requests for standardization. Most of these Internet-Drafts are informational RFCs and not "official" Ediint chartered efforts. Examples include drafts on Compression, the Features header, Certificate Exchange messages (CEM), filename transmission, multipart payload support, and Reliability for AS2. The question here concerns a small but important point in the AS2 reliability draft. =20 AS2 has an option for either synchronous or asynchronous MDNs. The issue for comment is concerned with synchronous MDN mode. =20 Most venders have attempted to provide for some recovery from network and/or server failures, and also to protect their customers from resource exhaustion. When synchronous MDNs are used to transfer large amounts of business data with compression, digital signatures, and encryption applied to that data, heavily loaded systems can take a large amount of time to produce the MDN to send back in the HTTP response. The HTTP connection then needs to be held open for an unpredictable amount of time, using resources on both sides.=20 =20 Now, because it is possible for an AS2 application to become "hung" on the server side, software engineers often build in a "timer" that closes a connection after some period of time. Unfortunately, the timeout can occur before the HTTP requester (client) has received the protocol's HTTP response. In addition, sometimes various HTTP intermediaries (tunnels/proxies/gateways/etc) may time out a connection along the path from client to final HTTP server based on "inactivity," and again prevent the completion of the HTTP protocol.=20 =20 These exceptional conditions may be tied to an exception handler that retries the HTTP request with its large payload. More often than not, this retry of a large payload to an ever increasingly loaded server is a recipe for further failure (and retry). Because AS2 payloads are growing from the tens to hundreds of megabytes, and the AS2 traffic on existing servers is growing, the "timeout/retry" spiral has become an operational difficulty for AS2 systems that needs consideration. =20 The AS2 specification does have a built-in solution for this problem-asynchronous MDN mode. However, users have indicated an interest in whether there is anything else that might be done to address the timeout problem and make AS2 in synchronous MDN mode more reliable. =20 One direction is to try to make the timeout interval value "flexible" and adapt it intelligently. While both transmission time and payload size are known to the sender, the receiver load (often the most critical factor) is not known. So it becomes difficult to arrive at an intelligent solution that will not sometimes be wrong, which tends to not satisfy AS2 endusers. =20 Another direction might be to prohibit timeouts. This solution would remove protections against tying up resources (both on sender and receiver sides) in the really exceptional situations of a hung or dead thread/process that did not clean up with an appropriate HTTP status code (5xx range). Again there would be resistance to the adoption of this solution by developers and engineers. =20 Another direction might be to prohibit retries when using synchronous MDNs. This direction effectively gives up on AS2 reliability. When the specific error condition is recoverable (server down, connection refused, transient network error, server temporarily busy), then retry can be a reasonable way to enhance automation and reduce the need for operational intervention and special manual handling. =20 If the basic problem of the "timeout/retry" spiral is that there is no way to tell intermediaries or the client that there is forward progress being made on completing the HTTP response, then one remaining direction is to provide a forward progress indicator. The HTTP protocol does have an option for providing this feature that takes advantage of the HTTP response "100 continue" status. In other words, a HTTP server can be configured to send a sequence of "100 continue" replies, and a HTTP 1.1 client is effectively instructed to wait for a reply in the success range ("2xx") or possibly failure ("5xx"). [ 3xx and 4xx cases ignored here for simplicity-these statuses should be given as an initial HTTP response IMO.] This solution does not magically create resources when they are falling short but at least it does potentially avoid the "retry/timeout" spiral. =20 Recommending that AS2 reliability makes use of this "keep alive" or "forward progress" indicator would mark a change in current operational modes. It is to be expected that this capability would be marked by a special feature value (or AS2-version number if the feature header is not approved) to allow a smooth transition to interoperability. Also, how frequently to send 100 continues and how to react to a stretch of time without "100 continues" are issues needing consensus from the participants on this list. This is assuming that people support the direction here proposed so stakeholders should let their views be known! =20 =20 =20 =20 =20 ------_=_NextPart_001_01C6420A.23ACCB7F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There are several residual Internet-Drafts under = review by the Ediint vender and user community that are responding to industry = requests for standardization. Most of these Internet-Drafts are informational = RFCs and not “official” Ediint chartered efforts. Examples include = drafts on Compression, the Features header, Certificate Exchange messages (CEM), = filename transmission, multipart payload support, and Reliability for AS2. The = question here concerns a small but important point in the AS2 reliability = draft.

 

AS2 has an option for either synchronous or = asynchronous MDNs. The issue for comment is concerned with synchronous MDN = mode.

 

Most venders have attempted to provide for some = recovery from network and/or server failures, and also to protect their customers = from resource exhaustion. When synchronous MDNs are used to transfer large = amounts of business data with compression, digital signatures, and encryption = applied to that data, heavily loaded systems can take a large amount of time to = produce the MDN to send back in the HTTP response. The HTTP connection then = needs to be held open for an unpredictable amount of time, using resources on both = sides.

 

Now, because it is possible for an AS2 application to = become “hung” on the server side, software engineers often build in = a “timer” that closes a connection after some period of time. Unfortunately, the = timeout can occur before the HTTP requester (client) has received the = protocol’s HTTP response. In addition, sometimes various HTTP intermediaries = (tunnels/proxies/gateways/etc) may time out a connection along the path from client to final HTTP = server based on “inactivity,” and again prevent the completion of the = HTTP protocol.

 

These exceptional conditions may be tied to an = exception handler that retries the HTTP request with its large payload. More often = than not, this retry of a large payload to an ever increasingly loaded server = is a recipe for further failure (and retry).  Because AS2 payloads are growing = from the tens to hundreds of megabytes, and the AS2 traffic on existing servers = is growing, the “timeout/retry” spiral has become an = operational difficulty for AS2 systems that needs = consideration.

 

The AS2 specification does have a built-in solution = for this problem—asynchronous MDN mode. However, users have indicated an = interest in whether there is anything else that might be done to address the = timeout problem and make AS2 in synchronous MDN mode more = reliable.

 

One direction is to try to make the timeout interval = value “flexible” and adapt it intelligently. While both transmission time and payload = size are known to the sender, the receiver load (often the most critical factor) = is not known. So it becomes difficult to arrive at an intelligent solution that = will not sometimes be wrong, which tends to not satisfy AS2 = endusers.

 

Another direction might be to prohibit timeouts. This solution would remove protections against tying up resources (both on = sender and receiver sides) in the really exceptional situations of a hung or = dead thread/process that did not clean up with an appropriate HTTP status code (5xx range). = Again there would be resistance to the adoption of this solution by developers = and engineers.

 

Another direction might be to prohibit retries when = using synchronous MDNs. This direction effectively gives up on AS2 = reliability. When the specific error condition is recoverable (server down, connection = refused, transient network error, server temporarily busy), then retry can be a reasonable way to enhance automation and reduce the need for operational intervention and special manual handling.

 

If the basic problem of the = “timeout/retry” spiral is that there is no way to tell intermediaries or the client that there = is forward progress being made on completing the HTTP response, then one = remaining direction is to provide a forward progress indicator. The HTTP protocol = does have an option for providing this feature that takes advantage of the = HTTP response “100 continue” status. In other words, a HTTP = server can be configured to send a sequence of “100 continue” replies, = and a HTTP 1.1 client is effectively instructed to wait for a reply in the = success range (“2xx”) or possibly failure (“5xx”). [ 3xx = and 4xx cases ignored here for simplicity—these statuses should be = given as an initial HTTP response IMO.]  This solution does not magically = create resources when they are falling short but at least it does potentially = avoid the “retry/timeout” spiral.

 

Recommending that AS2 reliability makes use of this = “keep alive” or “forward progress” indicator would mark a = change in current operational modes. It is to be expected that this capability = would be marked by a special feature value (or AS2-version number if the feature = header is not approved) to allow a smooth transition to interoperability. Also, = how frequently to send 100 continues and how to react to a stretch of time without = “100 continues”  are issues needing consensus from the = participants on this list. This is assuming that people support the direction here = proposed so stakeholders should let their views be = known!

 

 

 

 

 

------_=_NextPart_001_01C6420A.23ACCB7F-- From owner-ietf-ediint@mail.imc.org Tue Mar 07 15:27:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGimF-0000Ru-MA for ediint-archive@lists.ietf.org; Tue, 07 Mar 2006 15:27:27 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGimD-0001JH-Nj for ediint-archive@lists.ietf.org; Tue, 07 Mar 2006 15:27:27 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k27KAZ0k096508; Tue, 7 Mar 2006 13:10:35 -0700 (MST) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k27KAZ0V096507; Tue, 7 Mar 2006 13:10:35 -0700 (MST) (envelope-from owner-ietf-ediint@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from drummondgroup.com (drummondgroup.com [161.58.166.198]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k27KAXS6096501 for ; Tue, 7 Mar 2006 13:10:34 -0700 (MST) (envelope-from kyle@drummondgroup.com) Received: from KYLEDGILAPTOP (c-68-53-139-87.hsd1.tn.comcast.net [68.53.139.87]) by drummondgroup.com (8.12.11/8.12.11) with ESMTP id k27KATLP062351 for ; Tue, 7 Mar 2006 13:10:31 -0700 (MST) From: "Kyle Meadors" To: Subject: CEM Draft update Date: Tue, 7 Mar 2006 14:10:26 -0600 Message-ID: <00c701c64223$2f939ed0$7d01a8c0@KYLEDGILAPTOP> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00C8_01C641F0.E4F92ED0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZCIyxIHFmi+g4yRCuadc92UKAX6g== Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.4 (/) X-Scan-Signature: a3be21b2faf291b8175f59b45fa11751 This is a multi-part message in MIME format. ------=_NextPart_000_00C8_01C641F0.E4F92ED0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00C9_01C641F0.E4F92ED0" ------=_NextPart_001_00C9_01C641F0.E4F92ED0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable CEM Internet=96Draft has expired and can not be viewed until new version = is updated. However, IETF can not update until end of the month. I am = posting it here for temporary reference. =20 Kyle Meadors Principal, Test Process Drummond Group Inc. 615.212.0826 =20 --=20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.2.0/275 - Release Date: 3/6/2006 =20 =20 ------=_NextPart_001_00C9_01C641F0.E4F92ED0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

CEM Internet–Draft has expired and can not be = viewed until new version is updated. However, IETF can not update until end of = the month. I am posting it here for temporary = reference.

 

Kyle Meadors

Principal, Test Process

Drummond Group Inc.

615.212.0826

 


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.2.0/275 - Release Date: = 3/6/2006

------=_NextPart_001_00C9_01C641F0.E4F92ED0-- ------=_NextPart_000_00C8_01C641F0.E4F92ED0 Content-Type: text/plain; name="draft-meadors-certificate-exchange-03.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-meadors-certificate-exchange-03.txt" Draft CEM for EDIINT March 2006=20 =20 =20 Private K. Meadors=20 Internet-Draft Drummond Group Inc.=20 Document: draft-meadors-certificate-exchange- D. Moberg=20 03.txt Cyclone Commerce=20 Expires: September 2006 March 2006=20 =20 =20 =20 Certificate Exchange Messaging for EDIINT=20 draft-meadors-certificate-exchange-03.doc=20 =20 By submitting this Internet-Draft, each author represents that any=20 applicable patent or other IPR claims of which he or she is aware=20 have been disclosed, or will be disclosed, and any of which he or she = becomes aware will be disclosed, in accordance with Section 6 of BCP=20 79.=20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six months = and may be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference=20 material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.html=20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 Any questions, comments, and reports of defects or ambiguities in=20 this specification may be sent to the mailing list for the EDIINT=20 working group of the IETF, using the address .=20 Requests to subscribe to the mailing list should be addressed to=20 .=20 =20 =20 Abstract=20 =20 The EDIINT AS1, AS2 and AS3 message formats do not currently contain=20 any neutral provisions for transporting and exchanging trading=20 partner profiles or digital certificates. EDIINT Certificate Exchange = =20 =20 Meadors, Moberg Expires - September 2006 [Page 1]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 Messaging provides the format and means to effectively exchange=20 certificates for use within trading partner relationships. The=20 messaging consists of two types of messages, Request and Response,=20 which allow trading partners to communicate certificates, their=20 intended usage and their acceptance through XML. Certificates can be=20 specified for use in digital signatures, data encryption or SSL/TLS=20 over HTTP (HTTPS). =20 =20 =20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this = document are to be interpreted as described in RFC-2119.=20 =20 Feedback Instructions=20 =20 NOTE TO RFC EDITOR: This section should be removed by the RFC editor = prior to publication.=20 =20 If you want to provide feedback on this draft, follow these=20 guidelines:=20 =20 -Send feedback via e-mail to kyle@drummondgroup.com, with=20 "Certificate Exchange" in the Subject field.=20 =20 -Be specific as to what section you are referring to, preferably=20 quoting the portion that needs modification, after which you state=20 your comments.=20 =20 -If you are recommending some text to be replaced with your suggested = text, again, quote the section to be replaced, and be clear on the=20 section in question.=20 =20 =20 Table of Contents=20 =20 1. Introduction...................................................3=20 1.1 Overview...................................................3=20 1.2 Terminology and Key Word Convention........................4=20 1.3 Certificate Lifecycle......................................5=20 2. Message Processing.............................................6=20 2.1 Message Structure..........................................6=20 2.2 EDIINT Features Header.....................................7=20 2.3 Certificate Exchanging.....................................7=20 2.4 Certificate Implementation.................................8=20 2.5 CEM Response...............................................9=20 3. XML Schema Description........................................10=20 3.1 EDIINTCertificateExchangeRequest element..................10=20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 2]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 3.2 EDIINTCertificateExchangeResponse element.................13=20 4. Use Case Scenario.............................................14=20 5. Profile Exchange Messaging....................................16=20 6. Security Considerations.......................................16=20 7. IANA Considerations...........................................17=20 8. References....................................................17=20 8.1 Normative References......................................17=20 8.2 Informative References....................................18=20 9. Acknowledgments...............................................18=20 Author's Addresses...............................................18=20 Appendix.........................................................19=20 A.1 EDIINT Certificate Exchange XML Schema....................19=20 A.2 Example of EDIINT Certificate Exchange Request XML........21=20 A.3 Example of EDIINT Certificate Exchange Response XML.......22=20 Changes from Previous Versions...................................23=20 B.1 Updates from Version 00...................................23=20 B.2 Updates from Version 01...................................23=20 B.3 Updates from Version 02...................................23=20 =20 =20 1. =0D Introduction=20 =20 1.1 =0D Overview=20 =20 The growth and acceptance of EDIINT protocols, AS1, AS2 and AS3, in=20 numerous supply-chains was due in part to the security feature which=20 was provided. The security is not possible without the digital=20 certificates which enable it. To maintain the level of security=20 necessary to transmit business documentation, existing certificates=20 must occasionally be replaced and exchanged with newer ones. The=20 exchanging of digital certificates is unavoidable given how=20 certificates can expire or become compromised. Complicating this is=20 supply-chains which cannot afford to shutdown their business=20 transactions while trading partners laboriously upload new=20 certificates. Certificate exchange must be accomplished in a reliable = and seamless format so as not to affect ongoing business=20 transactions. =20 =20 This document describes how EDIINT products may exchange public-key=20 certificates. Since EDIINT is built upon the security provided by=20 public-private key pairs, it is vital that implementers are able to=20 update their trading partners with new certificates as their old=20 certificates expire, become outdated or insecure. EDIINT Certificate=20 Exchange Messaging (CEM) described here utilizes XML data to exchange = the certificate and provide information on its intended usage and=20 acceptance within the trading partner relationship. There are two=20 types of CEM messages, the CEM Request which presents the new=20 certificate to be introduced into the trading partner relationship=20 and the CEM Response which is the recipient=92s response to the CEM=20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 3]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 Request. CE messages can be exchanged through AS1 [AS1], AS2 [AS2] or = AS3 [AS3] message transports. However, it is possible to leverage CE=20 messaging through other transport standards besides EDIINT.=20 =20 1.2 =0D Terminology and Key Word Convention=20 =20 [RFC2818] provides a glossary of Internet security terms, and several = of their definitions are listed here verbatim. However, some=20 definitions required for this document were undefined by [RFC2818] or = rewritten to better explain their specific use within CEM. =20 =20 Certificate - A digital certificate contains the owner=92s (End=20 Entity=92s) name, the issuer=92s name, a serial number, expiration = date,=20 and a copy of the owner=92s Public Key. The Public Key is used for=20 Encrypting messages and Verifying Signatures (verifying a signature=20 is also called Authentication). =20 =20 Certificate Revocation List (CRL) - A data structure that enumerates=20 digital certificates that have been invalidated by their issuer prior = to when they were scheduled to expire. [RFC2828]=20 =20 Certification Authority (CA) - An entity that issues digital=20 certificates (especially X.509 certificates) and vouches for the=20 binding between the data items in a certificate. [RFC2828]=20 =20 CA Certificate - A certificate issued by a trusted certification=20 authority. CA certificates are not used to encrypt data but to sign=20 other certificates. CA certificates are signed by themselves, but are = not considered self-signed certificates for the purpose of this=20 document.=20 =20 Certification Hierarchy - In this structure, one CA is the top CA,=20 the highest level of the hierarchy. The top CA may issue public-key=20 certificates to one or more additional CAs that form the second=20 highest level. Each of these CAs may issue certificates to more CAs=20 at the third highest level, and so on. The CAs at the second-lowest=20 of the hierarchy issue certificates only to non-CA entities, called=20 "end entities" that form the lowest level. Thus, all certification=20 paths begin at the top CA and descend through zero or more levels of=20 other CAs. All certificate users base path validations on the top=20 CA's public key. [RFC2828]=20 =20 CEM Request -The EDIINT Certificate Exchange Messaging (CEM) Request=20 is one of two possible CEM messages. It presents a certificate to be=20 introduced into the trading partner relationship along with relevant=20 information on how it is to be implemented.=20 =20 CEM Response -The EDIINT Certificate Exchange Messaging (CEM)=20 Response is one of two possible CEM messages. It is the response to=20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 4]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 the CEM Request indicating whether or not the end entity certificate=20 present in the CEM Request was accepted. =20 =20 End Entity - A system entity that is the subject of a public-key=20 certificate and that is using, or is permitted and able to use, the=20 matching private key only for a purpose or purposes other than=20 signing a digital certificate; i.e., an entity that is not a CA.=20 [RFC2828]=20 =20 End Entity Certificate - A certificate which is used to encrypt data=20 or authenticate a signature. (The private key associated with the=20 certificate is used to decrypt data or sign data). The certificate=20 may be self-signed or issued by a trusted certificate.=20 =20 Intermediary Certificate - A certificate issued by a CA certificate=20 which itself issues another certificate (either intermediary or end=20 entity). Intermediary certificates are not used to encrypt data but=20 to sign other certificates.=20 =20 Public Key - The publicly-disclosable component of a pair of=20 cryptographic keys used for asymmetric cryptography. [RFC2828]=20 =20 Public Key Certificate - A digital certificate that binds a system=20 entity's identity to a public key value, and possibly to additional=20 data items. [RFC2828]=20 =20 Self-signed Certificate - A certificate which is issued by itself=20 (both issuer and subject are the same) and is an End Entity=20 certificate.=20 =20 1.3 =0D Certificate Lifecycle=20 =20 A certificate has five states.=20 =20 1. Pending - Upon receiving a certificate from a trading partner, the = certificate is marked as Pending until a decision can be made to=20 trust it or if its validity period has not yet begun.=20 2. Rejected - If a Pending certificate is not trusted, it is=20 considered Rejected.=20 3. Accepted - Once a Pending certificate has been trusted, it is=20 considered Accepted. An Accepted certificate may be used in=20 secure transactions. =20 4. Expired - A certificate which is no longer valid because its=20 expiration date has passed. Expired certificates SHOULD be kept=20 in a certificate storehouse for decrypting and validating past=20 transactions.=20 5. Revoked - A certificate which has been explicitly revoked by its=20 owner or the certificate authority.=20 =20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 5]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 2. =0D Message Processing=20 =20 2.1 =0D Message Structure=20 =20 CEM messages use the underlying EDIINT transport, such as AS2, to=20 communicate information on the certificate, its intended use and its=20 acceptance. Both digital certifications and the XML data describing=20 their intended use are stored within a multipart-related MIME=20 envelope [RFC2387]. The certificates are stored in certificate chains = through SMIME, certs-only MIME envelope [3851], and processing=20 information is XML data which is identified through the MIME content- type of application/ediint-cert-exchange+xml. The format for CEM=20 messages is as follows:=20 =20 Various EDIINT headers=20 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2-company=20 Content-Type: multipart/signed; micalg=3Dsha1;=20 protocol=3D"application/pkcs7-signature"; =20 boundary=3D"--OUTER-BOUNDARY"=20 =20 ----OUTER-BOUNDARY=20 Content-Type: multipart/related; type=3D" application/ediint-cert- exchange+xml"; boundary=3D"--INNER-BOUNDARY"=20 =20 ----INNER-BOUNDARY=20 Content-Type: application/ediint-cert-exchange+xml=20 Content-ID: <20040101-1.alpha@example.org>=20 =20 [CEM XML data]=20 ----INNER-BOUNDARY=20 Content-Type: application/pkcs7-mime; smime-type=3Dcerts-only=20 Content-ID: <20040101-2.alpha@example.org>=20 =20 [digital certificate]=20 ----INNER-BOUNDARY--=20 =20 ----OUTER-BOUNDARY=20 Content-Type: application/pkcs7-signature=20 =20 [Digital Signature]=20 ----OUTER-BOUNDARY--=20 =20 One and only one MIME type of application/ediint-cert-exchange+xml=20 MUST be present in the multipart/related structure, and it MUST be=20 the root element. Multiple certs-only media types may be included,=20 but at least one MUST be present. A unique content-id header MUST be=20 present within each of the multipart structures.=20 =20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 6]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 If possible, both the CEM Request and CEM Response message SHOULD be=20 signed. Applying digital signatures will allow for automatic exchange = based on a previous trust relationship. However, it may not be=20 possible in the initial exchange of a new trading partner. If a CEM=20 message is signed, the signing certificate MUST be included in the=20 digital signature. Extra security such as applying data encryption or = compression is OPTIONAL. Also, CEM messages SHOULD request a MDN and=20 SHOULD request a signed MDN. The MDN can be either synchronous or=20 asynchronous. The MDN response verifies the transport delivery but is = not equivalent to the CEM Response message. All necessary headers=20 MUST be applied to the message per the underlying transport standard. = =20 =20 2.2 =0D EDIINT Features Header=20 =20 To indicate support for CEM, an EDIINT application MUST use the=20 EDIINT Features header [EDIINT-FEATURE]. The Feature Header indicates = the instance application can support various features, such as=20 certification exchange. The header is present in all messages from=20 the instance application, not just those which feature certification=20 exchange.=20 =20 For applications implementing certification exchange, the CEM- Feature-Name MUST be used within the EDIINT Features header:=20 =20 CEM-Feature-Name =3D "CEM"=20 =20 2.3 =0D Certificate Exchanging=20 =20 After obtaining the desired certificate, the initiator of the=20 certificate exchange transmits the end-entity certificate in the CEM=20 Request message. If the end-entity certificate is not self-signed,=20 then the CA certificate and any other certificates needed to create=20 the chain of trust for the end-entity certificate MUST be included in = the CEM Request message. Multiple end-entity certificates MAY also be = present.=20 =20 The entire certificate trust chain is stored in a BER encoded P7C=20 format [REFERENCE LIKELY NEEDED] and placed within the SMIME certs- only MIME envelope which is then stored in a single part of the=20 multipart/related structure. Each P7C trust chain MUST include a=20 single end-entity certificate and its trust authorities. No other=20 certificates are to be part of this chain. The number of P7C trust=20 chains in a CEM Request message MUST be equal to the number of end- entity certificates being communicated in the CEM XML document.=20 If different end-entity certificates have common trust authorities=20 certificates, each P7C cert chain still MUST included each=20 certificate necessary to create a trust anchor. Thus, if a recipient=20 can not create a trust relationship from the P7C cert chain, it MAY=20 reject the end-entity certificate in the CEM Request.=20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 7]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 =20 End-entity certificates are referenced and identified in the XML data = by their content-id used in the multipart-related structure.=20 Information on how the certificate is to be used, or certificate=20 usage, by the receiving user agent and other related information is=20 found in the XML data. A certificate can be used for a single=20 function, like digital signatures, or used for multiple functions,=20 such as both digital signatures and data encryption. If a certificate = is intended for multiple usages, such as for both digital signatures=20 and data encryption, the certificate MUST be listed only once in the=20 CEM Request message and its multiple usage listed through the=20 CertUsage XML element.=20 =20 Upon receipt of the CEM Request, the recipient trading partner=20 processes the transport message as normal and returns the MDN. The=20 recipient MUST return the MDN before parsing and interpreting the CEM = XML data or certificate chains. The returned MDN only provides=20 information on the veracity of the transport message and not the=20 acceptance of the certificate(s) being exchanged.=20 =20 =20 2.4 =0D Certificate Implementation=20 =20 The new certificate is considered to be in the Pending state for the=20 recipient who MUST decide whether to accept the certificate as=20 trustworthy. This decision is arbitrary and left to each individual=20 trading partner. Upon accepting the certificate, it is to be=20 considered an Accepted certificate within the trading partner=20 relationship. If the certificate is not accepted, it is considered=20 Rejected.=20 =20 When a certificate is intended for use in data encryption or TLS/SSL=20 server authentication, the initiator MUST consider the certificate to = be Accepted and be prepared for its trading partner to begin using=20 the certificate upon generating the CEM Request message. After a=20 recipient generates a positive CEM Response message for a=20 certificate, the recipient MUST immediately begin using the=20 certificate in trading with the initiator of the request. The=20 recipient MAY apply encryption to the CEM Response message using the=20 new Accepted certificate or MAY apply encryption to the CEM Response=20 message using the previously Accepted encryption certificate.=20 =20 When a certificate is intended for use in digital signatures or=20 TLS/SSL client authentication, the initiator MUST NOT use the=20 certificate until the recipient trading partner generates a CEM=20 Response accepting the certificate or the respond by date, which is=20 listed in the RespondByDate XML element. The initiator MAY use the=20 certificate after the respond by date, regardless of whether the=20 partner has accepted it or not. The certificate used for the digital=20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 8]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 signature of the CEM Request message MUST be the one which is=20 currently Accepted within the trading partner relationship.=20 =20 Since implementers of EDIINT often use the same certificate with=20 multiple trading partners, implementers of CEM MUST be able to keep=20 both the old and new certificates as Accepted. If the initiator has=20 generated a CEM Request and exchanged a new encryption certificate to = multiple trading partners, it MUST be able to accept encrypted data=20 which uses either the older, existing encryption certificate or the=20 newly exchanged encryption certificate. Likewise, a recipient of a=20 CEM Request MUST be able to authenticate digital signatures using=20 either the new or old certificates, since the initiator may not be=20 able to switch certificates until all trading partners accept the new = certificate. Similar provisions MUST be made for certificates=20 intended for TLS/SSL server and client authentication. Revoking a=20 certificate MUST be done outside of CEM.=20 =20 If a CEM Request message contains a certificate which is currently=20 Accepted and has the identical usage for the certificate that has=20 been Accepted, the recipient MUST NOT reject the duplicate=20 certificate but MUST respond with a CEM Response message indicating=20 the certificate has been accepted. For example, if Certificate A is=20 currently Accepted as the encryption certificate for a user agent,=20 any CEM Request message containing Certificate A with the usage as=20 encryption only MUST be accepted by an existing trading partner. This = situation may be necessary for an implementation intending to verify=20 its current trading partner certificate.=20 =20 If two trading partners utilize multiple EDIINT protocols for=20 trading, such as AS2 for a primary transport and AS1 as the backup=20 transport, it is dependent upon implementation and trading partner=20 agreement how CEM messages are sent and which transports the=20 exchanged certificates affect.=20 =20 2.5 =0D CEM Response=20 =20 The CEM Response message contains a TrustResponse XML element.=20 TrustResponse provides information needed to match the end-entity=20 certificate sent in an earlier CEMRequest and indicate if the=20 certificate was accepted or rejected by the recipient. The=20 CertificateReference in a TrustResponse matches the=20 CertificateIdentifier value for the end-entity certificate in the CEM = Request. CertStatus indicates if the certificate was accepted or=20 rejected. If a CEM Request is received, the recipient MUST respond=20 with a CEM Response message indicating if the certificate is Accepted = or Rejected. More information about the XML attributes and value for=20 CEM Response can be found in 3.2.=20 =20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 9]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 If the certificate in the CEM Request message contains multiple=20 usages, such as for both digital signature and data encryption, only=20 a single TrustResponse is needed for that certificate. The CertStatus = value in the TrustResponse is the response for both usages of the=20 certificate. A recipient can NOT choose to accept the certificate for = one specified use and not the other.=20 =20 If multiple end-entity certificates were included within the CEM=20 Request, the recipient MAY generate individual CEM Response messages=20 for each certificate or the recipient MAY consolidate the=20 TrustResponse for multiple certificates into one CEM Response=20 message. A CEM Response may contain multiple TrustResponse elements=20 for different certificates but MUST NOT contain two or more=20 TrustResponses for the same certificate.=20 =20 If a second TrustResponses is received in different message matching=20 the same certificate as that of an earlier TrustRespnse but the=20 CertStatus have a different value than the other, the originator MAY=20 accept the CertStatus value in the most recent TrustResponse but MAY=20 choose to ignore it. If the CertStatus in both TrustResponses are the = same, the originator should disregard the second TrustResponse.=20 =20 If the originator receives a CEM Response message which violates the=20 rules listed above or is invalid in any way, the originator MAY=20 reject the message entirely but MUST return an MDN if requested.=20 =20 =20 3. =0D XML Schema Description=20 =20 The CEM schema has two top-level elements,=20 EDIINTCertificateExchangeRequest and=20 EDIINTCertificateExchangeResponse. The=20 EDIINTCertificateExchangeRequest element is present only in the CEM=20 Request message, and the EDIINTCertificateExchangeResponse is present = only in the CEM Response message. All other elements nest directly or = indirectly from these. Please refer to the appendix for the actual=20 schema document.=20 =20 3.1 =0D EDIINTCertificateExchangeRequest element=20 =20 EDIINTCertificateExchangeRequest contains two elements,=20 TradingPartnerInfo, which can only appear once and TrustRequest,=20 which may be present multiple times. TrustRequest contains=20 information on a certificate and its intended usage.=20 TradingPartnerInfo exists to provide information on the publication=20 of the CEM Request message since processing of the XML data may occur = apart from the handling of the accompanying transport message, for=20 example the AS2 request. =20 =20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 10]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 TradingPartnerInfo identifies the entity that created the CEM message = through the nested Name element. Both the optional qualifier=20 attribute and the element value of Name are left open to the=20 implementer, but some suggested choices are to list the EDI=20 identification or the transport trading partner relationship, for=20 example the qualifier of =93AS2=94 and the value of the AS2 system=20 identifier (AS2-From value). MessageOriginated is included in=20 TradingPartnerInfo to identify the time and date the message was=20 created. The MessageOriginated date and time values MUST follow XML=20 standard dateTime type syntax and be listed to at least the nearest=20 second and expressed in local time with UTC offset. For example, a=20 message originating from the US Eastern Standard timezone would use=20 2005-03-01T14:05:00-05:00.=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 The TrustRequest element contains the EndEntity, CertUsage,=20 RespondByDate and ResponseURL elements. The required EndEntity=20 element is found only once in a TrustRequest element and contains the = content-id reference to the end-entity certificate being exchanged. =20 =20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 11]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 EndEntity contains the nested elements of CertificateIdentifier and=20 CertificateContentID. CertificateContentID is a string element which=20 references the content-id of the multipart/related structure where=20 the certificate is stored. CertificateIdentifier comes from the XML=20 Signature schema namespace [XML-DSIG]. =20 =20 =20 =20 =20 =20 =20 =20 CertificateIdentifier contains the string element X509IssuerName and=20 the integer element X509SerialNumber. X509SerialNumber is the=20 assigned serial number of the end entity certificate as it is listed. = X509IssuerName contains the issuer name information of the end-entity = certificate, such as common name, organization, etc. This information = MUST be describe in a string format per the rules of RFC 2253=20 [RFC2253]. This results in the attributes within the Issuer Name to=20 be listed with their attribute type followed by an "=3D" and the=20 attribute value. Each attribute type and value are separated by a "," = and any escape characters in the value are preceded by a "\". Refer=20 to the appendix and the sample CEM Request message for an example of=20 the X509IssuerName.=20 =20 =20 =20 =20 =20 =20 =20 =20 CertUsage is an unbounded element which contains enumerated values on = how the exchanged certificate is to be used. There are enumerated=20 values for SMIME digital signatures (digitalSignature), SMIME data=20 encryption (keyEncipherment), the server certificate used in TLS=20 transport encryption (tlsServer) and the client certificate used in=20 TLS transport encryption (tlsClient). While the element is unbounded, = =20 =20 Meadors, Moberg Expires - September 2006 [Page 12]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 CertUsage only has a potential number of four occurrences due to the=20 limit of the enumerated values. =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 RespondByDate is a required element of the XML standard dateTime type = expressed in local time with UTC offset, which provides information=20 on when the certificate should be trusted, inserted into the trading=20 partner relationship and responded to by a CEM Response message. If=20 the certificate can not be trusted or inserted into the trading=20 partner relationship, the CEM Response message should still be=20 returned by the date indicated.=20 =20 =20 =20 ResponseURL is an element which indicates where the CEM Response=20 message should be sent. This value takes precedence over the existing = inbound URL of the current trading partner relationship. The Response = MUST use the same transport protocol (AS1, AS2, or AS3) as the=20 Request. =20 =20 =20 3.2 =0D EDIINTCertificateExchangeResponse element=20 =20 EDIINTCertificateExchangeResponse contains the two elements=20 TradingPartnerInfo and TrustResponse. TradingPartnerInfo, which is=20 also found in EDIINTCertificateExchangeRequest, describes the trading = partner generating this response message. TrustResponse provides=20 information on the acceptance of a previously sent end entity=20 certificate. There can be multiple TrustResponse elements within an=20 EDIINTCertificateExchangeResponse.=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 13]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 =20 =20 =20 =20 =20 = =20 =20 =20 =20 A TrustResponse element identifies a certificate which has been=20 previously exchanged within the trading partner relationship through=20 a CEM Request and now has been either accepted or rejected by the=20 partner. The CertificateReference element is of the same type as the=20 CertificateIdentifier element. A CertificateReference element in a=20 CEM Response MUST be identical to its CertificateIdentifier=20 counterpart in the associated CEM Request since they identify the=20 same certificate in question.=20 =20 The required element CertStatus has the enumerated values of=20 =93Accepted=94 or =93Rejected=94. =93Accepted=94 indicates the = certificate was=20 trusted by the trading partner and is now ready for use within the=20 trading partner relationship, and =93Rejected=94 indicates the=20 certificate is not trusted by the trading partner nor can it be=20 currently used with the trading partner relationship. If the value of = =93Rejected=94 is chosen, the optional string element = ReasonForRejection=20 may be included. If present, ReasonForRejection should contain a=20 brief description of why the certificate was not accepted. Since the=20 value for this element is not enumerated but open, it MUST be=20 interpreted through human means.=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 4. =0D Use Case Scenario=20 =20 This scenario illustrates how the CEM Request and CEM Response=20 messages described in Section 2 and 3 can be used to exchange=20 certificates. The scenario is only illustrative and any differences=20 between it and the rules above should defer to the rules in Section 2 = and 3.=20 =20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 14]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 Two trading partners, TPA and TPB, have an established trading=20 partner relationship using AS2. TPA is using a single certificate,=20 CertA, for both digital signatures and data encryption. TPA wants to=20 issue a new certificate, CertB, for digital signatures but keep CertA = for data encryption.=20 =20 TPB is using one certificate, Cert1, for digital signatures and=20 another certificate, Cert2, for data encryption. TPB wants to=20 introduce a new certificate, Cert3, for digital signature and a new=20 certificate, Cert4, for data encryption.=20 =20 TPA sends a CEM Request to TPB containing only CertB. The CertUsage=20 has a value of "digitalSignature". TPB immediately returns the MDN=20 but must make an internal security decision before accepting CertB.=20 In the mean time, TPA continues to send AS2 messages to TPB which=20 have been signed using CertA. The messages originating from TPB are=20 encrypted using CertA. After some point, TPB returns a CEMResponse=20 with the CertStatus of "Accepted" for CertB. Upon receipt, an MDN is=20 returned which is signed using CertA. TPB must be able to accept the=20 MDN if it has a digital signature from either CertA or CertB as TPA=20 may not be able to switch certificates simply upon receipt of the CEM = Response message without parsing the XML payload. Also, TPA may need=20 to wait for other trading partners to accept the new CertB. TPB=20 should be prepared to accept digital signatures either from CertA or=20 CertB. However, soon as possible, TPA should being using CertB=20 exclusively for digital signatures. =20 =20 TPB sends a CEM Request to TPA containing both Cert3 and Cert4. The=20 CertUsage for Cert3 and Cert4 are "digitalSignature" and=20 "keyEncipherment", respectively. TPA returns an MDN immediately. TPB=20 is prepared to receive any encrypted inbound messages by either Cert2 = or Cert4. All its digital signatures are done through Cert1. After=20 some time, TPA returns a single CEM Response message. It contains a=20 TrustResponse element for Cert3 and a TrustResponse element for=20 Cert4. The CertStatus for Cert3 is "Rejected" with the=20 ReasonForRejection field present and populated with the string=20 "KeyUsage value was incorrect". CertStatus for Cert4 was "Accepted."=20 TPB returns the MDN signed through Cert1. Immediately after this, an=20 AS2 message is received from TPA which is encrypted using Cert2. TPB=20 returns the MDN signed with Cert3 and is only using Cert3 for digital = signatures. After creating a new certificate, Cert5, which corrects=20 the previous keyUsage problem, TPB sends Cert5 in a CEM Request.=20 Shortly after this, TPA sends a CEM Response message for Cert5. It=20 contains a CertStatus of "Accepted". This CEM Response message was=20 encrypted using Cert4, but TPB was prepared for encryption from=20 either Cert2 or Cert4. The message is processed and a good MDN is=20 returned.=20 =20 =20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 15]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 5. =0D Profile Exchange Messaging=20 =20 CEM provides the means to exchange certificates among trading=20 partners. However, other profile information, such as URLs and=20 preferred security settings, is needed to create a trading partner=20 relationship. A future standard is needed to describe profile=20 descriptions and how they will be exchanged. The format for this=20 profile attachment is not defined in this specification but is=20 planned for a future document. It will build upon the existing CEM=20 protocol with profile information stored with XML data. Both=20 certificate and profile description information will be placed into a = multipart/related [RFC2387] body part entity. A possible format for a = profile description message is as follows:=20 =20 Various EDIINT headers=20 EDIINT=96Features: profile-exchange=20 Disposition-Notification-To: http://10.1.1.1:80/exchange/as2_company=20 Disposition-Notification-Options: signed-receipt-protocol=3Doptional, = pkcs7-signature; signed-receipt-micalg=3Doptional, sha1=20 Content-Type: multipart/signed; micalg=3Dsha1;=20 protocol=3D"application/pkcs7-signature"; boundary=3D"--BOUNDARY1"=20 =20 ----BOUNDARY1=20 Content-Type: multipart/related;=20 start=3D=94"; =20 type=3D=94application/ediint-cert-exchange+xml=94; =20 boundary=3D"--BOUNDARY2"=20 =20 ----BOUNDARY2=20 Content-Type: application/ediint-cert-exchange+xml=20 Content-ID: =20 =20 [CEM XML data]=20 ----BOUNDARY2=20 [Profile information attachment]=20 ----BOUNDARY2--=20 ----BOUNDARY1=20 =20 Content-Type: application/pkcs7-signature=20 =20 [Digital Signature]=20 ----BOUNDARY1--=20 =20 =20 6. =0D Security Considerations=20 =20 Certificate exchange is safe for transmitting. However, implementers=20 SHOULD verify the received certificate to determine if it is truly=20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 16]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 from the stated originator through out-of-band means or whenever the=20 request is not signed.=20 =20 =20 7. =0D IANA Considerations=20 =20 MIME Media type name: Application=20 =20 MIME subtype name: EDIINT-cert-exchange+xml=20 =20 Required parameters: None=20 =20 Optional parameters: This parameter has identical semantics to the=20 charset parameter of the =93application/xml=94 media type as = specified=20 in [RFC3023].=20 =20 Encoding considerations: Identical to those of "application/xml" as=20 described in [RFC3023], section 3.2.=20 =20 Security considerations: See section 6. =20 =20 Interoperability Considerations: See section 2.2=20 =20 Published specification: This document.=20 =20 Applications which use this media type: EDIINT applications, such as=20 AS1, AS2 and AS3 implementations.=20 =20 Additional Information: None=20 =20 Intended Usage: Common=20 =20 Author/Change controller: See Author=92s section of this document.=20 =20 8. =0D References=20 8.1 =0D Normative References=20 =20 [AS1] RFC3335 =93MIME-based Secure Peer-to-Peer Business Data=20 Interchange over the Internet using SMTP=94, T. Harding, R.=20 Drummond, C. Shih, 2002.=20 =20 [AS2] RFC4130 =93MIME-based Secure Peer-to-Peer Business Data=20 Interchange over the Internet using HTTP=94, D. Moberg, R.=20 Drummond, 2005.=20 =20 [AS3] draft-ietf-ediint-as3-02.txt =93MIME-based Secure Peer-to-Peer=20 Business Data Interchange over the Internet using FTP=94, T.=20 Harding, R. Scott, 2003.=20 =20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 17]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 [EDIINT FEATURE] draft-meadors-ediint-feature-header-00.txt = =93Feature=20 Header for EDI-INT=94, K. Meadors, 2005.=20 =20 [RFC2119] RFC2119 =93Key Words for Use in RFC's to Indicate = Requirement=20 Levels=94, S.Bradner, March 1997.=20 =20 [RFC2246] RFC2246 "The TLS Protocol", Dierks, T. and C. Allen,=20 January 1999.=20 =20 [RFC2253] RFC2253 "Lightweight Directory Access Protocol (v3): UTF-8=20 String Representation of Distinguished Names", M. Wahl, S. Kille=20 and T. Howes, Decemeber 1997.=20 =20 [RFC2387] RFC2387 "The MIME Multipart/Related Content-type", E.=20 Levinson, August 1998.=20 =20 [RFC2818] RFC2818 "HTTP over TLS", Rescorla, E., May 2000.=20 =20 [RFC2828] RFC2828 =93Internet Security Glossary=94, R. Shirley, May = 2000.=20 =20 [RFC3023] RFC3023 =93XML Media Types=94, M. Murata, January 2001.=20 =20 [3821] RFC3821 =93S/MIME Version 3.1 Message Specification=94, B.=20 Ramsdell, July 2004.=20 =20 [XML-DSIG] RFC3275 =93XML-Signature Syntax and Processing=94, D.=20 Eastlake, March 2002. =20 =20 [X.520] ITU-T Recommendation X.520: Information Technology - Open=20 Systems Interconnection - The Directory: Selected Attribute=20 Types, 1993.=20 =20 [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet=20 X.509 Public Key Infrastructure: Certificate and CRL Profile",=20 RFC 3280, April 2002.=20 =20 8.2 =0D Informative References=20 =20 9. =0D Acknowledgments=20 =20 The authors wish to extend gratitude to the ecGIF sub-committee=20 within the GS1 organization from which this effort began. Of special=20 note is John Duker who chaired the sub-committee and provided=20 valuable editing, Richard Bigelow who greatly assisted development of = the ideas presented and John Koehring with his insights on=20 implementation and Debra Petta for her review and comments.=20 =20 Author's Addresses=20 =20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 18]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 Kyle Meadors=20 Drummond Group Inc.=20 4700 Bryant Irvin Court, Suite 303=20 Fort Worth, TX 76107 USA=20 Email: kyle@drummondgroup.com=20 =20 Dale Moberg=20 Cyclone Commerce=20 8388 E. Hartford Drive, Suite 100=20 Scottsdale, AZ 85255 USA=20 Email: dmoberg@cyclonecommerce.com=20 =20 =20 Copyright Notice=20 Copyright (C) The Internet Society 2005. This document is subject=20 to the rights, licenses and restrictions contained in BCP 78, and=20 except as set forth therein, the authors retain all their rights.=20 =20 This document and the information contained herein are provided on an = "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS = OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=20 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=20 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=20 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20 =20 Appendix=20 =20 A.1 EDIINT Certificate Exchange XML Schema=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 19]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 20]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 = =20 =20 =20 =20 =20 A.2 Example of EDIINT Certificate Exchange Request XML=20 =20 =20 =20 =20 DGI_Test_CEM=20 =20 2005-08-30T00:30:00-05:00=20 =20 =20 keyEncipherment=20 digitalSignature=20 2005-09-30T12:00:00-05:00=20 http://10.1.1.1/as2=20 =20 =20 CN=3DCleo- SP,E=3Das2selfpacedsupport@drummondgroup.com,O=3DDGI,OU=3DDGI,L=3DFt. = Worth,S=3DTexas,C=3DUS 9659684611094873474886=20 =20 =20 SignEncCert-Example_vs02@example.org=20 =20 =20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 21]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 =20 tlsServer=20 2005-09-30T12:00:00-05:00=20 http://10.1.1.1/as2=20 =20 =20 CN=3DVeriSign Class 1 CA Individual=20 Subscriber-Persona Not Validated,OU=3Dwww.verisign.com/repository/RPA = Incorp. By Ref.\,LIAB.LTD(c)98,OU=3DVeriSign Trust = Network,O=3DVeriSign\,=20 Inc. 2673611014597817669550861744279966682=20 =20 =20 SSLCert-Example_vs02@example.org=20 =20 =20 =20 =20 A.3 Example of EDIINT Certificate Exchange Response XML=20 =20 =20 =20 =20 DGI_Test_CEM_Trading_Partner=20 =20 2005-08-31T00:21:00-05:00=20 =20 =20 Accepted=20 =20 CN=3DCleo- SP,E=3Das2selfpacedsupport@drummondgroup.com,O=3DDGI,OU=3DDGI,L=3DFt. = Worth,S=3DTexas,C=3DUS=20 9659684611094873474886=20 =20 =20 =20 Accepted=20 =20 CN=3DVeriSign Class 1 CA Individual=20 Subscriber-Persona Not Validated,OU=3Dwww.verisign.com/repository/RPA = Incorp. By Ref.\,LIAB.LTD(c)98,OU=3DVeriSign Trust = Network,O=3DVeriSign\,=20 Inc.=20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 22]=20 =0CDraft CEM for EDIINT March = 2006=20 =20 =20 2673611014597817669550861744279966682=20 =20 =20 =20 =20 Changes from Previous Versions=20 =20 B.1 Updates from Version 00=20 =20 . Updated security requirements in section 2.1, specifically in=20 regards to digital signatures.=20 . The XML element responseURL is now required. Modified section=20 3.1 and example messages in appendix accordingly.=20 . Certificates are exchanged within a full P7C cert chain. Section=20 2.3 reflects this.=20 . The XML element TrustChain is not longer necessary since the=20 entire cert chain is stored. Removed references in schema and=20 document.=20 . Added statement in 2.5 that multiple CEM Responses SHOULD NOT be=20 sent and that if this occurs, the action of the CEM Request=20 initiator is not defined. =20 . Updated the examples in Appendix B to reflect the current usage.=20 =20 B.2 Updates from Version 01=20 =20 . Added information for handling different scenarios with CEM=20 Response message.=20 . Rewrote use case scenarios.=20 . Added the EDIINT Features header information.=20 =20 B.3 Updates from Version 02=20 =20 . No changes =96 updated because Vs 02 expired.=20 =20 =20 Meadors, Moberg Expires - September 2006 [Page 23]=20 =0C ------=_NextPart_000_00C8_01C641F0.E4F92ED0-- From owner-ietf-ediint@mail.imc.org Mon Mar 13 19:11:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIx8C-0003kV-Px for ediint-archive@lists.ietf.org; Mon, 13 Mar 2006 19:11:20 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIx8B-0003bE-FG for ediint-archive@lists.ietf.org; Mon, 13 Mar 2006 19:11:20 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2E00ABu053988; Mon, 13 Mar 2006 17:00:10 -0700 (MST) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2E00Ac3053987; Mon, 13 Mar 2006 17:00:10 -0700 (MST) (envelope-from owner-ietf-ediint@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2E009Eb053972 for ; Mon, 13 Mar 2006 17:00:10 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k2E002vP032595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Mar 2006 00:00:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FIwxG-0001LS-5S; Mon, 13 Mar 2006 19:00:02 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org Cc: ietf-ediint@imc.org, Rik Drummond From: IESG Secretary Subject: WG Action: Conclusion of Electronic Data Interchange-Internet Integration (ediint) Message-Id: Date: Mon, 13 Mar 2006 19:00:02 -0500 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed The Electronic Data Interchange-Internet Integration WG (ediint) in the Applications Area has concluded. The IESG contact persons are Ted Hardie and Scott Hollenbeck. The mailing list will remain active. From owner-ietf-ediint@mail.imc.org Mon Mar 13 20:05:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIxya-0006zB-Tm for ediint-archive@lists.ietf.org; Mon, 13 Mar 2006 20:05:28 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIxyZ-00051H-IE for ediint-archive@lists.ietf.org; Mon, 13 Mar 2006 20:05:28 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2E0v8YI057376; Mon, 13 Mar 2006 17:57:08 -0700 (MST) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2E0v8av057375; Mon, 13 Mar 2006 17:57:08 -0700 (MST) (envelope-from owner-ietf-ediint@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2E0v7ad057369 for ; Mon, 13 Mar 2006 17:57:08 -0700 (MST) (envelope-from dhc@dcrocker.net) Received: from [192.168.0.2] (adsl-71-131-40-72.dsl.sntc01.pacbell.net [71.131.40.72]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2E0vbL4015240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Mar 2006 16:57:37 -0800 Message-ID: <441614DB.5040907@dcrocker.net> Date: Mon, 13 Mar 2006 16:56:59 -0800 From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: ietf-ediint@imc.org CC: Rik Drummond Subject: Re: WG Action: Conclusion of Electronic Data Interchange-Internet Integration (ediint) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f IESG Secretary wrote: > The Electronic Data Interchange-Internet Integration WG (ediint) in the > Applications Area has concluded. wow. so soon? d/ -- Dave Crocker Brandenburg InternetWorking From owner-ietf-ediint@mail.imc.org Mon Mar 13 22:19:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ042-0001Jh-ET for ediint-archive@lists.ietf.org; Mon, 13 Mar 2006 22:19:14 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ041-0000zZ-27 for ediint-archive@lists.ietf.org; Mon, 13 Mar 2006 22:19:14 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2E392pa063033; Mon, 13 Mar 2006 20:09:02 -0700 (MST) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2E392rK063032; Mon, 13 Mar 2006 20:09:02 -0700 (MST) (envelope-from owner-ietf-ediint@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from dfi.infobro.com (dfi.infobro.com [63.71.25.55]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2E391sN063026 for ; Mon, 13 Mar 2006 20:09:01 -0700 (MST) (envelope-from eric@infobro.com) Received: from black.infobro.com ([63.71.25.39] helo=INFOBROLAP) by dfi.infobro.com with smtp (Exim 4.60) (envelope-from ) id IW3KQZ-0000A5-Q5; Tue, 14 Mar 2006 03:09:04 +0000 Message-ID: <000301c64714$92024c60$cb01a8c0@INFOBROLAP> From: "Eric D. Williams" To: , Cc: "Rik Drummond" References: <441614DB.5040907@dcrocker.net> Subject: Re: WG Action: Conclusion of Electronic Data Interchange-Internet Integration (ediint) Date: Mon, 13 Mar 2006 22:08:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Level: ----- (-5.6) X-InfoBro-SA-Score: ----- (-5.6) Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb I guess so. It is a surprise. The activity though very low has produced some interesting output. I, at least, am not sure whether the integration part is completed. However, I am at a loss to make a salient argument why to continue with the activity. -e Eric Williams Information Brokers, Inc. http://www.infobro.com/ ----- Original Message ----- From: "Dave Crocker" To: Cc: "Rik Drummond" Sent: Monday, March 13, 2006 7:56 PM Subject: Re: WG Action: Conclusion of Electronic Data Interchange-Internet Integration (ediint) > > IESG Secretary wrote: >> The Electronic Data Interchange-Internet Integration WG (ediint) in the > > Applications Area has concluded. > > > wow. > > so soon? > > d/ > > -- > > Dave Crocker > Brandenburg InternetWorking > > From owner-ietf-ediint@mail.imc.org Mon Mar 20 00:18:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLCn6-0008Cb-Pd for ediint-archive@lists.ietf.org; Mon, 20 Mar 2006 00:18:52 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLCn5-00025f-1m for ediint-archive@lists.ietf.org; Mon, 20 Mar 2006 00:18:52 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2K56utN092598; Sun, 19 Mar 2006 22:06:56 -0700 (MST) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2K56uqO092597; Sun, 19 Mar 2006 22:06:56 -0700 (MST) (envelope-from owner-ietf-ediint@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2K56tBs092591 for ; Sun, 19 Mar 2006 22:06:56 -0700 (MST) (envelope-from dhc@dcrocker.net) Received: from [204.96.113.68] ([204.96.113.68]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2K57MF9015114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Mar 2006 21:07:25 -0800 Message-ID: <441E301D.8090201@dcrocker.net> Date: Sun, 19 Mar 2006 22:31:25 -0600 From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: "Eric D. Williams" CC: ietf-ediint@imc.org, Rik Drummond Subject: Re: WG Action: Conclusion of Electronic Data Interchange-Internet Integration (ediint) References: <441614DB.5040907@dcrocker.net> <000301c64714$92024c60$cb01a8c0@INFOBROLAP> In-Reply-To: <000301c64714$92024c60$cb01a8c0@INFOBROLAP> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Eric, On the other hand, the working group effort has been going continuously for more than 10 years... d/ Eric D. Williams wrote: > I guess so. It is a surprise. The activity though very low has produced > some interesting output. I, at least, am not sure whether the > integration part is completed. However, I am at a loss to make a > salient argument why to continue with the activity. > > -e > > > Eric Williams > Information Brokers, Inc. http://www.infobro.com/ > > > ----- Original Message ----- From: "Dave Crocker" > To: > Cc: "Rik Drummond" > Sent: Monday, March 13, 2006 7:56 PM > Subject: Re: WG Action: Conclusion of Electronic Data > Interchange-Internet Integration (ediint) > > >> >> IESG Secretary wrote: >>> The Electronic Data Interchange-Internet Integration WG (ediint) in the >> > Applications Area has concluded. >> >> >> wow. >> >> so soon? >> >> d/ >> >> -- >> >> Dave Crocker >> Brandenburg InternetWorking >> >> > -- Dave Crocker Brandenburg InternetWorking From kolin@flamenconetwork.com Thu Mar 30 08:59:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOxgR-0005yL-8g for ediint-archive@ietf.org; Thu, 30 Mar 2006 08:59:31 -0500 Received: from [220.120.231.96] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FOxgO-0004lz-8y for ediint-archive@ietf.org; Thu, 30 Mar 2006 08:59:31 -0500 Message-ID: <000001c6542c$e261eb00$0100007f@localhost> From: "Carlos Lopez" To: Subject: Three Steps to the Software You Need at the Prices You Want Date: Thu, 30 Mar 2006 22:59:29 +0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0001_01C6542C.E261EB00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.6 (+++) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6542C.E261EB00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C6542C.E261EB00" ------=_NextPart_001_000E_01C6542C.E261EB00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable By the time Scarlett had undressed and blown out the candle, her plan for tomorrow had worked itself out in every detail. It was a ------=_NextPart_001_000E_01C6542C.E261EB00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software






------=_NextPart_001_000E_01C6542C.E261EB00-- ------=_NextPart_000_0001_01C6542C.E261EB00 Content-Type: image/gif; name="Lf.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c63b06$0762dd00$0403a8c0@mlto> R0lGODlhmwBtAaIAAO3uygAzmQAAZv///8xmAAAAAAAAAAAAACH5BAAAAAAALAAAAACbAG0B AAP/OKrS/jDKSau9OOtNlx9cKI5kaXbeqa5sSy5uLM8yQ994noF67/+jD+/jIEpsDRiEl0ym BLYoE0pMCakPI3UKLDKRUmdEiUWKm9jscD2emsFubrS7/NrPZq8+r2TXy1xngmmEhYZ0gnB4 gYQMfGVOZI4geYNvd16SlV2Ki2R/Yo9bg5GlbWqoloyHQJ1pm6mAS3qsYUdxsZezrD+XmhVP o7toWq+rcK5VwZ+Izc7P0NHS09TV1tfY2dozAN3e3+Dh4uPk5ebn6Onq6+zeQu/w8fLz9PX2 9/j59936/f7/AAMKFMJvoMGDCBPmK6iwocOHAxlCnEixIjyJCglo1LiA/4AHjx82huTYEaSC jSQ7fiwp8iRIkjBNQsSIMGVMlR9f5pSZckDPnDhtvhzqsihFmgeFutQJdKRPkz1/sjxp9GlJ q0qPAniY1SNHmUuBZl3606vXqkq/QgXrEKnBrmHfCW1p9arcuGNb0pXa0O1AuFWp1u3Kk63g wWub8tUKESXUlSMTG3X8lO5hnyzLErU70a/Fz6APeg5NuvTCraZTqz7drrXr17Bjy55Nu7bt 27hz697Nu7fv38CDCx9OvLjx48iTK1/OvLnz5gECdIv+vPo6AeyiS/e2HUD37uq0gw9PnXv5 6ee9p2fuYN137vBfv3cff779+M+xpxsvXbx47//mbaedOPcJuF44AtaH34LN6YcOf9Phl6CE CNY3IYDjzIehhupZB4CD50CI4YgXqjcgOP9FqOKIKH5z34oMskffihqWOF6LOJJIYI4X9pjf A+SBV2OA6B14o5AHmnjeiUW6mKSHUEapnH9UVmnllVhmqeWW/knp5ZdghinmmGSWaeaZaKap 5ppstunmm3DGKeecdNZp5514knljjO3sGZufzrUXXobkAJohk4byWehsTKL45DkOglhOfzsS OuOGD14qX4zSDcBia5IuiuSSpKbXKIVKOmlgeY2emGKTRe7JIY2whWoppiq+iOunOvaqq660 +srnq6iCGiSrCuZq4an/qQb7q4RDCgtjhS16mig5ti6q7La7lkiti8l2y6CP0vJa7KzpQBAi jq8i2iqzR0KLJKwmnluqn6aqmidx1zLH5b8AByzwwAT3u+/BCCes8MIMN+zwwxBHLPHEFFds 8cUYZ6xxjhsLuq6zmTK6rKzMQhlpyL3uR9uzPJKZbYWU2vduqfbKmnK8yq5aXQODxhwuuQXu emvKqCI7rYyZ+swt0ApSih6h35XcbrHKnawyjEwvDR/O4HJbaddEV83zoFgH22y9WxP5rbcc Y/3oxhgXLPfccsNt991456333nz37fffgAcu+OCEF74voAav/ObLX7cNtqaQDx2gkSXvNnbS /407vm7ij2vrOdW8Ycd4i6NGbfqoUOvrtLumslq5zTnTK5t+oxf9M8hHA2u0uOxO+rWBZsem bogpsiwzvMWDzXKziB+6JOizX8278b57HS31knMKvfAo58r65KqKuCyLrJdu3rfou8254R7S 7f778GfJ/vz012///fjnr//+/Pfv//8ADE7i1vew4ZmjSwOcVNSCpzbZwUtKtWtbAgu1wLCV i1xPixKQukei1q3KZkoDUKKypiMCHieCyeud8mAmws6t7XZCgyAHT3c+BuLqPc2znfcqh7QP zZCBGExWEMcFQ0UF6nIH5JGrnpc7FfKqSw40UgAPF78qzm2KWMyiFv+3yMUuevGLYAyjGMdI xs9pDInEM2HueNga/rxtZ9kxYhJbJptWyTFQcSTQ83TWxKbRC11HC6R1NvgxOu6ObULKYNdC qDk1FsdqczTk5BC5yPBFyGnpM5fJvBHBC9qQa9EqoRkdeUI0HtCDC0qhJVOJKHNBEYplZJMV ZwmwWNrylrjMpS53ycte+vKXwAwmngxYPU1qLnJ0zGSfUNlAWL4GhWzLXBwNRUrpkTCarulk CFv5ynulLlbgnJA4W0ijt10TnNzDHNAwOERPSkucJPTc8u5ojk5u6Jy4e6IqszZOsz0qkVo7 ZrrINr1zfRKGNVqe+DqHPWNC6lKmY+UfiQj/roR2MFzMSxIsZ6YvYbqGliANKcE8StKSmvSk KE2pSlfK0pb6rZoH81gkgWVG2HC0gWhD0BuBA8liArKmH0VoEbc3nJ76bpvoTGory0nNfHJt WHvsVlRBZUpRkbOgAVXata4nUT1er58yyyYnVYZUdwatgo2bpyB3eEi2YhMdRvVpJbNKoadS FKtPxKjbtPfMqspzrh2kWdpkN0mc3lSn5iNfYmH6S5E69rHyc6lkJ0vZylr2spjNrGY9ytg1 7bQdMi1kDPeDVkbBzoLIrGZcv+lQ4tVQZLf6qfRcyI7V7uhXzKzoVZcaUWXqFpM57ZHrqNMf YoE2tLH1mnJ/m9fR/x7pdS2EXT+lulbQPiiFNFTkXLMrXCkG0meLdas/aaNNIQKRWtNFK7p+ yiGL9hG1tS2vbgPLRwmCj5Ua/ee43LXK9nbWS/+NE2QHTODNGvjACE6wghfM4AY7WE45DGpr 5SQp5CoqwqSdrmiLmUfaCg+JqwWuEQlIUw6b+Lqoyw2IQqxYwZ4tp5K8GXEHtLrh1lfE773N iscaY7y28516LW1A75m9AH9jx90I1SuFKt4X8q5DwdunXl1oZB4n2co69HF1gTwtdhbxrXad jQGRK6J2efO+He1ufTuUWCgv1VFLZONlCUxnKz74znjOs573zGeX+hVS9vyShUt5HdpVOP/Q R7wyewI9tj+77NCXI2SSgeSxDfLs0qEdXqNXTIFJT9rRPzK0pzd9ZFF/SHSiloCnOZlqU7N6 1Zg+tZkwTWliklrWpI60rU0taVi3+tSDhiOuDz2OW8d62K8Wh7GRu2xZJ1vQuhbUrn39aVcD G8SS9qumUX1t9oH6f9/u856DDcBwP9t+5l61xNRVaWlbutXtIWStt43sdzubTc0utbOPfWt9 o7HZqh42uR9N7WtzG9n7jlStwQFwhS8cTg0f9a8TTu1/8/rg91a3m/LN7ou7m9XujrbBM95x cZv85ChPucpXznLAfRZipNqyhCf8sJjvRrYSAy9TyXnYODuzYjqtF1pbP6VWi4G1bP7kqsxr vi0bgQ6fGSszkVIM4zdDueUCrDOVsM71rnv962APu9jHTvY/vXzmeMP5n/aGsw9W/czFy23O mehlJ9a9ygJues2uqUqKufdmTj3oxU4VSu5CS6lnbxje86b1yJb98ZCPvOQnT/nKWz6SvjUc voCqeVdyvnDANXN2Cdu3hkL9pVI2q3H5Zvp8Bq7M30vqiy+vG5HS/va4z73ud2+bBAAAOw== ------=_NextPart_000_0001_01C6542C.E261EB00 Content-Type: image/gif; name="MW.gif" Content-Transfer-Encoding: base64 Content-ID: <000b01c63b06$076ec3e0$0403a8c0@mlto> R0lGODlhNgFWAKIAAP//////zP/MmcxmM5lmM5kAAAAAAAAAACH5BAAAAAAALAAAAAA2AVYA AAP/CLrc/jDKSau9OOvNu/9gqBiGKJKkyaQbq74whpavGwO2vbL6bfUSnZAGrBR9I9ouOTs2 UaBjVHnLAaFIzjCyXX6kvh6PiiMvuh1wdrozz9YtslNOZ8Md1rPbXMbzL2p3WlQlQn2HTGNM eliMQ41lWE8PLm9JepeWbYWEmoiflZ5+l5gNV3ukjU2bnZCRVqqteaKvnSugnKSIKbySSqGl u7ZeEJUjwWO/w5HIysSHwMVEy8HPqZyKup/CzbrZ3Iva0aDe19qMpnXb5+Pn6ebgXfLq4PUU omJ8+eHV9vOU+qa92zZHHLxsp0Z5wUcPjTRouUr9W9hw2jdaAB2uY+ds/2A3R6tepZsokV6i bzgwdUTZj6CyWB41jiKEi6NNlxKP4XI1EFbIjD/XocnDxdNPlkg7wtMp8mBAhf0sDTUJdBPF nuocSuXZFKC4P16LQvVGTdojgTjTkkxZDeFTj+4gxqSasQ3Wu1efbS0YliwgsEIrWhOrMOnN tdQuOkvot3HNwWMPC+bX7uvcviX/Bnn7uC1auUvHIUYJmPRWs2fpuMrH15phRzsZuws6mOXm 20DpTgLJyjOkqVBsCxpOvLjx48iTK1/OvLnz59CjS59Ovbr169iza98+QEF3AN/Dex8Pnrz4 8ujPqzfPPn3789vjy78xYECA+vft49+vf4AA/v/5BQjggP3l91+BBB4oYH/zNeigCPYJEICE EwZQoYQUZljhhRxiaKGHIH64YYgkiujhhd89qOKKFvg3oogbdmjhiybWGGOIMtKIY4n3segg YGkMxxUD9k1IQAH/EfBfAQQoWYB/TwqA5JEE+DcAk/YVoGWEATS55H1MKnkkkxOGKSGSXVJZ ppgEfJiij/IBSVhLa9AEAZdUSmmkABKyKeZ9SloYKIaDTnhlmnyiiSiSen5oQJlnCorkAIH2 COd8cj4EWRZ2OuBin01SumSTaTZpqgCm+nckl1GKiCSalFaJapVtCmCAkmcm2SeUqaJ4aZzM MMWWKcMWwpQmERkVSyj/vfRwX4WxHgmpfloGgCWiFA5gAKEnomrrhFK6SOm2hBZQ5rmidhmt m7/G+Yuw+hTLFhG37FKvG/UOq28DeDrJpodkFvAoqi5WKKu1tRrMJKiEVmkuhmhua22iueZp aLvxdUovJcdsvDGxZ9yLR76d8otim2TaKq2UYqJJJZtoeqthuODeai6lE1Oa8sPrEkxzthhr p7GwIntMNLwkGxMy0nfqCKOGTkcN9dRPV/0i1f8FEHR2Q++7tLzzcvy11x+DffQCn8pY4tpq t832225DuzXX+W507NJl5123Tl2f7R2CgC8oOIGDB0744Ya/OTd1tDkh9kvvWpWI5ET30F2P /5hfrjkAltpXXuacbw565lqLN7roqIdO3uKYsu7669FlCvvstMcge+2456777rz37vvvsd8u g/DAF//cPnPWAlYgXzALOWx+OG/87MzrpVRxxhobMk0l66u939O3i3wt5MeTi/OQl1WM1x3f 0j33e4cfNPLjmx/cZ718NMH3xMI/tvcAlN/i6KeVlQxjfNVDB8f8Vzn3xU+Av0IgTEByPds8 gXgXzKAGN8hB4kFwO/ULFlHgYkEPLpBkDvwfA9n3QR+FEDRxIQowRJOp7I1thXJIIfhaqKIL QuQ3whnhUZRlhJSUDYDv0yELechEISXDF9I71rJM2MQqmoCKVsyiFv+3yMUuevGLYAyjGMdI xjKa8YxohE4CPVCANBaPNj+AI51i0EY3+q4yRrhecbTExwdoiQF8/CMEAllHBRCykHZkDkkU kT9zNLJ8kLRbA/5YR0QCoI+GLKQgJ6nJTiZSOou0yCOfmKzFKCUQlPTjJT2ZST+ycpWfDB5e YGi+vBBjjavc5AIq+Upd7rKXgYxlc0L5FWQdcA9ypAAhd/nLZrbSAZv05TOFmRxidsZ6s8Ei JwV5SG4u05XBhKYlqWkcGoZjhNjkhjkv0EZpSnOaEfCmM8lZTYaUEjJCNCYQK1BJWHLSlYAc ZzRfSU8wfvOfv/TlQBUazoKOcZwOjSgHICr/0Ypa9KIYzahGN8rRjnr0ow6iaHNEagKSghGd GUjmcChqyYM2VJy6PCg0B+nShmLSkJNMI0o1ExdB1LSlM2VmUHFKVAmYVKiXHGo/h2pG00wQ hujTX1BQmVRVApKpEEWkJpXJz6vmFKcsdSMRQ2OR/eHvrHPMaVi9ytaqfrWoJj1qUd2K1HbG U6yToSEQT0PWDbyTrrncKlLb2sm/yrWlN81lUhM716bmVY8iPGVElEdFxgLWq1q1amM3e1nN MhWsg+3sGKfSmGiYE49+baxIl8rZzH6Ws2/1LGhVi9fL/LC0FcxnWoMK1MGy1q2CJaprYzvI 2PY2uLAVI2tgIYy9L+51JDsFZ0xtmtiXarW6lg3ta19KV8bKFaTG+e4eVwpe6Yh3vHA4b3l/ p97UojEBADs= ------=_NextPart_000_0001_01C6542C.E261EB00 Content-Type: image/gif; name="A.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c63b06$077134e0$0403a8c0@mlto> R0lGODlh9QBXAKIAAP//////zP/MmcxmM5lmM5kAAAAAAAAAACH5BAAAAAAALAAAAAD1AFcA AAP/CLrcbsZJKKu9i+LNr+5gKI5kyXxetKEm5Lqnas4KS2Mvm8vAbtm2zGs1rAQfvF+ypJMd OU9Q9CbkfVAa7LK2PF63wjBy2gM3yNCuCm00S91U7nmdzNa3QPy9PR/rKVowYUUxghNqcoRV gYY5c40RilyGZWVPUWxyhzF8nJueYk1VYpWTpKWofaqQoFqqqF+mmrNfTmCYmV5Wt3ufp6Wu nqKpwL2vob3DqcNBzMnGoG2Uvp+X0NHLu792q887eq/O4drC0+Llx7/Sujh0KaPU2a3P3fVp Ptvu89i1sej/6oi1Q9Ru1jqBBrPhI8YNoCY2uOyRCpavITKJCTMWxKYk/5NGhraQJLT4kF6a dw5hkQtIshhGhCBHriTikaKyPBP9qQx5qpmbmzxl5ry4j5bOMQ4pdsilTCVHRgpdSbI0LWC+ Qnn63WEVzdGgqn4YiZ2a7pDPRx7jqF3LlkbatnDjyp1LF+7bunjz6t1L9y7fv4ADCx5MuLBh AAMUJEasuDHjx4sjO5YMebLlypgpaz7MuTOGAQMCgBY9QMDo06FRmy6NmvRq0q5Vt56duvZr 0Ks96969ILSAAAF+Axf+m/jw4MeRF0eunLnx586bQ28efDHv64Z9H18uvbv35dyNRwe/PTl1 8r+tY68Lx62HEtoJFDBNwHQBAgQCFCi9X8B8+f8EpHZfaAXcl99v+NlnH34ByHdfcAZCWJ18 vt0nAIPpradXezi89wN8yFHoX3D1kTgAfvXld2Jx9S0X4HIDFNDggSXS5599xxnw23w3Nvif duppOBeHHhpRZAilhZhgfTEyiOKTF+IXGoUAQBjefwIsmN+TwRlQ43wnkpjlk9qZJiR7lmRw wodb9aMmJWQhJtyTMvpX2pgyFjhliwj212CZM8qIGJOBJnnhfPqJqR+BJ2Io2pnsOVHDmkZa QamlsEyqpgOGrmiho/oZEKqJ4GHY4nEAFoeojXVKKICoN74qJoDIBQlpW5j2oOkEm+q6KabA UspAaEr62KV8JKZYIn7/DzKr6oHKGeAbgDIGGICOJ1qoX3oDjslfjY/eGleua3y4a7C/XupV A4YmF5678EYnr3j0xlvvvOGKa5ew5a4jaboAawqHaN2hV/DBBieM8MIJ26pvHLnC5GvAWVxq ca/D1gYbbRtrzPHHHofc8ci0PWyXJJecMYotWmElQWKPhhsaYzHDbHOVN9eM8846V6bzzznb HMBjJuNFZNFIJ82E0kw3fcPRTkct9dRUV2311VhnrfXWXHfdmV8beS12CwR1MglYH60FiSCE kNU22mNT8ZZNULMVia91rBnxxLruHTfEZTvilT+ARMJyy1apvLeli+st7N9q4SQQ3WcbbpRT /2k7vivGd2PMd+ebQy43QeasRFJLmIewdsWJbKN56KK7FThXlQflElpw+/vN7rz3/k3sgItU iEFnEcURCaB7znfojD8O/AySJwWO8YUPtULfD2Sv8uPJ1/287pZTtYs+xyAu/vHZ3928wMqv D/v3wK8Ojyznyg///e/jr//+/Pfv//8ADKAAB0jAAhrwgHIBmwgKgMDCrEt1DyxLXBjYQMEc ZSm2+0uBNtiADVJQAR78oANCyIAQitCA53BJ9UpSCfM9EA0FAgAFPxjDDtLwhCC84QJqWEGh YE5wPAHi5XQCQwaekIcl1OEIlShDHCIwhacLIjmi9xYP2tCKOdyhE/95yEUsNhCK5BOf7VD3 uxGQMIto7KIE1LjECoKReNNjoQRJgEU2NtGLV+RgG90YFDuEsXhybGEfoWbEGTIxiRuooR2/ iLIVKqUnh4sk+joIwiai0ZI2RGQmL4nEHjbtjDnUYyiPeMNOgtKTUnMiKg2oylW68pWwjKUs Z0nLWtrylp1ppWF0GQde7uaREMxdXnAISjziMY9JFOUILWBMZTqTkrcCJgYTh5diLnOHlcTm NbMpw0Qys4Tc7KY4xblFcUWRdhZx4SDhxCEjblOb2RRhOeHpy1bKM5wzxKYqfakbRRBOinBI J/kuWAF3QvOb40woPMfJS13eM6H5rKQ99QWmlMtVDisCtegCialMeoLznaXcJwaaiUQOFpKY FDVGRh+h0RWK0XuhLKgmtdhRfK7xpgiN50fBScODQqqiP5TiUAhKx3B69ALzNKpSFerTiCrV oArlp2eA6keLHoWd1uNARB/a0J1ydadgBalNP9rTsAopK4HYyViGh9FJJrOkojQhTZvqzJou dIlwNWUyfYpLme5Gqr3s60ivA1gaFFawujlsUcWVAAA7 ------=_NextPart_000_0001_01C6542C.E261EB00 Content-Type: image/gif; name="MO.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c63b06$076ec3e0$0403a8c0@mlto> R0lGODlhbQFWAKIAAP//////mcyZZsxmM5kAAAAAAP//zAAAACH5BAAAAAAALAAAAABtAVYA AAP/CLrcWsXJSasFEN7NcnwZ9nFkuXnmOaacxjauK8lvbU90F693n7cengi2+tWCoZuxB2JW jMjk7LMcOhdIR1CL0nWx0OqVlRNLRUWeWKkWmtbjeJNbCsuJuvx8L6P5f193R21PQn94goBu JHCCTnaMbo02ZVSEVmB7fJgPVn9JOyNbXpVno1mIdGihO6RpZ6mZnn2BoyCwtquir4eBt4eq FCituhGfvbAWxLKVwqKcGsu0Q13TfLuympyxetvAmNKLik3V2NnX2eHo1+br29qpoO3g7VKT s4jNUx2b+O9o3JZ1cwfvXDd9cyAZhBcq4Dx9CvVAvLTvX5R5/qBZykex/5BBgd5wJdyYcaA2 Vg4/LvpHLxbIX7lULkR47BSumydJqixXsefIcyCDrgR6CaHLTOZevqP5hSk3k+k6Kp10EarT ha6y/pRIEVjElC2ZFe3oM2ROZ1jAWJtqiCzPg2ShEtRYkOrQcXDlEilFciLHv8ECZ/Q69qnV wnrBDST21ayqq1hnpnGpM7FhyfEmq6go9KzjxjLDbhV72SJi0gcX65ym0JrobwXVejH5ba3m 0qaJUl5nO2roT3Xv7lp927XRxK5f38bgUaM8HL5iSm9bBRXt5bms414ynUut7/Z4LacXgm0U UiWHib8+5bxaRTd9OZpPv779+/jz69/Pv7////8ABijggAQWaOCBCCao4IIMNujggxBGSMEA ClAIgIUYVqjhhRtmyOGHHobY4YggkuihhCimqGIJAwxgQIsvugjjjDIOEACNMeaI4441xnhj jzz+qGONKxZp5JELuBiAAUsyaYCTSzYppZNQVhnlk1dmiSWVWna55ZVQWojkmGQ2aCOXW1Jp 5ZNofummmlqu2WacXr5Y5p39DXVEfsk04CKTAxAQgAA2CkAAATYSIIChiwoaqKKDHiqAAYcq 6mSLkRpgKKI3Hqqkp0sKqmmgnxKQI6B4pqqfnmhZlgg/Eyj5IqKGamrqkgMQSmuNTVoaZa5Q 1opprU9iKiixTN4qaAD/plKqKKbFqiqtfaxCh9uraUlwJq6BGhopjS2G22munU4aqgBTCmqp oeSGq6yNoUZ6LrPhynrjtPi+ag+sMDDXCRXvpYVSwL8ELN+Fl7pr66K2mippjAzPai6wUuZ6 K6OTPoruqMraCuikihYAI6r5ljxGH51k2+8zAPubMsrZGsJvERMmHIDI8jp5qLOAnmkzpeZe yqmtv1oMpahIB8Dsuez+avLTTND8Mg7/Tu0yv1e3jPUzKvsZZqKmbvpup7iCqnGyGzvJKJNi 56jopp+y/fCN6CJKpZhQ5/3GzClrUbW/Wm89M8x9S63tnGlOifjiijee+ONoOn6v3pTXwffV /5cD3rfgXVtdONZ+ein6mqOXTvrppl+Jd+WsC7P1SlxrnvXmhsecOeYM8Djk7rr3DuTvvAPv e+vEO4MT1X673NRew/EC+g8ilih99NSbaP30159Y/PbKcO/99ylWC/745Jdv/vnop6/++uy3 7/778MfP4D11iC///UjiZe171dk/SPOWkEcYaEE//KmvgHSJDbWYE7jNzU5wtTMg/vS3BZuQ JhoA5J+r/uZAzEWQZhGUoPzwor+wVJA4yjmB8pLHua4ZA3QijB8JjdIb1OTlDQRkReDUwI8Q xvB9FAyPKx5SGZgU8CJITKISq/LDEbZlL5qIyEsQOAPcyeyDPYRhE//bV8LR5MaGGPTNBV4o s5U9L4ud2yIXs6DD2XyRHTkcD9XIiEYOerCOuFOjHh0UnhwSTHl99N8eBykgQRLykIhMpCIX ychGOvKRkIykJCdJyUpaUpFUZAEBLsnImADhYAqMwyY5mcjkACEy96nUoRqgSgaocpQSeKUr ZUlKqPnlJ2HEpTEyCJMNAmCVo4TlKlkpTFjOcgHD/KUxa2nL07TRNuVBoXGqBUxixrKY10Qm Npmpt1umJymaCWIKWjlLcipTm9lUQDJpyc2SeVMg1iGMd0BpAXauM5jbtKY6l7nPdrrTmZWR YhFZMs5K9fOgyjQnMRWKTn/ma5q3iKIkwon/DYiSYJPDvGc6K5DRfDp0WtPZpUR9EkcNotKV 6jynSlfaUIS2VKMfjek+DapNms50mfdM5k35KVOH8rSnQK3PT4NK1KIa9ahITapSl8rUpjp1 qUMVUFSdMNWnJpAM9MTPUI2pUIaWk6teRSYFzPnKYnKVlVZtTijVmkmqMnSdKP1lXNEq1pTW c6xzjasw7UrXtHJmPbypR1MEawpqytUBGK2rXc+K2LlWdat55etef1rVp34HjAFUBgpTeIHE 0nWvdWVsXw9L2glEVbSKnSxe/bo/MU6zsG8ZjCFZSlqwwlWxeTUrZetpU9wmVK695StrwSJb 77gjl8WY7W93Ws3QgUZWuDyNLkcju1vQ+na4nimuCQUrGhsEs7HQDS94hXvd0o63tJC1Lnmx 6xh/PGc0wBEjQcHLT/V+N7W4ve96zTta1OrVt5V1KnyAU1L+vYJ5crxmcKHb265+9cGm5Whw pVvT0bJXWgHeT4aZsOELq6jD+QHxC0Ts4R+SuAQnLmoCAAA7 ------=_NextPart_000_0001_01C6542C.E261EB00--