From owner-ietf-ediint@mail.imc.org Sat Jan 6 12:18:05 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16454 for ; Sat, 6 Jan 2001 12:18:03 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA00338 for ietf-ediint-bks; Sat, 6 Jan 2001 08:37:44 -0800 (PST) Received: from tor-exchange.goldfarbconsultants.com (mail.goldfarbconsultants.com [204.101.222.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA00320 for ; Sat, 6 Jan 2001 08:37:42 -0800 (PST) Received: from shieldsmtp.goldfarbconsultants.com (SHIELDSMTP [151.51.192.28]) by tor-exchange.goldfarbconsultants.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Z5MVK7VC; Sat, 6 Jan 2001 09:22:12 -0500 Received: FROM mail.mindspring.com BY shieldsmtp.goldfarbconsultants.com ; Sat Jan 06 06:20:16 2001 -0500 From: To: Date: Sat, 6 Jan 2001 02:39:27 Message-Id: <169.566627.813192@mail.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH! DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL TO OUR OFFICE. YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with no extra charge! UNLIMITED TRAFFIC -- no extra charge! FRONT PAGE EXTENSIONS are FULLY SUPPORTED. A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE. FOR DETAILS CALL 1 888 248 0765 if you are outside the USA, please fax 240 337 8325 Webhosting International From owner-ietf-ediint@mail.imc.org Mon Jan 8 12:37:31 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11778 for ; Mon, 8 Jan 2001 12:37:31 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA19623 for ietf-ediint-bks; Mon, 8 Jan 2001 08:43:41 -0800 (PST) Received: from mail.healthlift.com (www.smokestoppers.com [207.106.24.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19616 for ; Mon, 8 Jan 2001 08:43:39 -0800 (PST) Received: from HL1 [216.233.45.163] by mail.healthlift.com (SMTPD32-6.00) id A2D9190C008E; Mon, 08 Jan 2001 12:03:21 -0500 Message-ID: <062c01c07993$bb3ca0c0$5501a8c0@HL1> From: "Jim Hurd" To: Subject: AS2 returning EDI Date: Mon, 8 Jan 2001 11:54:57 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0629_01C07969.D242E420" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0629_01C07969.D242E420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would like a future AS2 to clarify how EDI should be returned in the = http response. This is needed for healthcare transactions like = eligibility checks. I assume that the generalized receipt mechanism = could be used, but isn't this important enough to standardize? Are there = already proposals to this effect that I am unaware of? Jim ------=_NextPart_000_0629_01C07969.D242E420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I would like a future AS2 to clarify = how EDI should=20 be returned in the http response. This is needed for healthcare=20 transactions like eligibility checks. I assume that the generalized = receipt=20 mechanism could be used, but isn't this important enough to standardize? = Are=20 there already proposals to this effect that I am unaware = of?
 
Jim
 
------=_NextPart_000_0629_01C07969.D242E420-- From owner-ietf-ediint@mail.imc.org Mon Jan 8 19:08:01 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18878 for ; Mon, 8 Jan 2001 19:08:00 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA10955 for ietf-ediint-bks; Mon, 8 Jan 2001 15:28:22 -0800 (PST) Received: from infobro.com (InfoBro@black.infobro.com [63.71.25.39]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA10951 for ; Mon, 8 Jan 2001 15:28:20 -0800 (PST) Received: from red (unverified [205.161.100.60]) by infobro.com (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 08 Jan 2001 18:27:48 -0500 Received: by localhost with Microsoft MAPI; Mon, 8 Jan 2001 18:27:43 -0500 Message-ID: <01C079A0.B0FD1C40.eric@infobro.com> From: "Eric D. Williams" To: "'Jim Hurd'" , "ietf-ediint@imc.org" Subject: RE: AS2 returning EDI Date: Mon, 8 Jan 2001 18:25:20 -0500 Organization: Information Brokers, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim; The only previously stipulated mechanism for authentication that is 'definite' is the following: "It is expected that companies following the GISB AS2 profile will protect their web sites from unauthorized access through the use of basic authentication (username/passwords), as defined in the HTTP specification. GISB is not "requiring" the use of signed receipts; however, signed receipts are allowed between consenting trading partners." [http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-07.txt] Now, there may be an allowable construct in the healthcare industry under the HIPPA where the provider should be obligated to establish a vetting process for individuals or entities requesting information. with regard to the establishment of these procedures it would seem to me as an encumbrance on the provider to establish a mechanism (easily reached by the client/patient/service recipient and physician) which provides a lag for outside requests/denials ["for disclosure or use for research purposes, an Internal Review Board (IRB) or Privacy Review Board must make several determinations about the need for the PHI and the ability of the researcher to protect the information."..."of health and non-health items and services, disclosure by sale, rental, or barter, disclosure to an employer for use in employment determinations, and use or disclosure for fundraising."] to access. With regard to your specific query no other 'standard' for HTTP presentation is indicated that would augment the aforementioned - BTW, the use of PGP for additional security integrity (not authenticity) has been addressed. Hope this helps. Eric Eric Williams, Pres. Information Brokers, Inc. Phone: +1 202.889.4395 http://www.infobro.com/ Fax: +1 202.889.4396 mailto:eric@infobro.com Pager: +1 301.303.8998 For More Info: info@infobro.com PGP Public Key http://new.infobro.com/KeyServ/EricDWilliams.asc Finger Print: 1055 8AED 9783 2378 73EF 7B19 0544 A590 FF65 B789 On Monday, January 08, 2001 11:55 AM, Jim Hurd [SMTP:hurd@healthlift.com] wrote: > I would like a future AS2 to clarify how EDI should be returned in the http > response. This is needed for healthcare transactions like eligibility checks. > I assume that the generalized receipt mechanism could be used, but isn't this > important enough to standardize? Are there already proposals to this effect > that I am unaware of? > > Jim > > << File: ATT00004.htm >> -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUBOlpMYAVEpZD/ZbeJEQImwACg1PZWaIBTQeLBtiEqtcMrsKKXPEAAn3YG 0i5pKiPonHyXnIVbt5d82yop =0dmH -----END PGP SIGNATURE----- From owner-ietf-ediint@mail.imc.org Tue Jan 9 13:46:43 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19403 for ; Tue, 9 Jan 2001 13:46:43 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA21004 for ietf-ediint-bks; Tue, 9 Jan 2001 09:53:37 -0800 (PST) Received: from d04s.eskye.net ([207.12.237.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20996 for ; Tue, 9 Jan 2001 09:53:30 -0800 (PST) From: lzou@eskye.net Received: by D04S with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 11:57:31 -0600 Message-ID: <9547B8C72FC6D411AA27009027AF94520BFAC0@d02s.eskye.net> To: ietf-ediint@imc.org Subject: Need help on AS2 Date: Tue, 9 Jan 2001 11:57:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My company is planning to integrate with partner companies using AS2. I have read all related documents that I down loaded from the web site http://www.ietf.org/html.charters/ediint-charter.html but I still don't have a clear picture for how to implement the AS2. If you can give me some sample code or case study information, I will appreciate it. Thank you. Liping Zou -------------------------- email: lzou@eskye.net phone: 630-799-6972 From owner-ietf-ediint@mail.imc.org Wed Jan 10 01:01:13 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28185 for ; Wed, 10 Jan 2001 01:01:12 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA09164 for ietf-ediint-bks; Tue, 9 Jan 2001 21:12:25 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA09160 for ; Tue, 9 Jan 2001 21:12:24 -0800 (PST) Received: from divyaroot.India.Sun.COM ([129.158.228.35]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA05668 for ; Tue, 9 Jan 2001 21:17:19 -0800 (PST) Received: from badri (badri [129.158.226.153]) by divyaroot.India.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.0) with SMTP id KAA26111 for ; Wed, 10 Jan 2001 10:47:18 +0530 (IST) Message-ID: <107401c07ac3$9505ca90$99e29e81@india.sun.com> From: "Santanu De" To: References: <9547B8C72FC6D411AA27009027AF94520BFAC0@d02s.eskye.net> Subject: Re: Need help on AS2 Date: Wed, 10 Jan 2001 10:40:00 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, We are planning to make our B2B product AS2 compliant- and moving in this direction, we have decided to introduce an AS2 client and a AS2 compliant HTTP server in our product. However design issues still remain bleak. On the same lines as Liping, I'd request you to help me in this direction - i.e to implement AS2. Sample codes or guidelines will be just great. We have figured out that in order to implement the AS2 client, we need to do three things- 1) Package the data using standard MIME packaging. 2) Encrypt using S/MIME. 3) Delegate the HTTP client to send the data across to the trading partner. However, a few things are still in dark. Like, where do the specific AS2 headers like AS2-from and AS2-to come from? Are they a part of the MIME packaging in 1), or a part of the HTTP headers attached in 3)? Does it mean that the HTTP client needs to be changed accordingly? We are still to figure out the server implementation. We need a few information in this regard as well. Like, who sends the receipt, and who sends the reply? In case of synchronized reply, do we still send the receipt? Or the reply implicitly guarantees a receipt? When we are sending XML as a payload, how does the server delegate the responsibility to the XML parser? And several other issues- which are not discussed in detail. Actually, any input for AS2 implementaion will be highly appreciated. Thanks, Santanu. ----- Original Message ----- From: To: Sent: Tuesday, January 09, 2001 11:27 PM Subject: Need help on AS2 > My company is planning to integrate with partner companies using AS2. I > have read all related documents that I down loaded from the web site > http://www.ietf.org/html.charters/ediint-charter.html but I still don't have > a clear picture for how to implement the AS2. If you can give me some > sample code or case study information, I will appreciate it. > > Thank you. > > Liping Zou > -------------------------- > email: lzou@eskye.net > phone: 630-799-6972 > > From owner-ietf-ediint@mail.imc.org Wed Jan 10 08:43:21 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16252 for ; Wed, 10 Jan 2001 08:43:20 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA29094 for ietf-ediint-bks; Wed, 10 Jan 2001 05:04:59 -0800 (PST) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA29089 for ; Wed, 10 Jan 2001 05:04:57 -0800 (PST) Received: from apollo (user-2injpkr.dialup.mindspring.com [165.121.230.155]) by blount.mail.mindspring.net (8.9.3/8.8.5) with SMTP id IAA14700; Wed, 10 Jan 2001 08:09:51 -0500 (EST) From: "Dick Brooks" To: "Santanu De" , Subject: RE: Need help on AS2 Date: Wed, 10 Jan 2001 07:14:56 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <107401c07ac3$9505ca90$99e29e81@india.sun.com> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Santanu, >We have figured out that in order to implement the AS2 client, we need to do >three things- >1) Package the data using standard MIME packaging. >2) Encrypt using S/MIME. >3) Delegate the HTTP client to send the data across to the trading partner. The profile you identified above does not meet the Energy industry requirements for AS2. >However, a few things are still in dark. Like, where do the specific AS2 >headers like AS2-from and AS2-to >come from? Are they a part of the MIME packaging in 1), or a part of the >HTTP headers attached in 3)? Does >it mean that the HTTP client needs to be changed accordingly? The AS2-To and AS2-From headers are not part of the AS2 spec, yet. These were added by some vendors during an interoperability test when they discovered that certain HTTP headers "collide" with e-mail headers (e.g. From). There is also a risk that other e-mail headers used by AS2 could collide with future versions of HTTP. For example if a future version of HTTP includes a Subject or Message-ID header, the AS2 spec may have to prefix the e-mail versions of these headers with "AS2-" in order to avoid a collision with Web Servers. This is due to the fact that AS2, e-mail profile, doesn't follow proper MIME conventions for header extensions (X-). I've already addressed this with other AS2 folks and hopefully we'll have it resolved before the next AS2 spec is released. >And several other issues- which are not discussed in detail. Actually, any >input for AS2 implementation will be highly >appreciated. Group 8760 has implemented EDIINT AS2 within the Energy industry. A typical implementation of AS2 following the Energy industry profile, with no customizations, takes on average, 3 days and is "significantly" lower cost than other, similar approaches, like RosettaNet. Dick Brooks (EDIINT AS2 co-author) http://www.8760.com/ From owner-ietf-ediint@mail.imc.org Wed Jan 10 09:20:21 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17448 for ; Wed, 10 Jan 2001 09:20:20 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA01300 for ietf-ediint-bks; Wed, 10 Jan 2001 05:36:12 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA01291 for ; Wed, 10 Jan 2001 05:36:11 -0800 (PST) Received: from divyaroot.India.Sun.COM ([129.158.226.35]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26265; Wed, 10 Jan 2001 05:40:59 -0800 (PST) Received: from badri (badri [129.158.226.153]) by divyaroot.India.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.0) with SMTP id TAA18224; Wed, 10 Jan 2001 19:10:57 +0530 (IST) Message-ID: <017201c07b09$f4f6a1e0$99e29e81@india.sun.com> From: "Santanu De" To: "Dick Brooks" Cc: References: Subject: Re: Need help on AS2 Date: Wed, 10 Jan 2001 19:03:45 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Dick, Thanks a lot for your prompt and valuable input. However regarding the industry profiles, if you'd elaborate a little more, it will be still more useful to us. Initially, we thought to stick to the Energy Industry profile (GISB)- but later advised by our product marketing team, we are planning to implement AS2 in our product in such a manner that it "CAN CATER TO THE NEEDS OF ANY INDUSTRY", the reason given by the marketing team was that several of our customers want an AS2 compliant product- and not all of them (in fact, most of them don't) belong to the energy industry. I understand that there are distinct profiles adopted by different industries like the Energy Industry and the Healthcare Industry(correct me if I am wrong). But will it be possible if we want to implement a far more generalized AS2 in our product which can take care of all these profiles- and even any future profiles arising out of the AS2 specs? Thats excatly what the marketing team wants us to do- and thats what I am breaking my head at. A couple of other clarifications: 1- AS2-from/ AS2-to are part of the (modified/extended) MIME headers- and the HTTP headers remain the same. So we need not change our HTTP client. Tell me if my understanding is wrong. 2- The profile I identified earlier doesn't suit the requirements of the Energy Industry- does it mean that the Energy Industry will require a few more things, or that their requirements are "disjoint " from the profile identified? Will it be possible to identify a SUPERSET of all possible requirements of all possible industries- and yet implement it (the SUPERSET)? If its possible- then it'll address the demands of our marketing team- or else we'll have to take an alternative route/plan. In case the above works out (or its possible to work out)- what do you think will be the cost involved in the exercise in terms of effort required- provided we have a working SMTP client, a non-AS2 compliant HTTP client- and on the server side, a non-AS2 compliant HTTP web server? We shall highly appreciate your help in this matter. Thanks and Regards, Santanu De Lead Development Engineer- ECXpert iPlanet India Development Center Sun Microsystems (I) Private Limited Voice: +91-80-229 8989 (x27641) Email: santanu.de@india.sun.com iPlanet- A SUN|Netscape Alliance- visit http://www.iplanet.com ----- Original Message ----- From: Dick Brooks To: Santanu De ; Sent: Wednesday, January 10, 2001 6:44 PM Subject: RE: Need help on AS2 > Santanu, > > >We have figured out that in order to implement the AS2 client, we need to > do > >three things- > >1) Package the data using standard MIME packaging. > >2) Encrypt using S/MIME. > >3) Delegate the HTTP client to send the data across to the trading partner. > > The profile you identified above does not meet the Energy industry > requirements for AS2. > > >However, a few things are still in dark. Like, where do the specific AS2 > >headers like AS2-from and AS2-to > >come from? Are they a part of the MIME packaging in 1), or a part of the > >HTTP headers attached in 3)? Does > >it mean that the HTTP client needs to be changed accordingly? > > The AS2-To and AS2-From headers are not part of the AS2 spec, yet. These > were added by some vendors during an interoperability test when they > discovered that certain HTTP headers "collide" with e-mail headers (e.g. > From). There is also a risk that other e-mail headers used by AS2 could > collide with future versions of HTTP. For example if a future version of > HTTP includes a Subject or Message-ID header, the AS2 spec may have to > prefix the e-mail versions of these headers with "AS2-" in order to avoid a > collision with Web Servers. This is due to the fact that AS2, e-mail > profile, doesn't follow proper MIME conventions for header extensions (X-). > I've already addressed this with other AS2 folks and hopefully we'll have it > resolved before the next AS2 spec is released. > > >And several other issues- which are not discussed in detail. Actually, any > >input for AS2 implementation will be highly > >appreciated. > > Group 8760 has implemented EDIINT AS2 within the Energy industry. A typical > implementation of AS2 following the Energy industry profile, with no > customizations, takes on average, 3 days and is "significantly" lower cost > than other, similar approaches, like RosettaNet. > > Dick Brooks (EDIINT AS2 co-author) > http://www.8760.com/ > > > From owner-ietf-ediint@mail.imc.org Wed Jan 10 10:09:56 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18788 for ; Wed, 10 Jan 2001 10:09:55 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA04199 for ietf-ediint-bks; Wed, 10 Jan 2001 06:25:59 -0800 (PST) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04193 for ; Wed, 10 Jan 2001 06:25:56 -0800 (PST) Received: from apollo (user-2injpkr.dialup.mindspring.com [165.121.230.155]) by blount.mail.mindspring.net (8.9.3/8.8.5) with SMTP id JAA25442; Wed, 10 Jan 2001 09:30:54 -0500 (EST) From: "Dick Brooks" To: "Santanu De" Cc: Subject: RE: Need help on AS2 Date: Wed, 10 Jan 2001 08:35:59 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <017201c07b09$f4f6a1e0$99e29e81@india.sun.com> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >Initially, we thought to stick to the Energy Industry profile (GISB)- but >later advised by our product marketing team, >we are planning to implement AS2 in our product in such a manner that it >"CAN CATER TO THE NEEDS OF ANY >INDUSTRY", the reason given by the marketing team was that several of our >customers want an AS2 compliant product- and not all of them (in fact, most >of them don't) belong to the energy industry. The "Generalized Receipts" profile of AS2 IS INDUSTRY NEUTRAL. The Energy industry is following the "Generalized Receipts profile" within AS2 (we've been calling this the GISB profile). The Generalized Receipt profile is also being used in Healthcare and the Automotive industry. The Generalized Receipt mechanism defines metadata (headers) that are common to all industries, for example, here are some commonly used headers from the Generalized Receipt profile of AS2: AS2 Header Element Name Description ----------------------- ------------------------------------------------ -------------- To identifies the intended recipient From identifies the sender Version version of the specification being followed input-format identifies the type of data being sent (X12, XML, jpeg, etc.) input-data this element contains the payload Receipt-Disposition-to indicates that a receipt is requested Receipt-Report-Type indicates the type of receipt to return (each industry defines their own receipt types) Transaction-set a unique identifier providing further description of the data (e.g. PURCHASEORDER, HEALTHCLAIM, INVOICE) Receipt-Security-Selection Used by the sender to request a signed receipt There are more headers than this in the AS2 spec, but I won't list them here. Please identify which of the above headers from AS2 your marketing group is calling INDUSTRY SPECIFIC, or have them contact me and I'll be happy to discuss this with them. Another significant consideration about the Generalized receipts approach in AS2; it uses "Multipart/form-data" packaging, which IS an industry standard, ref: RFC 2388. In fact, multipart/form-data is the most popular/widely used standard on the Web for exchanging data over HTTP. It is implemented in all commercial web browsers, that I'm aware of (e.g. IE5, Netscape) and there are about 30 vendors who provide solutions B2B solutions using multipart/form-data packaging (Group 8760 is one of them). On the other hand, the e-mail packaging defined in AS2 is non-standard and unique to AS2; it is only implemented by a few vendors, that I'm aware of. Thanks, Dick Brooks (AS2 co-author) http://www.8760.com/ From owner-ietf-ediint@mail.imc.org Wed Jan 10 10:44:21 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19583 for ; Wed, 10 Jan 2001 10:44:20 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA05018 for ietf-ediint-bks; Wed, 10 Jan 2001 07:04:28 -0800 (PST) Received: from nexus.webmethods.com (IDENT:AUser@gw1.webmethods.com [208.234.160.254]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05012 for ; Wed, 10 Jan 2001 07:04:27 -0800 (PST) Received: from Patrick (IDENT:AUser@gw1.webmethods.com [10.1.1.254]) by nexus.webmethods.com (8.9.3/8.9.3) with SMTP id KAA07361; Wed, 10 Jan 2001 10:09:24 -0500 From: "Patrick Condon" To: , Subject: RE: Need help on AS2 Date: Wed, 10 Jan 2001 10:13:04 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <107401c07ac3$9505ca90$99e29e81@india.sun.com> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id HAA05018 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA19583 Seven companies have AS2-compliant solutions. If you need an existing solution, I am sure any one of us is happy to help. Of course, I am partial to webMethods, but all seven of us have completed and passed interoperability testing with each other, and should meet your needs. pat --------------------------- Seven Vendors complete First Secure EDI over the Internet (based on HTTP) Conformance Validation Test under UCC sponsorship “Important Step in Enabling eBusiness,” says co-author of the AS2 spec, Rik Drummond of Drummond Group, Inc. Austin, TX; December 20, 2000. The Uniform Code Council (UCC), a leading global standards organization, and Drummond Group today announced that bTrade.com, Compaq Computer Corporation, Cyclone Commerce, IPNet Solutions, Netfish Technologies, Sterling Commerce and webMethods, Inc. have achieved mutual interoperability by passing the first B2B AS2 Conformance Validation Test. This draft standard allows vendor applications to communicate EDI data over the Internet (via HTTP) in a secure manner. COMPANIES PRODUCTS bTrade.com SecureAccess2000, EDIINT engine vs. 1.38 Compaq Compaq ASx Transport Service (CATS), vs 2.0 Cyclone Commerce Cyclone Interchange, vs 3.1 IPNet Solutions eBizness™ Transact 3.3 Netfish Technologies XDI Product Suite, vs 4.2 Sterling Commerce E-Marketplace Enabling Services, vs 3.3 webMethods, Inc. webMethods B2B™, vs 3.6 “AS2 gives a company the ability to exchange data in real time in a secure manner over the Internet to other AS2 interoperable companies. Using this technology, gives a high return on investment to a company,” says Rik Drummond, CEO of the Drummond Group who managed the testing process. “It will greatly decrease the cost of doing business in EDI and one can expect savings of 60% or more over traditional VAN costs.” Drummond Group, who also facilitated the testing process for three years of AS1 testing, has been instrumental in bringing a new level of interoperability to EDI over the Internet products. Their test process provides a venue for vendors to test and correct their software systems in a non-competitive environment. “In our experience, we found that testing against a single implementation is not as effective as testing among the participating vendors,” says Beth Morrow, Vice President Drummond Group. “The vendors are able to gain much more insight on their product’s functionality in the marketplace and in this way ensure interoperability.” Another round of testing is planned for the year 2001. Drummond Group, Inc. (www.drummondgroup.com) provides B2B strategy, research analysis, and industry pilot facilitation. Founded by Rik Drummond, a recognized leader in eBusiness and international standards organizations, the group represents best-of-breed in the industry on horizontal infrastructure technologies and standards which support B2B commerce. Key areas include XML, Internet EDI, PKI, EAI, architecture, integration, interoperability and B2B business models. Drummond Group offers an integrated vendor neutral approach that concentrates on the intersection of technology, business processes, and culture of an organization to build strategy that reduces risk, lowers cost, and fosters e-Business. Contact: Beth@drummondgroup.com, 512-335-5606. Uniform Code Council (www.uc-council.org) The Uniform Code Council, Inc. (UCC) is a not-for-profit standards development organization originally founded in 1972. The UCC, along with its global partner EAN International, administers the EANUCC System, which includes Universal Product Code (U.P.C.) and other tools to facilitate efficient global trade. The EANUCC System is used by over 850,000 member companies worldwide. The UCC functions as a primary resource for business and industry, developing worldwide identification codes, data carriers, and electronic commerce. -----Original Message----- ----- Original Message ----- From: To: Sent: Tuesday, January 09, 2001 11:27 PM Subject: Need help on AS2 > My company is planning to integrate with partner companies using AS2. I > have read all related documents that I down loaded from the web site > http://www.ietf.org/html.charters/ediint-charter.html but I still don't have > a clear picture for how to implement the AS2. If you can give me some > sample code or case study information, I will appreciate it. > > Thank you. > > Liping Zou > -------------------------- > email: lzou@eskye.net > phone: 630-799-6972 > > From owner-ietf-ediint@mail.imc.org Wed Jan 10 10:56:28 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19811 for ; Wed, 10 Jan 2001 10:56:27 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA06117 for ietf-ediint-bks; Wed, 10 Jan 2001 07:14:56 -0800 (PST) Received: from omx1.stercomm.com (omx1.stercomm.com [209.95.244.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06106 for ; Wed, 10 Jan 2001 07:14:54 -0800 (PST) Received: from imx1.stercomm.com (imx1.stercomm.com [10.117.193.42]) by omx1.stercomm.com with ESMTP id KAA04265; Wed, 10 Jan 2001 10:18:15 -0500 (EST) Received: from cmh0203xcn01.nsg.stercomm.com (cmh0203xcn01.stercomm.com [10.117.193.89]) by imx1.stercomm.com with ESMTP id KAA22894; Wed, 10 Jan 2001 10:21:11 -0500 (EST) Received: by cmh0203xcn01.stercomm.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 10:22:05 -0500 Message-ID: <5FD6397E455FD4118BAE000629383540D39213@SCIDUBMSG02> From: "Moberg, Dale" To: "'Dick Brooks'" , Santanu De Cc: ietf-ediint@imc.org Subject: RE: Need help on AS2 Date: Wed, 10 Jan 2001 10:22:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Dick Brooks [mailto:dick@8760.com] { much stuff omitted] > On the other hand, the e-mail packaging defined in AS2 is > non-standard and > unique to AS2; it is only implemented by a few vendors, that > I'm aware of. Sorry, Dick, but I think this remark is misleading. The so-called "email" packaging makes use of IETF standards for MIME, the security multiparts, and the specifications for Open-PGP and SMIME. It is as much based on standards as is the packaging that makes use of "multipart/form-data." The questions about how many vendors have or are implementing the specification are really not ones for the ietf-ediint list. I think it is time for someone to volunteer so that we can offload interoperability and implementation issues from this list. Anyone willing to host one? From owner-ietf-ediint@mail.imc.org Wed Jan 10 12:17:35 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21714 for ; Wed, 10 Jan 2001 12:17:34 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA13521 for ietf-ediint-bks; Wed, 10 Jan 2001 08:28:05 -0800 (PST) Received: from mailman.8760.com (portal.8760.com [209.149.125.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13512 for ; Wed, 10 Jan 2001 08:28:03 -0800 (PST) Received: by mailman.8760.com from localhost (router,SLMail V3.2); Wed, 10 Jan 2001 10:29:22 -0600 Received: from gamma [192.168.21.160] by mailman.8760.com [192.168.21.90] (SLmail 3.2.3113) with SMTP id 3117BAEED36A11D4BB0D0060974E38DD for plus 2 more; Wed, 10 Jan 2001 10:29:21 -0600 Reply-To: From: "Dick Brooks" To: "Moberg, Dale" , "Santanu De" Cc: Subject: RE: Need help on AS2 Date: Wed, 10 Jan 2001 10:24:57 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <5FD6397E455FD4118BAE000629383540D39213@SCIDUBMSG02> X-SLUIDL: CEDE89C1-E66A11D4-BB0D0060-974E38DD Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dale, > Sorry, Dick, but I think this remark is misleading. > > The so-called "email" packaging makes use of IETF standards > for MIME, the security multiparts, and the specifications > for Open-PGP and SMIME. It is as much > based on standards as is the packaging that makes > use of "multipart/form-data." My comment about the email packaging of AS2 being non-standard refers to the fact that neither RFC 822 nor RFC 2045 nor RFC 2616 define the AS2-to or AS2-From headers. In fact, these don't exist in the current AS2 draft (ref: http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-07.txt) nor any previous draft of AS2. I know AS2 will be enhanced to support AS2-To and AS2-From, but as of right now, these headers aren't defined in any RFC or Internet Draft. Is this factual? I also wanted to point out that the email packaging specification within AS2 doesn't follow MIME (RFC 2045) or RFC 822 (which defines the standard syntax for e-mail messages) specifications for extension headers. According to these specs extension headers are supposed to contain an "X-" prefix, reference this excerpt from section 4.1 (Message Specification/Syntax) of RFC 822: " extension-field = " Is my assertion about AS2's email packaging use of non standard header extensions factual? I don't believe I've been misleading at all. To the best of my knowledge, everything I've stated has been 100% factual. Please let me know, specifically, how/where you believe I've been misleading in my statements. Dick Brooks Group 8760 110 12th Street North Birmingham, AL 35203 dick@8760.com 205-250-8053 Fax: 205-250-8057 http://www.8760.com/ InsideAgent - Empowering e-commerce solutions From owner-ietf-ediint@mail.imc.org Wed Jan 10 12:19:32 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21745 for ; Wed, 10 Jan 2001 12:19:30 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA13520 for ietf-ediint-bks; Wed, 10 Jan 2001 08:28:05 -0800 (PST) Received: from mailman.8760.com (portal.8760.com [209.149.125.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13513 for ; Wed, 10 Jan 2001 08:28:03 -0800 (PST) Received: by mailman.8760.com from localhost (router,SLMail V3.2); Wed, 10 Jan 2001 10:32:04 -0600 Received: from gamma [192.168.21.160] by mailman.8760.com [192.168.21.90] (SLmail 3.2.3113) with SMTP id 3117BAEFD36A11D4BB0D0060974E38DD for plus 2 more; Wed, 10 Jan 2001 10:32:04 -0600 Reply-To: From: "Dick Brooks" To: "Patrick Condon" , , Subject: RE: Need help on AS2 Date: Wed, 10 Jan 2001 10:27:40 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: X-SLUIDL: CEDE89C2-E66A11D4-BB0D0060-974E38DD Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Patrick, When you say Webmethods has an AS2 compliant solution, which version of AS2 are you referring to, the current draft version at: http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-07.txt Dick Brooks Group 8760 110 12th Street North Birmingham, AL 35203 dick@8760.com 205-250-8053 Fax: 205-250-8057 http://www.8760.com/ InsideAgent - Empowering e-commerce solutions From owner-ietf-ediint@mail.imc.org Wed Jan 10 12:37:53 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22149 for ; Wed, 10 Jan 2001 12:37:53 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA16290 for ietf-ediint-bks; Wed, 10 Jan 2001 08:50:47 -0800 (PST) Received: from omx1.stercomm.com (omx1.stercomm.com [209.95.244.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16282 for ; Wed, 10 Jan 2001 08:50:44 -0800 (PST) Received: from imx1.stercomm.com (imx1.stercomm.com [10.117.193.42]) by omx1.stercomm.com with ESMTP id LAA18127; Wed, 10 Jan 2001 11:53:36 -0500 (EST) Received: from cmh0203xcn01.nsg.stercomm.com (cmh0203xcn01.stercomm.com [10.117.193.89]) by imx1.stercomm.com with ESMTP id LAA02246; Wed, 10 Jan 2001 11:56:32 -0500 (EST) Received: by cmh0203xcn01.stercomm.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 11:57:28 -0500 Message-ID: <5FD6397E455FD4118BAE000629383540D39215@SCIDUBMSG02> From: "Moberg, Dale" To: "'dick@8760.com'" , Santanu De Cc: ietf-ediint@imc.org Subject: RE: Need help on AS2 Date: Wed, 10 Jan 2001 11:57:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Comments in-line. > -----Original Message----- > From: Dick Brooks [mailto:dick@8760.com] > Sent: Wednesday, January 10, 2001 11:25 AM > To: Moberg, Dale; Santanu De > Cc: ietf-ediint@imc.org > Subject: RE: Need help on AS2 > > > Dale, > > > Sorry, Dick, but I think this remark is misleading. > > > > The so-called "email" packaging makes use of IETF standards > > for MIME, the security multiparts, and the specifications > > for Open-PGP and SMIME. It is as much > > based on standards as is the packaging that makes > > use of "multipart/form-data." > > My comment about the email packaging of AS2 being > non-standard refers to the > fact that > neither RFC 822 nor RFC 2045 nor RFC 2616 define the AS2-to > or AS2-From > headers. In fact, these don't exist in the current AS2 draft (ref: > http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-07.t xt) nor any previous draft of AS2. I know AS2 will be enhanced to support AS2-To and AS2-From, but as of right now, these headers aren't defined in any RFC or Internet Draft. Is this factual? That detail is not a significant basis for saying that the _packaging_ is nonstandard. As you well know, HTTP allows headers to be added without the X- qualifier. And if we use AS2-To and AS2-From in the final draft, we can ask IANA to register these, in my opinion. Some on the list have proposed using different header field names from AS2-to and AS2-From. We should continue to discuss what field to use on this list if there are reasons for one way of proceeding rather than another. And we should discuss these final issues at an IETF meeting to see if we can determine the consensus. >I also wanted to point out that the email packaging specification within AS2 >doesn't follow MIME (RFC 2045) or RFC 822 (which defines the standard syntax >for e-mail messages) specifications for extension headers. According to >these specs extension headers are supposed to contain an "X-" prefix, >reference this excerpt from section 4.1 (Message Specification/Syntax) of >RFC 822: In the same spirit, HTTP doesn't follow every rule of RFC 2045 or RFC 822. That is one very good reason to stop calling AS2 "email" packaging. (As you will remember me saying more than once before ;-). That is one very specific way in which you are being misleading. We are instead following MIME as used in HTTP which, as we are at pains to point out in the AS2 spec, differs in some details from the way it is used in the SMTP context. Because these differences do not make HTTP RFCs 2068 or 2616 nonstandard, I think it is misleading to say that the use of MIME in AS2 is nonstandard. Rather the usage of MIME that we recommend follows how MIME is used in accordance with the standards in 2068 and 2616, and that makes it standard. We are, after all, describing "HTTP Transport for Secure EDI." and that is why we adhere to RFC 2068/2616 on those points where HTTP MIME differs from 2045... It might have been simpler if the HTTP and SMTP MIME were identical (and they are very similar) but that is not the case. So as a group chartered to find an applicability statement of existing standards, we have followed the existing standards even when those standards diverge slightly. (It is, after all, to be expected that a binary clean transport might need to say slightly different things about packaging than one whose default is 7 bit...) From owner-ietf-ediint@mail.imc.org Wed Jan 10 16:18:58 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27232 for ; Wed, 10 Jan 2001 16:18:56 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA29558 for ietf-ediint-bks; Wed, 10 Jan 2001 12:14:12 -0800 (PST) Received: from gbo126-n.gillette.com ([151.208.27.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29552 for ; Wed, 10 Jan 2001 12:14:00 -0800 (PST) From: Mark_Mueller@gillette.com Subject: API client for Cyclone Interchange 3.0 To: ietf-ediint@imc.org X-Mailer: Lotus Notes Release 5.0.2a (Intl) 23 November 1999 Message-ID: Date: Wed, 10 Jan 2001 15:18:47 -0500 X-MIMETrack: Serialize by Router on GBO126-N/GIL/bo/NA/Gillette(Release 5.0.5 |September 22, 2000) at 01/10/2001 03:14:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Has anyone else out there written/is writing a client for Cyclone Interchange 3.0? I'd be interested in sharing tips and tricks. Mark From owner-ietf-ediint@mail.imc.org Sat Jan 13 16:53:35 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20368 for ; Sat, 13 Jan 2001 16:53:32 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA17445 for ietf-ediint-bks; Sat, 13 Jan 2001 13:10:50 -0800 (PST) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17438 for ; Sat, 13 Jan 2001 13:10:48 -0800 (PST) Received: from gamma (user-33qt1rb.dialup.mindspring.com [199.174.135.107]) by smtp6.mindspring.com (8.9.3/8.8.5) with SMTP id QAA12621; Sat, 13 Jan 2001 16:16:00 -0500 (EST) Reply-To: From: "Dick Brooks" To: "Moberg, Dale" , "Santanu De" Cc: Subject: RE: Need help on AS2 Date: Sat, 13 Jan 2001 15:12:07 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5FD6397E455FD4118BAE000629383540D39215@SCIDUBMSG02> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dale, Sorry for the long delayed response, I've been traveling. For the past several weeks I've been talking with people about the similarities and differences between EDIINT AS1, AS2, SOAP, ebXML, GISB EDM and W3C XP. I'm convinced that this forest of "B2B standards" and all the vendor marketing hype is creating confusion and concern. There is significant overlap in functionality between these different standards, and more importantly, they are NOT interoperable. The "lack of consensus" within the vendor and standards making communities is causing concern within the business community. In 1996 the Energy industry created a INDUSTRY NEUTRAL Internet B2B standard to enable the secure, reliable exchange of data over the Internet to meet their needs. The Energy industry B2B standard has been used for mission critical B2B since April of 1997. Companies in other industries, Healthcare in particular, also use the Energy Industry B2B standard for exchanging data. The Energy industry B2B standard, along with AIAG E-5, formed the basis of the GENERALIZED RECEIPTS portion of the EDIINT AS2 specification. Approximately 20 vendors implement the Energy industry B2B standard; Sterling Commerce, BTrade, IPNet and Group 8760 from the AS2 community also implement the Energy Industry B2B standard. You claim that I'm being misleading with some of my comments on this list. I believe I've been completely above board in my assertions. But, how about the vendors who have been issuing press releases claiming to be "AS2 compliant", some are even claiming they are AS2 "certified", because they participated in a "clean room" interoperability test. Their software implements functionality that DOESN'T exist in the current AS2 spec. Do you consider their claims of AS2 compliance/certification misleading? I think it's time the AS2 community stops the "war of words" and starts pursuing true convergence. Software vendors, end users and industry standards bodies must come together to define a single interoperable AS2 standard that everyone could rally around/support. Dick Brooks Group 8760 110 12th Street North Birmingham, AL 35203 dick@8760.com 205-250-8053 Fax: 205-250-8057 http://www.8760.com/ InsideAgent - Empowering e-commerce solutions > -----Original Message----- > From: owner-ietf-ediint@mail.imc.org > [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Moberg, Dale > Sent: Wednesday, January 10, 2001 10:57 AM > To: 'dick@8760.com'; Santanu De > Cc: ietf-ediint@imc.org > Subject: RE: Need help on AS2 > > > Comments in-line. > > > -----Original Message----- > > From: Dick Brooks [mailto:dick@8760.com] > > Sent: Wednesday, January 10, 2001 11:25 AM > > To: Moberg, Dale; Santanu De > > Cc: ietf-ediint@imc.org > > Subject: RE: Need help on AS2 > > > > > > Dale, > > > > > Sorry, Dick, but I think this remark is misleading. > > > > > > The so-called "email" packaging makes use of IETF standards > > > for MIME, the security multiparts, and the specifications > > > for Open-PGP and SMIME. It is as much > > > based on standards as is the packaging that makes > > > use of "multipart/form-data." > > > > My comment about the email packaging of AS2 being > > non-standard refers to the > > fact that > > neither RFC 822 nor RFC 2045 nor RFC 2616 define the AS2-to > > or AS2-From > > headers. In fact, these don't exist in the current AS2 draft (ref: > > http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-07.t > xt) nor any > previous draft of AS2. I know AS2 will be enhanced to support AS2-To and > AS2-From, but as of right now, these headers aren't defined in any RFC or > Internet Draft. Is this factual? > > > That detail is not a significant basis for saying that > the _packaging_ is nonstandard. As you well know, HTTP > allows headers to be added without the X- qualifier. > And if we use AS2-To and AS2-From in the final draft, > we can ask IANA to register these, in my opinion. > > Some on the list have proposed using different header field > names from AS2-to and AS2-From. > > We should continue to discuss what field to use on this > list if there are reasons for one way of proceeding rather > than another. And we should discuss these final issues > at an IETF meeting to see if we can determine the consensus. > > > >I also wanted to point out that the email packaging specification within > AS2 > >doesn't follow MIME (RFC 2045) or RFC 822 (which defines the standard > syntax > >for e-mail messages) specifications for extension headers. According to > >these specs extension headers are supposed to contain an "X-" prefix, > >reference this excerpt from section 4.1 (Message Specification/Syntax) of > >RFC 822: > > > In the same spirit, HTTP doesn't follow every rule of RFC 2045 or > RFC 822. That is one very good reason to stop calling AS2 "email" > packaging. (As you will remember me saying more than once before ;-). > That is one very specific way in which you are being misleading. > > We are instead following MIME as used in HTTP which, > as we are at pains to point out in the AS2 spec, differs in some > details from the way it is used in the SMTP context. > Because these differences do not make HTTP RFCs 2068 or 2616 > nonstandard, I think it is misleading to say that the use of > MIME in AS2 is nonstandard. Rather the usage of MIME that we recommend > follows how MIME is used in accordance with the standards in 2068 > and 2616, and that makes it standard. We are, after all, describing > "HTTP Transport for Secure EDI." and that is why we adhere > to RFC 2068/2616 on those points where HTTP MIME differs from > 2045... It might have been simpler if the HTTP and SMTP MIME > were identical (and they are very similar) but that is not > the case. So as a group chartered to find an applicability > statement of existing standards, we have followed the existing > standards even when those standards diverge slightly. (It > is, after all, to be expected that a binary clean transport > might need to say slightly different things about packaging > than one whose default is 7 bit...) > > > > From owner-ietf-ediint@mail.imc.org Sat Jan 13 17:56:17 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20634 for ; Sat, 13 Jan 2001 17:56:17 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA20429 for ietf-ediint-bks; Sat, 13 Jan 2001 14:32:10 -0800 (PST) Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA20425 for ; Sat, 13 Jan 2001 14:32:08 -0800 (PST) Received: from gamma (user-33qt1rb.dialup.mindspring.com [199.174.135.107]) by barry.mail.mindspring.net (8.9.3/8.8.5) with SMTP id RAA25308; Sat, 13 Jan 2001 17:37:22 -0500 (EST) Reply-To: From: "Dick Brooks" To: "Jim Hurd" , Subject: RE: AS2 returning EDI Date: Sat, 13 Jan 2001 16:33:30 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C07D7E.9014AFC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <062c01c07993$bb3ca0c0$5501a8c0@HL1> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C07D7E.9014AFC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_01C07D7E.901DD780" ------=_NextPart_001_0001_01C07D7E.901DD780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Jim, Using the Generalized Receipts approach you would do the following: 1. Construct a Receipt-type that contains a "eligibility-response", e.g. HIPAA-ELIGIBILITY-RESPONSE 2. The sender should include a receipt-disposition-to header along with the receipt-report-type set to HIPAA-ELIGIBILITY-RESPONSE 3. If you want the response signed then indicate this with the receipt-security-selection header 4. Send these headers along with the HIPAA X12 eligibility inquiry in the payload 5. The server should follow the proper behavior to produce the HIPAA-ELIGIBILITY-RESPONSE I've attached a simple HTML form to demonstrate this. Dick Brooks Group 8760 110 12th Street North Birmingham, AL 35203 dick@8760.com 205-250-8053 Fax: 205-250-8057 http://www.8760.com/ InsideAgent - Empowering e-commerce solutions -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Jim Hurd Sent: Monday, January 08, 2001 10:55 AM To: ietf-ediint@imc.org Subject: AS2 returning EDI I would like a future AS2 to clarify how EDI should be returned in the http response. This is needed for healthcare transactions like eligibility checks. I assume that the generalized receipt mechanism could be used, but isn't this important enough to standardize? Are there already proposals to this effect that I am unaware of? Jim ------=_NextPart_001_0001_01C07D7E.901DD780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jim,
 
Using=20 the Generalized Receipts approach you would do the=20 following:
 
1.=20 Construct a Receipt-type that contains a "eligibility-response", e.g.=20 HIPAA-ELIGIBILITY-RESPONSE
2. The=20 sender should include a receipt-disposition-to header along with = the=20 receipt-report-type set to = HIPAA-ELIGIBILITY-RESPONSE
3. If=20 you want the response signed then indicate this with the=20 receipt-security-selection header
4.=20 Send these headers along with the HIPAA X12 eligibility inquiry in the=20 payload
5. The=20 server should follow the proper behavior to produce the=20 HIPAA-ELIGIBILITY-RESPONSE
 
I've=20 attached a simple HTML form to demonstrate this.
 

Dick Brooks
Group 8760
110 12th Street=20 North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax:=20 205-250-8057
http://www.8760.com/

InsideAgent= -=20 Empowering e-commerce solutions

-----Original Message-----
From:=20 owner-ietf-ediint@mail.imc.org = [mailto:owner-ietf-ediint@mail.imc.org]On=20 Behalf Of Jim Hurd
Sent: Monday, January 08, 2001 10:55=20 AM
To: ietf-ediint@imc.org
Subject: AS2 returning=20 EDI

I would like a future AS2 to clarify = how EDI=20 should be returned in the http response. This is needed for = healthcare=20 transactions like eligibility checks. I assume that the generalized = receipt=20 mechanism could be used, but isn't this important enough to = standardize? Are=20 there already proposals to this effect that I am unaware = of?
 
Jim
 
------=_NextPart_001_0001_01C07D7E.901DD780-- ------=_NextPart_000_0000_01C07D7E.9014AFC0 Content-Type: text/html; name="Upload-form.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Upload-form.html" Content-Transfer-Encoding: quoted-printable EDIINT AS2 TESTING

EDIINT AS2 UPLOAD FORM


Please send your EDIINT AS2 testdata
From:
To:
Agent:
Application:
Creation Date and Time:
RefNum:
User Parameter:
Version:
Transaction Set:
Send Receipt To:
Receipt Delivery Method:
Receipt Type:
Receipt Security Choices:
Format:
Payload:







Gisb log test.
------=_NextPart_000_0000_01C07D7E.9014AFC0-- From owner-ietf-ediint@mail.imc.org Sat Jan 13 19:16:16 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21137 for ; Sat, 13 Jan 2001 19:16:15 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA21128 for ietf-ediint-bks; Sat, 13 Jan 2001 15:40:46 -0800 (PST) Received: from mail.healthlift.com (www.smokestoppers.com [207.106.24.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA21124 for ; Sat, 13 Jan 2001 15:40:44 -0800 (PST) Received: from HL1 [216.233.45.163] by mail.healthlift.com (SMTPD32-6.00) id AC4220AF00D8; Sat, 13 Jan 2001 19:01:06 -0500 Message-ID: <002b01c07dbb$e54d5220$5501a8c0@HL1> From: "Jim Hurd" To: , References: Subject: Re: AS2 returning EDI Date: Sat, 13 Jan 2001 18:52:32 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C07D91.FC4EB380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C07D91.FC4EB380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dick, This looks like a reasonable approach. If there is a weakness it's the = "e.g.". It would be nice if the people behind AS2 would incorporate a = standard way of returning a general EDI payload. (The eligibility = response is just another edi payload in the reverse direction). So maybe = a receipt type of "edi-x12-response" would be a standard way to request = an inline edi response.=20 Jim ----- Original Message -----=20 From: Dick Brooks=20 To: Jim Hurd ; ietf-ediint@imc.org=20 Sent: Saturday, January 13, 2001 5:33 PM Subject: RE: AS2 returning EDI Jim, Using the Generalized Receipts approach you would do the following: 1. Construct a Receipt-type that contains a "eligibility-response", = e.g. HIPAA-ELIGIBILITY-RESPONSE 2. The sender should include a receipt-disposition-to header along = with the receipt-report-type set to HIPAA-ELIGIBILITY-RESPONSE 3. If you want the response signed then indicate this with the = receipt-security-selection header 4. Send these headers along with the HIPAA X12 eligibility inquiry in = the payload 5. The server should follow the proper behavior to produce the = HIPAA-ELIGIBILITY-RESPONSE I've attached a simple HTML form to demonstrate this. Dick Brooks Group 8760 110 12th Street North Birmingham, AL 35203 dick@8760.com 205-250-8053 Fax: 205-250-8057 http://www.8760.com/ InsideAgent - Empowering e-commerce solutions=20 -----Original Message----- From: owner-ietf-ediint@mail.imc.org = [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Jim Hurd Sent: Monday, January 08, 2001 10:55 AM To: ietf-ediint@imc.org Subject: AS2 returning EDI I would like a future AS2 to clarify how EDI should be returned in = the http response. This is needed for healthcare transactions like = eligibility checks. I assume that the generalized receipt mechanism = could be used, but isn't this important enough to standardize? Are there = already proposals to this effect that I am unaware of? Jim ------=_NextPart_000_0028_01C07D91.FC4EB380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dick,
 
This looks like a reasonable approach. = If there is=20 a weakness it's the "e.g.". It would be nice if the people behind AS2 = would=20 incorporate a standard way of returning a general EDI payload. (The = eligibility=20 response is just another edi payload in the reverse direction). So maybe = a=20 receipt type of "edi-x12-response" would be a standard way to request an = inline=20 edi response.
 
Jim
 
----- Original Message -----
From:=20 Dick Brooks =
Sent: Saturday, January 13, = 2001 5:33=20 PM
Subject: RE: AS2 returning = EDI

Jim,
 
Using the Generalized Receipts approach you would do the=20 following:
 
1.=20 Construct a Receipt-type that contains a "eligibility-response", e.g.=20 HIPAA-ELIGIBILITY-RESPONSE
2.=20 The sender should include a receipt-disposition-to header along = with the=20 receipt-report-type set to = HIPAA-ELIGIBILITY-RESPONSE
3.=20 If you want the response signed then indicate this with the=20 receipt-security-selection header
4.=20 Send these headers along with the HIPAA X12 eligibility inquiry in the = payload
5.=20 The server should follow the proper behavior to produce the=20 HIPAA-ELIGIBILITY-RESPONSE
 
I've=20 attached a simple HTML form to demonstrate this.
 

Dick Brooks
Group 8760
110 12th Street=20 North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: = 205-250-8057
http://www.8760.com/

InsideAgent= -=20 Empowering e-commerce solutions

-----Original Message-----
From:=20 owner-ietf-ediint@mail.imc.org = [mailto:owner-ietf-ediint@mail.imc.org]On=20 Behalf Of Jim Hurd
Sent: Monday, January 08, 2001 = 10:55=20 AM
To: ietf-ediint@imc.org
Subject: AS2 = returning=20 EDI

I would like a future AS2 to = clarify how EDI=20 should be returned in the http response. This is needed for = healthcare=20 transactions like eligibility checks. I assume that the generalized = receipt=20 mechanism could be used, but isn't this important enough to = standardize? Are=20 there already proposals to this effect that I am unaware = of?
 
Jim
 
------=_NextPart_000_0028_01C07D91.FC4EB380-- From owner-ietf-ediint@mail.imc.org Sun Jan 14 13:47:01 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09867 for ; Sun, 14 Jan 2001 13:47:00 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA20651 for ietf-ediint-bks; Sun, 14 Jan 2001 10:15:51 -0800 (PST) Received: from exchange.parex.co.nz ([203.167.234.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20636 for ; Sun, 14 Jan 2001 10:15:43 -0800 (PST) From: dadsaj@uni-mb.si To: Date: Sun, 14 Jan 2001 09:36:28 Message-Id: <655.84528.535639@mail.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit GET YOUR OWN 150 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH! DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL TO OUR OFFICE. YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with no extra charge! UNLIMITED TRAFFIC -- no extra charge! FRONT PAGE EXTENSIONS are FULLY SUPPORTED. A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE. FOR DETAILS CALL 1 888 248 0765 if you are outside the USA, please fax 240 337 8325 Webhosting International From owner-ietf-ediint@mail.imc.org Sun Jan 14 18:11:11 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11024 for ; Sun, 14 Jan 2001 18:11:11 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA03144 for ietf-ediint-bks; Sun, 14 Jan 2001 14:36:54 -0800 (PST) Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA03140 for ; Sun, 14 Jan 2001 14:36:52 -0800 (PST) Received: from gamma (user-33qt463.dialup.mindspring.com [199.174.144.195]) by hall.mail.mindspring.net (8.9.3/8.8.5) with SMTP id RAA03052; Sun, 14 Jan 2001 17:42:12 -0500 (EST) Reply-To: From: "Dick Brooks" To: "Jim Hurd" , Subject: RE: AS2 returning EDI Date: Sun, 14 Jan 2001 16:38:21 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01C07E48.67CFF180" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-reply-to: <002b01c07dbb$e54d5220$5501a8c0@HL1> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0042_01C07E48.67CFF180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Jim, I'm willing to help flush out a design for the "edi-x12-response" receipt type if there is consensus among the group for the functionality. Anyone else interested in a "edi-x12-response" receipt type? Dick Brooks Group 8760 110 12th Street North Birmingham, AL 35203 dick@8760.com 205-250-8053 Fax: 205-250-8057 http://www.8760.com/ InsideAgent - Empowering e-commerce solutions -----Original Message----- From: Jim Hurd [mailto:hurd@healthlift.com] Sent: Saturday, January 13, 2001 5:53 PM To: Dick Brooks; ietf-ediint@imc.org Subject: Re: AS2 returning EDI Dick, This looks like a reasonable approach. If there is a weakness it's the "e.g.". It would be nice if the people behind AS2 would incorporate a standard way of returning a general EDI payload. (The eligibility response is just another edi payload in the reverse direction). So maybe a receipt type of "edi-x12-response" would be a standard way to request an inline edi response. Jim ----- Original Message ----- From: Dick Brooks To: Jim Hurd ; ietf-ediint@imc.org Sent: Saturday, January 13, 2001 5:33 PM Subject: RE: AS2 returning EDI Jim, Using the Generalized Receipts approach you would do the following: 1. Construct a Receipt-type that contains a "eligibility-response", e.g. HIPAA-ELIGIBILITY-RESPONSE 2. The sender should include a receipt-disposition-to header along with the receipt-report-type set to HIPAA-ELIGIBILITY-RESPONSE 3. If you want the response signed then indicate this with the receipt-security-selection header 4. Send these headers along with the HIPAA X12 eligibility inquiry in the payload 5. The server should follow the proper behavior to produce the HIPAA-ELIGIBILITY-RESPONSE I've attached a simple HTML form to demonstrate this. Dick Brooks Group 8760 110 12th Street North Birmingham, AL 35203 dick@8760.com 205-250-8053 Fax: 205-250-8057 http://www.8760.com/ InsideAgent - Empowering e-commerce solutions -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Jim Hurd Sent: Monday, January 08, 2001 10:55 AM To: ietf-ediint@imc.org Subject: AS2 returning EDI I would like a future AS2 to clarify how EDI should be returned in the http response. This is needed for healthcare transactions like eligibility checks. I assume that the generalized receipt mechanism could be used, but isn't this important enough to standardize? Are there already proposals to this effect that I am unaware of? Jim ------=_NextPart_000_0042_01C07E48.67CFF180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jim,
 
I'm=20 willing to help flush out a design for the "edi-x12-response" receipt = type if=20 there is consensus among the group for the = functionality.
Anyone=20 else interested in a "edi-x12-response" receipt = type?

Dick Brooks
Group 8760
110 12th Street=20 North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax:=20 205-250-8057
http://www.8760.com/

InsideAgent= -=20 Empowering e-commerce solutions

-----Original Message-----
From: Jim Hurd=20 [mailto:hurd@healthlift.com]
Sent: Saturday, January 13, = 2001 5:53=20 PM
To: Dick Brooks; ietf-ediint@imc.org
Subject: = Re: AS2=20 returning EDI

Dick,
 
This looks like a reasonable = approach. If there=20 is a weakness it's the "e.g.". It would be nice if the people behind = AS2 would=20 incorporate a standard way of returning a general EDI payload. (The=20 eligibility response is just another edi payload in the reverse = direction). So=20 maybe a receipt type of "edi-x12-response" would be a standard way to = request=20 an inline edi response.
 
Jim
 
----- Original Message -----
From:=20 Dick = Brooks
To: Jim Hurd ; ietf-ediint@imc.org
Sent: Saturday, January 13, = 2001 5:33=20 PM
Subject: RE: AS2 returning = EDI

Jim,
 
Using the Generalized Receipts approach you would do the=20 following:
 
1.=20 Construct a Receipt-type that contains a "eligibility-response", = e.g.=20 HIPAA-ELIGIBILITY-RESPONSE
2.=20 The sender should include a receipt-disposition-to header along = with=20 the receipt-report-type set to=20 HIPAA-ELIGIBILITY-RESPONSE
3.=20 If you want the response signed then indicate this with the=20 receipt-security-selection header
4.=20 Send these headers along with the HIPAA X12 eligibility inquiry in = the=20 payload
5.=20 The server should follow the proper behavior to produce the=20 HIPAA-ELIGIBILITY-RESPONSE
 
I've attached a simple HTML form to demonstrate=20 this.
 

Dick Brooks
Group 8760
110 12th Street=20 North
Birmingham, AL = 35203
dick@8760.com
205-250-8053
Fax:=20 205-250-8057
http://www.8760.com/

InsideAgent= -=20 Empowering e-commerce solutions

-----Original Message-----
From:=20 owner-ietf-ediint@mail.imc.org=20 [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Jim=20 Hurd
Sent: Monday, January 08, 2001 10:55 = AM
To:=20 ietf-ediint@imc.org
Subject: AS2 returning=20 EDI

I would like a future AS2 to = clarify how EDI=20 should be returned in the http response. This is needed for=20 healthcare transactions like eligibility checks. I assume that the = generalized receipt mechanism could be used, but isn't this = important=20 enough to standardize? Are there already proposals to this effect = that I=20 am unaware of?
 
Jim
 
------=_NextPart_000_0042_01C07E48.67CFF180-- From owner-ietf-ediint@mail.imc.org Mon Jan 15 08:55:43 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05196 for ; Mon, 15 Jan 2001 08:55:42 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA23262 for ietf-ediint-bks; Mon, 15 Jan 2001 05:16:12 -0800 (PST) Received: from exchange.parex.co.nz ([203.167.234.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA23241 for ; Mon, 15 Jan 2001 05:15:55 -0800 (PST) From: ASADSAD@iae.cta.br To: Date: Mon, 15 Jan 2001 04:35:12 Message-Id: <764.232945.117109@mail.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit GET YOUR OWN 150 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH! DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL TO OUR OFFICE. YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with no extra charge! UNLIMITED TRAFFIC -- no extra charge! FRONT PAGE EXTENSIONS are FULLY SUPPORTED. A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE. FOR DETAILS CALL 1 888 248 0765 if you are outside the USA, please fax 240 337 8325 Webhosting International From owner-ietf-ediint@mail.imc.org Mon Jan 15 09:33:26 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06190 for ; Mon, 15 Jan 2001 09:33:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA26155 for ietf-ediint-bks; Mon, 15 Jan 2001 06:02:34 -0800 (PST) Received: from icsscmh4.shell.com (gate6out.shellus.com [134.163.253.248]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26151 for ; Mon, 15 Jan 2001 06:02:33 -0800 (PST) Received: from icsscxh7.shell.com by icsscmh4.shell.com (internal) with ESMTP; Mon, 15 Jan 2001 08:06:15 -0600 Received: by icsscxh7.shell.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Jan 2001 08:06:08 -0600 Message-ID: <01E6CE145384D011ADD70001FA37179002CD90F2@wcsscx01.shell.com> From: "Morris, Duane DK SSI-GRAN" To: "'ASADSAD@iae.cta.br'" , ietf-ediint@imc.org Subject: RE: Date: Mon, 15 Jan 2001 08:06:04 -0600 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please take me off of your email list! My email address is dkmorris@shellus.com. Thank you, Kevin Duane Kevin Morris Project Manager Systems Integration-AM-New Markets Global Practices Phone: 713-245-4427 Email: dkmorris@shellus.com > -----Original Message----- > From: ASADSAD@iae.cta.br [SMTP:ASADSAD@iae.cta.br] > Sent: Sunday, January 14, 2001 10:35 PM > To: ietf-ediint@imc.org > Subject: > > GET YOUR OWN 150 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! > > STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN > GET ONE FOR ONLY $11.95 PER MONTH! > > DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE > DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO > GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A > SIMPLE PHONE CALL TO OUR OFFICE. > > YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with > no extra charge! UNLIMITED TRAFFIC -- no extra charge! > > FRONT PAGE EXTENSIONS are FULLY SUPPORTED. > > A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. > > ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP > CHARGE. > > FOR DETAILS CALL 1 888 248 0765 if you are outside the USA, > please fax 240 337 8325 > > Webhosting International > > > > > > > From owner-ietf-ediint@mail.imc.org Mon Jan 15 10:35:32 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07501 for ; Mon, 15 Jan 2001 10:35:32 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA28270 for ietf-ediint-bks; Mon, 15 Jan 2001 06:56:45 -0800 (PST) Received: from exeug3.sp-eug.com ([157.245.1.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28266 for ; Mon, 15 Jan 2001 06:56:44 -0800 (PST) Received: by exeug3.sp-eug.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Jan 2001 07:02:45 -0800 Message-ID: <78445BA01DCED21197B400A0C9EA5F7E04A94E9D@exeug3.sp-eug.com> From: "Grimwood, Derald" To: "'ietf-ediint@imc.org'" Subject: unsusbscribe Date: Mon, 15 Jan 2001 07:02:39 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07F04.37651BC6" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C07F04.37651BC6 Content-Type: text/plain; charset="windows-1252" unsubscribe ------_=_NextPart_001_01C07F04.37651BC6 Content-Type: text/html; charset="windows-1252" unsusbscribe

unsubscribe

------_=_NextPart_001_01C07F04.37651BC6-- From owner-ietf-ediint@mail.imc.org Mon Jan 15 11:45:07 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10094 for ; Mon, 15 Jan 2001 11:45:07 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA06224 for ietf-ediint-bks; Mon, 15 Jan 2001 08:10:21 -0800 (PST) Received: from mx2.magma.ca (mx2.magma.ca [206.191.0.250]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06220 for ; Mon, 15 Jan 2001 08:10:19 -0800 (PST) Received: from mail6.magma.ca (mail6.magma.ca [206.191.0.248]) by mx2.magma.ca (8.9.3/8.9.3) with ESMTP id LAA15419 for ; Mon, 15 Jan 2001 11:15:47 -0500 (EST) Received: from don ([206.191.40.98]) by mail6.magma.ca (8.9.3/8.9.3) with SMTP id LAA12818 for ; Mon, 15 Jan 2001 11:15:46 -0500 (EST) From: "Don Gribble" To: Subject: RE: unsusbscribe Date: Mon, 15 Jan 2001 11:16:54 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C07EE4.E2B5EA70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C07EE4.E2B5EA70 Content-Type: text/plain; charset="Windows-1252" X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id IAA06224 Content-Transfer-Encoding: quoted-printable unsubscribe =A0 ------=_NextPart_000_000F_01C07EE4.E2B5EA70 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable unsusbscribe

unsubscribe

 

------=_NextPart_000_000F_01C07EE4.E2B5EA70-- From owner-ietf-ediint@mail.imc.org Mon Jan 15 12:21:26 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11176 for ; Mon, 15 Jan 2001 12:21:26 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA08586 for ietf-ediint-bks; Mon, 15 Jan 2001 08:52:52 -0800 (PST) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08580 for ; Mon, 15 Jan 2001 08:52:51 -0800 (PST) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id QAA09360 for ; Mon, 15 Jan 2001 16:59:31 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 15 Jan 2001 16:58:08 0000 (GMT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Jan 2001 08:58:07 -0800 Message-ID: <7B3D67AA81EBD111AC4000A0C96B23F705A3034A@orsmsx32.jf.intel.com> From: "Tsai, James" To: "'ietf-ediint@imc.org'" Subject: unsusbscribe Date: Mon, 15 Jan 2001 08:58:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07F14.538FF270" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C07F14.538FF270 Content-Type: text/plain; charset="windows-1252" unsubscribe ------_=_NextPart_001_01C07F14.538FF270 Content-Type: text/html; charset="windows-1252" unsusbscribe
unsubscribe
------_=_NextPart_001_01C07F14.538FF270-- From owner-ietf-ediint@mail.imc.org Wed Jan 17 00:41:19 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00756 for ; Wed, 17 Jan 2001 00:41:19 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA13565 for ietf-ediint-bks; Tue, 16 Jan 2001 21:00:08 -0800 (PST) Received: from zeus.amt.co.kr ([203.248.62.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA13555 for ; Tue, 16 Jan 2001 21:00:06 -0800 (PST) From: bk12bk27@yahoo.com Received: from max1-34.losangeles.corecomm.net by zeus.amt.co.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id DDA0T5HG; Wed, 17 Jan 2001 11:40:03 +0900 DATE: 16 Jan 01 6:44:04 PM Message-ID: SUBJECT: RE; THANK YOU Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Friend and Partner, Think of all the things you could do if you had more free time and money wasn't an object What kind of car would you be driving? Where would you live? Where would you go on vacation? Now, for a limited time, 300+ money making and saving secrets can be yours for less than $10.00. Click here http://www.300moneysecrets.com/ and ORDER NOW!!!!!!!!!!!!!! Get information now, that could make you millions!!!! ** REMOVE ** REMOVE ** REMOVE ** REMOVE ** REMOVE ** To be removed from our mailing list, please email sandywho1212@yahoo.com All REMOVE requests AUTOMATICALLY honored upon receipt. PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed from our mailing list as it will be impossible to take anyone off the list if the remove instruction can not be received. From owner-ietf-ediint@mail.imc.org Mon Jan 22 20:31:40 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18702 for ; Mon, 22 Jan 2001 20:31:39 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA21710 for ietf-ediint-bks; Mon, 22 Jan 2001 16:49:55 -0800 (PST) Received: from cins.hanyang.ac.kr ([166.104.204.187]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA21626; Mon, 22 Jan 2001 16:47:24 -0800 (PST) From: emed22@libero.it Received: by cins.hanyang.ac.kr id JAA305538; Tue, 23 Jan 2001 09:27:53 +0900 (KST) Subject: Obtain Biotech IPOs! 13 Date: Mon, 22 Jan 2001 19:51:16 Message-Id: <53.644352.589899@unknown> Reply-To: emed22@libero.it Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cins.hanyang.ac.kr id JAA305538 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable

Help Beta Test Our Site and Be Eligible to Purchase Shares= of=20 Future IPOs In Which We Participate**

eMedsecurities has selected you as a possible participant = to help=20 test our online stock-trading engine for knowledge-based investing = in the=20 life sciences.  For your cooperation, you will be eligible = to purchase=20 shares of future IPOs in which we participate, for as long as y= ou=20 maintain your account with us.  This is limited to only 50 = qualified=20 testers!  Request M= ore Information.**

eMedsecurities=85 The Cure for the Common Portfolio!

eMedsecurities provides you with a wealth of information, = all=20 compiled in a single, easy-to-use resource.  Learn about new r= esearch=20 and upcoming treatments for diabetes, glaucoma, cataract, obesity a= nd much more.  Obtain critical investment information about the=20 companies that are developing these treatments.  eMedsecuritie= s empowers=20 you to make more informed investment decisions.  Request More Information.**

Participation i= n eMedsecurities's Beta Test allows you:

  • Eligibility to purchase s= hares of IPOs in which=20 eMedsecurities participates for as long as you maintain your=20 account**

  • Valuable research of the = entire product=20 pipeline of companies, including stages of clinical development, = by=20 industry or specific disease

  • Useful information about = industry trends, recent=20 developments and upcoming IPOs

  • Commitment to customer se= rvice featuring=20 our Live Customer Service Online

  • Dedication to fast trade = executions at the best=20 possible price.

The following guideline= s will=20 explain what we expect from an eMedsecurities Beta Tester:

  • Open a funded eMedsecurities=20 account

  • Visit our online trading site onc= e=20 a week

  • Execute trades through our Web=20 site in accordance with your normal practice

  • Submit feedback to eMedsecurities= 's development team through a questionnaire sent via=20 email

  • Provide us with additional=20 feedback regarding the site as needed.

The test is limited to = only 50 Beta=20 Testers so sign up now to be considered!  Request More Information.**=20

Please note:<= /B> All applications for the Beta Test must be s= ubmitted by January 25, 2001 to be considered.=20

Please=20 be advised that your information will stay in our proprietary datab= ase and=20 will not be sold, traded, given or otherwise provided to outside ve= ndors.  We respect your privacy.=20

=20

By=20 submitting your information, you implicitly state that this is some= thing=20 that interests you and that you
agree to receive periodic emails from=20 eMedsecurities.=20

Research indicated= that you=20 might benefit from our offer.  To be removed instantly and per= manently from=20 our database, simply click here= .  We respect=20 all removal requests.

** R= estrictions=20 Apply:  Beta test not open t= o residents of HI, IL, MI, MN, NE, NH, TN, TX.  Initial Public=20 Offerings are considered speculative investments and as such may no= t be=20 appropriate for every investor. If an investor chooses to participa= te in=20 IPOs, there are certain restrictions that apply.   Flipping - The first time an invest= or sells their shares within the first 30 days the issue is trading in the=20 secondary market, that investor will not be allocated shares for th= e next=20 90 days following the sale.  The second time that investor =93= flips,"=20 they will not be allocated IPO shares for 180 days.  The third= time=20 that investor =93flips," they lose their IPO allocations perma= nently.  Transferring shares - If the=20 investor transfers IPO shares out of their account within the first= 30=20 days the issue is trading in the secondary market, they will perman= ently=20 lose their IPO allocations.  Beta investors will be chosen = from=20 all the applicants based on their income, net worth and investing=20 experience.  Beta Test open only to those 21 years of age= or older. IPO shares will only be allocated from transactions in=20 which eMedsecurities participates in the underwriting.  A0009-= 1-A2

eMedsecurities, Inc.   Member NASD  SIPC. 

From owner-ietf-ediint@mail.imc.org Mon Jan 29 19:00:58 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12346 for ; Mon, 29 Jan 2001 19:00:57 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA28227 for ietf-ediint-bks; Mon, 29 Jan 2001 15:05:49 -0800 (PST) Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4.email.verio.net [129.250.36.44]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA28121; Mon, 29 Jan 2001 15:01:45 -0800 (PST) Received: from [129.250.38.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout4.email.verio.net with esmtp id 14NNMx-0004IF-00; Mon, 29 Jan 2001 23:05:55 +0000 Received: from [206.133.83.14] (helo=localhost) by dfw-mmp3.email.verio.net with esmtp id 14NNMn-0003Uj-00; Mon, 29 Jan 2001 23:05:45 +0000 X-Sender: misterprivacy@hushmail.com From: Dave To: "customer" Date: Mon, 29 Jan 2001 14:22:13 -0500 Subject: I could go to JAIL for selling this CD! MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__10434935_51733.99" Message-Id: Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a Multipart MIME message. ------=_NextPart_000_001__10434935_51733.99 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__10434935_51733.99 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9u YWwvL2VuIj4NCjxodG1sPg0KPGhlYWQ+DQogICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50 LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCiAgIDxt ZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iTW96aWxsYS80LjYxIFtlbl0gKFdpbjk4 OyBJKSBbTmV0c2NhcGVdIj4NCiAgIDx0aXRsZT5UaGUgQkFOTkVEIENEITwvdGl0bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxmb250IHNpemU9KzE+SGksPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0rMT5JIGhhdmUgYmVlbiByZWNpZXZpbmcgZW1haWxzIHNheWluZyB0aGF0IEknbSBjb250 cmlidXRpbmcNCnRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGhlICJtb3JhbCBkZWNh eSBvZiBzb2NpZXR5IiBieSBzZWxsaW5nIHRoZSBCYW5uZWQgQ0QuJm5ic3A7DQpUaGF0PC9m b250Pg0KPGJyPjxmb250IHNpemU9KzE+bWF5IGJlLCBidXQgSSBmZWVsIHN0cm9uZ2x5IHRo YXQgeW91IGhhdmUgYSByaWdodCB0bw0KYmVuZWZpdCBmcm9tPC9mb250Pg0KPGJyPjxmb250 IHNpemU9KzE+dGhpcyBoYXJkLXRvLWZpbmQgaW5mb3JtYXRpb24uPC9mb250Pg0KPHA+PGZv bnQgY29sb3I9IiNDQzAwMDAiPjxmb250IHNpemU9KzE+U28gSSBhbSBnaXZpbmcgeW91IE9O RSBMQVNUIENIQU5DRQ0KdG8gb3JkZXI8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9y PSIjQ0MwMDAwIj48Zm9udCBzaXplPSsxPnRoZSBCYW5uZWQgQ0QhPC9mb250PjwvZm9udD4N Cjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9MCBDT0xTPTIgV0lEVEg9Ijc1JSIgPg0KPHRy Pg0KPHRkIFdJRFRIPSIxJSI+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2lt YWdlcy9zcHkuanBnIiBoZWlnaHQ9MTI4IHdpZHRoPTg2PjwvdGQ+DQoNCjx0ZD48Zm9udCBz aXplPSsxPldpdGggdGhpcyBwb3dlcmZ1bCBDRCwgeW91IHdpbGwgYmUgYWJsZSB0byBpbnZl c3RpZ2F0ZQ0KeW91ciBmcmllbmRzLCBlbmVtaWVzIGFuZCBsb3ZlcnMgaW4ganVzdCBtaW51 dGVzIHVzaW5nIHRoZSBJbnRlcm5ldC4mbmJzcDsNCllvdSBjYW4gdHJhY2sgZG93biBvbGQg ZmxhbWVzIGZyb20gY29sbGVnZSwgb3IgeW91IGNhbiBkaWcgdXAgc29tZSBkaXJ0DQpvbiB5 b3VyIGJvc3MgdG8gbWFrZSBzdXJlIHlvdSBnZXQgdGhhdCBuZXh0IHByb21vdGlvbiE8L2Zv bnQ+PC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD48Zm9udCBzaXplPSsxPk9yIG1heWJl IHlvdSB3YW50IGEgZmFrZSBkaXBsb21hIHRvIGhhbmcgb24geW91ciBiZWRyb29tPC9mb250 Pg0KPGJyPjxmb250IHNpemU9KzE+d2FsbC4mbmJzcDsgWW91J2xsIGZpbmQgYWRkcmVzc2Vz IGZvciBjb21wYW5pZXMgdGhhdA0KbWFrZSB0aGVzZTwvZm9udD4NCjxicj48Zm9udCBzaXpl PSsxPmRpcGxvbWFzIG9uIHRoZSBCYW5uZWQgQ0QuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0r MT5OZWVkIHRvIGRpc2FwcGVhciBmYXN0IGFuZCBuZXZlciBsb29rIGJhY2s/Jm5ic3A7IE5v IHByb2JsZW0hPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+VXNpbmcgdGhlIEJhbm5lZCBD RCwgeW91IHdpbGwgbGVhcm4gaG93IHRvIGJ1aWxkIGEgY29tcGxldGVseTwvZm9udD4NCjxi cj48Zm9udCBzaXplPSsxPm5ldyBpZGVudGl0eS48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsx Pk9idmlvdXNseSwgdGhlIFBvd2VycyBUaGF0IEJlIGRvbid0IHdhbnQgeW91IHRvIGhhdmUg dGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+QmFubmVkIENELiZuYnNwOyBUaGV5IGhh dmUgdGhyZWF0ZW5lZCBtZSB3aXRoIGxhd3N1aXRzLA0KZmluZXMsPC9mb250Pg0KPGJyPjxm b250IHNpemU9KzE+YW5kIGV2ZW4gaW1wcmlzb25tZW50IHVubGVzcyBJIHN0b3Agc2VsbGlu ZyBpdCBpbW1lZGlhdGVseS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5CdXQgSSBmZWVs IHRoYXQgWU9VIGhhdmUgYSBDb25zdGl0dXRpb25hbCByaWdodCB0byBhY2Nlc3M8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0rMT50aGlzIHR5cGUgb2YgaW5mb3JtYXRpb24sIGFuZCBJIGNh bid0IGJlIGludGltaWRhdGVkLjwvZm9udD4NCjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9 MCBDT0xTPTIgV0lEVEg9IjUwJSIgPg0KPHRyPg0KPHRkIFdJRFRIPSIxMDAlIj48aT48Zm9u dCBjb2xvcj0iIzMzMzNGRiI+PGZvbnQgc2l6ZT0rMT5VbmNsZSBTYW0gYW5kIHlvdXINCmNy ZWRpdG9ycyBhcmUgaG9ycmlmaWVkIHRoYXQgSSBhbSBzdGlsbCBzZWxsaW5nIHRoaXMgcHJv ZHVjdCEmbmJzcDsgVGhlcmUNCm11c3QgYmUgYSBwcmljZSBvbiBteSBoZWFkITwvZm9udD48 L2ZvbnQ+PC9pPjwvdGQ+DQoNCjx0ZCBXSURUSD0iMSUiPjxpbWcgU1JDPSJodHRwOi8vY29t cHV6b25ldXNhLmNvbS9pbWFnZXMvb3V0bGF3LmpwZyIgaGVpZ2h0PTEyOCB3aWR0aD05Mz48 L3RkPg0KPC90cj4NCjwvdGFibGU+DQoNCjxwPjxmb250IHNpemU9KzE+V2h5IGFyZSB0aGV5 IHNvIHVwc2V0PyBCZWNhdXNlIHRoaXMgQ0QgZ2l2ZXMgeW91IGZyZWVkb20uPC9mb250Pg0K PGJyPjxmb250IHNpemU9KzE+QW5kIHlvdSBjYW4ndCBidXkgZnJlZWRvbSBhdCB5b3VyIGxv Y2FsIFdhbG1hcnQuJm5ic3A7DQpZb3Ugd2lsbDwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx PmhhdmUgdGhlIGZyZWVkb20gdG8gYXZvaWQgY3JlZGl0b3JzLCBqdWRnbWVudHMsIGxhd3N1 aXRzLA0KSVJTPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGF4IGNvbGxlY3RvcnMsIGNy aW1pbmFsIGluZGljdG1lbnRzLCB5b3VyIGdyZWVkeSBleC13aWZlDQpvcjwvZm9udD4NCjxi cj48Zm9udCBzaXplPSsxPmV4LWh1c2JhbmQsIGFuZCBNVUNIIG1vcmUhPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0rMT5KdXN0IGxvb2sgYXQgc29tZSBvZiB0aGUgdGhpbmdzIHlvdSBjYW4g ZG8gd2l0aCB0aGlzIENEDQouLi48L2ZvbnQ+DQo8dWw+DQo8bGk+DQo8Yj48Zm9udCBjb2xv cj0iIzAwMDA5OSI+U2F2ZSBodW5kcmVkcyBvciBldmVuIHRob3VzYW5kcyBvZiBkb2xsYXJz IG9uDQp5b3VyIHRheGVzIGJ5IHVzaW5nIHRoZSBzZWNyZXQgdGF4IHRpcHMgY29udGFpbmVk IGluIHRoaXMgcGFja2FnZS4mbmJzcDsNClRoZSBJUlMgZG9lcyBOT1Qgd2FudCB5b3UgdG8g a25vdyB0aGVzZSBsb29waG9sZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u dCBjb2xvcj0iIzAwMDA5OSI+VHJhY2sgZG93biBmcmllbmRzIGFuZCBvbGQgZmxhbWVzIGZy b20gdGhlIGNvbWZvcnQNCm9mIHlvdXIgb3duIGhvbWUgd2l0aCBvdXIgSW50ZXJuZXQgaW52 ZXN0aWdhdGlvbiByZXNvdXJjZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u dCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQgd2hlcmUgeW91ciBFWCBpcyBoaWRpbmcgdGhl aXIgbW9uZXkgdG8NCmF2b2lkIGFsaW1vbnksIGNoaWxkIHN1cHBvcnQsIG9yIGRpdm9yY2Ug c2V0dGxlbWVudHMuIFRoZW4gZ2V0IHlvdXIgaGFuZHMNCm9uIHRoYXQgbW9uZXkuJm5ic3A7 IEJsZWVkICdlbSBkcnkhJm5ic3A7IFByaXZhdGUgaW52ZXN0aWdhdG9ycyBjaGFyZ2UNCnRo b3VzYW5kcyBvZiBkb2xsYXJzIGZvciB0aGlzIHNlcnZpY2UsIGJ1dCB5b3UgY2FuIGRvIGl0 IHdpdGggYSBjb21wdXRlcg0KYW5kIGFuIGludGVybmV0IGNvbmVjdGlvbiB3aGVuIHlvdSBi dXkgdGhlIEJhbm5lZCBDRCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNv bG9yPSIjMDAwMDk5Ij5MZWFybiBob3cgdG8gdXNlIG9mZnNob3JlIG1vbmV5IGhhdmVucyBh bmQgYXNzZXQNCnByb3RlY3Rpb24gdHJ1c3RzIHRvIGF2b2lkIGxhd3N1aXRzLCBqdWRnbWVu dHMsIGFuZCBmb29sIHRoZSBtb3N0IGFnZ3Jlc3NpdmUNCnRheCBjb2xsZWN0b3IhJm5ic3A7 IElmIHlvdXIgbW9uZXkgaXMgc2l0dGluZyBpbiBhIFVTIGJhbmsgYWNjb3VudCwgeW91cg0K ZnVuZHMgY2FuIGJlIGxldmllZCBvciBmcm96ZW4gY29tcGxldGVseSBhdCBhbnkgdGltZS4m bmJzcDsgVGhlIFVTIGdvdmVybm1lbnQNCnVzZXMgImNpdmlsIGFzc2V0IGZvcmZlaXR1cmUi IHRvIHN0ZWFsIGJpbGxpb25zIG9mIGRvbGxhcnMgZWFjaCB5ZWFyIGZyb20NCmhhcmQtd29y a2luZywgbGF3IGFiaWRpbmcgY2l0aXplbnMuJm5ic3A7IEdldCB5b3VyIG1vbmV5IG91dCBv ZiB0aGUgY291bnRyeQ0KYmVmb3JlIFVuY2xlIFNhbSBzbmF0Y2hlcyBpdCBhbGwuPC9mb250 PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQg d2hlcmUgdG8gYnV5ICJmb3JiaWRkZW4gcHJvZHVjdHMiIG9uDQp0aGUgSW50ZXJuZXQuIEZ1 cnRoZXIgZWxhYm9yYXRpb24gc2hvdWxkIG5vdCBiZSBuZWNlc3Nhcnk7IGp1c3QgdXNlIHlv dXINCmltYWdpbmF0aW9uLjwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29s b3I9IiMwMDAwOTkiPkdldCBhIGJldHRlciBqb2IgYnkgcHVyY2hhc2luZyBhIGNvbGxlZ2Ug ZGVncmVlDQooaW5jbHVkaW5nIGEgUGhkISkgZm9yIGEgdmVyeSBsb3cgZmVlLiBObyBzdHVk eSByZXF1aXJlZCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNvbG9yPSIj MDAwMDk5Ij5JZiB5b3VyIEVYIGlzIGNvbWluZyBhZnRlciB5b3VyIG1vbmV5LCBzdGF5IG9u ZQ0Kc3RlcCBhaGVhZCBvZiB0aGUgbGF3eWVycyBhbmQga2VlcCB0aGVpciBncmVlZHkgaGFu ZHMgb2ZmIHlvdXIgbG9vdC4gRmluZA0Kb3V0IGhvdyB0byBoaWRlIHlvdXIgbW9uZXkgd2hl cmUgaXQgd2lsbCBuZXZlciBiZSBmb3VuZC48L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxi Pjxmb250IGNvbG9yPSIjMDAwMDk5Ij5Bdm9pZCBsZWdhbCBwcm9ibGVtcywganVkZ21lbnRz LCBjb252aWN0aW9ucywNCmFuZCBldmVuIHByaXNvbiBzZW50ZW5jZXMgYnkgb2J0YWluaW5n IGEgY29tcGxldGVseSBuZXcgaWRlbnRpdHkgYW5kIGRpc2FwcGVhcmluZw0Kd2l0aG91dCBh IHRyYWNlITwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29sb3I9IiMwMDAw OTkiPkVyYXNlIHlvdXIgY3JpbWluYWwgcmVjb3JkIGFuZCBvYnRhaW4gYSBjb3B5IG9mDQp5 b3VyIEZCSSBmaWxlIHVzaW5nIHRoZSBGcmVlZG9tIG9mIEluZm9ybWF0aW9uIEFjdC4mbmJz cDsgRmluZCBvdXQgaWYgdGhlDQpnb3Zlcm5tZW50IGlzIGludmVzdGlnYXRpbmcgeW91IE5P VyBiZWZvcmUgaXQncyB0b28gTEFURSE8L2ZvbnQ+PC9iPjwvbGk+DQo8L3VsPg0KPGZvbnQg c2l6ZT0rMT5JZiB5b3UgaGF2ZSBiZWVuIHB1dHRpbmcgb2ZmIGJ1eWluZyBUaGUgQmFubmVk IENELCB3aGF0IGFyZQ0KeW91PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+d2FpdGluZyBm b3I/Jm5ic3A7IEJpZyBCcm90aGVyIGlzIGFscmVhZHkgYnJlYXRoaW5nIGRvd24NCm15IG5l Y2ssIHNvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+SSBjYW4ndCBrZWVwIHNlbGxpbmcg aXQgZm9yZXZlci4mbmJzcDsgSWYgeW91IGtlZXAgd2FpdGluZw0KdG8gcGxhY2U8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0rMT55b3VyIG9yZGVyLCB5b3UgbWF5IG5ldmVyIGZpbmQgVGhl IEJhbm5lZCBDRCBhZ2Fpbi4mbmJzcDsNCkZvciBvbmx5PC9mb250Pg0KPGJyPjxmb250IHNp emU9KzE+JDE5Ljk5LCB5b3Ugd2lsbCBnYWluIHZhbHVhYmxlIHBlYWNlLW9mLW1pbmQga25v d2luZw0KaG93IHRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+c2FmZWd1YXJkIHlvdXJz ZWxmLCB5b3VyIGZhbWlseSwgYW5kIHlvdXIgbW9uZXkuJm5ic3A7DQpXaG8gY2FuIHB1dCBh PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+cHJpY2Ugb24gZnJlZWRvbT8hPC9mb250Pg0K PHA+PGk+PHU+PGZvbnQgc2l6ZT0rMT5IZXJlIGlzIGFub3RoZXIgbG9vayBhdCB0aGUgY29u dGVudHMgb2YgdGhlIEJBTk5FRA0KQ0Q6PC9mb250PjwvdT48L2k+DQo8cD48aW1nIFNSQz0i aHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3 aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgY29u ZmlkZW50aWFsIGluZm8gb24gYW55b25lIGluIDMwIG1pbnV0ZXMgb3I8L2ZvbnQ+PC9mb250 Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmxlc3Mgb24gdGhl IEludGVybmV0LiBZb3UnbGwgYmUNCmFibGUgdG8gdHJhY2sgZG93biB5b3VyPC9mb250Pjwv Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vbGQgZmxh bWUsIGZpbmQgb3V0IGhvdyBtdWNoIG1vbmV5DQp5b3VyIGV4IGlzIGhpZGluZzwvZm9udD48 L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW4gdGhl aXIgYmFuayBhY2NvdW50LCBvciBydW4gYQ0KYmFja2dyb3VuZCBjaGVjayBvbjwvZm9udD48 L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+cHJvZXNw ZWN0aXZlIGNsaWVudCBvciBlbXBsb3llZS4NCkV2ZW4gZ292ZXJubWVudDwvZm9udD48L2Zv bnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YWdlbmNpZXMg aGF2ZSB0cm91YmxlIG9idGFpbmluZw0KbXVjaCBvZiB0aGlzIGluZm9ybWF0aW9uLjwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+WW91 IHdpbGwgaGF2ZSBhbGwgdGhlIHJlc291cmNlcw0Kb2YgYW55IHByb2Zlc3Npb25hbDwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW52 ZXN0aWdhdG9yIHJpZ2h0IGF0IHlvdXIgZmluZ2VydGlwcw0KLSBvbiB5b3VyIGhvbWU8L2Zv bnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNv bXB1dGVyITwvZm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVz YS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xv cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkxpc3Qgb2YgY29tcGFuaWVzIHdobyB3aWxs IGlzc3VlIHlvdSBhIGNvbGxlZ2U8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIj NjY2NjY2Ij48Zm9udCBzaXplPSsxPmRlZ3JlZSAoaW5jbHVkaW5nIGEgUGhkLikgZm9yIGEN CmZlZS4gTm8gc3R1ZHkgcmVxdWlyZWQhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJo dHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdp ZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93 IHRvIGdldCBGUkVFIGNhYmxlIGFuZCBEU1MgY2hhbm5lbHMsPC9mb250PjwvZm9udD4NCjxi cj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5pbmNsdWRpbmcgdGhlIGFk dWx0IHN0YXRpb25zIGFuZA0KUGF5LVBlci1WaWV3ITwvZm9udD48L2ZvbnQ+DQo8cD48aW1n IFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdo dD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkhv dyB0byBPYnRhaW4gTWljcm9zb2Z0IFByb2R1Y3RzIGFic29sdXRlbHk8L2ZvbnQ+PC9mb250 Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPkZSRUUsIHRoZSBz YWZlIGFuZCBMRUdBTCB3YXkhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8v Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5 Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGlzdCBvZiBzdXBwbGll cnMgb2YgInF1ZXN0aW9uYWJsZSIgaXRlbXMsIHN1Y2g8L2ZvbnQ+PC9mb250Pg0KPGJyPjxm b250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmFzIGZjYyBiYW5uZWQgY29tbXVu aWNhdGlvbnMgZGV2aWNlcywNCnNjYW5uZXJzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQg Y29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+bmlnaHQgdmlzaW9uIGdvZ2dsZXMsIHBh c3Nwb3J0cywNCmZha2UgaWRlbnRpZmljYXRpb24sPC9mb250PjwvZm9udD4NCjxicj48Zm9u dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5hbmQgZXZlcnl0aGluZyBlbHNlIHRo YXQgeW91IHdvbid0DQpmaW5kIGluIHRoZSBiYWNrPC9mb250PjwvZm9udD4NCjxicj48Zm9u dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vZiBTb2xkaWVyIG9mIEZvcnR1bmUg bWFnYXppbmUhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KRmluZCBwcm9kdWN0cyB0byByZXNlbGwg b24gdGhlIEludGVybmV0IHdpdGggb3VyPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xv cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5XaG9sZXNhbGUgRGlyZWN0b3J5IGNvbnRhaW5p bmcNCm92ZXIgMSBtaWxsaW9uPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2 NjY2NiI+PGZvbnQgc2l6ZT0rMT4odGhhdCdzIHJpZ2h0LCBvbmUgbWlsbGlvbiEpIHdob2xl c2FsZQ0Kc291cmNlcyBmb3I8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2 NjY2Ij48Zm9udCBzaXplPSsxPmNvbXB1dGVycywgZWxlY3Ryb25pY3MsIGJlYW5pZXMsDQp0 cmVuZCBpdGVtcyw8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48 Zm9udCBzaXplPSsxPmpld2VscnksIGNhcnMsIGNvbGxlY3RpYmxlcywgYW5kDQpldmVyeXRo aW5nIGVsc2UhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KT3ZlciAyNSBtaWxsaW9uIGVtYWlsIGFk ZHJlc3NlcywgZnJlc2ggYW5kPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2 NjY2NiI+PGZvbnQgc2l6ZT0rMT50YXJnZXRlZCEgWW91IGNhbiB1c2UgdGhlc2UgdG8NCmNv bnRhY3QgdGhlIHBlb3BsZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2 NjYiPjxmb250IHNpemU9KzE+YW5kIHNlbmQgdGhlbSB5b3VyIGFkdmVydGlzZW1lbnRzLjwv Zm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1h Z2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2 NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgb3V0IGhvdyB0byBnZXQgYSBjb21wbGV0ZWx5IG5l dyBpZGVudGl0eS48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48 Zm9udCBzaXplPSsxPkRpc2FwcGVhciB3aXRob3V0IGEgdHJhY2UhPC9mb250PjwvZm9udD4N CjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdp ZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXpl PSsxPg0KRmluZCBvdXQgaG93IHRvIEVSQVNFIGJhZCBjcmVkaXQgYW5kIGV2ZW48L2ZvbnQ+ PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNyZWF0 ZSBhIHdob2xlIG5ldyBmaWxlIGluIHRoZQ0KY3JlZGl0IGJ1cmVhdSBjb21wdXRlcnMuPC9m b250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFn ZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2 Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93IHRvIGJlYXQgdGhlIElSUy4gVGF4IHRpcHMg Zm9yIHRoZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250 IHNpemU9KzE+cmVzdCBvZiB1cy48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6 Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9 MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpDb21wbGV0ZSBndWlk ZSBvbiBob3cgdG8gY2xhaW0gcHVibGljIGxhbmQ8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250 IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPm9mZmVyZWQgYnkgdGhlIEdvdmVybm1l bnQuIFlvdQ0KY2FuIGZpbmQgeW91cjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9 IiM2NjY2NjYiPjxmb250IHNpemU9KzE+ZHJlYW0gaG9tZSBmb3IgYSByaWRpY3Vsb3VzbHkg bG93DQpwcmljZSBvciBidXk8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2 NjY2Ij48Zm9udCBzaXplPSsxPnByb3BlcnRpZXMgdG8gcmVzZWxsIGZvciBhIGh1Z2UNCnBy b2ZpdCE8L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2Eu Y29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9 IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBY2NlcHQgY2hlY2tzIGZyb20geW91ciBjdXN0 b21lcnMgYnkgZmF4LDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYi Pjxmb250IHNpemU9KzE+cGhvbmUgYW5kIGVtYWlsIHdpdGggdGhlIGZ1bGwgd29ya2luZw0K dmVyc2lvbiBvZjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxm b250IHNpemU9KzE+Q2hlY2tlciBTb2Z0d2FyZSBpbmNsdWRlZCE8L2ZvbnQ+PC9mb250Pg0K PHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lm IiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9 KzE+DQpCdXNpbmVzcyBzb2Z0d2FyZSB0byBoZWxwIHlvdSBydW4geW91ciBzbWFsbDwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YnVz aW5lc3MsIGluY2x1ZGluZyBsYWJlbCBtYWtlcg0Kc29mdHdhcmUsIG1vbmV5PC9mb250Pjwv Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5tYW5hZ2Vt ZW50IHNvZnR3YXJlLCBJUlMgZm9yZ2l2ZW5lc3MNCnByb2dyYW0sPC9mb250PjwvZm9udD4N Cjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5kYXRhYmFzZSBzb2Z0 d2FyZSwgYW5kIG11Y2ggbW9yZS48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6 Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9 MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBIGh1Z2UgY29sbGVj dGlvbiBvZiBzY3JlZW5zYXZlcnMsIGdyYXBoaWNzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZv bnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+Y2xpcGFydCwgYW5kIGRlc2t0b3Ag dGhlbWVzIHRvDQpzcGljZSB1cCB5b3VyIGNvbXB1dGVyLjwvZm9udD48L2ZvbnQ+DQo8cD48 aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhl aWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4N Ck1VQ0gsIE1VQ0ggTU9SRSB0aGF0IHdlIGRvbid0IGhhdmUgcm9vbSB0byBsaXN0ITwvZm9u dD48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsxPldlIGFyZSBzbyBjb25maWRlbnQgdGhhdCB5 b3Ugd2lsbCBsb3ZlIHRoaXMgQ0QgdGhhdCB3ZTwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx Pm9mZmVyIGEgZnVsbCAzMC1kYXksIG5vIHF1ZXN0aW9ucyBhc2tlZCBtb25leS1iYWNrPC9m b250Pg0KPGJyPjxmb250IHNpemU9KzE+Z3VhcmFudGVlLiBUbyBvcmRlciB0aGUgIkJhbm5l ZCBDRCIgcmlnaHQgbm93IGZvciB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5zdXBl ciBsb3cgcHJpY2Ugb2Ygb25seSAkMTkuOTksIGp1c3QgY2xpY2sgb24gdGhlIGxpbms8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5iZWxvdyB0byBwYXkgd2l0aCBhIFZpc2Egb3IgTWFz dGVyY2FyZDo8L2ZvbnQ+DQo8YnI+Jm5ic3A7DQo8dGFibGUgQk9SREVSPTAgQ09MUz0yIFdJ RFRIPSI1MCUiID4NCjx0cj4NCjx0ZD48Zm9udCBzaXplPSsyPjxhIGhyZWY9Imh0dHA6Ly93 d3cuY29tcHV6b25ldXNhLmNvbS9jY3BheW1lbnQvYmFubmVkY2Q3Mi5odG0iPk9yZGVyDQpO b3chPC9hPjwvZm9udD48L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxpbWcgU1JDPSJodHRwOi8v Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvZ3VhcmFudGVlLmdpZiIgaGVpZ2h0PTk2IHdpZHRo PTk1PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD5PciB5b3UgbWF5 IHBheSB3aXRoIGNhc2gsIGNoZWNrIG9yIG1vbmV5IG9yZGVyIGJ5IHByaW50aW5nIHRoZSBv cmRlcg0KPGJyPmZvcm0gYmVsb3cgYW5kIHNlbmRpbmcgaXQgd2l0aCB5b3VyIHBheW1lbnQu DQo8cD48Yj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIENVVCBIRVJFIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPC9iPg0KPHA+UHJvZHVjdDogIlRoZSBCYW5uZWQgQ0QiDQo8YnI+UHJp Y2U6ICQxOS45OSArICQ0LjAxIHNoaXBwaW5nL2hhbmRsaW5nDQo8cD5IT1cgVE8gT1JERVIg QlkgTUFJTDogUHJpbnQgb3V0IHRoaXMgb3JkZXIgZm9ybSBhbmQgc2VuZCBjYXNoLA0KPGJy PnBlcnNvbmFsIGNoZWNrLCBtb25leSBvcmRlciBvciBjYXNoaWVyJ3MgY2hlY2sgdG8gdGhl IGFkZHJlc3MgbGlzdGVkDQpiZWxvdzoNCjxwPlF1aWtzaWx2ZXIgRW50ZXJwcmlzZXMgSW5j Lg0KPGJyPjM3OTIgQnJvYWR3YXkgIzM5OA0KPGJyPk5ldyBZb3JrLCBOWSAxMDAzMg0KPHA+ WW91ciBTaGlwcGluZyBJbmZvcm1hdGlvbjoNCjxwPllvdXIgTmFtZV9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQWRkcmVzc19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQ2l0eV9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPlN0YXRl IC8gWmlwX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJy PlBob25lICM6IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPGJyPihGb3IgcHJvYmxlbXMgd2l0aCB5b3VyIG9yZGVyIG9ubHkuIE5vIHNhbGVzbWVu IHdpbGwgY2FsbC4pDQo8cD5FbWFpbCBBZGRyZXNzX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPHA+UGxlYXNlIG5vdGUgdGhhdCBtYWlsLWluIG9yZGVycyBt YXkgYmUgZGVsYXllZCAyLTQgd2Vla3MuDQo8cD5bIF0gSSBhbSBlbmNsb3NpbmcgYSBjaGVj ayBvciBtb25leSBvcmRlciBmb3IgJDI0LjAwDQo8cD5bIF0gSSBhbSBtYWlsaW5nIG15IGNy ZWRpdCBjYXJkIG51bWJlci4gKE5vdGUgeW91ciBjYXJkIHdpbGwgYmUgY2hhcmdlZA0KZm9y ICQyNC4wMCkNCjxwPklmIHBheWluZyBieSBjcmVkaXQgY2FyZCwgcGxlYXNlIGZpbGwgaW4g dGhlIGluZm9ybWF0aW9uIGJlbG93Og0KPHA+Q3JlZGl0IENhcmQgTnVtYmVyOl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo8YnI+RXhwaXJhdGlvbiBEYXRlOl9fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPGJyPlNpZ25hdHVyZTpfX19fX19fX19fX19fX19fX19f X19fX19fDQo8YnI+RGF0ZTpfX19fX19fX19fX19fX19fX19fXw0KPHA+Tk9URTogVGhpcyBD RCBpcyBmb3IgaW5mb3JtYXRpb25hbCwgZWR1Y2F0aW9uYWwsIG9yDQo8YnI+ZW50ZXJ0YWlu bWVudCBwdXJwb3NlcyBvbmx5LiZuYnNwOyBTb21lIG9mIHRoZSBhY3Rpdml0aWVzDQo8YnI+ ZGVzY3JpYmVkIG9uIHRoaXMgQ0QgbWF5IGJlIGlsbGVnYWwgaWYgY2FycmllZCBvdXQuDQo8 YnI+VGhpcyBDRCBjb250YWlucyBsaW5rcyBhbmQgYWRkcmVzc2VzIG9mIGNvbXBhbmllcw0K PGJyPmFuZCBpbmRpdmlkdWFscyB3aGljaCBwcm9kdWNlIHZhcmlvdXMgcHJvZHVjdHMsIG9y DQo8YnI+b2ZmZXIgdmFyaW91cyBzZXJ2aWNlcywgd2hpY2ggbWF5IGJlIGlsbGVnYWwgaW4g eW91cg0KPGJyPmNvdW50cnksIHN0YXRlLCBvciBjaXR5LiZuYnNwOyBIb3dldmVyLCBpdCBp cyBwZXJmZWN0bHkNCjxicj5MRUdBTCB0byBwdXJjaGFzZSBhbmQgcG9zc2VzcyB0aGUgQmFu bmVkIENEIGluIHRoZQ0KPGJyPlVuaXRlZCBTdGF0ZXMgb2YgQW1lcmljYS4mbmJzcDsgQ29u dGFpbnMgYXBwcm94aW1hdGVseQ0KPGJyPjEwMCBtZWdzIG9mIGluZm9ybWF0aW9uLg0KPHA+ U2hpcHBpbmcgb3V0c2lkZSBVU0EgYWRkICQxMC4wMA0KPHA+KioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCjxicj5Zb3UgYXJl IHJlY2lldmluZyBhbiB1bnNvbGljaXRlZCBjb21tZXJjaWFsIGVtYWlsIGZyb20NCjxicj5R dWlrc2lsdmVyIEVudGVycHJpc2VzIEluYy4mbmJzcDsgV2UgcmVjb2duaXplIHRoYXQgeW91 IG1heQ0KPGJyPm5vdCB3aXNoIHRvIHJlY2lldmUgc3VjaCBlbWFpbHMgaW4gdGhlIGZ1dHVy ZSwgYW5kIHdlDQo8YnI+aGF2ZSBwcm92aWRlZCBhIGxpbmsgdG8gYXV0b21hdGljYWxseSBh bmQgaW5zdGFudGx5DQo8YnI+cmVtb3ZlIHlvdXJzZWxmOiA8YSBocmVmPSJodHRwOi8vd3d3 LmNvbXB1em9uZXVzYS5jb20vcmVtb3ZlLmh0bSI+UkVNT1ZFPC9hPg0KPGJyPlRoaXMgbWVz c2FnZSBpcyBiZWluZyBzZW50IHRvIHlvdSBpbiBjb21wbGlhbmNlIHdpdGgNCjxicj5mZWRl cmFsIGd1aWRlbGluZXMgZ292ZXJuaW5nIHRoZSB0cmFuc21pc3Npb24gb2YNCjxicj51bnNv bGljaXRlZCBjb21tZXJjaWFsIGVtYWlsLCBpbmNsdWRpbmcgdGhlIHByb3Zpc2lvbiBvZg0K PGJyPmNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIG91ciBjb21wYW55IHdpdGhpbiB0aGlzIGVt YWlsLCBhDQo8YnI+dmFsaWQgcmV0dXJuIGVtYWlsIGFkZHJlc3MsIGFuZCBhIHdheSBmb3Ig Y3VzdG9tZXJzDQo8YnI+dG8gcmVtb3ZlIHRoZW1zZWx2ZXMuJm5ic3A7IFBsZWFzZSBub3Rl LCBob3dldmVyLCB0aGF0IG91cg0KPGJyPmVtYWlsIGFkZHJlc3Mgd2FzIHZhbGlkIGF0IHRo ZSB0aW1lIG9mIHNlbmRpbmcsIGJ1dCBtYXkNCjxicj5iZSBjYW5jZWxsZWQgYnkgdGhlIElT UCBzaG9ydGx5IHRoZXJlYWZ0ZXIgZHVlIHRvIG91cg0KPGJyPnVzZSBvZiB1bnNvbGljaXRl ZCBlbWFpbC4mbmJzcDsgWW91IGNhbiByZWFkIGFib3V0IHRoZSB2YXJpb3VzDQo8YnI+bGF3 cyBnb3Zlcm5pbmcgdW5zb2xpY2l0ZWQgZW1haWw6IGh0dHA6Ly9zcGFtbGF3cy5jb20NCjxi cj4iVW5zb2xpY2l0ZWQgY29tbWVyY2lhbCBlbGVjdHJvbmljIG1haWwgY2FuIGJlIGFuIGlt cG9ydGFudA0KPGJyPm1lY2hhbmlzbSB0aHJvdWdoIHdoaWNoIGJ1c2luZXNzZXMgYWR2ZXJ0 aXNlIGFuZCBhdHRyYWN0DQo8YnI+Y3VzdG9tZXJzIGluIHRoZSBvbmxpbmUgZW52aXJvbm1l bnQuIiZuYnNwOyAtLSBVLlMuIENvbmdyZXNzLA0KPGJyPkguUi4gMTA2dGggQ09OR1JFU1Mg MmQgU2Vzc2lvbiBILiBSLiAzMTEzIFNlYy4gMiAoYSkzIEp1bHkNCjxicj4xOSwgMjAwMCBo dHRwOi8vd3d3LnNwYW1sYXdzLmNvbS9mZWRlcmFsL2hyMzExMy5odG1sDQo8YnI+KioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN Cjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjwvYm9keT4NCjwvaHRtbD4NCg== ------=_NextPart_000_001__10434935_51733.99-- From owner-ietf-ediint@mail.imc.org Tue Jan 30 15:12:15 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16923 for ; Tue, 30 Jan 2001 15:12:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA13132 for ietf-ediint-bks; Tue, 30 Jan 2001 11:24:48 -0800 (PST) Received: from mail-00-sct.usa.vcommerce.com (mail.vstore.com [63.67.128.133]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13125 for ; Tue, 30 Jan 2001 11:24:46 -0800 (PST) Received: by mail-00-sct.usa.vcommerce.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Jan 2001 12:31:12 -0700 Message-ID: <1F74D7EC7C994A4F8A642913A5B6C14D02BEAE@mail-00-sct.usa.vcommerce.com> From: Shan Harter To: ietf-ediint@imc.org Subject: AS1 and AS1 Government adoption Date: Tue, 30 Jan 2001 12:31:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I was looking for the email that spoke in regard the adoption of the US Gov and EDI INT. Maybe the HHS Secretary? Was I mistaken? Regards, Shan ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Shan Harter Director of EDI Systems Vcommerce Corporation "The Leading Provider of Outsourced e-Commerce Services" Phone: 480-315-6525 ext 525 Fax:480-922-9921 Web: Web:www.vcommerce.com/> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ietf-ediint@mail.imc.org Tue Jan 30 21:13:16 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20379 for ; Tue, 30 Jan 2001 21:13:15 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA29888 for ietf-ediint-bks; Tue, 30 Jan 2001 17:30:13 -0800 (PST) Received: from ns0.utdallas.edu (ns0.utdallas.edu [129.110.10.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA29884 for ; Tue, 30 Jan 2001 17:30:12 -0800 (PST) From: jcobb@utdallas.edu Received: from apache.utdallas.edu (apache.utdallas.edu [129.110.16.9]) by ns0.utdallas.edu (Postfix) with ESMTP id 4F41E1A0393 for ; Tue, 30 Jan 2001 19:36:57 -0600 (CST) Received: (from jcobb@localhost) by apache.utdallas.edu (8.9.1/8.9.1) id TAA12937 for ietf-ediint@imc.org; Tue, 30 Jan 2001 19:36:57 -0600 (CST) Date: Tue, 30 Jan 2001 19:36:57 -0600 (CST) Message-Id: <200101310136.TAA12937@apache.utdallas.edu> To: ietf-ediint@imc.org Subject: ISADS 2001 Call for Participation Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: (* our apologies if you receive multiple copies *) ISADS 2001 CALL FOR PARTICIPATION The Fifth International Symposium on Autonomous Decentralized Systems Monday March 26 - Wednesday March 28, 2001 Dallas, Texas, USA http://isads.utdallas.edu Sponsored by: IEEE Computer Society Information Processing Society of Japan The Society of Instrument and Control Engineers of Japan The Institute of Electronics, Infor. and Communication Engineers, Japan In Cooperation with: International Federation for Information Processing International Federation of Automatic Control OMG TINA-C Manufacturing Science and Technology Center, Japan Scope: Driven by the continuous growth in the power, intelligence and openness of computer, communication and control technologies, possibilities and opportunities for realizing highly efficient and dependable business and control systems have been steadily increasing. Dynamically changing social and economic situations demand next-generation systems based on emerging technologies and applications. Such systems are expected to have the characteristics of living systems composed of largely autonomous and decentralized components. Such systems are called Autonomous Decentralized Systems (ADS). After four successful symposiums, the Fifth International Symposium on Autonomous Decentralized Systems (ISADS) will be held in Dallas, Texas, USA during March 26-28, 2001. While ISADS 2001 will primarily focus on advancements and innovation in the ADS concept, technologies and applications related to the increasingly important topic of *Electronic Commerce* are also included. The symposium features 13 paper sessions and seven panel sessions, whose titles are below. In addition to the paper and panel sessions, the following events have been organized. * Reception (March 26) * Banquet (March 27) * A tour and dinner at the famous Southfork Ranch of Dallas (March 28). * A plant tour of two telecommunication companies in the Dallas area, Alcatel and Nortel (March 29). For general information, including registration, see our World-Wide Web Page at: http://isads.utdallas.edu Important Deadlines: *March 1, 2001 - Deadline for early registration *March 2, 2001, 5:00 p.m. central time - Any reservation at the conference hotel received after the cut-off date will be accepted based on space availability Paper Sessions: *E-commerce Models and Protocols *High Assurance Systems *Fault Tolerance and Safety Critical Systems *Architecture and Models for Distributed Systems *E-commerce Technology and Architecture *Distributed Object Management Systems *Short Papers: Distributed Object Management and Control *Multiagent systems *Middleware Technologies *Agent Technology for E-commerce *Self Stabilizing Systems *Secure Systems and Applications *Modeling and Performance Panel Sessions: *XML and E-Business Frameworks *Agent-Based Electronic Commerce: Opportunities and Challenges *Embedded Systems *Mobile Computing and Communication *Robotics for Education and Entertainment *Security for the Web and E-Commerce Systems *Plenary closing panel: Future of Autonomous Decentralized Systems