From owner-ietf-ediint@mail.imc.org Wed Nov 1 10:55:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05093 for ; Wed, 1 Nov 2000 10:55:43 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA18161 for ietf-ediint-bks; Wed, 1 Nov 2000 07:11:55 -0800 (PST) Received: from del2.vsnl.net.in (del2.vsnl.net.in [202.54.15.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18154 for ; Wed, 1 Nov 2000 07:11:49 -0800 (PST) From: gary@gnetservices.com Received: from abinfosys01.abinfosys ([202.54.109.152]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id UAA21925 for ; Wed, 1 Nov 2000 20:51:01 -0500 (GMT) Received: from abinfosys01.abinfosys (ABINFOSYS01 [192.168.1.1]) by abinfosys01.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id VRK6SCLS; Wed, 1 Nov 2000 20:33:58 +0530 Received: by abinfosys01.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11012000-200936-2220.MMD@abinfosys; Wed, 1 Nov 2000 20:09:36 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id PAA23292 for ; Sat, 28 Oct 2000 15:18:06 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id CAA26483 for ; Sat, 28 Oct 2000 02:44:49 -0700 Received: by ns.secondary.com (8.9.3/8.9.3) id BAA22378 for ietf-ediint-bks; Sat, 28 Oct 2000 01:45:09 -0700 (PDT) Received: from del2.vsnl.net.in (del2.vsnl.net.in [202.54.15.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA22364 for ; Sat, 28 Oct 2000 01:45:04 -0700 (PDT) Received: from abinfosys01.abinfosys (d4105.pppdel.vsnl.net.in [203.197.206.220]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id OAA17403 for ; Sat, 28 Oct 2000 14:24:06 -0500 (GMT) Received: from abinfosys01.abinfosys (ABINFOSYS01 [192.168.1.1]) by abinfosys01.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id VRK6SB0W; Sat, 28 Oct 2000 14:13:07 +0530 Received: by abinfosys01.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG10282000-135111-1066.MMD@abinfosys; Sat, 28 Oct 2000 13:51:11 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id KAA28003 for ; Thu, 26 Oct 2000 10:22:47 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id VAA28714 for ; Wed, 25 Oct 2000 21:48:24 -0700 Received: by ns.secondary.com (8.9.3/8.9.3) id UAA24493 for ietf-ediint-bks; Wed, 25 Oct 2000 20:58:40 -0700 (PDT) Received: from gnetservices.com (gary.vnet.net [166.82.199.116]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA24487 for ; Wed, 25 Oct 2000 20:58:32 -0700 (PDT) Date: Wed, 25 Oct 2000 20:58:32 -0700 (PDT) Message-Id: <200010260358.UAA24487@ns.secondary.com> MIME-Version: 1.0 To: ietf-ediint@imc.org X-Mailer: 51883080.7AB27F4C.3a379d2dda9b5e34889937d7d67c6924 Subject: Imagine how many people in your downline would like to use this service to boost their online recruiting efforts. Now multiply that number by $10.00! Organization: GNet Services List-Archive: List-ID: List-Unsubscribe: X-UIDL: 5c64e5ef08750b4023e5f5fb3674694d Status: U List-Archive: List-ID: List-Unsubscribe: Content-Type: multipart/mixed; boundary="=200010252328=" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=200010252328= Content-Type: text/plain;charset=US-ASCII Welcome to the most effective prospecting site on the Internet today! I began using your website just 75 days ago and it now has become my number one source of qualified prospects for my business! So far this month I have enrolled 19 new Marketing Executives into my program with my HomeBusiness.to website and it's only the 19th of the month. I have never enrolled one per day in my entire career in this business before now! Jim Simpson ***************************************************************************************** You can now use our site to promote either an e-commerce opportunity or a diet and nutrition opportunity. When signing up, simply choose the version you would like to use. To make our service even better, you can now earn an incredible $10.00 PER MONTH for each person you refer to our site! That's right, every month you can get paid $10.00 for every person using our service that you sent to us. Imagine how many people in your downline would like to use this service to boost their online recruiting efforts. Now multiply that number by $10.00! Our basic subscription service is just $19.95, that means with just two active referrals your service now becomes virtually free! With three referrals, you actually make money each month. How many magazines and newspapers can offer that? Signup Now http://www.homebusiness.to/GNetSvcs ACT TODAY!!! --=200010252328=-- From owner-ietf-ediint@mail.imc.org Thu Nov 2 12:16:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22806 for ; Thu, 2 Nov 2000 12:16:42 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA23015 for ietf-ediint-bks; Thu, 2 Nov 2000 08:07:07 -0800 (PST) Received: from aurora.regenstrief.org (aurora.regenstrief.org [134.68.31.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23011 for ; Thu, 2 Nov 2000 08:07:04 -0800 (PST) Received: from aurora.regenstrief.org (schadow_g.regenstrief.org [134.68.31.121]) by aurora.regenstrief.org (8.11.1/8.9.3) with ESMTP id eA2GCdZ67816; Thu, 2 Nov 2000 11:12:39 -0500 (EST) (envelope-from gunther@aurora.regenstrief.org) Message-ID: <3A01927C.4CD41F28@aurora.regenstrief.org> Date: Thu, 02 Nov 2000 11:12:44 -0500 From: Gunther Schadow Organization: Regenstrief Institute X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: dick@8760.com CC: Rik Drummond , Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: Re: EDIINT and HIPAA References: <00e901c044dc$9f394b80$cde379a5@techcomm.com> Content-Type: multipart/mixed; boundary="------------954AD96CD27051380068DB64" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------954AD96CD27051380068DB64 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dick, I appreciate your warning. Please me (and others) understand ... You say: > AS2 contains two distinctly different ways to package and send EDI > and other data over HTTP: > > 1. The HTTP standard approach, ref: HTTP spec (www.ietf.org/rfc/rfc2616.txt), > Multipart/form-data spec (www.ietf.org/rfc/rfc2388.txt formerly rfc 1867) and > HTML 4.0 spec (http://www.w3.org/TR/REC-html40/) > This is the approach used by GISB and the Automotive Industry (AIAG E5) > > 2. E-mail based packaging as specified in EDIINT AS1 > (http://www.ietf.org/internet-drafts/draft-ietf-ediint-as1-11.txt ). Hmm, my understanding is that, while AS#1 uses SMTP (which I still believe is good ... but we had enough of that discussion :-), both AS#2 and the GISB profile use HTTP. The difference may be the payload of the HTTP request. Isn't it true that both AS#2 and GISB use the MIME security wrappers? Isn't the only difference that AS#2 uses RFC1767 application/EDI-* payload while GISB use multipart/form-data? Since you use form data, does that mean that GISB's operational model is that of a user interacting with a web-based e-commerce system directly (i.e. filling out an HTML form?) Most of X12, HL7, and NCPDP, certainly do not work with direct user interactions but use an EDI message payload formatted according to X12, HL7 and NCPDP specifications respectively. (Though I know that NCPDP has done something in direct user interaction too, but not sure how much that is actually used.) > The EDIINT AS2 interoperability test currently underway by the Drummond Group > and sponsored by UCC is exercising the e-mail specifications (option #2 above). > The "profile" defined and adopted by GISB and AIAG (option #1 above) is not > included in the EDIINT test, however there are numerous implementations of GISB > EDM and AIAG-E5 (the foundation specs that formed the basis of AS2 profile #1) > that have been used daily since 4/1997 for E-Commerce on the Internet (Enron > recently announced $200 Billion dollars in E-Commerce on the Internet; they were > the first company to implement the GISB standard for Internet E-Commerce). this is good and fine. The only requirement would be that these implementations can also support the EDI payload method of AS#2, either now or easily soon (I suppose they can.) We certainly do not want to change the underlying EDI standards to use form-data presentation. > The EDIINT AS2 interoperability test has uncovered some issues that required > changes to the e-mail formatting specifications within AS2 (Rik can provide the > details of the problems, but they were "show stoppers" that had to be fixed). > These changes do NOT affect the GISB or AIAG profiles of AS2 (option #1), the > changes are limited to the e-mail section (option #2). This means the AS2 > authors (Dale Moberg, Rik Drummond and myself) will have to make appropriate > adjustments to AS2 and republish as an IETF draft. This will begin a review > process and will most likely require a face-to-face meeting at the IETF to move > the process along. This could delay the standardization of AS2 by IETF, > depending on the feedback received regarding the changes. The GISB profile of > AS2 (option #1) has remained unchanged, so I don't expect any opposition/issues > to arise. Gulp, this means another year delay until the final RFC is out, the IESG has got to speed up its processes! > I'm willing to discuss this further and help move AS2 closer to becoming an IETF > and government approved standard, beyond the endorsement received by GISB from > DOE/FERC. > > FYI - Group 8760 has assisted in performing interoperability testing (Internet > transport only), using the GISB standard (with PGP encryption/signatures), > between an institutional provider and a large Insurance Carrier (payer) for > HIPAA compliance within the last 3 months with successful results. Would you be willing to come to a couple of HL7 meetings and help us release the IETF specs as HL7 standard (for ANSI approval) and communicate our few additional requirements back into the IETF? In addition, I would like to have some other IETF-EDIINT members (vendors) to step up and join that fast track group for EDIINT ANSI approval. If we could get three people who see this as a valuable investment, it would help. May be on the next IETF-EDIINT meeting we should talk about this. Either Kepa and/or I should come see you to discuss the ANSI question and get the ball rolling. But, you have to understand, I'm kind of looking for a clear sign from the EDIINT group to say "yes, this ANSI thing makes sense, so let's go do it," you know, some committment. Note that neither I nor HL7 has a particularly huge selfish interest in this to happen, we would not participate in that sudden market growth, we are not vendors selling products to every Medicare provider in the US :-). We are just kind of hoping to help the right thing to happen for the sake of sanity :-) regards -Gunther --------------954AD96CD27051380068DB64 Content-Type: text/x-vcard; charset=us-ascii; name="gunther.vcf" Content-Description: Card for Gunther Schadow Content-Disposition: attachment; filename="gunther.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Schadow;Gunther tel;fax:+1 317 630 6962 tel;home:+1 317 816 0516 tel;work:+1 317 630 7960 x-mozilla-html:FALSE url:http://aurora.rg.iupui.edu org:Regenstrief Institute for Health Care adr:;;1050 Wishard Blvd;Indianapolis;Indiana;46202;USA version:2.1 email;internet:gschadow@regenstrief.org title:M.D., Medical Information Scientist note;quoted-printable:Al oppinions expressed in this message are my own and do =0D=0Anot necessarily represent those of the Regenstrief Institute. fn:Gunther Schadow end:vcard --------------954AD96CD27051380068DB64-- From owner-ietf-ediint@mail.imc.org Thu Nov 2 14:19:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24270 for ; Thu, 2 Nov 2000 14:19:26 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA02762 for ietf-ediint-bks; Thu, 2 Nov 2000 10:26:20 -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 KAA02758 for ; Thu, 2 Nov 2000 10:26:18 -0800 (PST) Received: by mailman.8760.com from localhost (router,SLMail V3.2); Thu, 02 Nov 2000 12:30:35 -0600 Received: from gamma [192.168.21.133] by mailman.8760.com [192.168.21.90] (SLmail 3.2.3113) with SMTP id 91935FB1A38111D4BB090060974E38DD for plus 9 more; Thu, 02 Nov 2000 12:30:35 -0600 Reply-To: From: "Dick Brooks" To: "Gunther Schadow" Cc: "Rik Drummond" , "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , , "Dick Brooks" Subject: RE: EDIINT and HIPAA Date: Thu, 2 Nov 2000 12:26:46 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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: <3A01927C.4CD41F28@aurora.regenstrief.org> X-SLUIDL: DCF92622-AC1A11D4-BB090060-974E38DD Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Gunther, In my travels I've realized there is a great deal of confusion regarding AS2, your questions/comments are a great lead-in to help clear up some of the misunderstandings. I apologize for sending such a long e-mail but I think it is necessary at this point. I've provided my responses inline bounded by , so here goes: > -----Original Message----- > From: Gunther Schadow [mailto:gunther@aurora.regenstrief.org] > Sent: Thursday, November 02, 2000 10:13 AM > To: Dick Brooks > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: EDIINT and HIPAA > > > Dick, > > I appreciate your warning. Please me (and others) understand ... > > You say: > > AS2 contains two distinctly different ways to package and send EDI > > and other data over HTTP: > > > > 1. The HTTP standard approach, ref: HTTP spec > (www.ietf.org/rfc/rfc2616.txt), > > Multipart/form-data spec (www.ietf.org/rfc/rfc2388.txt formerly > rfc 1867) and > > HTML 4.0 spec (http://www.w3.org/TR/REC-html40/) > > This is the approach used by GISB and the Automotive Industry (AIAG E5) > > > > 2. E-mail based packaging as specified in EDIINT AS1 > > (http://www.ietf.org/internet-drafts/draft-ietf-ediint-as1-11.txt ). > > Hmm, my understanding is that, while AS#1 uses SMTP (which I still believe > is good ... but we had enough of that discussion :-), both AS#2 > and the GISB > profile use HTTP. The difference may be the payload of the HTTP request. > There are many good reasons why people prefer HTTP over E-mail (SMTP) for their mission critical EDI data exchanges, but we won't re-hash them here. If people want to know the details send me an e-mail mailto:dick@8760.com There are three key concepts when discussing EDIINT AS2; 1. Packaging 2. Payload 3. Data Transport 1. Packaging defines the way in which EDI data and header information is packaged together in preparation for transport. The packaging also includes a definition the headers that will be used for purposes such as identifying senders, receivers, etc. (e.g. within the GISB - multipart/form-data packaging of AS2 there is a "To" header which contains a DUNS number that identifies the intended recipient. Within the e-mail based packaging of AS2 there is a new header, called "AS2-To", which serves the same purpose as GISB's "To" header. The "AS2-To" header is one of the changes that came out of the EDIINT AS2 interoperability tests and this will be defined in the next draft release of AS2.) 2. Payload is the actual data a party wishes to send, typically a business transaction formatted in X12, EDIFACT, XML, etc. A payload is contained within a "package", as defined by 1. 3. Data Transport defines the mechanism used to send/receive data (HTTP, SMTP, FTP are all data transports). With regard to EDIINT AS2 it: Defines two types of packaging; 1. Multipart/form-data (as in GISB) 2. E-mail (as in AS1) Can package and send any type of payload (X12, XML, JPEG, etc.), regardless of the packaging used. The data can be encrypted and digitally signed. Mandates that all "packages" be exchanged via HTTP. Can support both batch and interactive (web forms) modes when using Multipart/form-data packaging. Here are two examples to help make this clear: GISB/AS2 example sending a signed/encrypted X12 file over HTTP using a non-interactive batch browser: POST c:\execute HTTP/1.0 Connection: Keep-Alive User-Agent: Group 8760 Batch Browser Content-type: multipart/form-data; boundary=---------------------------87453838942833 Content-Length: 5379 -----------------------------87453838942833 Content-Disposition: form-data; name="from" 123456789 -----------------------------87453838942833 Content-Disposition: form-data; name="to" 234567890 -----------------------------87453838942833 Content-Disposition: form-data; name="version" 1.4 -----------------------------87453838942833 Content-Disposition: form-data; name="receipt-disposition-to" 123456789 -----------------------------87453838942833 Content-Disposition: form-data; name="receipt-report-type" GISB-Acknowledgement-Receipt -----------------------------87453838942833 Content-Disposition: form-data; name="input-format" X12 -----------------------------87453838942833 Content-Disposition: form-data; name="input-data"; filename= c:\temp\smallnom.bin Content-Type: multipart/encrypted; boundary=8760; protocol="application/pgp-encrypted" --8760 Content-Type: application/pgp-encrypted Version: 1 --8760 Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----- Version: PGP 6.5 hQCMAzRG1pEOIOvdAQP+JMr0m/9+8yOL60Z9Vr6fFV81FCExB/o0xmwiMkiwYsHs z0e8sb7ErC340MrNA/dw3taGMjmI+CXYRF/PLEdg1NZE1ZCtNeL4YdIHAMLWwODG lQxhSucz8rMSgQ5mZzcOJwBdWLW70efgsu/9UljuJjYc1uZ6C03eFQv/43fkB+al ATtgydxX4g8QK664ad+Jo/XUICSmWBL66fqJR1KLeLf4wTaqGy174Aq48Wpwvg1E h785zC03UAw0qg0ugMt86dPeyd91e2JigqwDYEf/DYEKD0J9BGiGpS/uAupNKj8O cp2IWClxKOGUbxpVNOnNTqWHS/GntegvDE/7/ewCxDxsnmQS95pOl141QZ1RQbeN aqx2Dq/ra9g65HNchOCzjul5Vi8HHf6Yhg2WnROe+npByyCue6rihqgNVOJwj0cV zpb4JE+gMDf3q4ISUb1Fv7/+SSFHDdnhdC5YTpqf1Bc3B07hiLmtTXqNit31EbX9 UVElObzSa9ZhxbC6/eSl7Nuf5ZTDsh9nrk+QQJ6FeC9W4cqXLj7IZySaRO8Vtff+ 4ktqeuhYusT4kSpnk027aw4O/5jomUkfb22CAe4= =Oiuo -----END PGP MESSAGE----- --8760-- -----------------------------87453838942833 Here is an e-mail based example, taken directly from the current AS2 interoperability testing underway (this was provided by Dale Moberg). NOTE: the AS2-To and AS2-From headers are NOT defined by the current AS2 draft (these will be included in the next draft release of AS2): POST / HTTP/1.0 User-Agent: Somebodys AS2 implementation AS2-From: ZZCYCLONE AS2-To: someone@btradecorp.com Date: Wed, 18 Oct 2000 23:24:59 GMT Message-ID: <4fd79e5b-9e71-4655-8f98-d61f832dc11d@ipnetsolutions.com > Subject: EDI Document Content-Type: MULTIPART/SIGNED; protocol="application/pkcs7-signature";micalg=sha1;boundary="_=boundary1" Content-Disposition: attachment; filename="ZZIPNET-000000022.edi" Content-Length: 1507 --_=boundary1 Content-Type: APPLICATION/EDI-X12 Content-Disposition: attachment; filename="ZZIPNET-000000022.edi" ISA*00*ssssssssss*00*rrrrrrrrrr*ZZ*ipnet *ZZ*btrade --_=boundary1 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s ??Binary signature here?? --_=boundary1-- > Isn't it true that both AS#2 and GISB use the MIME security wrappers? > The AS2 compliant version of GISB uses the MIME security wrappers, the old GISB simply placed encrypted data into an application/octet-stream wrapper. > Isn't the only difference that AS#2 uses RFC1767 application/EDI-* > payload while GISB use multipart/form-data? > The AS2 compliant GISB also packages X12 payload data in a RFC 1767 compliant manner before placing it inside a multipart/form-data package. For example, here is an unencrypted X12 file in multipart/form-data packaging: Content-type: multipart/form-data; boundary=---------------------------87453838942833 Content-Length: 5379 -----------------------------87453838942833 Content-Disposition: form-data; name="from" 123456789 -----------------------------87453838942833 Content-Disposition: form-data; name="to" 234567890 -----------------------------87453838942833 Content-Disposition: form-data; name="version" 1.4 -----------------------------87453838942833 Content-Disposition: form-data; name="receipt-disposition-to" 123456789 -----------------------------87453838942833 Content-Disposition: form-data; name="receipt-report-type" GISB-Acknowledgement-Receipt -----------------------------87453838942833 Content-Disposition: form-data; name="input-format" X12 -----------------------------87453838942833 Content-Disposition: form-data; name="input-data"; filename= hipaa-institution-claim.x12 Content-Type: application/EDI-X12 healthcare claim data in X12 format goes here -----------------------------87453838942833 > Since you use form data, does that mean that GISB's operational model > is that of a user interacting with a web-based e-commerce system > directly (i.e. filling out an HTML form?) > This is the biggest misconception - GISB's operational model supports BOTH unattended (aka batch mode) and interactive types of data exchange. Both use the exact same packaging (multipart/form-data). By supporting both interactive and batch mode GISB has been able to support the small trading partner, via an interactive web form upload and the large multi-national using the batch file upload. > Most of X12, HL7, and NCPDP, certainly do not work with direct user > interactions but use an EDI message payload formatted according to > X12, HL7 and NCPDP specifications respectively. (Though I know that > NCPDP has done something in direct user interaction too, but not > sure how much that is actually used.) > No problem HL7 and HIPAA can support both interactive and batch mode clients using the GISB/AS2 profile. > > The EDIINT AS2 interoperability test currently underway by the > Drummond Group > > and sponsored by UCC is exercising the e-mail specifications > (option #2 above). > > The "profile" defined and adopted by GISB and AIAG (option #1 > above) is not > > included in the EDIINT test, however there are numerous > implementations of GISB > > EDM and AIAG-E5 (the foundation specs that formed the basis of > AS2 profile #1) > > that have been used daily since 4/1997 for E-Commerce on the > Internet (Enron > > recently announced $200 Billion dollars in E-Commerce on the > Internet; they were > > the first company to implement the GISB standard for Internet > E-Commerce). > > this is good and fine. The only requirement would be that these > implementations can also support the EDI payload method of AS#2, > either now or easily soon (I suppose they can.) > > We certainly do not want to change the underlying EDI standards to > use form-data presentation. > This is no need to change X12 - the X12 data is simply a payload within the multipart/form-data package. No changes are needed to package and send X12 following the GISB AS2 profile. In fact all of GISB's business transactions use standard X12 representation and there were no changes required to X12. > > The EDIINT AS2 interoperability test has uncovered some issues > that required > > changes to the e-mail formatting specifications within AS2 (Rik > can provide the > > details of the problems, but they were "show stoppers" that had > to be fixed). > > These changes do NOT affect the GISB or AIAG profiles of AS2 > (option #1), the > > changes are limited to the e-mail section (option #2). This > means the AS2 > > authors (Dale Moberg, Rik Drummond and myself) will have to > make appropriate > > adjustments to AS2 and republish as an IETF draft. This will > begin a review > > process and will most likely require a face-to-face meeting at > the IETF to move > > the process along. This could delay the standardization of AS2 by IETF, > > depending on the feedback received regarding the changes. The > GISB profile of > > AS2 (option #1) has remained unchanged, so I don't expect any > opposition/issues > > to arise. > > Gulp, this means another year delay until the final RFC is out, the IESG > has got to speed up its processes! > I'm not sure how long a delay we're looking at to make AS2 an RFC. When I worked on the development of RFC 1767 I thought we would finish in 3 months (we only had to define 3 MIME types). We started in 1993 and it didn't reach RFC status until March 1995. You just can't predict what will happen within the IETF. > > I'm willing to discuss this further and help move AS2 closer to > becoming an IETF > > and government approved standard, beyond the endorsement > received by GISB from > > DOE/FERC. > > > > FYI - Group 8760 has assisted in performing interoperability > testing (Internet > > transport only), using the GISB standard (with PGP > encryption/signatures), > > between an institutional provider and a large Insurance Carrier > (payer) for > > HIPAA compliance within the last 3 months with successful results. > > Would you be willing to come to a couple of HL7 meetings and help us > release the IETF specs as HL7 standard (for ANSI approval) and > communicate > our few additional requirements back into the IETF? > I'm interested in talking with you about your requirements and would be happy to assist. > In addition, I would like to have some other IETF-EDIINT members (vendors) > to step up and join that fast track group for EDIINT ANSI approval. If we > could get three people who see this as a valuable investment, it would > help. May be on the next IETF-EDIINT meeting we should talk about this. > Either Kepa and/or I should come see you to discuss the ANSI question and > get the ball rolling. > > But, you have to understand, I'm kind of looking for a clear sign > from the > EDIINT group to say "yes, this ANSI thing makes sense, so let's > go do it," > you know, some committment. Note that neither I nor HL7 has a > particularly > huge selfish interest in this to happen, we would not participate in that > sudden market growth, we are not vendors selling products to > every Medicare > provider in the US :-). We are just kind of hoping to help the right thing > to happen for the sake of sanity :-) > I'm not familiar with the HL7 standards process, all of my experience has been with IETF, DISA, GISB and recently ebXML. Each of these organizations has a different process for developing standards. If we brought AS2 to HL7 today, how long would it take to become an ANSI standard? I would like to read HL7's operational process document, can you provide a pointer? > regards > -Gunther Thanks, and sorry for the loooong message, 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 Thu Nov 2 15:20:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09298 for ; Thu, 2 Nov 2000 15:20:14 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA07344 for ietf-ediint-bks; Thu, 2 Nov 2000 11:31:50 -0800 (PST) Received: from gpu1dot38.gpu.com (gpu1dot38.gpu.com [148.108.1.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07337 for ; Thu, 2 Nov 2000 11:31:48 -0800 (PST) From: pbyrne@gpu.com Received: from cnotesmta1.gpuc.com (gpu4dot95.gpu.com [148.108.4.95]) by gpu1dot38.gpu.com (Build 98 8.9.3/NT-8.9.3) with SMTP id OAA26273; Thu, 02 Nov 2000 14:40:05 -0500 Received: by cnotesmta1.gpuc.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525698B.006BB573 ; Thu, 2 Nov 2000 14:36:28 -0500 X-Lotus-FromDomain: GPU To: Gunther Schadow cc: dick@8760.com, Rik Drummond , Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Message-ID: <8525698B.006BB458.00@cnotesmta1.gpuc.com> Date: Thu, 2 Nov 2000 14:36:22 -0500 Subject: Re: EDIINT and HIPAA Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings from Pennsylvania. For what it is worth, the regulated electric utilities in PA exchange X12 EDI data with energy suppliers using the "old" GISB method; i.e. X12 EDI transactions encrypted with PGP and transported via batch-mode HTTP POST method. The transaction volume averages in excess of one million EDI transactions per month. Many of the utilities have already declared their intention to migrate to AS2-compliant GISB as soon as the software is commercially available. The GISB method, whether "old" or AS2-compliant, is content neutral. It will transport data of any size, shape, color, or flavor, whether X12, HL7, or any other. In addition, it supports unattended, batch processing (which is how my company uses it). Hope this helps. Pete Byrne GPU Energy EC/EDI and Chair, Utility Industry Group Gunther Schadow on 11/02/2000 11:12:44 AM To: dick@8760.com cc: Rik Drummond , Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org(bcc: Pete Byrne) Subject: Re: EDIINT and HIPAA Dick, I appreciate your warning. Please me (and others) understand ... regards -Gunther From owner-ietf-ediint@mail.imc.org Thu Nov 2 17:30:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09544 for ; Thu, 2 Nov 2000 17:30:05 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA12869 for ietf-ediint-bks; Thu, 2 Nov 2000 13:45:42 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12865 for ; Thu, 2 Nov 2000 13:45:40 -0800 (PST) Received: by spyglass.cyclonecommerce.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Nov 2000 14:54:08 -0700 Received: from THARDINGLAPTOP (cx66967-a.phnx3.az.home.com [24.1.196.29]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VF1K0SSP; Thu, 2 Nov 2000 14:54:03 -0700 From: Terry Harding To: dick@8760.com, Gunther Schadow Cc: Rik Drummond , Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org, Dick Brooks Message-ID: <011901c04517$0cece530$1dc40118@THARDINGLAPTOP> References: Subject: Re: EDIINT and HIPAA Date: Thu, 2 Nov 2000 14:51:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Dick, This may have been mentioned in your email, but i must ask. You mentioned within your email, that AS2 supports two distinct types of packaging, a GISB style and an AS1 style. EDIINT(AS1) also specifies two packaging standards, one based around S/MIME(RSA) and another around openPGP(PGP). Will the gas industry support an AS2 compliant product which produces a GISB style message using RSA security, or must the security layer be PGP as in your example... Terry Harding Cyclone Commerce ----- Original Message ----- From: "Dick Brooks" To: "Gunther Schadow" Cc: "Rik Drummond" ; "Kepa Zubeldia" ; "CLEM" ; "Gary Crough" ; "Beth Morrow" ; "David@Drummondgroup. Com" ; ; ; "Dick Brooks" Sent: Thursday, November 02, 2000 11:26 AM Subject: RE: EDIINT and HIPAA > Gunther, > > In my travels I've realized there is a great deal of confusion regarding > AS2, your questions/comments are a great lead-in to help clear up some of > the misunderstandings. I apologize for sending such a long e-mail but I > think it is necessary at this point. I've provided my responses inline > bounded by , so here goes: > > > > -----Original Message----- > > From: Gunther Schadow [mailto:gunther@aurora.regenstrief.org] > > Sent: Thursday, November 02, 2000 10:13 AM > > To: Dick Brooks > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > Subject: Re: EDIINT and HIPAA > > > > > > Dick, > > > > I appreciate your warning. Please me (and others) understand ... > > > > You say: > > > AS2 contains two distinctly different ways to package and send EDI > > > and other data over HTTP: > > > > > > 1. The HTTP standard approach, ref: HTTP spec > > (www.ietf.org/rfc/rfc2616.txt), > > > Multipart/form-data spec (www.ietf.org/rfc/rfc2388.txt formerly > > rfc 1867) and > > > HTML 4.0 spec (http://www.w3.org/TR/REC-html40/) > > > This is the approach used by GISB and the Automotive Industry (AIAG E5) > > > > > > 2. E-mail based packaging as specified in EDIINT AS1 > > > (http://www.ietf.org/internet-drafts/draft-ietf-ediint-as1-11.txt ). > > > > Hmm, my understanding is that, while AS#1 uses SMTP (which I still believe > > is good ... but we had enough of that discussion :-), both AS#2 > > and the GISB > > profile use HTTP. The difference may be the payload of the HTTP request. > > > > > There are many good reasons why people prefer HTTP over E-mail (SMTP) for > their mission critical EDI data exchanges, but we won't re-hash them here. > If people want to know the details send me an e-mail mailto:dick@8760.com > > There are three key concepts when discussing EDIINT AS2; > 1. Packaging > 2. Payload > 3. Data Transport > > 1. Packaging defines the way in which EDI data and header information is > packaged together in preparation for transport. The packaging also includes > a definition the headers that will be used for purposes such as identifying > senders, receivers, etc. (e.g. within the GISB - multipart/form-data > packaging of AS2 there is a "To" header which contains a DUNS number that > identifies the intended recipient. Within the e-mail based packaging of AS2 > there is a new header, called "AS2-To", which serves the same purpose as > GISB's "To" header. The "AS2-To" header is one of the changes that came out > of the EDIINT AS2 interoperability tests and this will be defined in the > next draft release of AS2.) > > 2. Payload is the actual data a party wishes to send, typically a business > transaction formatted in X12, EDIFACT, XML, etc. > A payload is contained within a "package", as defined by 1. > > 3. Data Transport defines the mechanism used to send/receive data (HTTP, > SMTP, FTP are all data transports). > > With regard to EDIINT AS2 it: > Defines two types of packaging; > 1. Multipart/form-data (as in GISB) > 2. E-mail (as in AS1) > > Can package and send any type of payload (X12, XML, JPEG, etc.), > regardless of the packaging used. The data can be > encrypted and digitally signed. > > Mandates that all "packages" be exchanged via HTTP. > > Can support both batch and interactive (web forms) modes when using > Multipart/form-data packaging. > > Here are two examples to help make this clear: > > GISB/AS2 example sending a signed/encrypted X12 file over HTTP using a > non-interactive batch browser: > > POST c:\execute HTTP/1.0 > Connection: Keep-Alive > User-Agent: Group 8760 Batch Browser > Content-type: multipart/form-data; > boundary=---------------------------87453838942833 > Content-Length: 5379 > > -----------------------------87453838942833 > Content-Disposition: form-data; name="from" > 123456789 > -----------------------------87453838942833 > Content-Disposition: form-data; name="to" > 234567890 > -----------------------------87453838942833 > Content-Disposition: form-data; name="version" > 1.4 > -----------------------------87453838942833 > Content-Disposition: form-data; name="receipt-disposition-to" > 123456789 > -----------------------------87453838942833 > Content-Disposition: form-data; name="receipt-report-type" > GISB-Acknowledgement-Receipt > -----------------------------87453838942833 > Content-Disposition: form-data; name="input-format" > X12 > -----------------------------87453838942833 > Content-Disposition: form-data; name="input-data"; filename= > c:\temp\smallnom.bin > Content-Type: multipart/encrypted; boundary=8760; > protocol="application/pgp-encrypted" > --8760 > Content-Type: application/pgp-encrypted > Version: 1 > --8760 > Content-Type: application/octet-stream > -----BEGIN PGP MESSAGE----- > Version: PGP 6.5 > > hQCMAzRG1pEOIOvdAQP+JMr0m/9+8yOL60Z9Vr6fFV81FCExB/o0xmwiMkiwYsHs > z0e8sb7ErC340MrNA/dw3taGMjmI+CXYRF/PLEdg1NZE1ZCtNeL4YdIHAMLWwODG > lQxhSucz8rMSgQ5mZzcOJwBdWLW70efgsu/9UljuJjYc1uZ6C03eFQv/43fkB+al > ATtgydxX4g8QK664ad+Jo/XUICSmWBL66fqJR1KLeLf4wTaqGy174Aq48Wpwvg1E > h785zC03UAw0qg0ugMt86dPeyd91e2JigqwDYEf/DYEKD0J9BGiGpS/uAupNKj8O > cp2IWClxKOGUbxpVNOnNTqWHS/GntegvDE/7/ewCxDxsnmQS95pOl141QZ1RQbeN > aqx2Dq/ra9g65HNchOCzjul5Vi8HHf6Yhg2WnROe+npByyCue6rihqgNVOJwj0cV > zpb4JE+gMDf3q4ISUb1Fv7/+SSFHDdnhdC5YTpqf1Bc3B07hiLmtTXqNit31EbX9 > UVElObzSa9ZhxbC6/eSl7Nuf5ZTDsh9nrk+QQJ6FeC9W4cqXLj7IZySaRO8Vtff+ > 4ktqeuhYusT4kSpnk027aw4O/5jomUkfb22CAe4= > =Oiuo > -----END PGP MESSAGE----- > --8760-- > -----------------------------87453838942833 > > > Here is an e-mail based example, taken directly from the current AS2 > interoperability testing underway (this was provided by Dale Moberg). > NOTE: the AS2-To and AS2-From headers are NOT defined by the current AS2 > draft (these will be included in the next draft release of AS2): > > POST / HTTP/1.0 > User-Agent: Somebodys AS2 implementation > AS2-From: ZZCYCLONE > AS2-To: someone@btradecorp.com > Date: Wed, 18 Oct 2000 23:24:59 GMT > Message-ID: <4fd79e5b-9e71-4655-8f98-d61f832dc11d@ipnetsolutions.com > > > Subject: EDI Document > Content-Type: MULTIPART/SIGNED; > protocol="application/pkcs7-signature";micalg=sha1;boundary="_=boundary1" > Content-Disposition: attachment; filename="ZZIPNET-000000022.edi" > Content-Length: 1507 > > --_=boundary1 > Content-Type: APPLICATION/EDI-X12 > Content-Disposition: attachment; filename="ZZIPNET-000000022.edi" > > ISA*00*ssssssssss*00*rrrrrrrrrr*ZZ*ipnet *ZZ*btrade > --_=boundary1 > Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s > > ??Binary signature here?? > --_=boundary1-- > > > > > Isn't it true that both AS#2 and GISB use the MIME security wrappers? > > > > The AS2 compliant version of GISB uses the MIME security wrappers, the > old GISB simply placed encrypted data into an application/octet-stream > wrapper. > > > Isn't the only difference that AS#2 uses RFC1767 application/EDI-* > > payload while GISB use multipart/form-data? > > > > The AS2 compliant GISB also packages X12 payload data in a RFC 1767 > compliant manner before placing it inside a multipart/form-data package. For > example, here is an unencrypted X12 file in multipart/form-data packaging: > > Content-type: multipart/form-data; > boundary=---------------------------87453838942833 > Content-Length: 5379 > > -----------------------------87453838942833 > Content-Disposition: form-data; name="from" > 123456789 > -----------------------------87453838942833 > Content-Disposition: form-data; name="to" > 234567890 > -----------------------------87453838942833 > Content-Disposition: form-data; name="version" > 1.4 > -----------------------------87453838942833 > Content-Disposition: form-data; name="receipt-disposition-to" > 123456789 > -----------------------------87453838942833 > Content-Disposition: form-data; name="receipt-report-type" > GISB-Acknowledgement-Receipt > -----------------------------87453838942833 > Content-Disposition: form-data; name="input-format" > X12 > -----------------------------87453838942833 > Content-Disposition: form-data; name="input-data"; filename= > hipaa-institution-claim.x12 > Content-Type: application/EDI-X12 > > healthcare claim data in X12 format goes here > -----------------------------87453838942833 > > > > Since you use form data, does that mean that GISB's operational model > > is that of a user interacting with a web-based e-commerce system > > directly (i.e. filling out an HTML form?) > > > > This is the biggest misconception - GISB's operational model supports > BOTH unattended (aka batch mode) and interactive types of data exchange. > Both use the exact same packaging (multipart/form-data). By supporting both > interactive and batch mode GISB has been able to support the small trading > partner, via an interactive web form upload and the large multi-national > using the batch file upload. > > > > Most of X12, HL7, and NCPDP, certainly do not work with direct user > > interactions but use an EDI message payload formatted according to > > X12, HL7 and NCPDP specifications respectively. (Though I know that > > NCPDP has done something in direct user interaction too, but not > > sure how much that is actually used.) > > > > No problem HL7 and HIPAA can support both interactive and batch mode > clients using the GISB/AS2 profile. > > > > > The EDIINT AS2 interoperability test currently underway by the > > Drummond Group > > > and sponsored by UCC is exercising the e-mail specifications > > (option #2 above). > > > The "profile" defined and adopted by GISB and AIAG (option #1 > > above) is not > > > included in the EDIINT test, however there are numerous > > implementations of GISB > > > EDM and AIAG-E5 (the foundation specs that formed the basis of > > AS2 profile #1) > > > that have been used daily since 4/1997 for E-Commerce on the > > Internet (Enron > > > recently announced $200 Billion dollars in E-Commerce on the > > Internet; they were > > > the first company to implement the GISB standard for Internet > > E-Commerce). > > > > this is good and fine. The only requirement would be that these > > implementations can also support the EDI payload method of AS#2, > > either now or easily soon (I suppose they can.) > > > > We certainly do not want to change the underlying EDI standards to > > use form-data presentation. > > > > This is no need to change X12 - the X12 data is simply a payload within > the multipart/form-data package. No changes are needed to package and send > X12 following the GISB AS2 profile. In fact all of GISB's business > transactions use standard X12 representation and there were no changes > required to X12. > > > > > > The EDIINT AS2 interoperability test has uncovered some issues > > that required > > > changes to the e-mail formatting specifications within AS2 (Rik > > can provide the > > > details of the problems, but they were "show stoppers" that had > > to be fixed). > > > These changes do NOT affect the GISB or AIAG profiles of AS2 > > (option #1), the > > > changes are limited to the e-mail section (option #2). This > > means the AS2 > > > authors (Dale Moberg, Rik Drummond and myself) will have to > > make appropriate > > > adjustments to AS2 and republish as an IETF draft. This will > > begin a review > > > process and will most likely require a face-to-face meeting at > > the IETF to move > > > the process along. This could delay the standardization of AS2 by IETF, > > > depending on the feedback received regarding the changes. The > > GISB profile of > > > AS2 (option #1) has remained unchanged, so I don't expect any > > opposition/issues > > > to arise. > > > > Gulp, this means another year delay until the final RFC is out, the IESG > > has got to speed up its processes! > > > > I'm not sure how long a delay we're looking at to make AS2 an RFC. When > I worked on the development of RFC 1767 I thought we would finish in 3 > months (we only had to define 3 MIME types). We started in 1993 and it > didn't reach RFC status until March 1995. You just can't predict what will > happen within the IETF. > > > > > I'm willing to discuss this further and help move AS2 closer to > > becoming an IETF > > > and government approved standard, beyond the endorsement > > received by GISB from > > > DOE/FERC. > > > > > > FYI - Group 8760 has assisted in performing interoperability > > testing (Internet > > > transport only), using the GISB standard (with PGP > > encryption/signatures), > > > between an institutional provider and a large Insurance Carrier > > (payer) for > > > HIPAA compliance within the last 3 months with successful results. > > > > Would you be willing to come to a couple of HL7 meetings and help us > > release the IETF specs as HL7 standard (for ANSI approval) and > > communicate > > our few additional requirements back into the IETF? > > > > I'm interested in talking with you about your requirements and would be > happy to assist. > > > In addition, I would like to have some other IETF-EDIINT members (vendors) > > to step up and join that fast track group for EDIINT ANSI approval. If we > > could get three people who see this as a valuable investment, it would > > help. May be on the next IETF-EDIINT meeting we should talk about this. > > Either Kepa and/or I should come see you to discuss the ANSI question and > > get the ball rolling. > > > > But, you have to understand, I'm kind of looking for a clear sign > > from the > > EDIINT group to say "yes, this ANSI thing makes sense, so let's > > go do it," > > you know, some committment. Note that neither I nor HL7 has a > > particularly > > huge selfish interest in this to happen, we would not participate in that > > sudden market growth, we are not vendors selling products to > > every Medicare > > provider in the US :-). We are just kind of hoping to help the right thing > > to happen for the sake of sanity :-) > > > > I'm not familiar with the HL7 standards process, all of my experience > has been with IETF, DISA, GISB and recently ebXML. Each of these > organizations has a different process for developing standards. If we > brought AS2 to HL7 today, how long would it take to become an ANSI standard? > I would like to read HL7's operational process document, can you provide a > pointer? > > > > regards > > -Gunther > > Thanks, and sorry for the loooong message, > > 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 Thu Nov 2 19:51:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09359 for ; Thu, 2 Nov 2000 19:51:17 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA17739 for ietf-ediint-bks; Thu, 2 Nov 2000 15:54:10 -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 PAA17717 for ; Thu, 2 Nov 2000 15:53:34 -0800 (PST) Received: by mailman.8760.com from localhost (router,SLMail V3.2); Thu, 02 Nov 2000 17:59:00 -0600 Received: from gamma [192.168.21.133] by mailman.8760.com [192.168.21.90] (SLmail 3.2.3113) with SMTP id 385F061EB11411D4BB090060974E38DD for plus 9 more; Thu, 02 Nov 2000 17:59:00 -0600 Reply-To: From: "Dick Brooks" To: "Terry Harding" , "Gunther Schadow" Cc: "Rik Drummond" , "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: RE: EDIINT and HIPAA Date: Thu, 2 Nov 2000 17:55:12 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <011901c04517$0cece530$1dc40118@THARDINGLAPTOP> X-SLUIDL: DCF92728-AC1A11D4-BB090060-974E38DD Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Terry, my answers are inline: > This may have been mentioned in your email, but i must ask. > > You mentioned within your email, that AS2 supports two distinct types of > packaging, > a GISB style and an AS1 style. EDIINT(AS1) also specifies two packaging > standards, > one based around S/MIME(RSA) and another around openPGP(PGP). > > Will the gas industry support an AS2 compliant product which > produces a GISB > style message using RSA security, or must the security layer be PGP as in > your example... GISB has been using PGP to encrypt and sign EDI data since 1997 so this will remain their "crypto" standard. GISB REQUIRES the use of RSA public key algorithms to process EDI data. RSA algorithms are supported in PGP. The GISB/AS2 interoperability profile packages "PGP processed" data inside a multipart/signed or multipart/encrypted MIME envelope, in accordance with AS2 specifications. The entire multipart/* MIME envelope and encrypted data is then placed inside a multipart/form-data package. Here is what the entire package looks like when it's all put together (indention used to indicate layering only): Content-Type: multipart/form-data; boundary="foo" message headers are packaged here (To=XXX, From=YYY, etc.) Content-Type: multipart/encrypted; boundary="foo2"; protocol="application/pgp-encrypted" Content-Type: application/pgp-encrypted Content-Type: application/octet-stream Content-Type: application/EDI-X12 (signed/encrypted using PGP) ISA*.....X12 data (signed/encrypted using PGP) With regard to an earlier reference to the AS1 packaging style within AS2; I believe the new AS2-To and AS2-From header fields are incompatible with AS1 so we might want to refer to this "new packaging style" as the AS2/email packaging style in the next version of the AS2 spec and remove references to AS1. Would you agree? Regards, 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 Thu Nov 2 20:45:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21260 for ; Thu, 2 Nov 2000 20:45:09 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA19985 for ietf-ediint-bks; Thu, 2 Nov 2000 16:55:00 -0800 (PST) Received: from tdc.org.hk (ns2.tdc.org.hk [202.64.103.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA19981 for ; Thu, 2 Nov 2000 16:54:57 -0800 (PST) Received: from TDCMAIL.tdc.org.hk (hkntexs001p.tdc.org.hk [10.10.8.38]) by tdc.org.hk (8.9.1/8.9.1) with ESMTP id JAA11403; Fri, 3 Nov 2000 09:03:23 +0800 (HKT) Received: by tdcmail.tdc.org.hk with Internet Mail Service (5.5.2448.0) id ; Fri, 3 Nov 2000 08:57:24 +0800 Message-ID: <46BF451F9288D3119CB20090273D792002587254@tdcmail.tdc.org.hk> From: "K.W. Chan" To: dick@8760.com, Terry Harding , Gunther Schadow Cc: Rik Drummond , Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: RE: EDIINT and HIPAA Date: Fri, 3 Nov 2000 08:57:20 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04531.07641F10" 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_01C04531.07641F10 Content-Type: text/plain; charset="ISO-8859-1" Hi, I am a new comer to this group. Can anyone kindly point to me some useful sources to study how XML influences the development of Internet EDI? In various places, I see mentioning that EDI is dead because of the proliferation of XML. I don't understand this. Conventional EDI requires translators to integrate with backend applications. XML will not do away with this, but will perhaps make it easier for organizations to write their own translators. Is XML a hype or really a catalyst for next generation of EDI? K. W. -----Original Message----- From: Dick Brooks [mailto:dick@8760.com] Sent: Friday, November 03, 2000 7:55 AM To: Terry Harding; Gunther Schadow Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org Subject: RE: EDIINT and HIPAA Terry, my answers are inline: > This may have been mentioned in your email, but i must ask. > > You mentioned within your email, that AS2 supports two distinct types of > packaging, > a GISB style and an AS1 style. EDIINT(AS1) also specifies two packaging > standards, > one based around S/MIME(RSA) and another around openPGP(PGP). > > Will the gas industry support an AS2 compliant product which > produces a GISB > style message using RSA security, or must the security layer be PGP as in > your example... GISB has been using PGP to encrypt and sign EDI data since 1997 so this will remain their "crypto" standard. GISB REQUIRES the use of RSA public key algorithms to process EDI data. RSA algorithms are supported in PGP. The GISB/AS2 interoperability profile packages "PGP processed" data inside a multipart/signed or multipart/encrypted MIME envelope, in accordance with AS2 specifications. The entire multipart/* MIME envelope and encrypted data is then placed inside a multipart/form-data package. Here is what the entire package looks like when it's all put together (indention used to indicate layering only): Content-Type: multipart/form-data; boundary="foo" message headers are packaged here (To=XXX, From=YYY, etc.) Content-Type: multipart/encrypted; boundary="foo2"; protocol="application/pgp-encrypted" Content-Type: application/pgp-encrypted Content-Type: application/octet-stream Content-Type: application/EDI-X12 (signed/encrypted using PGP) ISA*.....X12 data (signed/encrypted using PGP) With regard to an earlier reference to the AS1 packaging style within AS2; I believe the new AS2-To and AS2-From header fields are incompatible with AS1 so we might want to refer to this "new packaging style" as the AS2/email packaging style in the next version of the AS2 spec and remove references to AS1. Would you agree? Regards, 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 ------_=_NextPart_001_01C04531.07641F10 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: EDIINT and HIPAA

Hi,

I am a new comer to this group. Can anyone kindly = point to me some useful sources to study how XML influences the = development of Internet EDI? In various places, I see mentioning that = EDI is dead because of the proliferation of XML. I don't understand = this. Conventional EDI requires translators to integrate with backend = applications. XML will not do away with this, but will perhaps make it = easier for organizations to write their own translators.

Is XML a hype or really a catalyst for next = generation of EDI?

K. W.

-----Original Message-----
From: Dick Brooks [mailto:dick@8760.com]
Sent: Friday, November 03, 2000 7:55 AM
To: Terry Harding; Gunther Schadow
Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; = Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; = ietf-ediint@imc.org

Subject: RE: EDIINT and HIPAA


Terry, my answers are inline:

> This may have been mentioned in your email, but = i must ask.
>
> You mentioned within your email, that AS2 = supports two distinct types of
> packaging,
> a  GISB style and an AS1 style. = EDIINT(AS1) also specifies two packaging
> standards,
> one based around S/MIME(RSA) and another around = openPGP(PGP).
>
> Will the gas industry support an AS2 compliant = product which
> produces a GISB
> style message using RSA security, or must the = security layer be PGP as in
> your example...

GISB has been using PGP to encrypt and sign EDI data = since 1997 so this will
remain their "crypto" standard. GISB = REQUIRES the use of RSA public key
algorithms to process EDI data. RSA algorithms are = supported in PGP.

The GISB/AS2 interoperability profile packages = "PGP processed" data inside a
multipart/signed or multipart/encrypted MIME = envelope, in accordance with
AS2 specifications. The entire multipart/* MIME = envelope and encrypted data
is then placed inside a multipart/form-data package. = Here is what the entire
package looks like when it's all put together = (indention used to indicate
layering only):

Content-Type: multipart/form-data; = boundary=3D"foo"

  message headers are packaged here (To=3DXXX, = From=3DYYY, etc.)

  Content-Type: multipart/encrypted; = boundary=3D"foo2";
  = protocol=3D"application/pgp-encrypted"

     Content-Type: = application/pgp-encrypted

     Content-Type: = application/octet-stream

         = Content-Type: application/EDI-X12 (signed/encrypted using PGP)

        =         ISA*.....X12 = data           &n= bsp;  (signed/encrypted using PGP)

With regard to an earlier reference to the AS1 = packaging style within AS2; I
believe the new AS2-To and AS2-From header fields = are incompatible with AS1
so we might want to refer to this "new = packaging style" as the AS2/email
packaging style in the next version of the AS2 spec = and remove references to
AS1. Would you agree?

Regards,

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

------_=_NextPart_001_01C04531.07641F10-- From owner-ietf-ediint@mail.imc.org Fri Nov 3 03:51:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27539 for ; Fri, 3 Nov 2000 03:51:28 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA23463 for ietf-ediint-bks; Fri, 3 Nov 2000 00:18:36 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA23453 for ; Fri, 3 Nov 2000 00:18:33 -0800 (PST) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JW311V93KW00004Q@mauve.mrochek.com> for ietf-ediint@imc.org; Fri, 03 Nov 2000 00:24:57 -0700 (PDT) Date: Fri, 03 Nov 2000 00:20:13 -0700 (PDT) Subject: AD review of EDIINT documents (was RE: Status and Future of EDIINT) In-reply-to: "Your message dated Tue, 31 Oct 2000 10:34:43 -0600" To: Rik Drummond Cc: ietf-ediint@imc.org Message-id: <01JW318160SM00004Q@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: <39FEE816.AE3E1EAB@aurora.regenstrief.org> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > well it is not dead. the spec is in the loop for rfc approval... and we now > have 12 vendors supporting as1 and 9 supporting as2. these are all > interoperable. if we don't get something back from the ietf shortly it might > be wise to go the ansi route... rik Well, as it happens I've been working on the AD review of these documents. I just completed that review today. I've attached my review comments below. Sorry it took so long. Ned ------ AD review of draft-ietf-ediint-req-08.txt: I started to write a bunch of comments on this document, but then decided against it. The basic problem is that due to the substantial amount of time that has passed since this text was written (through no fault of the authors or the WG, I hasten to add), quite a bit of it seems dated. For example, a discussion of the use of VPNs in contrast to VANs would seem appropriate. Some of the symmetric cipher discussion is likely dated as well. But given that it is informational I see little harm in publishing it as-is. Note that it may end up with an IESG note pointing out the timing issue, however. AD review of draft-ietf-ediint-as1-11.txt: This is where the issues are. Some are very minor, but a couple must be addressed. Security considerations section. The word "Technologies" is capitalized when it should not be. The security considerations section is normally at the end of the document. It also should cover actual considerations rather than restating what the document is about. 1.0 Introduction, first paragraph. The impression is given here that this is purely an Applicability Statement. However, the very next paragraph then indicates otherwise. I suggest that this be clarified by referring to "the bulk of this document is an Applicability Statement", or something similar. 1.0 Introduction, second paragraph. There's a reference to section 3.1.8, which does not exist in the current document. I believe this is supposed to be 5.3.1. 1.0 Introduction, third paragraph. "Used" -> "used". 2.1. Reference to "standard" is premature. I suggest saying "document" instead. 2.2.2, first paragraph. "The functional requirements document, [9] "Requirements for Inter-operable Internet EDI" (can be found at www.ietf.org)," needs to be rewritten as a reference to an RFC-to-be. 2.2.2, first paragraph, "Provides" -> "provides". 2.2.2, second paragraph. Use of the term "transport" here is confusing. I suggest "environment" or something similar instead. 2.2.2, last paragraph. "Satisfy" -> "satisfy". 2.2.3, first bullet item. This section doesn't identify RFC 2298 as the mechanism being used to request EDI receipts. Suggest making it clear here rather than having to get further into the document to find out. 2.3.2, fourth bullet item. Now that PGP itself is an IETF standard, should reference RFC 2440 as well as RFC 2015 here and elsewhere in the document. 2.3.2, fourth bullet item. REQUIRES is not a keyword on the 2119 list; suggest rewording to use REQUIRED instead. 5.4.1, first paragraph. The phrase Using message, "partial", should be Using message/partial 5.4.1, second paragraph. The phrase "so that if fragmentation does occur," isn't right in this context. I suggest "so that if fragmentation is needed" instead. 5.4.1. Recommending that partial be used but saying that support for it is optional could lead to interoperability issues. I suggest that you add that in the absence of knowledge that the recipient supports partial it SHOULD NOT be used. 5.4.1, last paragraph. This is the biggie. Saying it is OK to use content-encoding in email even as an option just isn't acceptable. The problem is one of interoperability: An unextended agent that receives a message with, say, a content-encoding of gzip won't recognize the field for what it is and will cheerfully decode the base64 expecting to find text or whatever. Instead it will find garbage. Unfortunately, the only way to add compression to email in a backwards compatible way is to define new content-transfer-encodings. If this is a real issue this is the mechanism that needs to be pursued. Note that it is fine to recommend use of content-encoding if the transport is HTTP. Content-encoding is well-defined there and agents are required to check for it and handle it. Finally, this document defines new disposition-notification-options and a new MDN field received-content-mic. Both of these things require IANA registration. It is customary in standards track documents to do this with an appendix containing the appropriate registration forms. This needs to be done per sections 10.2 and 10.3 of RFC 2298. That's it! From owner-ietf-ediint@mail.imc.org Fri Nov 3 06:27:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12167 for ; Fri, 3 Nov 2000 06:27:40 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA10797 for ietf-ediint-bks; Fri, 3 Nov 2000 02:49:35 -0800 (PST) Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA10785 for ; Fri, 3 Nov 2000 02:49:27 -0800 (PST) Received: from vaio ([12.74.11.150]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20001103105524.JZKZ14078.mtiwmhc23.worldnet.att.net@vaio>; Fri, 3 Nov 2000 10:55:24 +0000 From: "Rik Drummond" To: , "Gunther Schadow" Cc: , "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: RE: EDIINT and HIPAA Date: Fri, 3 Nov 2000 04:55:46 -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: <8525698B.006BB458.00@cnotesmta1.gpuc.com> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit bty, we are in the final edit phase of making as1 an rfc. after this goes through, as2 (which is based on as1) is next.... thanks for the note pete! best regards, rik -----Original Message----- From: pbyrne@gpu.com [mailto:pbyrne@gpu.com] Sent: Thursday, November 02, 2000 1:36 PM To: Gunther Schadow Cc: dick@8760.com; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org Subject: Re: EDIINT and HIPAA Greetings from Pennsylvania. For what it is worth, the regulated electric utilities in PA exchange X12 EDI data with energy suppliers using the "old" GISB method; i.e. X12 EDI transactions encrypted with PGP and transported via batch-mode HTTP POST method. The transaction volume averages in excess of one million EDI transactions per month. Many of the utilities have already declared their intention to migrate to AS2-compliant GISB as soon as the software is commercially available. The GISB method, whether "old" or AS2-compliant, is content neutral. It will transport data of any size, shape, color, or flavor, whether X12, HL7, or any other. In addition, it supports unattended, batch processing (which is how my company uses it). Hope this helps. Pete Byrne GPU Energy EC/EDI and Chair, Utility Industry Group Gunther Schadow on 11/02/2000 11:12:44 AM To: dick@8760.com cc: Rik Drummond , Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org(bcc: Pete Byrne) Subject: Re: EDIINT and HIPAA Dick, I appreciate your warning. Please me (and others) understand ... regards -Gunther From owner-ietf-ediint@mail.imc.org Fri Nov 3 06:38:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14492 for ; Fri, 3 Nov 2000 06:38:04 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA10763 for ietf-ediint-bks; Fri, 3 Nov 2000 02:49:13 -0800 (PST) Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA10757 for ; Fri, 3 Nov 2000 02:49:12 -0800 (PST) Received: from vaio ([12.74.11.150]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20001103105504.JZJW14078.mtiwmhc23.worldnet.att.net@vaio>; Fri, 3 Nov 2000 10:55:04 +0000 From: "Rik Drummond" To: Cc: Subject: RE: AD review of EDIINT documents (was RE: Status and Future of EDIINT) Date: Fri, 3 Nov 2000 04:55:28 -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: <01JW318160SM00004Q@mauve.mrochek.com> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit thanks, ned. we will get the changes in asap. bty the as2 document does not show it is being worked. i looked at all the minutes of over the last year and did not see it mentioned at all since january... best regards, rik -----Original Message----- From: ned.freed@innosoft.com [mailto:ned.freed@innosoft.com] Sent: Friday, November 03, 2000 1:20 AM To: Rik Drummond Cc: ietf-ediint@imc.org Subject: AD review of EDIINT documents (was RE: Status and Future of EDIINT) > well it is not dead. the spec is in the loop for rfc approval... and we now > have 12 vendors supporting as1 and 9 supporting as2. these are all > interoperable. if we don't get something back from the ietf shortly it might > be wise to go the ansi route... rik Well, as it happens I've been working on the AD review of these documents. I just completed that review today. I've attached my review comments below. Sorry it took so long. Ned ------ AD review of draft-ietf-ediint-req-08.txt: I started to write a bunch of comments on this document, but then decided against it. The basic problem is that due to the substantial amount of time that has passed since this text was written (through no fault of the authors or the WG, I hasten to add), quite a bit of it seems dated. For example, a discussion of the use of VPNs in contrast to VANs would seem appropriate. Some of the symmetric cipher discussion is likely dated as well. But given that it is informational I see little harm in publishing it as-is. Note that it may end up with an IESG note pointing out the timing issue, however. AD review of draft-ietf-ediint-as1-11.txt: This is where the issues are. Some are very minor, but a couple must be addressed. Security considerations section. The word "Technologies" is capitalized when it should not be. The security considerations section is normally at the end of the document. It also should cover actual considerations rather than restating what the document is about. 1.0 Introduction, first paragraph. The impression is given here that this is purely an Applicability Statement. However, the very next paragraph then indicates otherwise. I suggest that this be clarified by referring to "the bulk of this document is an Applicability Statement", or something similar. 1.0 Introduction, second paragraph. There's a reference to section 3.1.8, which does not exist in the current document. I believe this is supposed to be 5.3.1. 1.0 Introduction, third paragraph. "Used" -> "used". 2.1. Reference to "standard" is premature. I suggest saying "document" instead. 2.2.2, first paragraph. "The functional requirements document, [9] "Requirements for Inter-operable Internet EDI" (can be found at www.ietf.org)," needs to be rewritten as a reference to an RFC-to-be. 2.2.2, first paragraph, "Provides" -> "provides". 2.2.2, second paragraph. Use of the term "transport" here is confusing. I suggest "environment" or something similar instead. 2.2.2, last paragraph. "Satisfy" -> "satisfy". 2.2.3, first bullet item. This section doesn't identify RFC 2298 as the mechanism being used to request EDI receipts. Suggest making it clear here rather than having to get further into the document to find out. 2.3.2, fourth bullet item. Now that PGP itself is an IETF standard, should reference RFC 2440 as well as RFC 2015 here and elsewhere in the document. 2.3.2, fourth bullet item. REQUIRES is not a keyword on the 2119 list; suggest rewording to use REQUIRED instead. 5.4.1, first paragraph. The phrase Using message, "partial", should be Using message/partial 5.4.1, second paragraph. The phrase "so that if fragmentation does occur," isn't right in this context. I suggest "so that if fragmentation is needed" instead. 5.4.1. Recommending that partial be used but saying that support for it is optional could lead to interoperability issues. I suggest that you add that in the absence of knowledge that the recipient supports partial it SHOULD NOT be used. 5.4.1, last paragraph. This is the biggie. Saying it is OK to use content-encoding in email even as an option just isn't acceptable. The problem is one of interoperability: An unextended agent that receives a message with, say, a content-encoding of gzip won't recognize the field for what it is and will cheerfully decode the base64 expecting to find text or whatever. Instead it will find garbage. Unfortunately, the only way to add compression to email in a backwards compatible way is to define new content-transfer-encodings. If this is a real issue this is the mechanism that needs to be pursued. Note that it is fine to recommend use of content-encoding if the transport is HTTP. Content-encoding is well-defined there and agents are required to check for it and handle it. Finally, this document defines new disposition-notification-options and a new MDN field received-content-mic. Both of these things require IANA registration. It is customary in standards track documents to do this with an appendix containing the appropriate registration forms. This needs to be done per sections 10.2 and 10.3 of RFC 2298. That's it! From owner-ietf-ediint@mail.imc.org Fri Nov 3 09:30:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26851 for ; Fri, 3 Nov 2000 09:30:01 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA23253 for ietf-ediint-bks; Fri, 3 Nov 2000 05:36:58 -0800 (PST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA23249 for ; Fri, 3 Nov 2000 05:36:56 -0800 (PST) From: dick@8760.com Received: from farpoint (user-2injrj7.dialup.mindspring.com [165.121.238.103]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with SMTP id IAA25872; Fri, 3 Nov 2000 08:43:08 -0500 (EST) Message-ID: <00a601c0459e$28b56620$67ee79a5@techcomm.com> To: "Rik Drummond" , , "Gunther Schadow" , Cc: "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , , References: Subject: Re: EDIINT and HIPAA Date: Fri, 3 Nov 2000 07:58:32 -0600 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 Rik, I agree, the original AS2 spec was based on AS1, but there were problems discovered during AS2 interoperability testing (using RFC 822 (email) style packaging) related to "To" and "From" headers, which resulted in the creation of two new headers specific to AS2, "AS2-To" and "AS2-From". We (as the authors of AS2) will have to provide details of these new routing headers and cannot depend entirely on AS1, as we had originally. AS1 and AS2 (using RFC 822 (email) packaging) will be VERY similar, but not exactly alike. I believe AS2 will have to stand on its own through the IESG review process and we'll have to provide "complete" technical specifications in AS2 to satisfy IESG requirements. Ned, am I correct in this postulation? Regards, Dick Brooks http://www.8760.com/ ----- Original Message ----- From: Rik Drummond To: ; Gunther Schadow Cc: Dick Brooks ; Kepa Zubeldia ; CLEM ; Gary Crough ; Beth Morrow ; David@Drummondgroup. Com ; ; Sent: Friday, November 03, 2000 4:55 AM Subject: RE: EDIINT and HIPAA > bty, we are in the final edit phase of making as1 an rfc. after this goes > through, as2 (which is based on as1) is next.... thanks for the note pete! > best regards, rik > > -----Original Message----- > From: pbyrne@gpu.com [mailto:pbyrne@gpu.com] > Sent: Thursday, November 02, 2000 1:36 PM > To: Gunther Schadow > Cc: dick@8760.com; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: EDIINT and HIPAA > > > > > Greetings from Pennsylvania. For what it is worth, the regulated electric > utilities in PA exchange X12 EDI data with energy suppliers using the "old" > GISB > method; i.e. X12 EDI transactions encrypted with PGP and transported via > batch-mode HTTP POST method. The transaction volume averages in excess of > one > million EDI transactions per month. > > Many of the utilities have already declared their intention to migrate to > AS2-compliant GISB as soon as the software is commercially available. > > The GISB method, whether "old" or AS2-compliant, is content neutral. It > will > transport data of any size, shape, color, or flavor, whether X12, HL7, or > any > other. In addition, it supports unattended, batch processing (which is how > my > company uses it). > > Hope this helps. > > Pete Byrne > GPU Energy EC/EDI > and > Chair, Utility Industry Group > > > > > > > Gunther Schadow on 11/02/2000 11:12:44 AM > > > > To: dick@8760.com > > cc: Rik Drummond , Kepa Zubeldia > , CLEM > , Gary Crough > , Beth Morrow > , "David@Drummondgroup. > Com" , GISB1@aol.com, > ietf-ediint@imc.org(bcc: Pete Byrne) > > > > Subject: Re: EDIINT and HIPAA > > > > > > > > > Dick, > > I appreciate your warning. Please me (and others) understand ... > > > > regards > -Gunther > > > > > From owner-ietf-ediint@mail.imc.org Fri Nov 3 09:58:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03913 for ; Fri, 3 Nov 2000 09:58:39 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA25572 for ietf-ediint-bks; Fri, 3 Nov 2000 06:13:19 -0800 (PST) Received: from inforack.cdac.org.sg ([203.127.153.65]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA25542 for ; Fri, 3 Nov 2000 06:12:54 -0800 (PST) From: hv@of-hachetal.de Received: from [63.30.197.239] by inforack.cdac.org.sg (NTMail 3.03.0014/1f.aaac) with ESMTP id sa364564 for ; Fri, 3 Nov 2000 22:26:43 +0800 To: hv@of-hachetal.de Subject: At last, Herbal V, the all natural alternative to V----A! Date: Fri, 3 Nov 2000 22:26:43 +0800 Message-Id: <14264334819878@cdac.org.sg> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Herbal V: An Incredible All-Natural Healthy Alternative Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhanced testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! “On a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!” — Justin Q B., New Haven, Texas “I haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!” — Sid R., Lakeland, Florida “I had sex four times in one night. It made me feel like a 19-year-old again.” — Chip S, Beech Mountain, North Carolina “Herbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days.” — Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. “Man! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!” — Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $28 ______ 2 Bottles of Herbal V $48 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ] International Orders Please add $16 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ] We cannot accept foreign checks. International money orders or credit cards only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 3502 N. Powerline Rd. #525 Pompano Beach, FL 33069 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From owner-ietf-ediint@mail.imc.org Fri Nov 3 10:44:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14573 for ; Fri, 3 Nov 2000 10:44:04 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA29659 for ietf-ediint-bks; Fri, 3 Nov 2000 06:57:16 -0800 (PST) Received: from aurora.regenstrief.org (aurora.regenstrief.org [134.68.31.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA29654 for ; Fri, 3 Nov 2000 06:57:14 -0800 (PST) Received: from aurora.regenstrief.org (schadow_g.regenstrief.org [134.68.31.121]) by aurora.regenstrief.org (8.11.1/8.9.3) with ESMTP id eA3F3VZ75767; Fri, 3 Nov 2000 10:03:31 -0500 (EST) (envelope-from gunther@aurora.regenstrief.org) Message-ID: <3A02D3CA.C723409F@aurora.regenstrief.org> Date: Fri, 03 Nov 2000 10:03:38 -0500 From: Gunther Schadow Organization: Regenstrief Institute X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: dick@8760.com CC: GISB1@aol.com, ietf-ediint@imc.org Subject: Re: EDIINT and HIPAA References: Content-Type: multipart/mixed; boundary="------------640FE2421E6885A84B080A01" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------640FE2421E6885A84B080A01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dick Brooks wrote: > With regard to an earlier reference to the AS1 packaging style within AS2; I > believe the new AS2-To and AS2-From header fields are incompatible with AS1 > so we might want to refer to this "new packaging style" as the AS2/email > packaging style in the next version of the AS2 spec and remove references to > AS1. Would you agree? Dick, (I have taken bunch of people off the CC list) I would raise the only caveat that the AS1-style AS2 should not be called "email" because of the negative connotations that this entails to some (not to me). regards -Gunther --------------640FE2421E6885A84B080A01 Content-Type: text/x-vcard; charset=us-ascii; name="gunther.vcf" Content-Description: Card for Gunther Schadow Content-Disposition: attachment; filename="gunther.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Schadow;Gunther tel;fax:+1 317 630 6962 tel;home:+1 317 816 0516 tel;work:+1 317 630 7960 x-mozilla-html:FALSE url:http://aurora.rg.iupui.edu org:Regenstrief Institute for Health Care adr:;;1050 Wishard Blvd;Indianapolis;Indiana;46202;USA version:2.1 email;internet:gschadow@regenstrief.org title:M.D., Medical Information Scientist note;quoted-printable:Al oppinions expressed in this message are my own and do =0D=0Anot necessarily represent those of the Regenstrief Institute. fn:Gunther Schadow end:vcard --------------640FE2421E6885A84B080A01-- From owner-ietf-ediint@mail.imc.org Fri Nov 3 16:26:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29650 for ; Fri, 3 Nov 2000 16:26:35 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA17298 for ietf-ediint-bks; Fri, 3 Nov 2000 12:40:37 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA17294 for ; Fri, 3 Nov 2000 12:40:35 -0800 (PST) Received: by spyglass.cyclonecommerce.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Nov 2000 13:49:03 -0700 Received: from THARDINGLAPTOP (cx66967-a.phnx3.az.home.com [24.1.196.29]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VF1K04M5; Fri, 3 Nov 2000 13:49:01 -0700 From: Terry Harding To: ietf-ediint@imc.org Message-ID: <00ff01c045d7$2153d040$1dc40118@THARDINGLAPTOP> References: <3A02D3CA.C723409F@aurora.regenstrief.org> Subject: IETF review of AS1 Date: Fri, 3 Nov 2000 13:46:22 -0700 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.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The AS1 documents Requirements for Inter-operable Internet EDI and MIME-based Secure EDI are currently under review by IETF and they have come back with some changes to the documents. I would like to get feedback from the list about one of these issues. Feedback: My comments follow with 5.4.1, last paragraph. This is the biggie. Saying it is OK to use content-encoding in email even as an option just isn't acceptable. The problem is one of interoperability: An unextended agent that receives a message with, say, a content-encoding of gzip won't recognize the field for what it is and will cheerfully decode the base64 expecting to find text or whatever. Instead it will find garbage. This holds true regardless of the method used to indicate compressed data. If we create a new Transfer-Encoding scheme or create a new header to indicate that the payload is compressed, unless the receiving agent supports the method in which compression was applied, it will received garbled data. Unfortunately, the only way to add compression to email in a backwards compatible way is to define new content-transfer-encodings. If this is a real issue this is the mechanism that needs to be pursued. I don't believe this is a viable method as this header is used extensively to indicate transfer encodings for smtp transfers. We would be required to create a new encoding type that compressed as well as converted the data into 7 bit ascii. Note that it is fine to recommend use of content-encoding if the transport is HTTP. Content-encoding is well-defined there and agents are required to check for it and handle it. This will only apply to unsecured data, meaning the content-encoding header is used as an http header and not within a mime bodypart. We require the compression of the payload not the whole message.. So it looks like we have 3 choices, 1 - strongly suggest that we wish to use the content-encoding header inside a mime bodypart 2 - create a new content-transfer-encoding method 3 - use one of the other acceptable headers to express compressed data. ex: Content-Description: 4 - add a name value pair to the content-type line ex: Content-Type: application/xml; encoding=gzip or Content-Type: applicatoin/xml; conversion= gzip. It is my preference to use a name value pair on the content-type line if we can not use the content-encoding header. Open for comments... Terry Harding Cyclone Commerce From owner-ietf-ediint@mail.imc.org Fri Nov 3 17:54:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20919 for ; Fri, 3 Nov 2000 17:54:05 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA19405 for ietf-ediint-bks; Fri, 3 Nov 2000 14:16:19 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19401 for ; Fri, 3 Nov 2000 14:16:18 -0800 (PST) Received: by spyglass.cyclonecommerce.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Nov 2000 15:24:49 -0700 Received: from THARDINGLAPTOP (cx66967-a.phnx3.az.home.com [24.1.196.29]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VF1K04TZ; Fri, 3 Nov 2000 15:24:45 -0700 From: Terry Harding To: ietf-ediint@imc.org Message-ID: <012501c045e4$80ef2470$1dc40118@THARDINGLAPTOP> References: <3A02D3CA.C723409F@aurora.regenstrief.org> <00ff01c045d7$2153d040$1dc40118@THARDINGLAPTOP> Subject: Re: IETF review of AS1 Date: Fri, 3 Nov 2000 15:22:07 -0700 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.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Another possible approach to the problem would be to create a new content subtype example: Content-Type: application/x-zlib; uncompresse-type=xml Here we are expressing the contents of the body part as a compressed unit, which when uncompressed will give us an xml document. Terry Harding Cyclone Commerce From owner-ietf-ediint@mail.imc.org Fri Nov 3 19:23:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10557 for ; Fri, 3 Nov 2000 19:23:55 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA21343 for ietf-ediint-bks; Fri, 3 Nov 2000 15:48:27 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA21339 for ; Fri, 3 Nov 2000 15:48:27 -0800 (PST) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JW3Q6NWVBK0000T2@mauve.mrochek.com> for ietf-ediint@imc.org; Fri, 03 Nov 2000 15:54:51 -0700 (PDT) Date: Fri, 03 Nov 2000 14:54:31 -0700 (PDT) Subject: Re: IETF review of AS1 In-reply-to: "Your message dated Fri, 03 Nov 2000 15:22:07 -0700" <012501c045e4$80ef2470$1dc40118@THARDINGLAPTOP> To: Terry Harding Cc: ietf-ediint@imc.org Message-id: <01JW3XOXWKN20000T2@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: <3A02D3CA.C723409F@aurora.regenstrief.org> <00ff01c045d7$2153d040$1dc40118@THARDINGLAPTOP> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > Another possible approach to the problem would be to create > a new content subtype example: > Content-Type: application/x-zlib; uncompresse-type=xml > Here we are expressing the contents of the body part as > a compressed unit, which when uncompressed will give us > an xml document. MIME expressly forbids the creation of content types of this sort. See RFC 2048, section 2.2.1. The way to do this is with a content-transfer-encoding. As it happens I've had this as a low priority task on my to-do list for some time; the work has gotten as far as draft-freed-newenc-00.txt Ned From owner-ietf-ediint@mail.imc.org Fri Nov 3 20:25:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23942 for ; Fri, 3 Nov 2000 20:25:43 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA23044 for ietf-ediint-bks; Fri, 3 Nov 2000 16:47:29 -0800 (PST) Received: from femail2.sdc1.sfba.home.com (femail2.sdc1.sfba.home.com [24.0.95.82]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA23040 for ; Fri, 3 Nov 2000 16:47:28 -0800 (PST) Received: from sv.chage.com ([24.20.168.137]) by femail2.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001104005342.HJNK14736.femail2.sdc1.sfba.home.com@sv.chage.com> for ; Fri, 3 Nov 2000 16:53:42 -0800 From: "Carl Hage" To: ietf-ediint@imc.org Date: Fri, 3 Nov 2000 16:53:36 -0800 Subject: Re: IETF review of AS1 In-reply-to: <00ff01c045d7$2153d040$1dc40118@THARDINGLAPTOP> X-mailer: Pegasus Mail for Win32 (v3.01d) Message-Id: <20001104005342.HJNK14736.femail2.sdc1.sfba.home.com@sv.chage.com> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Terry Harding Date sent: Fri, 3 Nov 2000 13:46:22 -0700 > 5.4.1, last paragraph. This is the biggie. Saying it is OK to use > content-encoding in email even as an option just isn't acceptable. Seems like "Content-Encoding" is a resonable extension, but... > 4 - add a name value pair to the content-type line > ex: Content-Type: application/xml; encoding=gzip > or Content-Type: applicatoin/xml; conversion= gzip. This wouldn't be backwards-compatible (has the same problem). However, it seems like the other way around, as you mention, makes sense as it can work with existing MIME software. I believe, the best backwards-compatible solution would be to define a new (standards track) discrete-type extension-token, "encoded", with subtypes registered for the different encodings, e.g. "gzip". A required parameter for encoded/gzip would be "encoded-type", which is the replacement "type/subtype" for the Content-Type before encoding. discrete-type := "text" / "image" / "audio" / "video" / "application" / extension-token [Note the word "Encoded" is more general than "Compress", and matches the nomenclature of "Content-Encoding".] Since it's impractical to include parameters within the Encoded-Type="string", the semantics is that an application processing "encoded/gzip" will strip off a "encoded-type" parameter, then decode the binary data and pass it to a MIME application with encoded-type used for Content-Type and the remaining parameters appended. Example: Content-Type: encoded/gzip; encoded-type=text/xml; schema="http://www.w3.org/xml/schema/EDI-HL7" (Test software can use: Content-Type: x-encoded/gzip; encoded-type=text/xml; schema="http://www.w3.org/xml/schema/EDI-HL7") An old MIME program would handle "encoded/gzip" like application/octet-stream, and typically would allow definition of a processing application for "encoding/gzip" to be some GUI that can uncompress and save the data. It makes more sense than "application/gzip". A new MIME processor would know that "encoded/XXXX" can be used as a piped filter, automatically post-processing the output of the XXXX filter and passed to the MIME handler for "encoding-type". In the above example, the "schema" is a hypothetical parameter passed to the xml MIME processor. Of course, it might make more sense to use "xml/edi-hl7" instead. (Or whatever content-type is used-- not the issue here.) Does this make sense to y'all? -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint@mail.imc.org Sat Nov 4 04:38:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25325 for ; Sat, 4 Nov 2000 04:38:42 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA21905 for ietf-ediint-bks; Sat, 4 Nov 2000 00:59:42 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA21901 for ; Sat, 4 Nov 2000 00:59:40 -0800 (PST) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JW45FZ42E800004Q@mauve.mrochek.com> for ietf-ediint@imc.org; Sat, 04 Nov 2000 01:06:10 -0700 (PDT) Date: Sat, 04 Nov 2000 00:47:32 -0700 (PDT) Subject: Re: IETF review of AS1 In-reply-to: "Your message dated Fri, 03 Nov 2000 13:46:22 -0700" <00ff01c045d7$2153d040$1dc40118@THARDINGLAPTOP> To: Terry Harding Cc: ietf-ediint@imc.org Message-id: <01JW4GYGF9YK00004Q@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: <3A02D3CA.C723409F@aurora.regenstrief.org> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > So it looks like we have 3 choices, > 1 - strongly suggest that we wish to use > the content-encoding header inside a mime bodypart As I explained before, this is not a viable option. Adding a new header whose use changes the essential nature of the underlying content is intrinsicly incompatible with the installed base. Speaking as an Area Director, I cannot approve such a document, and even if I did, the chances it would pass subsequent IESG review are for all intents and purposes nonexistant. > 2 - create a new content-transfer-encoding method This works because existing applications are required to examine this field if present and there's a well defined way new values are to be handled. > 3 - use one of the other acceptable headers to express compressed data. > ex: Content-Description: This has the same problem as content-encoding -- while content-description is a known field, its semantics in email don't affect data interpretation. > 4 - add a name value pair to the content-type line > ex: Content-Type: application/xml; encoding=gzip > or Content-Type: applicatoin/xml; conversion= gzip. Again, this has the same problem. > It is my preference to use a name value pair on the content-type line > if we can not use the content-encoding header. This is just as much of a nonstarter as content-encoding is. You do have one other option here, and that is to drop the compression idea entirely. But this and defining a content-transfer-encoding are the only viable approaches I see to the problem. Ned From owner-ietf-ediint@mail.imc.org Sun Nov 5 18:44:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09952 for ; Sun, 5 Nov 2000 18:44:06 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA06312 for ietf-ediint-bks; Sun, 5 Nov 2000 14:53:54 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06307 for ; Sun, 5 Nov 2000 14:53:42 -0800 (PST) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JW45FZ42E800004Q@mauve.mrochek.com> for ietf-ediint@imc.org; Sun, 05 Nov 2000 15:00:10 -0700 (PDT) Date: Sun, 05 Nov 2000 14:42:44 -0700 (PDT) Subject: Re: EDIINT and HIPAA In-reply-to: "Your message dated Fri, 03 Nov 2000 07:58:32 -0600" <00a601c0459e$28b56620$67ee79a5@techcomm.com> To: dick@8760.com Cc: Rik Drummond , pbyrne@gpu.com, Gunther Schadow , ned.freed@innosoft.com, Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org, dick@8760.com Message-id: <01JW6ODRLFHG00004Q@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > Rik, > I agree, the original AS2 spec was based on AS1, but there were problems > discovered during AS2 interoperability testing (using RFC 822 (email) style > packaging) related to "To" and "From" headers, which resulted in the creation > of two new headers specific to AS2, "AS2-To" and "AS2-From". We (as the authors > of AS2) will have to provide details of these new routing headers and cannot > depend entirely on AS1, as we had originally. > AS1 and AS2 (using RFC 822 (email) packaging) will be VERY similar, but not > exactly alike. I believe AS2 will have to stand on its own through the IESG > review process and we'll have to provide "complete" technical specifications in > AS2 to satisfy IESG requirements. > Ned, am I correct in this postulation? Well, sort of. The specification certainly has to be complete -- you cannot assume that missing bits will be inferred from another specification. However, you certainly can refer to the other specification rather than repeating the same words in both. Do note that normative references create a dependency as far as the standards process is concerned -- the specification referred to must be at the same or higher standards level as the one that refers to it. Ned From owner-ietf-ediint@mail.imc.org Mon Nov 6 12:41:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07152 for ; Mon, 6 Nov 2000 12:41:37 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA17629 for ietf-ediint-bks; Mon, 6 Nov 2000 08:59:53 -0800 (PST) Received: from abs.abinfosys ([203.197.233.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17618 for ; Mon, 6 Nov 2000 08:59:40 -0800 (PST) Received: from abs.abinfosys (ABS [192.168.1.1]) by abs.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WMF2WLR8; Mon, 6 Nov 2000 21:40:42 +0530 Received: by abs.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11062000-213817-31.MMD@abinfosys; Mon, 6 Nov 2000 21:38:17 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id EAA06072 for ; Sat, 4 Nov 2000 04:31:52 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id OAA05606 for ; Fri, 3 Nov 2000 14:58:16 -0800 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA19405 for ietf-ediint-bks; Fri, 3 Nov 2000 14:16:19 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19401 for ; Fri, 3 Nov 2000 14:16:18 -0800 (PST) Received: by spyglass.cyclonecommerce.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Nov 2000 15:24:49 -0700 Received: from THARDINGLAPTOP (cx66967-a.phnx3.az.home.com [24.1.196.29]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VF1K04TZ; Fri, 3 Nov 2000 15:24:45 -0700 From: Terry Harding To: ietf-ediint@imc.org Message-ID: <012501c045e4$80ef2470$1dc40118@THARDINGLAPTOP> References: <3A02D3CA.C723409F@aurora.regenstrief.org> <00ff01c045d7$2153d040$1dc40118@THARDINGLAPTOP> Subject: Re: IETF review of AS1 Date: Fri, 3 Nov 2000 15:22:07 -0700 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Archive: List-ID: List-Unsubscribe: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 983fe33f1bae9e3c1f4750dd769e890d Status: U Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Another possible approach to the problem would be to create a new content subtype example: Content-Type: application/x-zlib; uncompresse-type=xml Here we are expressing the contents of the body part as a compressed unit, which when uncompressed will give us an xml document. Terry Harding Cyclone Commerce From owner-ietf-ediint@mail.imc.org Mon Nov 6 12:44:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07735 for ; Mon, 6 Nov 2000 12:44:14 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA17609 for ietf-ediint-bks; Mon, 6 Nov 2000 08:59:37 -0800 (PST) Received: from abs.abinfosys ([203.197.233.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17593 for ; Mon, 6 Nov 2000 08:59:11 -0800 (PST) Received: from abs.abinfosys (ABS [192.168.1.1]) by abs.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WMF2WLRT; Mon, 6 Nov 2000 21:40:40 +0530 Received: by abs.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11062000-213808-26.MMD@abinfosys; Mon, 6 Nov 2000 21:38:08 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id DAA28694 for ; Sat, 4 Nov 2000 03:04:46 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id NAA28884 for ; Fri, 3 Nov 2000 13:31:13 -0800 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA17298 for ietf-ediint-bks; Fri, 3 Nov 2000 12:40:37 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA17294 for ; Fri, 3 Nov 2000 12:40:35 -0800 (PST) Received: by spyglass.cyclonecommerce.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Nov 2000 13:49:03 -0700 Received: from THARDINGLAPTOP (cx66967-a.phnx3.az.home.com [24.1.196.29]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VF1K04M5; Fri, 3 Nov 2000 13:49:01 -0700 From: Terry Harding To: ietf-ediint@imc.org Message-ID: <00ff01c045d7$2153d040$1dc40118@THARDINGLAPTOP> References: <3A02D3CA.C723409F@aurora.regenstrief.org> Subject: IETF review of AS1 Date: Fri, 3 Nov 2000 13:46:22 -0700 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Archive: List-ID: List-Unsubscribe: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 75ff1df30f36b96d3dd91f87e1e034a3 Status: U Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The AS1 documents Requirements for Inter-operable Internet EDI and MIME-based Secure EDI are currently under review by IETF and they have come back with some changes to the documents. I would like to get feedback from the list about one of these issues. Feedback: My comments follow with 5.4.1, last paragraph. This is the biggie. Saying it is OK to use content-encoding in email even as an option just isn't acceptable. The problem is one of interoperability: An unextended agent that receives a message with, say, a content-encoding of gzip won't recognize the field for what it is and will cheerfully decode the base64 expecting to find text or whatever. Instead it will find garbage. This holds true regardless of the method used to indicate compressed data. If we create a new Transfer-Encoding scheme or create a new header to indicate that the payload is compressed, unless the receiving agent supports the method in which compression was applied, it will received garbled data. Unfortunately, the only way to add compression to email in a backwards compatible way is to define new content-transfer-encodings. If this is a real issue this is the mechanism that needs to be pursued. I don't believe this is a viable method as this header is used extensively to indicate transfer encodings for smtp transfers. We would be required to create a new encoding type that compressed as well as converted the data into 7 bit ascii. Note that it is fine to recommend use of content-encoding if the transport is HTTP. Content-encoding is well-defined there and agents are required to check for it and handle it. This will only apply to unsecured data, meaning the content-encoding header is used as an http header and not within a mime bodypart. We require the compression of the payload not the whole message.. So it looks like we have 3 choices, 1 - strongly suggest that we wish to use the content-encoding header inside a mime bodypart 2 - create a new content-transfer-encoding method 3 - use one of the other acceptable headers to express compressed data. ex: Content-Description: 4 - add a name value pair to the content-type line ex: Content-Type: application/xml; encoding=gzip or Content-Type: applicatoin/xml; conversion= gzip. It is my preference to use a name value pair on the content-type line if we can not use the content-encoding header. Open for comments... Terry Harding Cyclone Commerce From owner-ietf-ediint@mail.imc.org Mon Nov 6 12:50:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09516 for ; Mon, 6 Nov 2000 12:50:37 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA17660 for ietf-ediint-bks; Mon, 6 Nov 2000 09:00:54 -0800 (PST) Received: from abs.abinfosys ([203.197.233.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17652 for ; Mon, 6 Nov 2000 09:00:21 -0800 (PST) Received: from abs.abinfosys (ABS [192.168.1.1]) by abs.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WMF2WLSH; Mon, 6 Nov 2000 21:40:44 +0530 Received: by abs.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11062000-213833-36.MMD@abinfosys; Mon, 6 Nov 2000 21:38:33 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id HAA12552 for ; Sat, 4 Nov 2000 07:04:10 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id RAA09903 for ; Fri, 3 Nov 2000 17:30:35 -0800 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA23044 for ietf-ediint-bks; Fri, 3 Nov 2000 16:47:29 -0800 (PST) Received: from femail2.sdc1.sfba.home.com (femail2.sdc1.sfba.home.com [24.0.95.82]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA23040 for ; Fri, 3 Nov 2000 16:47:28 -0800 (PST) Received: from sv.chage.com ([24.20.168.137]) by femail2.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001104005342.HJNK14736.femail2.sdc1.sfba.home.com@sv.chage.com> for ; Fri, 3 Nov 2000 16:53:42 -0800 From: "Carl Hage" To: ietf-ediint@imc.org Date: Fri, 3 Nov 2000 16:53:36 -0800 Subject: Re: IETF review of AS1 In-reply-to: <00ff01c045d7$2153d040$1dc40118@THARDINGLAPTOP> X-mailer: Pegasus Mail for Win32 (v3.01d) Message-Id: <20001104005342.HJNK14736.femail2.sdc1.sfba.home.com@sv.chage.com> List-Archive: List-ID: List-Unsubscribe: Content-Type: text X-UIDL: 24666f93e6659f59bdf3006d0654fd0d Status: U Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Terry Harding Date sent: Fri, 3 Nov 2000 13:46:22 -0700 > 5.4.1, last paragraph. This is the biggie. Saying it is OK to use > content-encoding in email even as an option just isn't acceptable. Seems like "Content-Encoding" is a resonable extension, but... > 4 - add a name value pair to the content-type line > ex: Content-Type: application/xml; encoding=gzip > or Content-Type: applicatoin/xml; conversion= gzip. This wouldn't be backwards-compatible (has the same problem). However, it seems like the other way around, as you mention, makes sense as it can work with existing MIME software. I believe, the best backwards-compatible solution would be to define a new (standards track) discrete-type extension-token, "encoded", with subtypes registered for the different encodings, e.g. "gzip". A required parameter for encoded/gzip would be "encoded-type", which is the replacement "type/subtype" for the Content-Type before encoding. discrete-type := "text" / "image" / "audio" / "video" / "application" / extension-token [Note the word "Encoded" is more general than "Compress", and matches the nomenclature of "Content-Encoding".] Since it's impractical to include parameters within the Encoded-Type="string", the semantics is that an application processing "encoded/gzip" will strip off a "encoded-type" parameter, then decode the binary data and pass it to a MIME application with encoded-type used for Content-Type and the remaining parameters appended. Example: Content-Type: encoded/gzip; encoded-type=text/xml; schema="http://www.w3.org/xml/schema/EDI-HL7" (Test software can use: Content-Type: x-encoded/gzip; encoded-type=text/xml; schema="http://www.w3.org/xml/schema/EDI-HL7") An old MIME program would handle "encoded/gzip" like application/octet-stream, and typically would allow definition of a processing application for "encoding/gzip" to be some GUI that can uncompress and save the data. It makes more sense than "application/gzip". A new MIME processor would know that "encoded/XXXX" can be used as a piped filter, automatically post-processing the output of the XXXX filter and passed to the MIME handler for "encoding-type". In the above example, the "schema" is a hypothetical parameter passed to the xml MIME processor. Of course, it might make more sense to use "xml/edi-hl7" instead. (Or whatever content-type is used-- not the issue here.) Does this make sense to y'all? -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint@mail.imc.org Mon Nov 6 12:50:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09545 for ; Mon, 6 Nov 2000 12:50:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17647 for ietf-ediint-bks; Mon, 6 Nov 2000 09:00:17 -0800 (PST) Received: from abs.abinfosys ([203.197.233.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17630 for ; Mon, 6 Nov 2000 08:59:57 -0800 (PST) From: ned.freed@innosoft.com Received: from abs.abinfosys (ABS [192.168.1.1]) by abs.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WMF2WLSB; Mon, 6 Nov 2000 21:40:43 +0530 Received: by abs.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11062000-213825-33.MMD@abinfosys; Mon, 6 Nov 2000 21:38:25 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id GAA11270 for ; Sat, 4 Nov 2000 06:01:48 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id QAA13333 for ; Fri, 3 Nov 2000 16:28:13 -0800 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA21343 for ietf-ediint-bks; Fri, 3 Nov 2000 15:48:27 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA21339 for ; Fri, 3 Nov 2000 15:48:27 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JW3Q6NWVBK0000T2@mauve.mrochek.com> for ietf-ediint@imc.org; Fri, 03 Nov 2000 15:54:51 -0700 (PDT) Date: Fri, 03 Nov 2000 14:54:31 -0700 (PDT) Subject: Re: IETF review of AS1 In-reply-to: "Your message dated Fri, 03 Nov 2000 15:22:07 -0700" <012501c045e4$80ef2470$1dc40118@THARDINGLAPTOP> To: Terry Harding Cc: ietf-ediint@imc.org Message-id: <01JW3XOXWKN20000T2@mauve.mrochek.com> MIME-version: 1.0 Content-transfer-encoding: 7BIT References: <3A02D3CA.C723409F@aurora.regenstrief.org> <00ff01c045d7$2153d040$1dc40118@THARDINGLAPTOP> List-Archive: List-ID: List-Unsubscribe: Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-UIDL: fb1cd0f623b85532bc68ca86c2f4c999 Status: U Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > Another possible approach to the problem would be to create > a new content subtype example: > Content-Type: application/x-zlib; uncompresse-type=xml > Here we are expressing the contents of the body part as > a compressed unit, which when uncompressed will give us > an xml document. MIME expressly forbids the creation of content types of this sort. See RFC 2048, section 2.2.1. The way to do this is with a content-transfer-encoding. As it happens I've had this as a low priority task on my to-do list for some time; the work has gotten as far as draft-freed-newenc-00.txt Ned From owner-ietf-ediint@mail.imc.org Mon Nov 6 12:51:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09746 for ; Mon, 6 Nov 2000 12:51:17 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17684 for ietf-ediint-bks; Mon, 6 Nov 2000 09:01:07 -0800 (PST) Received: from abs.abinfosys ([203.197.233.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17668 for ; Mon, 6 Nov 2000 09:00:58 -0800 (PST) From: ned.freed@innosoft.com Received: from abs.abinfosys (ABS [192.168.1.1]) by abs.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WMF2WLTF; Mon, 6 Nov 2000 21:40:48 +0530 Received: by abs.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11062000-213924-51.MMD@abinfosys; Mon, 6 Nov 2000 21:39:24 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id PAA14788 for ; Sat, 4 Nov 2000 15:17:16 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id BAA27324 for ; Sat, 4 Nov 2000 01:43:37 -0800 Received: by ns.secondary.com (8.9.3/8.9.3) id AAA21905 for ietf-ediint-bks; Sat, 4 Nov 2000 00:59:42 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA21901 for ; Sat, 4 Nov 2000 00:59:40 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JW45FZ42E800004Q@mauve.mrochek.com> for ietf-ediint@imc.org; Sat, 04 Nov 2000 01:06:10 -0700 (PDT) Date: Sat, 04 Nov 2000 00:47:32 -0700 (PDT) Subject: Re: IETF review of AS1 In-reply-to: "Your message dated Fri, 03 Nov 2000 13:46:22 -0700" <00ff01c045d7$2153d040$1dc40118@THARDINGLAPTOP> To: Terry Harding Cc: ietf-ediint@imc.org Message-id: <01JW4GYGF9YK00004Q@mauve.mrochek.com> MIME-version: 1.0 Content-transfer-encoding: 7BIT References: <3A02D3CA.C723409F@aurora.regenstrief.org> List-Archive: List-ID: List-Unsubscribe: Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-UIDL: 6ae1d7ea96e43edce83f606f679e6c39 Status: U Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > So it looks like we have 3 choices, > 1 - strongly suggest that we wish to use > the content-encoding header inside a mime bodypart As I explained before, this is not a viable option. Adding a new header whose use changes the essential nature of the underlying content is intrinsicly incompatible with the installed base. Speaking as an Area Director, I cannot approve such a document, and even if I did, the chances it would pass subsequent IESG review are for all intents and purposes nonexistant. > 2 - create a new content-transfer-encoding method This works because existing applications are required to examine this field if present and there's a well defined way new values are to be handled. > 3 - use one of the other acceptable headers to express compressed data. > ex: Content-Description: This has the same problem as content-encoding -- while content-description is a known field, its semantics in email don't affect data interpretation. > 4 - add a name value pair to the content-type line > ex: Content-Type: application/xml; encoding=gzip > or Content-Type: applicatoin/xml; conversion= gzip. Again, this has the same problem. > It is my preference to use a name value pair on the content-type line > if we can not use the content-encoding header. This is just as much of a nonstarter as content-encoding is. You do have one other option here, and that is to drop the compression idea entirely. But this and defining a content-transfer-encoding are the only viable approaches I see to the problem. Ned From owner-ietf-ediint@mail.imc.org Mon Nov 6 12:57:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11461 for ; Mon, 6 Nov 2000 12:57:23 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA17578 for ietf-ediint-bks; Mon, 6 Nov 2000 08:58:02 -0800 (PST) Received: from abs.abinfosys ([203.197.233.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17562 for ; Mon, 6 Nov 2000 08:57:04 -0800 (PST) From: ned.freed@innosoft.com Received: from abs.abinfosys (ABS [192.168.1.1]) by abs.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WMF2WLVJ; Mon, 6 Nov 2000 22:21:54 +0530 Received: by abs.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11062000-221637-141.MMD@abinfosys; Mon, 6 Nov 2000 22:16:37 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id FAA10850 for ; Mon, 6 Nov 2000 05:22:12 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id PAA08930 for ; Sun, 5 Nov 2000 15:48:19 -0800 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA06312 for ietf-ediint-bks; Sun, 5 Nov 2000 14:53:54 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06307 for ; Sun, 5 Nov 2000 14:53:42 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JW45FZ42E800004Q@mauve.mrochek.com> for ietf-ediint@imc.org; Sun, 05 Nov 2000 15:00:10 -0700 (PDT) Date: Sun, 05 Nov 2000 14:42:44 -0700 (PDT) Subject: Re: EDIINT and HIPAA In-reply-to: "Your message dated Fri, 03 Nov 2000 07:58:32 -0600" <00a601c0459e$28b56620$67ee79a5@techcomm.com> To: dick@8760.com Cc: Rik Drummond , pbyrne@gpu.com, Gunther Schadow , ned.freed@innosoft.com, Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org, dick@8760.com Message-id: <01JW6ODRLFHG00004Q@mauve.mrochek.com> MIME-version: 1.0 Content-transfer-encoding: 7BIT References: List-Archive: List-ID: List-Unsubscribe: Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-UIDL: 603faf11251cf383a5bf4ce72a8814dd Status: U Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > Rik, > I agree, the original AS2 spec was based on AS1, but there were problems > discovered during AS2 interoperability testing (using RFC 822 (email) style > packaging) related to "To" and "From" headers, which resulted in the creation > of two new headers specific to AS2, "AS2-To" and "AS2-From". We (as the authors > of AS2) will have to provide details of these new routing headers and cannot > depend entirely on AS1, as we had originally. > AS1 and AS2 (using RFC 822 (email) packaging) will be VERY similar, but not > exactly alike. I believe AS2 will have to stand on its own through the IESG > review process and we'll have to provide "complete" technical specifications in > AS2 to satisfy IESG requirements. > Ned, am I correct in this postulation? Well, sort of. The specification certainly has to be complete -- you cannot assume that missing bits will be inferred from another specification. However, you certainly can refer to the other specification rather than repeating the same words in both. Do note that normative references create a dependency as far as the standards process is concerned -- the specification referred to must be at the same or higher standards level as the one that refers to it. Ned From owner-ietf-ediint@mail.imc.org Mon Nov 6 13:23:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17452 for ; Mon, 6 Nov 2000 13:23:49 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA19805 for ietf-ediint-bks; Mon, 6 Nov 2000 09:44:05 -0800 (PST) Received: from abs.abinfosys ([203.197.233.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19783 for ; Mon, 6 Nov 2000 09:43:54 -0800 (PST) Received: from abs.abinfosys (ABS [192.168.1.1]) by abs.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WMJDBPZ4; Mon, 6 Nov 2000 23:23:56 +0530 Received: by abs.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11062000-232343-87.MMD@abinfosys; Mon, 6 Nov 2000 23:23:43 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id XAA03927 for ; Mon, 6 Nov 2000 23:23:03 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id JAA06085 for ; Mon, 6 Nov 2000 09:49:03 -0800 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA17609 for ietf-ediint-bks; Mon, 6 Nov 2000 08:59:37 -0800 (PST) Received: from abs.abinfosys ([203.197.233.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17593 for ; Mon, 6 Nov 2000 08:59:11 -0800 (PST) Received: from abs.abinfosys (ABS [192.168.1.1]) by abs.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WMF2WLRT; Mon, 6 Nov 2000 21:40:40 +0530 Received: by abs.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11062000-213808-26.MMD@abinfosys; Mon, 6 Nov 2000 21:38:08 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id DAA28694 for ; Sat, 4 Nov 2000 03:04:46 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id NAA28884 for ; Fri, 3 Nov 2000 13:31:13 -0800 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA17298 for ietf-ediint-bks; Fri, 3 Nov 2000 12:40:37 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA17294 for ; Fri, 3 Nov 2000 12:40:35 -0800 (PST) Received: by spyglass.cyclonecommerce.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Nov 2000 13:49:03 -0700 Received: from THARDINGLAPTOP (cx66967-a.phnx3.az.home.com [24.1.196.29]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VF1K04M5; Fri, 3 Nov 2000 13:49:01 -0700 From: Terry Harding To: ietf-ediint@imc.org Message-ID: <00ff01c045d7$2153d040$1dc40118@THARDINGLAPTOP> References: <3A02D3CA.C723409F@aurora.regenstrief.org> Subject: IETF review of AS1 Date: Fri, 3 Nov 2000 13:46:22 -0700 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Archive: List-ID: List-Unsubscribe: X-UIDL: 75ff1df30f36b96d3dd91f87e1e034a3 Status: U List-Archive: List-ID: List-Unsubscribe: Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The AS1 documents Requirements for Inter-operable Internet EDI and MIME-based Secure EDI are currently under review by IETF and they have come back with some changes to the documents. I would like to get feedback from the list about one of these issues. Feedback: My comments follow with 5.4.1, last paragraph. This is the biggie. Saying it is OK to use content-encoding in email even as an option just isn't acceptable. The problem is one of interoperability: An unextended agent that receives a message with, say, a content-encoding of gzip won't recognize the field for what it is and will cheerfully decode the base64 expecting to find text or whatever. Instead it will find garbage. This holds true regardless of the method used to indicate compressed data. If we create a new Transfer-Encoding scheme or create a new header to indicate that the payload is compressed, unless the receiving agent supports the method in which compression was applied, it will received garbled data. Unfortunately, the only way to add compression to email in a backwards compatible way is to define new content-transfer-encodings. If this is a real issue this is the mechanism that needs to be pursued. I don't believe this is a viable method as this header is used extensively to indicate transfer encodings for smtp transfers. We would be required to create a new encoding type that compressed as well as converted the data into 7 bit ascii. Note that it is fine to recommend use of content-encoding if the transport is HTTP. Content-encoding is well-defined there and agents are required to check for it and handle it. This will only apply to unsecured data, meaning the content-encoding header is used as an http header and not within a mime bodypart. We require the compression of the payload not the whole message.. So it looks like we have 3 choices, 1 - strongly suggest that we wish to use the content-encoding header inside a mime bodypart 2 - create a new content-transfer-encoding method 3 - use one of the other acceptable headers to express compressed data. ex: Content-Description: 4 - add a name value pair to the content-type line ex: Content-Type: application/xml; encoding=gzip or Content-Type: applicatoin/xml; conversion= gzip. It is my preference to use a name value pair on the content-type line if we can not use the content-encoding header. Open for comments... Terry Harding Cyclone Commerce From owner-ietf-ediint@mail.imc.org Mon Nov 6 13:24:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17697 for ; Mon, 6 Nov 2000 13:24:55 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA19801 for ietf-ediint-bks; Mon, 6 Nov 2000 09:44:02 -0800 (PST) Received: from abs.abinfosys ([203.197.233.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19784 for ; Mon, 6 Nov 2000 09:43:54 -0800 (PST) Received: from abs.abinfosys (ABS [192.168.1.1]) by abs.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WMJDBPZ3; Mon, 6 Nov 2000 23:23:56 +0530 Received: by abs.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11062000-232338-84.MMD@abinfosys; Mon, 6 Nov 2000 23:23:38 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id XAA01073 for ; Mon, 6 Nov 2000 23:19:35 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id JAA05005 for ; Mon, 6 Nov 2000 09:45:35 -0800 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA17629 for ietf-ediint-bks; Mon, 6 Nov 2000 08:59:53 -0800 (PST) Received: from abs.abinfosys ([203.197.233.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17618 for ; Mon, 6 Nov 2000 08:59:40 -0800 (PST) Received: from abs.abinfosys (ABS [192.168.1.1]) by abs.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WMF2WLR8; Mon, 6 Nov 2000 21:40:42 +0530 Received: by abs.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11062000-213817-31.MMD@abinfosys; Mon, 6 Nov 2000 21:38:17 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id EAA06072 for ; Sat, 4 Nov 2000 04:31:52 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id OAA05606 for ; Fri, 3 Nov 2000 14:58:16 -0800 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA19405 for ietf-ediint-bks; Fri, 3 Nov 2000 14:16:19 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19401 for ; Fri, 3 Nov 2000 14:16:18 -0800 (PST) Received: by spyglass.cyclonecommerce.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Nov 2000 15:24:49 -0700 Received: from THARDINGLAPTOP (cx66967-a.phnx3.az.home.com [24.1.196.29]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VF1K04TZ; Fri, 3 Nov 2000 15:24:45 -0700 From: Terry Harding To: ietf-ediint@imc.org Message-ID: <012501c045e4$80ef2470$1dc40118@THARDINGLAPTOP> References: <3A02D3CA.C723409F@aurora.regenstrief.org> <00ff01c045d7$2153d040$1dc40118@THARDINGLAPTOP> Subject: Re: IETF review of AS1 Date: Fri, 3 Nov 2000 15:22:07 -0700 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Archive: List-ID: List-Unsubscribe: X-UIDL: 983fe33f1bae9e3c1f4750dd769e890d Status: RO List-Archive: List-ID: List-Unsubscribe: Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Another possible approach to the problem would be to create a new content subtype example: Content-Type: application/x-zlib; uncompresse-type=xml Here we are expressing the contents of the body part as a compressed unit, which when uncompressed will give us an xml document. Terry Harding Cyclone Commerce From owner-ietf-ediint@mail.imc.org Mon Nov 6 13:38:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20704 for ; Mon, 6 Nov 2000 13:38:13 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA20334 for ietf-ediint-bks; Mon, 6 Nov 2000 09:51:58 -0800 (PST) Received: from abs.abinfosys ([203.197.233.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20309 for ; Mon, 6 Nov 2000 09:51:51 -0800 (PST) From: ned.freed@innosoft.com Received: from abs.abinfosys (ABS [192.168.1.1]) by abs.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WMJDBPZ8; Mon, 6 Nov 2000 23:31:57 +0530 Received: by abs.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11062000-233138-100.MMD@abinfosys; Mon, 6 Nov 2000 23:31:38 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id XAA06062 for ; Mon, 6 Nov 2000 23:29:32 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id JAA09194 for ; Mon, 6 Nov 2000 09:55:30 -0800 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17647 for ietf-ediint-bks; Mon, 6 Nov 2000 09:00:17 -0800 (PST) Received: from abs.abinfosys ([203.197.233.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17630 for ; Mon, 6 Nov 2000 08:59:57 -0800 (PST) Received: from abs.abinfosys (ABS [192.168.1.1]) by abs.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WMF2WLSB; Mon, 6 Nov 2000 21:40:43 +0530 Received: by abs.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11062000-213825-33.MMD@abinfosys; Mon, 6 Nov 2000 21:38:25 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id GAA11270 for ; Sat, 4 Nov 2000 06:01:48 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id QAA13333 for ; Fri, 3 Nov 2000 16:28:13 -0800 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA21343 for ietf-ediint-bks; Fri, 3 Nov 2000 15:48:27 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA21339 for ; Fri, 3 Nov 2000 15:48:27 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JW3Q6NWVBK0000T2@mauve.mrochek.com> for ietf-ediint@imc.org; Fri, 03 Nov 2000 15:54:51 -0700 (PDT) Date: Fri, 03 Nov 2000 14:54:31 -0700 (PDT) Subject: Re: IETF review of AS1 In-reply-to: "Your message dated Fri, 03 Nov 2000 15:22:07 -0700" <012501c045e4$80ef2470$1dc40118@THARDINGLAPTOP> To: Terry Harding Cc: ietf-ediint@imc.org Message-id: <01JW3XOXWKN20000T2@mauve.mrochek.com> MIME-version: 1.0 Content-transfer-encoding: 7BIT References: <3A02D3CA.C723409F@aurora.regenstrief.org> <00ff01c045d7$2153d040$1dc40118@THARDINGLAPTOP> List-Archive: List-ID: List-Unsubscribe: X-UIDL: fb1cd0f623b85532bc68ca86c2f4c999 Status: U List-Archive: List-ID: List-Unsubscribe: Content-Type: TEXT/PLAIN; charset=iso-8859-1 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > Another possible approach to the problem would be to create > a new content subtype example: > Content-Type: application/x-zlib; uncompresse-type=xml > Here we are expressing the contents of the body part as > a compressed unit, which when uncompressed will give us > an xml document. MIME expressly forbids the creation of content types of this sort. See RFC 2048, section 2.2.1. The way to do this is with a content-transfer-encoding. As it happens I've had this as a low priority task on my to-do list for some time; the work has gotten as far as draft-freed-newenc-00.txt Ned From owner-ietf-ediint@mail.imc.org Mon Nov 6 13:38:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20799 for ; Mon, 6 Nov 2000 13:38:33 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA20345 for ietf-ediint-bks; Mon, 6 Nov 2000 09:52:03 -0800 (PST) Received: from abs.abinfosys ([203.197.233.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20308 for ; Mon, 6 Nov 2000 09:51:51 -0800 (PST) From: ned.freed@innosoft.com Received: from abs.abinfosys (ABS [192.168.1.1]) by abs.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WMJDBPZ6; Mon, 6 Nov 2000 23:31:57 +0530 Received: by abs.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11062000-233137-99.MMD@abinfosys; Mon, 6 Nov 2000 23:31:37 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id XAA05990 for ; Mon, 6 Nov 2000 23:29:22 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id JAA09049 for ; Mon, 6 Nov 2000 09:55:22 -0800 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17684 for ietf-ediint-bks; Mon, 6 Nov 2000 09:01:07 -0800 (PST) Received: from abs.abinfosys ([203.197.233.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17668 for ; Mon, 6 Nov 2000 09:00:58 -0800 (PST) Received: from abs.abinfosys (ABS [192.168.1.1]) by abs.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WMF2WLTF; Mon, 6 Nov 2000 21:40:48 +0530 Received: by abs.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11062000-213924-51.MMD@abinfosys; Mon, 6 Nov 2000 21:39:24 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id PAA14788 for ; Sat, 4 Nov 2000 15:17:16 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id BAA27324 for ; Sat, 4 Nov 2000 01:43:37 -0800 Received: by ns.secondary.com (8.9.3/8.9.3) id AAA21905 for ietf-ediint-bks; Sat, 4 Nov 2000 00:59:42 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA21901 for ; Sat, 4 Nov 2000 00:59:40 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JW45FZ42E800004Q@mauve.mrochek.com> for ietf-ediint@imc.org; Sat, 04 Nov 2000 01:06:10 -0700 (PDT) Date: Sat, 04 Nov 2000 00:47:32 -0700 (PDT) Subject: Re: IETF review of AS1 In-reply-to: "Your message dated Fri, 03 Nov 2000 13:46:22 -0700" <00ff01c045d7$2153d040$1dc40118@THARDINGLAPTOP> To: Terry Harding Cc: ietf-ediint@imc.org Message-id: <01JW4GYGF9YK00004Q@mauve.mrochek.com> MIME-version: 1.0 Content-transfer-encoding: 7BIT References: <3A02D3CA.C723409F@aurora.regenstrief.org> List-Archive: List-ID: List-Unsubscribe: X-UIDL: 6ae1d7ea96e43edce83f606f679e6c39 Status: RO List-Archive: List-ID: List-Unsubscribe: Content-Type: TEXT/PLAIN; charset=iso-8859-1 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > So it looks like we have 3 choices, > 1 - strongly suggest that we wish to use > the content-encoding header inside a mime bodypart As I explained before, this is not a viable option. Adding a new header whose use changes the essential nature of the underlying content is intrinsicly incompatible with the installed base. Speaking as an Area Director, I cannot approve such a document, and even if I did, the chances it would pass subsequent IESG review are for all intents and purposes nonexistant. > 2 - create a new content-transfer-encoding method This works because existing applications are required to examine this field if present and there's a well defined way new values are to be handled. > 3 - use one of the other acceptable headers to express compressed data. > ex: Content-Description: This has the same problem as content-encoding -- while content-description is a known field, its semantics in email don't affect data interpretation. > 4 - add a name value pair to the content-type line > ex: Content-Type: application/xml; encoding=gzip > or Content-Type: applicatoin/xml; conversion= gzip. Again, this has the same problem. > It is my preference to use a name value pair on the content-type line > if we can not use the content-encoding header. This is just as much of a nonstarter as content-encoding is. You do have one other option here, and that is to drop the compression idea entirely. But this and defining a content-transfer-encoding are the only viable approaches I see to the problem. Ned From owner-ietf-ediint@mail.imc.org Mon Nov 6 13:45:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22375 for ; Mon, 6 Nov 2000 13:45:25 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA20353 for ietf-ediint-bks; Mon, 6 Nov 2000 09:52:05 -0800 (PST) Received: from abs.abinfosys ([203.197.233.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20311 for ; Mon, 6 Nov 2000 09:51:51 -0800 (PST) Received: from abs.abinfosys (ABS [192.168.1.1]) by abs.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WMJDBPZ0; Mon, 6 Nov 2000 23:31:58 +0530 Received: by abs.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11062000-233140-101.MMD@abinfosys; Mon, 6 Nov 2000 23:31:40 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id XAA06415 for ; Mon, 6 Nov 2000 23:29:53 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id JAA09330 for ; Mon, 6 Nov 2000 09:55:54 -0800 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA17660 for ietf-ediint-bks; Mon, 6 Nov 2000 09:00:54 -0800 (PST) Received: from abs.abinfosys ([203.197.233.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17652 for ; Mon, 6 Nov 2000 09:00:21 -0800 (PST) Received: from abs.abinfosys (ABS [192.168.1.1]) by abs.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WMF2WLSH; Mon, 6 Nov 2000 21:40:44 +0530 Received: by abs.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11062000-213833-36.MMD@abinfosys; Mon, 6 Nov 2000 21:38:33 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id HAA12552 for ; Sat, 4 Nov 2000 07:04:10 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id RAA09903 for ; Fri, 3 Nov 2000 17:30:35 -0800 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA23044 for ietf-ediint-bks; Fri, 3 Nov 2000 16:47:29 -0800 (PST) Received: from femail2.sdc1.sfba.home.com (femail2.sdc1.sfba.home.com [24.0.95.82]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA23040 for ; Fri, 3 Nov 2000 16:47:28 -0800 (PST) Received: from sv.chage.com ([24.20.168.137]) by femail2.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001104005342.HJNK14736.femail2.sdc1.sfba.home.com@sv.chage.com> for ; Fri, 3 Nov 2000 16:53:42 -0800 From: "Carl Hage" To: ietf-ediint@imc.org Date: Fri, 3 Nov 2000 16:53:36 -0800 Subject: Re: IETF review of AS1 In-reply-to: <00ff01c045d7$2153d040$1dc40118@THARDINGLAPTOP> X-mailer: Pegasus Mail for Win32 (v3.01d) Message-Id: <20001104005342.HJNK14736.femail2.sdc1.sfba.home.com@sv.chage.com> List-Archive: List-ID: List-Unsubscribe: X-UIDL: 24666f93e6659f59bdf3006d0654fd0d Status: U List-Archive: List-ID: List-Unsubscribe: Content-Type: text Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Terry Harding Date sent: Fri, 3 Nov 2000 13:46:22 -0700 > 5.4.1, last paragraph. This is the biggie. Saying it is OK to use > content-encoding in email even as an option just isn't acceptable. Seems like "Content-Encoding" is a resonable extension, but... > 4 - add a name value pair to the content-type line > ex: Content-Type: application/xml; encoding=gzip > or Content-Type: applicatoin/xml; conversion= gzip. This wouldn't be backwards-compatible (has the same problem). However, it seems like the other way around, as you mention, makes sense as it can work with existing MIME software. I believe, the best backwards-compatible solution would be to define a new (standards track) discrete-type extension-token, "encoded", with subtypes registered for the different encodings, e.g. "gzip". A required parameter for encoded/gzip would be "encoded-type", which is the replacement "type/subtype" for the Content-Type before encoding. discrete-type := "text" / "image" / "audio" / "video" / "application" / extension-token [Note the word "Encoded" is more general than "Compress", and matches the nomenclature of "Content-Encoding".] Since it's impractical to include parameters within the Encoded-Type="string", the semantics is that an application processing "encoded/gzip" will strip off a "encoded-type" parameter, then decode the binary data and pass it to a MIME application with encoded-type used for Content-Type and the remaining parameters appended. Example: Content-Type: encoded/gzip; encoded-type=text/xml; schema="http://www.w3.org/xml/schema/EDI-HL7" (Test software can use: Content-Type: x-encoded/gzip; encoded-type=text/xml; schema="http://www.w3.org/xml/schema/EDI-HL7") An old MIME program would handle "encoded/gzip" like application/octet-stream, and typically would allow definition of a processing application for "encoding/gzip" to be some GUI that can uncompress and save the data. It makes more sense than "application/gzip". A new MIME processor would know that "encoded/XXXX" can be used as a piped filter, automatically post-processing the output of the XXXX filter and passed to the MIME handler for "encoding-type". In the above example, the "schema" is a hypothetical parameter passed to the xml MIME processor. Of course, it might make more sense to use "xml/edi-hl7" instead. (Or whatever content-type is used-- not the issue here.) Does this make sense to y'all? -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint@mail.imc.org Mon Nov 6 14:16:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29422 for ; Mon, 6 Nov 2000 14:16:11 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA23509 for ietf-ediint-bks; Mon, 6 Nov 2000 10:19:27 -0800 (PST) Received: from abs.abinfosys ([203.197.233.139]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23504 for ; Mon, 6 Nov 2000 10:19:20 -0800 (PST) From: ned.freed@innosoft.com Received: from abs.abinfosys (ABS [192.168.1.1]) by abs.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WMJDBP5B; Mon, 6 Nov 2000 23:59:21 +0530 Received: by abs.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11062000-235903-107.MMD@abinfosys; Mon, 6 Nov 2000 23:59:03 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id XAA10559 for ; Mon, 6 Nov 2000 23:35:15 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id KAA11676 for ; Mon, 6 Nov 2000 10:01:15 -0800 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA17578 for ietf-ediint-bks; Mon, 6 Nov 2000 08:58:02 -0800 (PST) Received: from abs.abinfosys ([203.197.233.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17562 for ; Mon, 6 Nov 2000 08:57:04 -0800 (PST) Received: from abs.abinfosys (ABS [192.168.1.1]) by abs.abinfosys with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id WMF2WLVJ; Mon, 6 Nov 2000 22:21:54 +0530 Received: by abs.abinfosys (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG11062000-221637-141.MMD@abinfosys; Mon, 6 Nov 2000 22:16:37 +0530 Received: from chaorg.com (chaorg.com [216.121.32.105]) by del2.vsnl.net.in (8.9.2/8.9.2) with ESMTP id FAA10850 for ; Mon, 6 Nov 2000 05:22:12 -0500 (GMT) Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by chaorg.com (8.9.3/8.9.3) with ESMTP id PAA08930 for ; Sun, 5 Nov 2000 15:48:19 -0800 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA06312 for ietf-ediint-bks; Sun, 5 Nov 2000 14:53:54 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06307 for ; Sun, 5 Nov 2000 14:53:42 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JW45FZ42E800004Q@mauve.mrochek.com> for ietf-ediint@imc.org; Sun, 05 Nov 2000 15:00:10 -0700 (PDT) Date: Sun, 05 Nov 2000 14:42:44 -0700 (PDT) Subject: Re: EDIINT and HIPAA In-reply-to: "Your message dated Fri, 03 Nov 2000 07:58:32 -0600" <00a601c0459e$28b56620$67ee79a5@techcomm.com> To: dick@8760.com Cc: Rik Drummond , pbyrne@gpu.com, Gunther Schadow , ned.freed@innosoft.com, Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org, dick@8760.com Message-id: <01JW6ODRLFHG00004Q@mauve.mrochek.com> MIME-version: 1.0 Content-transfer-encoding: 7BIT References: List-Archive: List-ID: List-Unsubscribe: X-UIDL: 603faf11251cf383a5bf4ce72a8814dd Status: U List-Archive: List-ID: List-Unsubscribe: Content-Type: TEXT/PLAIN; charset=iso-8859-1 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > Rik, > I agree, the original AS2 spec was based on AS1, but there were problems > discovered during AS2 interoperability testing (using RFC 822 (email) style > packaging) related to "To" and "From" headers, which resulted in the creation > of two new headers specific to AS2, "AS2-To" and "AS2-From". We (as the authors > of AS2) will have to provide details of these new routing headers and cannot > depend entirely on AS1, as we had originally. > AS1 and AS2 (using RFC 822 (email) packaging) will be VERY similar, but not > exactly alike. I believe AS2 will have to stand on its own through the IESG > review process and we'll have to provide "complete" technical specifications in > AS2 to satisfy IESG requirements. > Ned, am I correct in this postulation? Well, sort of. The specification certainly has to be complete -- you cannot assume that missing bits will be inferred from another specification. However, you certainly can refer to the other specification rather than repeating the same words in both. Do note that normative references create a dependency as far as the standards process is concerned -- the specification referred to must be at the same or higher standards level as the one that refers to it. Ned From owner-ietf-ediint@mail.imc.org Thu Nov 16 06:02:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA00779 for ; Thu, 16 Nov 2000 06:02:57 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA06497 for ietf-ediint-bks; Thu, 16 Nov 2000 02:18:43 -0800 (PST) Received: from mtiwmhc28.worldnet.att.net (mtiwmhc28.worldnet.att.net [204.127.131.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA06486 for ; Thu, 16 Nov 2000 02:18:40 -0800 (PST) Received: from vaio ([12.74.11.251]) by mtiwmhc28.worldnet.att.net (InterMail vM.4.01.03.10 201-229-121-110) with SMTP id <20001116102542.YLVC25926.mtiwmhc28.worldnet.att.net@vaio>; Thu, 16 Nov 2000 10:25:42 +0000 From: "Rik Drummond" To: , , "Gunther Schadow" , Cc: "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , , "Beth Morrow" Subject: RE: EDIINT and HIPAA Date: Thu, 16 Nov 2000 04:26:18 -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 In-Reply-To: <00a601c0459e$28b56620$67ee79a5@techcomm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit i have david fischer, the drummond group guy running the as2 testing is taking copious notes on the issues. he will be glad to give them to you soon as you want them..... i think we are really close. one of the reasons we changed the to / from headers was not that they were necessarily incorrect in the current as2 spec, but because they, if used as written in the spec, would almost always cause implementation confusion and prohibit interoperability. i really think we are very close with the current as2 spec. nothing like an implementation to clean things up in a spec. best regards, rik -----Original Message----- From: dick@8760.com [mailto:dick@8760.com] Sent: Friday, November 03, 2000 7:59 AM To: Rik Drummond; pbyrne@gpu.com; Gunther Schadow; ned.freed@innosoft.com Cc: Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org; dick@8760.com Subject: Re: EDIINT and HIPAA Rik, I agree, the original AS2 spec was based on AS1, but there were problems discovered during AS2 interoperability testing (using RFC 822 (email) style packaging) related to "To" and "From" headers, which resulted in the creation of two new headers specific to AS2, "AS2-To" and "AS2-From". We (as the authors of AS2) will have to provide details of these new routing headers and cannot depend entirely on AS1, as we had originally. AS1 and AS2 (using RFC 822 (email) packaging) will be VERY similar, but not exactly alike. I believe AS2 will have to stand on its own through the IESG review process and we'll have to provide "complete" technical specifications in AS2 to satisfy IESG requirements. Ned, am I correct in this postulation? Regards, Dick Brooks http://www.8760.com/ ----- Original Message ----- From: Rik Drummond To: ; Gunther Schadow Cc: Dick Brooks ; Kepa Zubeldia ; CLEM ; Gary Crough ; Beth Morrow ; David@Drummondgroup. Com ; ; Sent: Friday, November 03, 2000 4:55 AM Subject: RE: EDIINT and HIPAA > bty, we are in the final edit phase of making as1 an rfc. after this goes > through, as2 (which is based on as1) is next.... thanks for the note pete! > best regards, rik > > -----Original Message----- > From: pbyrne@gpu.com [mailto:pbyrne@gpu.com] > Sent: Thursday, November 02, 2000 1:36 PM > To: Gunther Schadow > Cc: dick@8760.com; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: EDIINT and HIPAA > > > > > Greetings from Pennsylvania. For what it is worth, the regulated electric > utilities in PA exchange X12 EDI data with energy suppliers using the "old" > GISB > method; i.e. X12 EDI transactions encrypted with PGP and transported via > batch-mode HTTP POST method. The transaction volume averages in excess of > one > million EDI transactions per month. > > Many of the utilities have already declared their intention to migrate to > AS2-compliant GISB as soon as the software is commercially available. > > The GISB method, whether "old" or AS2-compliant, is content neutral. It > will > transport data of any size, shape, color, or flavor, whether X12, HL7, or > any > other. In addition, it supports unattended, batch processing (which is how > my > company uses it). > > Hope this helps. > > Pete Byrne > GPU Energy EC/EDI > and > Chair, Utility Industry Group > > > > > > > Gunther Schadow on 11/02/2000 11:12:44 AM > > > > To: dick@8760.com > > cc: Rik Drummond , Kepa Zubeldia > , CLEM > , Gary Crough > , Beth Morrow > , "David@Drummondgroup. > Com" , GISB1@aol.com, > ietf-ediint@imc.org(bcc: Pete Byrne) > > > > Subject: Re: EDIINT and HIPAA > > > > > > > > > Dick, > > I appreciate your warning. Please me (and others) understand ... > > > > regards > -Gunther > > > > > From owner-ietf-ediint@mail.imc.org Thu Nov 16 06:31:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA00788 for ; Thu, 16 Nov 2000 06:02:58 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA09043 for ietf-ediint-bks; Thu, 16 Nov 2000 02:26:05 -0800 (PST) Received: from mtiwmhc28.worldnet.att.net (mtiwmhc28.worldnet.att.net [204.127.131.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA09024 for ; Thu, 16 Nov 2000 02:26:02 -0800 (PST) Received: from vaio ([12.74.11.251]) by mtiwmhc28.worldnet.att.net (InterMail vM.4.01.03.10 201-229-121-110) with SMTP id <20001116103305.YNEJ25926.mtiwmhc28.worldnet.att.net@vaio>; Thu, 16 Nov 2000 10:33:05 +0000 From: "Rik Drummond" To: Cc: , "Terry Harding" Subject: RE: AD review of EDIINT documents (was RE: Status and Future of EDIINT) Date: Thu, 16 Nov 2000 04:33:42 -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 In-Reply-To: <01JW318160SM00004Q@mauve.mrochek.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ned we are working on the edits... should have something back to you in a couple of weeks.... one of the editors is buried in a as2 test.... best regards, rik -----Original Message----- From: ned.freed@innosoft.com [mailto:ned.freed@innosoft.com] Sent: Friday, November 03, 2000 1:20 AM To: Rik Drummond Cc: ietf-ediint@imc.org Subject: AD review of EDIINT documents (was RE: Status and Future of EDIINT) > well it is not dead. the spec is in the loop for rfc approval... and we now > have 12 vendors supporting as1 and 9 supporting as2. these are all > interoperable. if we don't get something back from the ietf shortly it might > be wise to go the ansi route... rik Well, as it happens I've been working on the AD review of these documents. I just completed that review today. I've attached my review comments below. Sorry it took so long. Ned ------ AD review of draft-ietf-ediint-req-08.txt: I started to write a bunch of comments on this document, but then decided against it. The basic problem is that due to the substantial amount of time that has passed since this text was written (through no fault of the authors or the WG, I hasten to add), quite a bit of it seems dated. For example, a discussion of the use of VPNs in contrast to VANs would seem appropriate. Some of the symmetric cipher discussion is likely dated as well. But given that it is informational I see little harm in publishing it as-is. Note that it may end up with an IESG note pointing out the timing issue, however. AD review of draft-ietf-ediint-as1-11.txt: This is where the issues are. Some are very minor, but a couple must be addressed. Security considerations section. The word "Technologies" is capitalized when it should not be. The security considerations section is normally at the end of the document. It also should cover actual considerations rather than restating what the document is about. 1.0 Introduction, first paragraph. The impression is given here that this is purely an Applicability Statement. However, the very next paragraph then indicates otherwise. I suggest that this be clarified by referring to "the bulk of this document is an Applicability Statement", or something similar. 1.0 Introduction, second paragraph. There's a reference to section 3.1.8, which does not exist in the current document. I believe this is supposed to be 5.3.1. 1.0 Introduction, third paragraph. "Used" -> "used". 2.1. Reference to "standard" is premature. I suggest saying "document" instead. 2.2.2, first paragraph. "The functional requirements document, [9] "Requirements for Inter-operable Internet EDI" (can be found at www.ietf.org)," needs to be rewritten as a reference to an RFC-to-be. 2.2.2, first paragraph, "Provides" -> "provides". 2.2.2, second paragraph. Use of the term "transport" here is confusing. I suggest "environment" or something similar instead. 2.2.2, last paragraph. "Satisfy" -> "satisfy". 2.2.3, first bullet item. This section doesn't identify RFC 2298 as the mechanism being used to request EDI receipts. Suggest making it clear here rather than having to get further into the document to find out. 2.3.2, fourth bullet item. Now that PGP itself is an IETF standard, should reference RFC 2440 as well as RFC 2015 here and elsewhere in the document. 2.3.2, fourth bullet item. REQUIRES is not a keyword on the 2119 list; suggest rewording to use REQUIRED instead. 5.4.1, first paragraph. The phrase Using message, "partial", should be Using message/partial 5.4.1, second paragraph. The phrase "so that if fragmentation does occur," isn't right in this context. I suggest "so that if fragmentation is needed" instead. 5.4.1. Recommending that partial be used but saying that support for it is optional could lead to interoperability issues. I suggest that you add that in the absence of knowledge that the recipient supports partial it SHOULD NOT be used. 5.4.1, last paragraph. This is the biggie. Saying it is OK to use content-encoding in email even as an option just isn't acceptable. The problem is one of interoperability: An unextended agent that receives a message with, say, a content-encoding of gzip won't recognize the field for what it is and will cheerfully decode the base64 expecting to find text or whatever. Instead it will find garbage. Unfortunately, the only way to add compression to email in a backwards compatible way is to define new content-transfer-encodings. If this is a real issue this is the mechanism that needs to be pursued. Note that it is fine to recommend use of content-encoding if the transport is HTTP. Content-encoding is well-defined there and agents are required to check for it and handle it. Finally, this document defines new disposition-notification-options and a new MDN field received-content-mic. Both of these things require IANA registration. It is customary in standards track documents to do this with an appendix containing the appropriate registration forms. This needs to be done per sections 10.2 and 10.3 of RFC 2298. That's it! From owner-ietf-ediint@mail.imc.org Thu Nov 16 07:47:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10055 for ; Thu, 16 Nov 2000 07:47:40 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA09431 for ietf-ediint-bks; Thu, 16 Nov 2000 03:58:01 -0800 (PST) Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA09424 for ; Thu, 16 Nov 2000 03:57:59 -0800 (PST) Received: from dcsnet.demon.co.uk ([194.222.162.207]) by anchor-post-30.mail.demon.net with smtp (Exim 2.12 #1) id 13wNnE-0008Hm-0U for ietf-ediint@imc.org; Thu, 16 Nov 2000 12:05:31 +0000 Received: from Delta by Delta with NETFAM id 001095; Thu, 16 Nov 2000 11:33:22 +0100 (BST) From: chris@dcsnet.demon.co.uk (Chris Davenport) Reply-To: chris@dcsnet.demon.co.uk Date: Thu, 16 Nov 2000 11:33:12 +0100 (BST) Message-Id: <20001116.113312.001@dcsnet.demon.co.uk> To: ietf-ediint@imc.org Subject: RE: EDIINT and HIPAA X-Mailer: DVMAIL Version 2.3 (142) 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 Could we not come up with some more meaningful names for these new headers? I'm thinking that in 10 years time no-one will remember what "AS2-To" means. Just a thought. Chris. > >I agree, the original AS2 spec was based on AS1, but there were problems >discovered during AS2 interoperability testing (using RFC 822 (email) style >packaging) related to "To" and "From" headers, which resulted in the >creation >of two new headers specific to AS2, "AS2-To" and "AS2-From". We (as the >authors >of AS2) will have to provide details of these new routing headers and >cannot >depend entirely on AS1, as we had originally. > -- Chris Davenport chris@dcsnet.demon.co.uk Davros Computer Systems From owner-ietf-ediint@mail.imc.org Thu Nov 16 10:07:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03454 for ; Thu, 16 Nov 2000 10:07:04 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA22580 for ietf-ediint-bks; Thu, 16 Nov 2000 06:19:18 -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 GAA22570 for ; Thu, 16 Nov 2000 06:19:16 -0800 (PST) Received: from imx1.stercomm.com (imx1.stercomm.com [10.117.193.42]) by omx1.stercomm.com with ESMTP id JAA14313; Thu, 16 Nov 2000 09:25:38 -0500 (EST) Received: from cmh0203xcn01.nsg.stercomm.com (cmh0203xcn01.stercomm.com [10.117.193.89]) by imx1.stercomm.com with ESMTP id JAA23465; Thu, 16 Nov 2000 09:27:56 -0500 (EST) Received: by cmh0203xcn01.stercomm.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Nov 2000 09:27:22 -0500 Message-ID: <5FD6397E455FD4118BAE000629383540D3913D@SCIDUBMSG02> From: "Moberg, Dale" To: "'chris@dcsnet.demon.co.uk'" , ietf-ediint@imc.org Subject: RE: EDIINT and HIPAA Date: Thu, 16 Nov 2000 09:27:22 -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: Suggest them now! Dale Moberg > -----Original Message----- > From: chris@dcsnet.demon.co.uk [mailto:chris@dcsnet.demon.co.uk] > Sent: Thursday, November 16, 2000 5:33 AM > To: ietf-ediint@imc.org > Subject: RE: EDIINT and HIPAA > > > Could we not come up with some more meaningful names for > these new headers? > I'm thinking that in 10 years time no-one will remember what > "AS2-To" means. > > Just a thought. > > Chris. > > > > >I agree, the original AS2 spec was based on AS1, but there > were problems > >discovered during AS2 interoperability testing (using RFC > 822 (email) style > >packaging) related to "To" and "From" headers, which resulted in the > >creation > >of two new headers specific to AS2, "AS2-To" and "AS2-From". > We (as the > >authors > >of AS2) will have to provide details of these new routing > headers and > >cannot > >depend entirely on AS1, as we had originally. > > > -- > Chris Davenport chris@dcsnet.demon.co.uk > Davros Computer Systems > From owner-ietf-ediint@mail.imc.org Thu Nov 16 12:27:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25693 for ; Thu, 16 Nov 2000 12:27:56 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA04034 for ietf-ediint-bks; Thu, 16 Nov 2000 08:24:28 -0800 (PST) Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04010 for ; Thu, 16 Nov 2000 08:24:22 -0800 (PST) Received: from dcsnet.demon.co.uk ([194.222.162.207]) by anchor-post-30.mail.demon.net with smtp (Exim 2.12 #1) id 13wRww-0008n9-0U; Thu, 16 Nov 2000 16:31:49 +0000 Received: from Delta by Delta with NETFAM id 001096; Thu, 16 Nov 2000 16:19:41 +0100 (BST) From: chris@dcsnet.demon.co.uk (Chris Davenport) Reply-To: chris@dcsnet.demon.co.uk Date: Thu, 16 Nov 2000 16:19:30 +0100 (BST) Message-Id: <20001116.161930.001@dcsnet.demon.co.uk> To: Dale_Moberg@stercomm.com, ietf-ediint@imc.org Subject: RE: EDIINT and HIPAA X-Mailer: DVMAIL Version 2.3 (142) 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 I was afraid you might say that! Actually I'm not clued up on why it was considered necessary to introduce these headers. The answer does not appear to be in the AS2 revision in internet-drafts. Perhaps I missed it being discussed on this list? How about: "EDI-To" and "EDI-From" Be happy, Chris. ---------- Original Message ---------- From : "Moberg, Dale" To : "'chris@dcsnet.demon.co.uk'" ,ietf-ediint@imc.org Date : Thu, 16 Nov 2000 09:27:22 -0500 Subject: RE: EDIINT and HIPAA >Suggest them now! > >Dale Moberg > > >> -----Original Message----- >> From: chris@dcsnet.demon.co.uk [mailto:chris@dcsnet.demon.co.uk] >> Sent: Thursday, November 16, 2000 5:33 AM >> To: ietf-ediint@imc.org >> Subject: RE: EDIINT and HIPAA >> >> >> Could we not come up with some more meaningful names for >> these new headers? >> I'm thinking that in 10 years time no-one will remember what >> "AS2-To" means. >> >> Just a thought. >> >> Chris. >> >> > >> >I agree, the original AS2 spec was based on AS1, but there >> were problems >> >discovered during AS2 interoperability testing (using RFC >> 822 (email) style >> >packaging) related to "To" and "From" headers, which resulted in the >> >creation >> >of two new headers specific to AS2, "AS2-To" and "AS2-From". >> We (as the >> >authors >> >of AS2) will have to provide details of these new routing >> headers and >> >cannot >> >depend entirely on AS1, as we had originally. >> > >> -- >> Chris Davenport chris@dcsnet.demon.co.uk >> Davros Computer Systems >> -- Chris Davenport chris@dcsnet.demon.co.uk Davros Computer Systems From owner-ietf-ediint@mail.imc.org Thu Nov 16 13:48:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25706 for ; Thu, 16 Nov 2000 13:48:19 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA00182 for ietf-ediint-bks; Thu, 16 Nov 2000 09:54:51 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00170 for ; Thu, 16 Nov 2000 09:54:49 -0800 (PST) Received: by spyglass.cyclonecommerce.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Nov 2000 11:02:23 -0700 Received: from THARDINGLAPTOP (cx66967-a.phnx3.az.home.com [24.1.196.29]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VF1LAHBM; Thu, 16 Nov 2000 11:02:21 -0700 From: Terry Harding To: ietf-ediint@imc.org, Dale_Moberg@stercomm.com, chris@dcsnet.demon.co.uk Cc: b2b_int_as2@lists.drummondgroup.com Message-ID: <001901c04ff7$4bd8f500$1dc40118@THARDINGLAPTOP> References: <20001116.161930.001@dcsnet.demon.co.uk> Subject: Re: EDIINT and HIPAA Date: Thu, 16 Nov 2000 11:01:50 -0700 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.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit How about. senderId and receiverId. Terry ----- Original Message ----- From: "Chris Davenport" To: ; Sent: Thursday, November 16, 2000 8:19 AM Subject: RE: EDIINT and HIPAA > I was afraid you might say that! Actually I'm not clued up on why it was > considered necessary to introduce these headers. The answer does not appear > to be in the AS2 revision in internet-drafts. Perhaps I missed it being > discussed on this list? > > How about: "EDI-To" and "EDI-From" > > Be happy, > > Chris. > > ---------- Original Message ---------- > From : "Moberg, Dale" > To : "'chris@dcsnet.demon.co.uk'" ,ietf-ediint@imc.org > Date : Thu, 16 Nov 2000 09:27:22 -0500 > Subject: RE: EDIINT and HIPAA > >Suggest them now! > > > >Dale Moberg > > > > > >> -----Original Message----- > >> From: chris@dcsnet.demon.co.uk [mailto:chris@dcsnet.demon.co.uk] > >> Sent: Thursday, November 16, 2000 5:33 AM > >> To: ietf-ediint@imc.org > >> Subject: RE: EDIINT and HIPAA > >> > >> > >> Could we not come up with some more meaningful names for > >> these new headers? > >> I'm thinking that in 10 years time no-one will remember what > >> "AS2-To" means. > >> > >> Just a thought. > >> > >> Chris. > >> > >> > > >> >I agree, the original AS2 spec was based on AS1, but there > >> were problems > >> >discovered during AS2 interoperability testing (using RFC > >> 822 (email) style > >> >packaging) related to "To" and "From" headers, which resulted in the > >> >creation > >> >of two new headers specific to AS2, "AS2-To" and "AS2-From". > >> We (as the > >> >authors > >> >of AS2) will have to provide details of these new routing > >> headers and > >> >cannot > >> >depend entirely on AS1, as we had originally. > >> > > >> -- > >> Chris Davenport chris@dcsnet.demon.co.uk > >> Davros Computer Systems > >> > -- > Chris Davenport chris@dcsnet.demon.co.uk > Davros Computer Systems From owner-ietf-ediint@mail.imc.org Thu Nov 16 14:14:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05371 for ; Thu, 16 Nov 2000 14:14:12 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA05633 for ietf-ediint-bks; Thu, 16 Nov 2000 10:14:45 -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 KAA05612 for ; Thu, 16 Nov 2000 10:14:36 -0800 (PST) Received: from imx1.stercomm.com (imx1.stercomm.com [10.117.193.42]) by omx1.stercomm.com with ESMTP id NAA09204; Thu, 16 Nov 2000 13:20:45 -0500 (EST) Received: from cmh0203xcn01.nsg.stercomm.com (cmh0203xcn01.stercomm.com [10.117.193.89]) by imx1.stercomm.com with ESMTP id NAA16902; Thu, 16 Nov 2000 13:23:03 -0500 (EST) Received: by cmh0203xcn01.stercomm.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Nov 2000 13:22:32 -0500 Message-ID: <5FD6397E455FD4118BAE000629383540D39143@SCIDUBMSG02> From: "Moberg, Dale" To: "'Terry Harding'" , ietf-ediint@imc.org, chris@dcsnet.demon.co.uk Cc: b2b_int_as2@lists.drummondgroup.com Subject: RE: EDIINT and HIPAA Date: Thu, 16 Nov 2000 13:22:29 -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: OK by me. Anybody not like these? Please respond quickly so we can get this settled. > -----Original Message----- > From: Terry Harding [mailto:tharding@cyclonecommerce.com] > Sent: Thursday, November 16, 2000 1:02 PM > To: ietf-ediint@imc.org; Moberg, Dale; chris@dcsnet.demon.co.uk > Cc: b2b_int_as2@lists.drummondgroup.com > Subject: Re: EDIINT and HIPAA > > > How about. > > senderId and receiverId. > > Terry > ----- Original Message ----- > From: "Chris Davenport" > To: ; > Sent: Thursday, November 16, 2000 8:19 AM > Subject: RE: EDIINT and HIPAA > > > > I was afraid you might say that! Actually I'm not clued up > on why it was > > considered necessary to introduce these headers. The > answer does not > appear > > to be in the AS2 revision in internet-drafts. Perhaps I > missed it being > > discussed on this list? > > > > How about: "EDI-To" and "EDI-From" > > > > Be happy, > > > > Chris. > > > > ---------- Original Message ---------- > > From : "Moberg, Dale" > > To : "'chris@dcsnet.demon.co.uk'" > ,ietf-ediint@imc.org > > Date : Thu, 16 Nov 2000 09:27:22 -0500 > > Subject: RE: EDIINT and HIPAA > > >Suggest them now! > > > > > >Dale Moberg > > > > > > > > >> -----Original Message----- > > >> From: chris@dcsnet.demon.co.uk [mailto:chris@dcsnet.demon.co.uk] > > >> Sent: Thursday, November 16, 2000 5:33 AM > > >> To: ietf-ediint@imc.org > > >> Subject: RE: EDIINT and HIPAA > > >> > > >> > > >> Could we not come up with some more meaningful names for > > >> these new headers? > > >> I'm thinking that in 10 years time no-one will remember what > > >> "AS2-To" means. > > >> > > >> Just a thought. > > >> > > >> Chris. > > >> > > >> > > > >> >I agree, the original AS2 spec was based on AS1, but there > > >> were problems > > >> >discovered during AS2 interoperability testing (using RFC > > >> 822 (email) style > > >> >packaging) related to "To" and "From" headers, which > resulted in the > > >> >creation > > >> >of two new headers specific to AS2, "AS2-To" and "AS2-From". > > >> We (as the > > >> >authors > > >> >of AS2) will have to provide details of these new routing > > >> headers and > > >> >cannot > > >> >depend entirely on AS1, as we had originally. > > >> > > > >> -- > > >> Chris Davenport chris@dcsnet.demon.co.uk > > >> Davros Computer Systems > > >> > > -- > > Chris Davenport chris@dcsnet.demon.co.uk > > Davros Computer Systems > From owner-ietf-ediint@mail.imc.org Thu Nov 16 14:26:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10016 for ; Thu, 16 Nov 2000 14:26:27 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA02926 for ietf-ediint-bks; Thu, 16 Nov 2000 10:04:19 -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 KAA02897 for ; Thu, 16 Nov 2000 10:04:12 -0800 (PST) Received: from imx1.stercomm.com (imx1.stercomm.com [10.117.193.42]) by omx1.stercomm.com with ESMTP id NAA08296; Thu, 16 Nov 2000 13:10:34 -0500 (EST) Received: from cmh0203xcn01.nsg.stercomm.com (cmh0203xcn01.stercomm.com [10.117.193.89]) by imx1.stercomm.com with ESMTP id NAA15973; Thu, 16 Nov 2000 13:12:52 -0500 (EST) Received: by cmh0203xcn01.stercomm.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Nov 2000 13:12:21 -0500 Message-ID: <5FD6397E455FD4118BAE000629383540D39141@SCIDUBMSG02> From: "Moberg, Dale" To: "'chris@dcsnet.demon.co.uk'" , ietf-ediint@imc.org Subject: Header names for sender and receiver identiifiers...Was RE: EDII NT and HIPAA Date: Thu, 16 Nov 2000 13:12:18 -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: I would not like to suggest that the identifiers are EDI specific and therefore would not favor your initial suggestion. Got others? On the second issue, before too long changes will be made in the draft to explain the usage of the headers. One basic problems stems from the fact that in SMTP and HTTP the "From" headers have restrictions on values and usages. In HTTP it points to an admistrative contact of sorts -- the email address "on whose behalf" the request has been made. There are privacy and other caveats not found in an email context. In SMTP, "From" is normally the sender's email address, sometimes used for replies... I here omit a long story. In both cases it is restricted to be an email address. (RFCs 822/1123) For some b2b applications, different identifier schemes are used to indicate requester and responder. DUNS numbers might be used or other namespaces might supply identifiers-- some groups are considering URIs & URNs for business identifiers, e.g. These identifiers have "back-end" integration significance and are independent of the RFC822 email address namespace. Middleware layers (containing automated user-agents and beyond) can benefit greatly by customizing configurations, looked up on the basis of different identity namespaces. The identity namespaces used for authentication will remain tied to the trust model's treatment of identity for digital signatures (for SMIME, certificates; for openPGP, the various keyrings and extensions to accomodate certificates) For these reasons, among others, we are introducing new extension headers to label the values for identifiers in other namespaces. It has created unnecesary confusion and potential interoperability obstacles by attempting to shoehorn different usages into the existing slots. Glad we found this out now. Hope that helps. > -----Original Message----- > From: chris@dcsnet.demon.co.uk [mailto:chris@dcsnet.demon.co.uk] > Sent: Thursday, November 16, 2000 10:20 AM > To: Moberg, Dale; ietf-ediint@imc.org > Subject: RE: EDIINT and HIPAA > > > I was afraid you might say that! Actually I'm not clued up > on why it was > considered necessary to introduce these headers. The answer > does not appear > to be in the AS2 revision in internet-drafts. Perhaps I > missed it being > discussed on this list? > > How about: "EDI-To" and "EDI-From" > > Be happy, > > Chris. > > ---------- Original Message ---------- > From : "Moberg, Dale" > To : "'chris@dcsnet.demon.co.uk'" > ,ietf-ediint@imc.org > Date : Thu, 16 Nov 2000 09:27:22 -0500 > Subject: RE: EDIINT and HIPAA > >Suggest them now! > > > >Dale Moberg > > > > > >> -----Original Message----- > >> From: chris@dcsnet.demon.co.uk [mailto:chris@dcsnet.demon.co.uk] > >> Sent: Thursday, November 16, 2000 5:33 AM > >> To: ietf-ediint@imc.org > >> Subject: RE: EDIINT and HIPAA > >> > >> > >> Could we not come up with some more meaningful names for > >> these new headers? > >> I'm thinking that in 10 years time no-one will remember what > >> "AS2-To" means. > >> > >> Just a thought. > >> > >> Chris. > >> > >> > > >> >I agree, the original AS2 spec was based on AS1, but there > >> were problems > >> >discovered during AS2 interoperability testing (using RFC > >> 822 (email) style > >> >packaging) related to "To" and "From" headers, which > resulted in the > >> >creation > >> >of two new headers specific to AS2, "AS2-To" and "AS2-From". > >> We (as the > >> >authors > >> >of AS2) will have to provide details of these new routing > >> headers and > >> >cannot > >> >depend entirely on AS1, as we had originally. > >> > > >> -- > >> Chris Davenport chris@dcsnet.demon.co.uk > >> Davros Computer Systems > >> > -- > Chris Davenport chris@dcsnet.demon.co.uk > Davros Computer Systems > From owner-ietf-ediint@mail.imc.org Thu Nov 16 17:17:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15280 for ; Thu, 16 Nov 2000 17:17:01 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA08140 for ietf-ediint-bks; Thu, 16 Nov 2000 13:00:15 -0800 (PST) Received: from drummondgroup.com (drummondgroup.com [192.41.39.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08131 for ; Thu, 16 Nov 2000 13:00:13 -0800 (PST) Received: from fischer (adsl-64-219-162-12.dsl.rcsntx.swbell.net [64.219.162.12]) by drummondgroup.com (8.8.5) id OAA26968; Thu, 16 Nov 2000 14:07:23 -0700 (MST) X-Authentication-Warning: drummondgroup.com: Host adsl-64-219-162-12.dsl.rcsntx.swbell.net [64.219.162.12] claimed to be fischer Reply-To: From: "David Fischer" To: "Moberg, Dale" , , Subject: RE: Header names for sender and receiver identifiers...Was RE: EDIINT and HIPAA Date: Thu, 16 Nov 2000 15:07:28 -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) In-Reply-To: <5FD6397E455FD4118BAE000629383540D39141@SCIDUBMSG02> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This was discussed in our conference call this morning and one of the AS2 Interop participants has already committed their code for release. This change at this late date would mean a significant hardship for them. David Fischer Drummond Group AS2 Interop Project david@drummondgroup.com 817.371.8422 -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Moberg, Dale Sent: Thursday, November 16, 2000 12:12 PM To: 'chris@dcsnet.demon.co.uk'; ietf-ediint@imc.org Subject: Header names for sender and receiver identiifiers...Was RE: EDIINT and HIPAA I would not like to suggest that the identifiers are EDI specific and therefore would not favor your initial suggestion. Got others? On the second issue, before too long changes will be made in the draft to explain the usage of the headers. One basic problems stems from the fact that in SMTP and HTTP the "From" headers have restrictions on values and usages. In HTTP it points to an admistrative contact of sorts -- the email address "on whose behalf" the request has been made. There are privacy and other caveats not found in an email context. In SMTP, "From" is normally the sender's email address, sometimes used for replies... I here omit a long story. In both cases it is restricted to be an email address. (RFCs 822/1123) For some b2b applications, different identifier schemes are used to indicate requester and responder. DUNS numbers might be used or other namespaces might supply identifiers-- some groups are considering URIs & URNs for business identifiers, e.g. These identifiers have "back-end" integration significance and are independent of the RFC822 email address namespace. Middleware layers (containing automated user-agents and beyond) can benefit greatly by customizing configurations, looked up on the basis of different identity namespaces. The identity namespaces used for authentication will remain tied to the trust model's treatment of identity for digital signatures (for SMIME, certificates; for openPGP, the various keyrings and extensions to accomodate certificates) For these reasons, among others, we are introducing new extension headers to label the values for identifiers in other namespaces. It has created unnecesary confusion and potential interoperability obstacles by attempting to shoehorn different usages into the existing slots. Glad we found this out now. Hope that helps. > -----Original Message----- > From: chris@dcsnet.demon.co.uk [mailto:chris@dcsnet.demon.co.uk] > Sent: Thursday, November 16, 2000 10:20 AM > To: Moberg, Dale; ietf-ediint@imc.org > Subject: RE: EDIINT and HIPAA > > > I was afraid you might say that! Actually I'm not clued up > on why it was > considered necessary to introduce these headers. The answer > does not appear > to be in the AS2 revision in internet-drafts. Perhaps I > missed it being > discussed on this list? > > How about: "EDI-To" and "EDI-From" > > Be happy, > > Chris. > > ---------- Original Message ---------- > From : "Moberg, Dale" > To : "'chris@dcsnet.demon.co.uk'" > ,ietf-ediint@imc.org > Date : Thu, 16 Nov 2000 09:27:22 -0500 > Subject: RE: EDIINT and HIPAA > >Suggest them now! > > > >Dale Moberg > > > > > >> -----Original Message----- > >> From: chris@dcsnet.demon.co.uk [mailto:chris@dcsnet.demon.co.uk] > >> Sent: Thursday, November 16, 2000 5:33 AM > >> To: ietf-ediint@imc.org > >> Subject: RE: EDIINT and HIPAA > >> > >> > >> Could we not come up with some more meaningful names for > >> these new headers? > >> I'm thinking that in 10 years time no-one will remember what > >> "AS2-To" means. > >> > >> Just a thought. > >> > >> Chris. > >> > >> > > >> >I agree, the original AS2 spec was based on AS1, but there > >> were problems > >> >discovered during AS2 interoperability testing (using RFC > >> 822 (email) style > >> >packaging) related to "To" and "From" headers, which > resulted in the > >> >creation > >> >of two new headers specific to AS2, "AS2-To" and "AS2-From". > >> We (as the > >> >authors > >> >of AS2) will have to provide details of these new routing > >> headers and > >> >cannot > >> >depend entirely on AS1, as we had originally. > >> > > >> -- > >> Chris Davenport chris@dcsnet.demon.co.uk > >> Davros Computer Systems > >> > -- > Chris Davenport chris@dcsnet.demon.co.uk > Davros Computer Systems > From owner-ietf-ediint@mail.imc.org Fri Nov 17 00:17:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20889 for ; Fri, 17 Nov 2000 00:17:58 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA22439 for ietf-ediint-bks; Thu, 16 Nov 2000 20:14:15 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22435 for ; Thu, 16 Nov 2000 20:14:14 -0800 (PST) Received: from divyaroot.India.Sun.COM ([129.158.226.35]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA25407 for ; Thu, 16 Nov 2000 20:21:51 -0800 (PST) Received: from badri (badri [129.158.226.153]) by divyaroot.India.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id JAA14418; Fri, 17 Nov 2000 09:51:49 +0530 (IST) Message-ID: <074601c0504d$6175d530$99e29e81@india.sun.com> From: "Santanu De" To: Cc: , "Manoj Kamani" References: Subject: AS2 implementation. Date: Fri, 17 Nov 2000 09:48:04 +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, We have a middleware product which uses HTTP as one of its comm agents, and for secure EDI, we have been using GISB which we now need to upgrade towards AS2. We recently subscribed to the EDIINT mailing list and found that quite some work have been already done in order to implement AS2. Now thats a rich harvest, but we'd like someone to pitch in with a little help. I have got the IETF draft with me (I guess there's no RFC yet), but looks like we'll have to get hold of even a few more things. Can any of you guys help me a little? Also, looks like a few of you are discussing about changing the headers from what is there in the draft, citing implementation and interoperability issues. (AT&T guys are discussing testing, right?) So it turns out that quite some work has already been done in this direction, and I won't like to be missed out on that as well. I'll appreciate every bit of cooperation. Right now, I just need to know how much work has alerady been done towards implementting AS2, and how to go about doing it. Thanks, Santanu. From owner-ietf-ediint@mail.imc.org Fri Nov 17 02:58:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15455 for ; Fri, 17 Nov 2000 02:58:20 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA02084 for ietf-ediint-bks; Thu, 16 Nov 2000 23:17:40 -0800 (PST) Received: from irvine.ipnet-solutions.com (irvine.ipnet-solutions.com [38.222.138.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA02075 for ; Thu, 16 Nov 2000 23:17:38 -0800 (PST) Received: by IRVINE with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Nov 2000 13:31:15 -0800 Message-ID: <2435214A0303D41182FF009027F64714BEEC0A@IRVINE> From: Manny Horani To: "'Terry Harding'" , ietf-ediint@imc.org, Dale_Moberg@stercomm.com, chris@dcsnet.demon.co.uk Cc: b2b_int_as2@lists.drummondgroup.com Subject: RE: EDIINT and HIPAA Date: Thu, 16 Nov 2000 13:31:11 -0800 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: I think "as2-from" and "as2-to" naming is adequate. These two header lines are used and meaningful in AS2 context and they are not seen outside AS2. Therefore, they should not cause any confusion. Thanks, Manny -----Original Message----- From: Terry Harding [mailto:tharding@cyclonecommerce.com] Sent: Thursday, November 16, 2000 10:02 AM To: ietf-ediint@imc.org; Dale_Moberg@stercomm.com; chris@dcsnet.demon.co.uk Cc: b2b_int_as2@lists.drummondgroup.com Subject: Re: EDIINT and HIPAA How about. senderId and receiverId. Terry ----- Original Message ----- From: "Chris Davenport" To: ; Sent: Thursday, November 16, 2000 8:19 AM Subject: RE: EDIINT and HIPAA > I was afraid you might say that! Actually I'm not clued up on why it was > considered necessary to introduce these headers. The answer does not appear > to be in the AS2 revision in internet-drafts. Perhaps I missed it being > discussed on this list? > > How about: "EDI-To" and "EDI-From" > > Be happy, > > Chris. > > ---------- Original Message ---------- > From : "Moberg, Dale" > To : "'chris@dcsnet.demon.co.uk'" ,ietf-ediint@imc.org > Date : Thu, 16 Nov 2000 09:27:22 -0500 > Subject: RE: EDIINT and HIPAA > >Suggest them now! > > > >Dale Moberg > > > > > >> -----Original Message----- > >> From: chris@dcsnet.demon.co.uk [mailto:chris@dcsnet.demon.co.uk] > >> Sent: Thursday, November 16, 2000 5:33 AM > >> To: ietf-ediint@imc.org > >> Subject: RE: EDIINT and HIPAA > >> > >> > >> Could we not come up with some more meaningful names for > >> these new headers? > >> I'm thinking that in 10 years time no-one will remember what > >> "AS2-To" means. > >> > >> Just a thought. > >> > >> Chris. > >> > >> > > >> >I agree, the original AS2 spec was based on AS1, but there > >> were problems > >> >discovered during AS2 interoperability testing (using RFC > >> 822 (email) style > >> >packaging) related to "To" and "From" headers, which resulted in the > >> >creation > >> >of two new headers specific to AS2, "AS2-To" and "AS2-From". > >> We (as the > >> >authors > >> >of AS2) will have to provide details of these new routing > >> headers and > >> >cannot > >> >depend entirely on AS1, as we had originally. > >> > > >> -- > >> Chris Davenport chris@dcsnet.demon.co.uk > >> Davros Computer Systems > >> > -- > Chris Davenport chris@dcsnet.demon.co.uk > Davros Computer Systems From owner-ietf-ediint@mail.imc.org Fri Nov 17 09:01:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09503 for ; Fri, 17 Nov 2000 09:01:36 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA11381 for ietf-ediint-bks; Fri, 17 Nov 2000 05:11:36 -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 FAA11377 for ; Fri, 17 Nov 2000 05:11:35 -0800 (PST) Received: from apollo (user-33qt1fm.dialup.mindspring.com [199.174.133.246]) by blount.mail.mindspring.net (8.9.3/8.8.5) with SMTP id IAA29198; Fri, 17 Nov 2000 08:19:11 -0500 (EST) From: "Dick Brooks" To: "Moberg, Dale" , "'Terry Harding'" , , Cc: Subject: RE: EDIINT and HIPAA Date: Fri, 17 Nov 2000 07:22:01 -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: <5FD6397E455FD4118BAE000629383540D39143@SCIDUBMSG02> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I like senderId and receiverId. Rik, will the EDIINT workgroup hold a session to discuss the new AS2 draft at the next IETF meeting in San Diego? Dick Brooks http://www.8760.com/ -----Original Message----- From: Moberg, Dale [mailto:Dale_Moberg@stercomm.com] Sent: Thursday, November 16, 2000 12:22 PM To: 'Terry Harding'; ietf-ediint@imc.org; chris@dcsnet.demon.co.uk Cc: b2b_int_as2@lists.drummondgroup.com Subject: RE: EDIINT and HIPAA List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , OK by me. Anybody not like these? Please respond quickly so we can get this settled. > -----Original Message----- > From: Terry Harding [mailto:tharding@cyclonecommerce.com] > Sent: Thursday, November 16, 2000 1:02 PM > To: ietf-ediint@imc.org; Moberg, Dale; chris@dcsnet.demon.co.uk > Cc: b2b_int_as2@lists.drummondgroup.com > Subject: Re: EDIINT and HIPAA > > > How about. > > senderId and receiverId. > > Terry > ----- Original Message ----- > From: "Chris Davenport" > To: ; > Sent: Thursday, November 16, 2000 8:19 AM > Subject: RE: EDIINT and HIPAA > > > > I was afraid you might say that! Actually I'm not clued up > on why it was > > considered necessary to introduce these headers. The > answer does not > appear > > to be in the AS2 revision in internet-drafts. Perhaps I > missed it being > > discussed on this list? > > > > How about: "EDI-To" and "EDI-From" > > > > Be happy, > > > > Chris. > > > > ---------- Original Message ---------- > > From : "Moberg, Dale" > > To : "'chris@dcsnet.demon.co.uk'" > ,ietf-ediint@imc.org > > Date : Thu, 16 Nov 2000 09:27:22 -0500 > > Subject: RE: EDIINT and HIPAA > > >Suggest them now! > > > > > >Dale Moberg > > > > > > > > >> -----Original Message----- > > >> From: chris@dcsnet.demon.co.uk [mailto:chris@dcsnet.demon.co.uk] > > >> Sent: Thursday, November 16, 2000 5:33 AM > > >> To: ietf-ediint@imc.org > > >> Subject: RE: EDIINT and HIPAA > > >> > > >> > > >> Could we not come up with some more meaningful names for > > >> these new headers? > > >> I'm thinking that in 10 years time no-one will remember what > > >> "AS2-To" means. > > >> > > >> Just a thought. > > >> > > >> Chris. > > >> > > >> > > > >> >I agree, the original AS2 spec was based on AS1, but there > > >> were problems > > >> >discovered during AS2 interoperability testing (using RFC > > >> 822 (email) style > > >> >packaging) related to "To" and "From" headers, which > resulted in the > > >> >creation > > >> >of two new headers specific to AS2, "AS2-To" and "AS2-From". > > >> We (as the > > >> >authors > > >> >of AS2) will have to provide details of these new routing > > >> headers and > > >> >cannot > > >> >depend entirely on AS1, as we had originally. > > >> > > > >> -- > > >> Chris Davenport chris@dcsnet.demon.co.uk > > >> Davros Computer Systems > > >> > > -- > > Chris Davenport chris@dcsnet.demon.co.uk > > Davros Computer Systems > From owner-ietf-ediint@mail.imc.org Fri Nov 17 09:49:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29355 for ; Fri, 17 Nov 2000 09:49:17 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA13340 for ietf-ediint-bks; Fri, 17 Nov 2000 06:00:59 -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 GAA13336 for ; Fri, 17 Nov 2000 06:00:56 -0800 (PST) Received: from imx1.stercomm.com (imx1.stercomm.com [10.117.193.42]) by omx1.stercomm.com with ESMTP id JAA05070; Fri, 17 Nov 2000 09:07:14 -0500 (EST) Received: from cmh0203xcn01.nsg.stercomm.com (cmh0203xcn01.stercomm.com [10.117.193.89]) by imx1.stercomm.com with ESMTP id JAA07259; Fri, 17 Nov 2000 09:09:32 -0500 (EST) Received: by cmh0203xcn01.stercomm.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Nov 2000 09:09:01 -0500 Message-ID: <5FD6397E455FD4118BAE000629383540D3914F@SCIDUBMSG02> From: "Moberg, Dale" To: "'Manny Horani'" , "'Terry Harding'" , ietf-ediint@imc.org, chris@dcsnet.demon.co.uk Cc: b2b_int_as2@lists.drummondgroup.com Subject: RE: EDIINT and HIPAA Date: Fri, 17 Nov 2000 09:08:51 -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: Thanks Manny. Any other people wish to comment on this to see what consensus exists on whether header string changes are needed, and if so, what to change to? I sense that people are far from convinced that a change is needed. Human readability is not a real concern here because most AS2 agents are for automated systems, right? And it might be better to indicate that these headers have a very restricted applicability (AS2) and leave it to a later standard to straighten out the variety of namespaces used in identifying persons or organizations in XML and EDI messaging contexts. After all we are leaving the values for these headers very unconstrained and subject to bilateral trading partner agreements... Other angles? > -----Original Message----- > From: Manny Horani [mailto:mhorani@ipnetsolutions.com] > Sent: Thursday, November 16, 2000 4:31 PM > To: 'Terry Harding'; ietf-ediint@imc.org; Moberg, Dale; > chris@dcsnet.demon.co.uk > Cc: b2b_int_as2@lists.drummondgroup.com > Subject: RE: EDIINT and HIPAA > > > > I think "as2-from" and "as2-to" naming is adequate. These > two header lines > are used and meaningful in AS2 context and they are not seen > outside AS2. > Therefore, they should not cause any confusion. > > Thanks, > Manny > > -----Original Message----- > From: Terry Harding [mailto:tharding@cyclonecommerce.com] > Sent: Thursday, November 16, 2000 10:02 AM > To: ietf-ediint@imc.org; Dale_Moberg@stercomm.com; > chris@dcsnet.demon.co.uk > Cc: b2b_int_as2@lists.drummondgroup.com > Subject: Re: EDIINT and HIPAA > > > How about. > > senderId and receiverId. > > Terry > ----- Original Message ----- > From: "Chris Davenport" > To: ; > Sent: Thursday, November 16, 2000 8:19 AM > Subject: RE: EDIINT and HIPAA > > > > I was afraid you might say that! Actually I'm not clued up > on why it was > > considered necessary to introduce these headers. The > answer does not > appear > > to be in the AS2 revision in internet-drafts. Perhaps I > missed it being > > discussed on this list? > > > > How about: "EDI-To" and "EDI-From" > > > > Be happy, > > > > Chris. > > > > ---------- Original Message ---------- > > From : "Moberg, Dale" > > To : "'chris@dcsnet.demon.co.uk'" > ,ietf-ediint@imc.org > > Date : Thu, 16 Nov 2000 09:27:22 -0500 > > Subject: RE: EDIINT and HIPAA > > >Suggest them now! > > > > > >Dale Moberg > > > > > > > > >> -----Original Message----- > > >> From: chris@dcsnet.demon.co.uk [mailto:chris@dcsnet.demon.co.uk] > > >> Sent: Thursday, November 16, 2000 5:33 AM > > >> To: ietf-ediint@imc.org > > >> Subject: RE: EDIINT and HIPAA > > >> > > >> > > >> Could we not come up with some more meaningful names for > > >> these new headers? > > >> I'm thinking that in 10 years time no-one will remember what > > >> "AS2-To" means. > > >> > > >> Just a thought. > > >> > > >> Chris. > > >> > > >> > > > >> >I agree, the original AS2 spec was based on AS1, but there > > >> were problems > > >> >discovered during AS2 interoperability testing (using RFC > > >> 822 (email) style > > >> >packaging) related to "To" and "From" headers, which > resulted in the > > >> >creation > > >> >of two new headers specific to AS2, "AS2-To" and "AS2-From". > > >> We (as the > > >> >authors > > >> >of AS2) will have to provide details of these new routing > > >> headers and > > >> >cannot > > >> >depend entirely on AS1, as we had originally. > > >> > > > >> -- > > >> Chris Davenport chris@dcsnet.demon.co.uk > > >> Davros Computer Systems > > >> > > -- > > Chris Davenport chris@dcsnet.demon.co.uk > > Davros Computer Systems > From owner-ietf-ediint@mail.imc.org Fri Nov 17 09:49:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29426 for ; Fri, 17 Nov 2000 09:49:27 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA13745 for ietf-ediint-bks; Fri, 17 Nov 2000 06:07:17 -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 GAA13741 for ; Fri, 17 Nov 2000 06:07:15 -0800 (PST) Received: from apollo (user-33qt1fm.dialup.mindspring.com [199.174.133.246]) by blount.mail.mindspring.net (8.9.3/8.8.5) with SMTP id JAA04794; Fri, 17 Nov 2000 09:14:51 -0500 (EST) From: "Dick Brooks" To: "Santanu De" , Cc: , "Manoj Kamani" Subject: RE: AS2 implementation. Date: Fri, 17 Nov 2000 08:17:42 -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: <074601c0504d$6175d530$99e29e81@india.sun.com> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Santanu, The AS2 changes coming out of the interoperability testing conducted by the Drummond Group DO NOT affect the GISB profile within AS2. In fact, there are several Energy companies in New York and Pennsylvania that are implementing AS2/GISB now. The implementations are based on the current AS2 draft. Let me know if you would like to conduct interoperability testing on the AS2/GISB profile. I've started discussions with a couple organizations that expressed an interest in sponsoring the next set of AS2 interoperability tests, which will be based on the AS2/GISB profile. Regards, Dick Brooks http://www.8760.com/ -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Santanu De Sent: Thursday, November 16, 2000 10:18 PM To: ietf-ediint@imc.org Cc: iec-iplanet-ecx@india.sun.com; Manoj Kamani Subject: AS2 implementation. Hi, We have a middleware product which uses HTTP as one of its comm agents, and for secure EDI, we have been using GISB which we now need to upgrade towards AS2. We recently subscribed to the EDIINT mailing list and found that quite some work have been already done in order to implement AS2. Now thats a rich harvest, but we'd like someone to pitch in with a little help. I have got the IETF draft with me (I guess there's no RFC yet), but looks like we'll have to get hold of even a few more things. Can any of you guys help me a little? Also, looks like a few of you are discussing about changing the headers from what is there in the draft, citing implementation and interoperability issues. (AT&T guys are discussing testing, right?) So it turns out that quite some work has already been done in this direction, and I won't like to be missed out on that as well. I'll appreciate every bit of cooperation. Right now, I just need to know how much work has alerady been done towards implementting AS2, and how to go about doing it. Thanks, Santanu. From owner-ietf-ediint@mail.imc.org Fri Nov 17 10:52:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01698 for ; Fri, 17 Nov 2000 10:52:52 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA19569 for ietf-ediint-bks; Fri, 17 Nov 2000 07:11:32 -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 HAA19565 for ; Fri, 17 Nov 2000 07:11:30 -0800 (PST) Received: from imx1.stercomm.com (imx1.stercomm.com [10.117.193.42]) by omx1.stercomm.com with ESMTP id KAA12208; Fri, 17 Nov 2000 10:17:54 -0500 (EST) Received: from cmh0203xcn01.nsg.stercomm.com (cmh0203xcn01.stercomm.com [10.117.193.89]) by imx1.stercomm.com with ESMTP id KAA13734; Fri, 17 Nov 2000 10:20:13 -0500 (EST) Received: by cmh0203xcn01.stercomm.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Nov 2000 10:19:41 -0500 Message-ID: <5FD6397E455FD4118BAE000629383540D39154@SCIDUBMSG02> From: "Moberg, Dale" To: "'Santanu De'" , ietf-ediint@imc.org Cc: iec-iplanet-ecx@india.sun.com, Manoj Kamani Subject: RE: AS2 implementation. Date: Fri, 17 Nov 2000 10:19:40 -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: Actually this list is for discussion of the specification itself and not specifically directed at discussing implementation issues. There is another list dealing more with interoperability and with implementatations that the Drummond Group operates, maybe with UCC assistance. (not sure of the details here.) I think the implementation list may be slightly restricted to those with implementation efforts, so check out www.drummondgroup.com for more info. I am sure they will provide assistance! > -----Original Message----- > From: Santanu De [mailto:santanu.de@india.sun.com] > Sent: Thursday, November 16, 2000 11:18 PM > To: ietf-ediint@imc.org > Cc: iec-iplanet-ecx@india.sun.com; Manoj Kamani > Subject: AS2 implementation. > > > > Hi, > > We have a middleware product which uses HTTP as one of its > comm agents, and > for secure EDI, we have been using GISB which we now need to > upgrade towards > AS2. > > We recently subscribed to the EDIINT mailing list and found > that quite some > work have been already done in order to implement AS2. Now > thats a rich > harvest, but we'd like someone to pitch in with a little help. > > I have got the IETF draft with me (I guess there's no RFC > yet), but looks > like we'll have to get hold of even a few more things. Can > any of you guys > help me a little? > > > Also, looks like a few of you are discussing about changing > the headers from > what is there in the draft, citing implementation and interoperability > issues. (AT&T guys are discussing testing, right?) So it > turns out that > quite some work has already been done in this direction, and > I won't like to > be missed out on that as well. > > I'll appreciate every bit of cooperation. Right now, I just > need to know how > much work has alerady been done towards implementting AS2, > and how to go > about doing it. > > Thanks, > Santanu. > From owner-ietf-ediint@mail.imc.org Fri Nov 17 14:16:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24389 for ; Fri, 17 Nov 2000 14:16:53 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA03256 for ietf-ediint-bks; Fri, 17 Nov 2000 10:14:31 -0800 (PST) Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03250 for ; Fri, 17 Nov 2000 10:14:28 -0800 (PST) Received: from dcsnet.demon.co.uk ([194.222.162.207]) by anchor-post-34.mail.demon.net with smtp (Exim 2.12 #1) id 13wq8x-000NQR-0Y for ietf-ediint@imc.org; Fri, 17 Nov 2000 18:21:50 +0000 Received: from Delta by Delta with NETFAM id 001099; Fri, 17 Nov 2000 18:10:07 +0100 (BST) From: chris@dcsnet.demon.co.uk (Chris Davenport) Reply-To: chris@dcsnet.demon.co.uk Date: Fri, 17 Nov 2000 18:09:56 +0000 (GMT) Message-Id: <20001117.180956.001@dcsnet.demon.co.uk> To: ietf-ediint@imc.org Subject: RE: EDIINT and HIPAA X-Mailer: DVMAIL Version 2.3 (144) 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 senderID and receiverID sound good to me too, but perhaps Sender-ID and Receiver-ID (ie. with hyphens) would be more in keeping with the syntax of SMTP and HTTP headers? These seem to be very generic, like they may have been used somewhere else. Has anyone checked that this will not conflict with any current or planned usage by other groups? Be happy, Chris. ---------- Original Message ---------- From : "Dick Brooks" To : "Moberg, Dale" ,"'Terry Harding'" , Date : Fri, 17 Nov 2000 07:22:01 -0600 Subject: RE: EDIINT and HIPAA >I like senderId and receiverId. > >Rik, will the EDIINT workgroup hold a session to discuss the new AS2 draft >at the next IETF meeting in San Diego? > >Dick Brooks >http://www.8760.com/ > > >-----Original Message----- >From: Moberg, Dale [mailto:Dale_Moberg@stercomm.com] >Sent: Thursday, November 16, 2000 12:22 PM >To: 'Terry Harding'; ietf-ediint@imc.org; chris@dcsnet.demon.co.uk >Cc: b2b_int_as2@lists.drummondgroup.com >Subject: RE: EDIINT and HIPAA > > >List-Subscribe: > >List-Unsubscribe: > >List-Archive: >List-Help: , > > >OK by me. > >Anybody not like these? >Please respond quickly >so we can get this >settled. > > >> -----Original Message----- >> From: Terry Harding [mailto:tharding@cyclonecommerce.com] >> Sent: Thursday, November 16, 2000 1:02 PM >> To: ietf-ediint@imc.org; Moberg, Dale; chris@dcsnet.demon.co.uk >> Cc: b2b_int_as2@lists.drummondgroup.com >> Subject: Re: EDIINT and HIPAA >> >> >> How about. >> >> senderId and receiverId. >> >> Terry >> ----- Original Message ----- >> From: "Chris Davenport" >> To: ; >> Sent: Thursday, November 16, 2000 8:19 AM >> Subject: RE: EDIINT and HIPAA >> >> >> > I was afraid you might say that! Actually I'm not clued up >> on why it was >> > considered necessary to introduce these headers. The >> answer does not >> appear >> > to be in the AS2 revision in internet-drafts. Perhaps I >> missed it being >> > discussed on this list? >> > >> > How about: "EDI-To" and "EDI-From" >> > >> > Be happy, >> > >> > Chris. >> > >> > ---------- Original Message ---------- >> > From : "Moberg, Dale" >> > To : "'chris@dcsnet.demon.co.uk'" >> ,ietf-ediint@imc.org >> > Date : Thu, 16 Nov 2000 09:27:22 -0500 >> > Subject: RE: EDIINT and HIPAA >> > >Suggest them now! >> > > >> > >Dale Moberg >> > > >> > > >> > >> -----Original Message----- >> > >> From: chris@dcsnet.demon.co.uk [mailto:chris@dcsnet.demon.co.uk] >> > >> Sent: Thursday, November 16, 2000 5:33 AM >> > >> To: ietf-ediint@imc.org >> > >> Subject: RE: EDIINT and HIPAA >> > >> >> > >> >> > >> Could we not come up with some more meaningful names for >> > >> these new headers? >> > >> I'm thinking that in 10 years time no-one will remember what >> > >> "AS2-To" means. >> > >> >> > >> Just a thought. >> > >> >> > >> Chris. >> > >> >> > >> > >> > >> >I agree, the original AS2 spec was based on AS1, but there >> > >> were problems >> > >> >discovered during AS2 interoperability testing (using RFC >> > >> 822 (email) style >> > >> >packaging) related to "To" and "From" headers, which >> resulted in the >> > >> >creation >> > >> >of two new headers specific to AS2, "AS2-To" and "AS2-From". >> > >> We (as the >> > >> >authors >> > >> >of AS2) will have to provide details of these new routing >> > >> headers and >> > >> >cannot >> > >> >depend entirely on AS1, as we had originally. >> > >> > >> > >> -- >> > >> Chris Davenport chris@dcsnet.demon.co.uk >> > >> Davros Computer Systems >> > >> >> > -- >> > Chris Davenport chris@dcsnet.demon.co.uk >> > Davros Computer Systems >> > -- Chris Davenport chris@dcsnet.demon.co.uk Davros Computer Systems From owner-ietf-ediint@mail.imc.org Fri Nov 17 16:28:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10935 for ; Fri, 17 Nov 2000 16:28:44 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA00567 for ietf-ediint-bks; Fri, 17 Nov 2000 12:45:51 -0800 (PST) Received: from inforum.net (AVAIL.calweb.com [207.211.85.137] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00557 for ; Fri, 17 Nov 2000 12:45:49 -0800 (PST) Received: from computer [209.128.192.193] by inforum.net (SMTPD32-5.05) id AACA18260162; Fri, 17 Nov 2000 12:53:30 -0800 Message-ID: <007801c050d8$a4e67aa0$c1c080d1@computer> From: "John Roberts" To: Subject: Someone please! Get me off this list! Date: Fri, 17 Nov 2000 12:54:56 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0075_01C05095.9613C0C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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_0075_01C05095.9613C0C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Help! I can't find the original e-mail that tells me how to unsubscribe = from this list and it is not included with any of the posts. Can = someone please let me know how to get off this list?? Thank you! John Roberts -------------------------------------------------------------------------= ------------------------------------------------------- Graeagle Alaskan Malamutes Home of Mack, Kimbra, Dancer, Tonka, Cheyenne and Kitty Cats Foxy, = Roxanne and Mei-Hu =20 530.647.8540 graeagle@inforum.net=20 -------------------------------------------------------------------------= ------------------------------------------------------- ------=_NextPart_000_0075_01C05095.9613C0C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Help!  I can't find the original e-mail that tells me how to=20 unsubscribe from this list and it is not included with any of the = posts. =20 Can someone please let me know how to get off this list??
 
Thank you!
 
John Roberts
--------------------------------------------------------------------= ------------------------------------------------------------
Graeagle = Alaskan Malamutes
Home of Mack, Kimbra, Dancer, Tonka, Cheyenne and = Kitty=20 Cats Foxy, Roxanne and Mei-Hu  
530.647.8540
graeagle@inforum.net=20
---------------------------------------------------------------------= -----------------------------------------------------------
------=_NextPart_000_0075_01C05095.9613C0C0-- From owner-ietf-ediint@mail.imc.org Fri Nov 17 21:39:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17622 for ; Fri, 17 Nov 2000 21:39:45 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA22858 for ietf-ediint-bks; Fri, 17 Nov 2000 17:59:51 -0800 (PST) Received: from puma.gartner.com (overlord.gartner.com [207.140.148.33]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA22826 for ; Fri, 17 Nov 2000 17:59:44 -0800 (PST) Received: by puma.gartner.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Nov 2000 21:07:21 -0500 Message-ID: <69A38F8986F3D211A6B00008C79121060969A29F@mammoth.gartner.com> From: "Rishel,Wes" To: "'dick@8760.com'" , Gunther Schadow Cc: GISB1@aol.com, ietf-ediint@imc.org, Kepa Zubeldia Subject: RE: EDIINT and HIPAA--where's the HIPAA? Date: Fri, 17 Nov 2000 21:07:21 -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: I have enjoyed this dialogue, at least the part that started on 11/2 and went forward. As Dick knows, I have been trying to scrape together the time to write a Gartner Research Note about AS2 since last Spring. I have previously criticized the work of the WEDI/AFEHCT interoperability pilot for not at least giving some attention to EDIINT, although this is a minor criticism along with my major praise of a very important and well-conducted effort. I am intrigued by the title, but can find no reference to HIPAA in the thread going back to 11/2. I don't think I got messages before 11/2. Can anyone back-fill me on the HIPAA comments? Wes Rishel Research Director Healthcare Industry Research & Advisory Services GartnerGroup Alameda, CA Client inquiries: call +1-203-316-1288 or email to indapps@gartner.com wes.rishel@gartner.com 510 522 8135 510 521 2423 (fax) > -----Original Message----- > From: Dick Brooks [mailto:dick@8760.com] > Sent: Thursday, November 02, 2000 10:27 AM > To: Gunther Schadow > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org; Dick > Brooks > Subject: RE: EDIINT and HIPAA > > > Gunther, > > In my travels I've realized there is a great deal of > confusion regarding > AS2, your questions/comments are a great lead-in to help > clear up some of > the misunderstandings. I apologize for sending such a long > e-mail but I > think it is necessary at this point. I've provided my responses inline > bounded by , so here goes: > > > > -----Original Message----- > > From: Gunther Schadow [mailto:gunther@aurora.regenstrief.org] > > Sent: Thursday, November 02, 2000 10:13 AM > > To: Dick Brooks > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > Subject: Re: EDIINT and HIPAA > > > > > > Dick, > > > > I appreciate your warning. Please me (and others) understand ... > > > > You say: > > > AS2 contains two distinctly different ways to package > and send EDI > > > and other data over HTTP: > > > > > > 1. The HTTP standard approach, ref: HTTP spec > > (www.ietf.org/rfc/rfc2616.txt), > > > Multipart/form-data spec (www.ietf.org/rfc/rfc2388.txt formerly > > rfc 1867) and > > > HTML 4.0 spec (http://www.w3.org/TR/REC-html40/) > > > This is the approach used by GISB and the Automotive > Industry (AIAG E5) > > > > > > 2. E-mail based packaging as specified in EDIINT AS1 > > > > (http://www.ietf.org/internet-drafts/draft-ietf-ediint-as1-11.txt ). > > > > Hmm, my understanding is that, while AS#1 uses SMTP (which > I still believe > > is good ... but we had enough of that discussion :-), both AS#2 > > and the GISB > > profile use HTTP. The difference may be the payload of the > HTTP request. > > > > > There are many good reasons why people prefer HTTP over > E-mail (SMTP) for > their mission critical EDI data exchanges, but we won't > re-hash them here. > If people want to know the details send me an e-mail > mailto:dick@8760.com > > There are three key concepts when discussing EDIINT AS2; > 1. Packaging > 2. Payload > 3. Data Transport > > 1. Packaging defines the way in which EDI data and header > information is > packaged together in preparation for transport. The packaging > also includes > a definition the headers that will be used for purposes such > as identifying > senders, receivers, etc. (e.g. within the GISB - multipart/form-data > packaging of AS2 there is a "To" header which contains a DUNS > number that > identifies the intended recipient. Within the e-mail based > packaging of AS2 > there is a new header, called "AS2-To", which serves the same > purpose as > GISB's "To" header. The "AS2-To" header is one of the changes > that came out > of the EDIINT AS2 interoperability tests and this will be > defined in the > next draft release of AS2.) > > 2. Payload is the actual data a party wishes to send, > typically a business > transaction formatted in X12, EDIFACT, XML, etc. > A payload is contained within a "package", as defined by 1. > > 3. Data Transport defines the mechanism used to send/receive > data (HTTP, > SMTP, FTP are all data transports). > > With regard to EDIINT AS2 it: > Defines two types of packaging; > 1. Multipart/form-data (as in GISB) > 2. E-mail (as in AS1) > > Can package and send any type of payload (X12, XML, JPEG, etc.), > regardless of the packaging used. The data can be > encrypted and digitally signed. > > Mandates that all "packages" be exchanged via HTTP. > > Can support both batch and interactive (web forms) modes > when using > Multipart/form-data packaging. > > Here are two examples to help make this clear: > > GISB/AS2 example sending a signed/encrypted X12 file over HTTP using a > non-interactive batch browser: > > POST c:\execute HTTP/1.0 > Connection: Keep-Alive > User-Agent: Group 8760 Batch Browser > Content-type: multipart/form-data; > boundary=---------------------------87453838942833 > Content-Length: 5379 > > -----------------------------87453838942833 > Content-Disposition: form-data; name="from" > 123456789 > -----------------------------87453838942833 > Content-Disposition: form-data; name="to" > 234567890 > -----------------------------87453838942833 > Content-Disposition: form-data; name="version" > 1.4 > -----------------------------87453838942833 > Content-Disposition: form-data; name="receipt-disposition-to" > 123456789 > -----------------------------87453838942833 > Content-Disposition: form-data; name="receipt-report-type" > GISB-Acknowledgement-Receipt > -----------------------------87453838942833 > Content-Disposition: form-data; name="input-format" > X12 > -----------------------------87453838942833 > Content-Disposition: form-data; name="input-data"; filename= > c:\temp\smallnom.bin > Content-Type: multipart/encrypted; boundary=8760; > protocol="application/pgp-encrypted" > --8760 > Content-Type: application/pgp-encrypted > Version: 1 > --8760 > Content-Type: application/octet-stream > -----BEGIN PGP MESSAGE----- > Version: PGP 6.5 > > hQCMAzRG1pEOIOvdAQP+JMr0m/9+8yOL60Z9Vr6fFV81FCExB/o0xmwiMkiwYsHs > z0e8sb7ErC340MrNA/dw3taGMjmI+CXYRF/PLEdg1NZE1ZCtNeL4YdIHAMLWwODG > lQxhSucz8rMSgQ5mZzcOJwBdWLW70efgsu/9UljuJjYc1uZ6C03eFQv/43fkB+al > ATtgydxX4g8QK664ad+Jo/XUICSmWBL66fqJR1KLeLf4wTaqGy174Aq48Wpwvg1E > h785zC03UAw0qg0ugMt86dPeyd91e2JigqwDYEf/DYEKD0J9BGiGpS/uAupNKj8O > cp2IWClxKOGUbxpVNOnNTqWHS/GntegvDE/7/ewCxDxsnmQS95pOl141QZ1RQbeN > aqx2Dq/ra9g65HNchOCzjul5Vi8HHf6Yhg2WnROe+npByyCue6rihqgNVOJwj0cV > zpb4JE+gMDf3q4ISUb1Fv7/+SSFHDdnhdC5YTpqf1Bc3B07hiLmtTXqNit31EbX9 > UVElObzSa9ZhxbC6/eSl7Nuf5ZTDsh9nrk+QQJ6FeC9W4cqXLj7IZySaRO8Vtff+ > 4ktqeuhYusT4kSpnk027aw4O/5jomUkfb22CAe4= > =Oiuo > -----END PGP MESSAGE----- > --8760-- > -----------------------------87453838942833 > > > Here is an e-mail based example, taken directly from the current AS2 > interoperability testing underway (this was provided by Dale Moberg). > NOTE: the AS2-To and AS2-From headers are NOT defined by the > current AS2 > draft (these will be included in the next draft release of AS2): > > POST / HTTP/1.0 > User-Agent: Somebodys AS2 implementation > AS2-From: ZZCYCLONE > AS2-To: someone@btradecorp.com > Date: Wed, 18 Oct 2000 23:24:59 GMT > Message-ID: <4fd79e5b-9e71-4655-8f98-d61f832dc11d@ipnetsolutions.com > > > Subject: EDI Document > Content-Type: MULTIPART/SIGNED; > protocol="application/pkcs7-signature";micalg=sha1;boundary="_ > =boundary1" > Content-Disposition: attachment; filename="ZZIPNET-000000022.edi" > Content-Length: 1507 > > --_=boundary1 > Content-Type: APPLICATION/EDI-X12 > Content-Disposition: attachment; filename="ZZIPNET-000000022.edi" > > ISA*00*ssssssssss*00*rrrrrrrrrr*ZZ*ipnet *ZZ*btrade > --_=boundary1 > Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s > > ??Binary signature here?? > --_=boundary1-- > > > > > Isn't it true that both AS#2 and GISB use the MIME security > wrappers? > > > > The AS2 compliant version of GISB uses the MIME security > wrappers, the > old GISB simply placed encrypted data into an application/octet-stream > wrapper. > > > Isn't the only difference that AS#2 uses RFC1767 application/EDI-* > > payload while GISB use multipart/form-data? > > > > The AS2 compliant GISB also packages X12 payload data in > a RFC 1767 > compliant manner before placing it inside a > multipart/form-data package. For > example, here is an unencrypted X12 file in > multipart/form-data packaging: > > Content-type: multipart/form-data; > boundary=---------------------------87453838942833 > Content-Length: 5379 > > -----------------------------87453838942833 > Content-Disposition: form-data; name="from" > 123456789 > -----------------------------87453838942833 > Content-Disposition: form-data; name="to" > 234567890 > -----------------------------87453838942833 > Content-Disposition: form-data; name="version" > 1.4 > -----------------------------87453838942833 > Content-Disposition: form-data; name="receipt-disposition-to" > 123456789 > -----------------------------87453838942833 > Content-Disposition: form-data; name="receipt-report-type" > GISB-Acknowledgement-Receipt > -----------------------------87453838942833 > Content-Disposition: form-data; name="input-format" > X12 > -----------------------------87453838942833 > Content-Disposition: form-data; name="input-data"; filename= > hipaa-institution-claim.x12 > Content-Type: application/EDI-X12 > > healthcare claim data in X12 format goes here > -----------------------------87453838942833 > > > > Since you use form data, does that mean that GISB's > operational model > > is that of a user interacting with a web-based e-commerce system > > directly (i.e. filling out an HTML form?) > > > > This is the biggest misconception - GISB's operational > model supports > BOTH unattended (aka batch mode) and interactive types of > data exchange. > Both use the exact same packaging (multipart/form-data). By > supporting both > interactive and batch mode GISB has been able to support the > small trading > partner, via an interactive web form upload and the large > multi-national > using the batch file upload. > > > > Most of X12, HL7, and NCPDP, certainly do not work with direct user > > interactions but use an EDI message payload formatted according to > > X12, HL7 and NCPDP specifications respectively. (Though I know that > > NCPDP has done something in direct user interaction too, but not > > sure how much that is actually used.) > > > > No problem HL7 and HIPAA can support both interactive > and batch mode > clients using the GISB/AS2 profile. > > > > > The EDIINT AS2 interoperability test currently underway by the > > Drummond Group > > > and sponsored by UCC is exercising the e-mail specifications > > (option #2 above). > > > The "profile" defined and adopted by GISB and AIAG (option #1 > > above) is not > > > included in the EDIINT test, however there are numerous > > implementations of GISB > > > EDM and AIAG-E5 (the foundation specs that formed the basis of > > AS2 profile #1) > > > that have been used daily since 4/1997 for E-Commerce on the > > Internet (Enron > > > recently announced $200 Billion dollars in E-Commerce on the > > Internet; they were > > > the first company to implement the GISB standard for Internet > > E-Commerce). > > > > this is good and fine. The only requirement would be that these > > implementations can also support the EDI payload method of AS#2, > > either now or easily soon (I suppose they can.) > > > > We certainly do not want to change the underlying EDI standards to > > use form-data presentation. > > > > This is no need to change X12 - the X12 data is simply a > payload within > the multipart/form-data package. No changes are needed to > package and send > X12 following the GISB AS2 profile. In fact all of GISB's business > transactions use standard X12 representation and there were no changes > required to X12. > > > > > > The EDIINT AS2 interoperability test has uncovered some issues > > that required > > > changes to the e-mail formatting specifications within AS2 (Rik > > can provide the > > > details of the problems, but they were "show stoppers" that had > > to be fixed). > > > These changes do NOT affect the GISB or AIAG profiles of AS2 > > (option #1), the > > > changes are limited to the e-mail section (option #2). This > > means the AS2 > > > authors (Dale Moberg, Rik Drummond and myself) will have to > > make appropriate > > > adjustments to AS2 and republish as an IETF draft. This will > > begin a review > > > process and will most likely require a face-to-face meeting at > > the IETF to move > > > the process along. This could delay the standardization > of AS2 by IETF, > > > depending on the feedback received regarding the changes. The > > GISB profile of > > > AS2 (option #1) has remained unchanged, so I don't expect any > > opposition/issues > > > to arise. > > > > Gulp, this means another year delay until the final RFC is > out, the IESG > > has got to speed up its processes! > > > > I'm not sure how long a delay we're looking at to make > AS2 an RFC. When > I worked on the development of RFC 1767 I thought we would finish in 3 > months (we only had to define 3 MIME types). We started in 1993 and it > didn't reach RFC status until March 1995. You just can't > predict what will > happen within the IETF. > > > > > I'm willing to discuss this further and help move AS2 closer to > > becoming an IETF > > > and government approved standard, beyond the endorsement > > received by GISB from > > > DOE/FERC. > > > > > > FYI - Group 8760 has assisted in performing interoperability > > testing (Internet > > > transport only), using the GISB standard (with PGP > > encryption/signatures), > > > between an institutional provider and a large Insurance Carrier > > (payer) for > > > HIPAA compliance within the last 3 months with successful results. > > > > Would you be willing to come to a couple of HL7 meetings and help us > > release the IETF specs as HL7 standard (for ANSI approval) and > > communicate > > our few additional requirements back into the IETF? > > > > I'm interested in talking with you about your > requirements and would be > happy to assist. > > > In addition, I would like to have some other IETF-EDIINT > members (vendors) > > to step up and join that fast track group for EDIINT ANSI > approval. If we > > could get three people who see this as a valuable > investment, it would > > help. May be on the next IETF-EDIINT meeting we should talk > about this. > > Either Kepa and/or I should come see you to discuss the > ANSI question and > > get the ball rolling. > > > > But, you have to understand, I'm kind of looking for a clear sign > > from the > > EDIINT group to say "yes, this ANSI thing makes sense, so let's > > go do it," > > you know, some committment. Note that neither I nor HL7 has a > > particularly > > huge selfish interest in this to happen, we would not > participate in that > > sudden market growth, we are not vendors selling products to > > every Medicare > > provider in the US :-). We are just kind of hoping to help > the right thing > > to happen for the sake of sanity :-) > > > > I'm not familiar with the HL7 standards process, all of > my experience > has been with IETF, DISA, GISB and recently ebXML. Each of these > organizations has a different process for developing standards. If we > brought AS2 to HL7 today, how long would it take to become an > ANSI standard? > I would like to read HL7's operational process document, can > you provide a > pointer? > > > > regards > > -Gunther > > Thanks, and sorry for the loooong message, > > 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 Fri Nov 17 22:22:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18474 for ; Fri, 17 Nov 2000 22:22:28 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA28958 for ietf-ediint-bks; Fri, 17 Nov 2000 18:24:50 -0800 (PST) Received: from puma.gartner.com (overlord.gartner.com [207.140.148.33]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA28936 for ; Fri, 17 Nov 2000 18:24:43 -0800 (PST) Received: by puma.gartner.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Nov 2000 21:31:43 -0500 Message-ID: <69A38F8986F3D211A6B00008C79121060969A2A0@mammoth.gartner.com> From: "Rishel,Wes" To: "'dick@8760.com'" , Gunther Schadow Cc: Rik Drummond , Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Fri, 17 Nov 2000 21:31:43 -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: As the chair-elect of HL7 I would like to respond to DB's question about HL7 process. HL7 has two kinds of specifications that are published using slighly different processes: a Standard is submitted to ANSI for certification once it has passed ballot; a Recommendation is published by HL7 but is not submitted to ANSI and does not become an ANSI standard. Some Recommendations have had substantial acceptance among the HL7 community, including it's "lower level protocols" which define ways to reliably pass discrete messages over RS-232 and TCP, and were published sometime in the early 1990s. A Standard originates under the sponsorship of a Technical Committee. If HL7 were to create a Standard for EDIINT it would be the Control/Query committee. It is balloted at the committee level. (Actually anyone can participate in the committee ballot, but in practice those who choose to do so are usually those who participate in, or follow the work of, the Technical Committee.) When it passes a committee level ballot it is submitted for ballot by the full HL7 Working Group (which is the entire organization). If it passes at this level it is automatically submitted to ANSI for certification. The ANSI review allows time for public comment, but it is primarily a certification that the process was fair and consistent with our bylaws. To date, have never had an issue arise that prevented or delayed the certification process. In addition to Technical Committees HL7 has Special Interest Groups. Gunther is co-chair of our SIG on security. Strictly speaking, a SIG cannot initiate the balloting of a standard; but SIGs can prepare such a document, and obtain the consent of a Technical Committee which sponsors the ballot. The other kind of document, the Recommendation, is easier to get out the door. It can be originated by a SIG, and it has only one level of balloting. The majority that is required to pass a Recommendation is less severe than the majority required to pass a Standard (67% vs. 90%). Ballots are conducted using the Web. Assuming that both ballots pass an energetic committee can easily complete the entire process in two of our three-per-year Working Group meetings (roughly 8 months elapsed time). (Of course most committees have substantial time invested in debating the document before it begins the process.) Most of the meetings required at certain points in the process can be handled using conference calls; in theory a REALLY motivated committee could accomplish the two-level ballot in five months and then wait about three months for ANSI certication. (That is a theoretical figure that has never been realized in practise.) Recommendations can be passed in roughly four months. Best regards, Wes Rishel Research Director Healthcare Industry Research & Advisory Services GartnerGroup Alameda, CA Client inquiries: call +1-203-316-1288 or email to indapps@gartner.com wes.rishel@gartner.com 510 522 8135 510 521 2423 (fax) > -----Original Message----- > From: Dick Brooks [mailto:dick@8760.com] > Sent: Thursday, November 02, 2000 10:27 AM > To: Gunther Schadow > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org; Dick > Brooks > Subject: RE: EDIINT and HIPAA > > > > I'm not familiar with the HL7 standards process, all of > my experience > has been with IETF, DISA, GISB and recently ebXML. Each of these > organizations has a different process for developing standards. If we > brought AS2 to HL7 today, how long would it take to become an > ANSI standard? > I would like to read HL7's operational process document, can > you provide a > pointer? > > From owner-ietf-ediint@mail.imc.org Sat Nov 18 17:01:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12803 for ; Sat, 18 Nov 2000 17:01:48 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA17219 for ietf-ediint-bks; Sat, 18 Nov 2000 13:17:03 -0800 (PST) Received: from pimout1-int.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17209 for ; Sat, 18 Nov 2000 13:17:02 -0800 (PST) Received: from Govaserver (A020-0310.SNFC.splitrock.net [63.253.7.56]) by pimout1-int.prodigy.net (8.10.1/8.10.1) with SMTP id eAILOjZ137410; Sat, 18 Nov 2000 16:24:45 -0500 Received: by localhost with Microsoft MAPI; Sat, 18 Nov 2000 13:42:49 -0800 Message-ID: <01C05165.70C2DF60.amitrao@prodigy.net> From: Amit Rao Reply-To: "amitrao@prodigy.net" To: "'John Roberts'" , "ietf-ediint@imc.org" Subject: RE: Someone please! Get me off this list! Date: Sat, 18 Nov 2000 13:42:48 -0800 Organization: Govatech X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ditto. Amit Rao. -----Original Message----- From: John Roberts [SMTP:graeagle@inforum.net] Sent: Friday, November 17, 2000 12:55 PM To: ietf-ediint@imc.org Subject: Someone please! Get me off this list! << File: ATT00001.html >> Help! I can't find the original e-mail that tells me how to unsubscribe from this list and it is not included with any of the posts. Can someone please let me know how to get off this list?? Thank you! John Roberts ------------------------------------------------------------------------ -------------------------------------------------------- Graeagle Alaskan Malamutes Home of Mack, Kimbra, Dancer, Tonka, Cheyenne and Kitty Cats Foxy, Roxanne and Mei-Hu 530.647.8540 graeagle@inforum.net ------------------------------------------------------------------------ -------------------------------------------------------- From owner-ietf-ediint@mail.imc.org Sat Nov 18 17:20:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12917 for ; Sat, 18 Nov 2000 17:20:04 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA26826 for ietf-ediint-bks; Sat, 18 Nov 2000 13:48:45 -0800 (PST) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26809 for ; Sat, 18 Nov 2000 13:48:42 -0800 (PST) Received: from gamma (user-33qt5a1.dialup.mindspring.com [199.174.149.65]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with SMTP id QAA00861; Sat, 18 Nov 2000 16:56:06 -0500 (EST) Reply-To: From: "Dick Brooks" To: "Rishel,Wes" , "Gunther Schadow" Cc: "Rik Drummond" , "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Sat, 18 Nov 2000 15:52:32 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <69A38F8986F3D211A6B00008C79121060969A2A0@mammoth.gartner.com> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks Wes. Based on your description I would anticipate the EDIINT AS2 spec taking the "Recommendation" route, IF the group decides to go forward. Do you see it the same way? FYI - other groups that have adopted AS2 have found it necessary to define "interoperability profiles". These profiles identify the exact set of "options" from AS2 that everyone in the "trading community" agrees to follow, in order to ensure interoperability. For example, GISB has already defined an AS2 interoperability profile and the New York Collaborative, in accordance with the Public Service Commission regulations, is in the process of defining their interoperability profile. I'm familiar with both these groups and the process used to develop their profiles. I could help HL7 develop an AS2 interoperability profile, if the group decides to pursue this approach. Regards, 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: Rishel,Wes [mailto:wes.rishel@gartner.com] > Sent: Friday, November 17, 2000 8:32 PM > To: 'dick@8760.com'; Gunther Schadow > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > As the chair-elect of HL7 I would like to respond to DB's > question about HL7 > process. > > HL7 has two kinds of specifications that are published using slighly > different processes: a Standard is submitted to ANSI for > certification once > it has passed ballot; a Recommendation is published by HL7 but is not > submitted to ANSI and does not become an ANSI standard. Some > Recommendations > have had substantial acceptance among the HL7 community, including it's > "lower level protocols" which define ways to reliably pass > discrete messages > over RS-232 and TCP, and were published sometime in the early 1990s. > > A Standard originates under the sponsorship of a Technical > Committee. If HL7 > were to create a Standard for EDIINT it would be the Control/Query > committee. It is balloted at the committee level. (Actually anyone can > participate in the committee ballot, but in practice those who > choose to do > so are usually those who participate in, or follow the work of, the > Technical Committee.) When it passes a committee level ballot it is > submitted for ballot by the full HL7 Working Group (which is the entire > organization). If it passes at this level it is automatically submitted to > ANSI for certification. The ANSI review allows time for public > comment, but > it is primarily a certification that the process was fair and consistent > with our bylaws. To date, have never had an issue arise that prevented or > delayed the certification process. > > In addition to Technical Committees HL7 has Special Interest > Groups. Gunther > is co-chair of our SIG on security. Strictly speaking, a SIG > cannot initiate > the balloting of a standard; but SIGs can prepare such a document, and > obtain the consent of a Technical Committee which sponsors the ballot. > > The other kind of document, the Recommendation, is easier to get out the > door. It can be originated by a SIG, and it has only one level of > balloting. > The majority that is required to pass a Recommendation is less severe than > the majority required to pass a Standard (67% vs. 90%). > > Ballots are conducted using the Web. Assuming that both ballots pass an > energetic committee can easily complete the entire process in two of our > three-per-year Working Group meetings (roughly 8 months elapsed time). (Of > course most committees have substantial time invested in debating the > document before it begins the process.) > > Most of the meetings required at certain points in the process can be > handled using conference calls; in theory a REALLY motivated > committee could > accomplish the two-level ballot in five months and then wait about three > months for ANSI certication. (That is a theoretical figure that has never > been realized in practise.) > > Recommendations can be passed in roughly four months. > > Best regards, > > Wes Rishel > Research Director > Healthcare Industry Research & Advisory Services > GartnerGroup > Alameda, CA > Client inquiries: call +1-203-316-1288 or email to indapps@gartner.com > wes.rishel@gartner.com > 510 522 8135 > 510 521 2423 (fax) > > > > > -----Original Message----- > > From: Dick Brooks [mailto:dick@8760.com] > > Sent: Thursday, November 02, 2000 10:27 AM > > To: Gunther Schadow > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org; Dick > > Brooks > > Subject: RE: EDIINT and HIPAA > > > > > > > > I'm not familiar with the HL7 standards process, all of > > my experience > > has been with IETF, DISA, GISB and recently ebXML. Each of these > > organizations has a different process for developing standards. If we > > brought AS2 to HL7 today, how long would it take to become an > > ANSI standard? > > I would like to read HL7's operational process document, can > > you provide a > > pointer? > > > > From owner-ietf-ediint@mail.imc.org Sat Nov 18 17:26:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12952 for ; Sat, 18 Nov 2000 17:26:32 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA28049 for ietf-ediint-bks; Sat, 18 Nov 2000 13:52:55 -0800 (PST) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28037 for ; Sat, 18 Nov 2000 13:52:53 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <007801c050d8$a4e67aa0$c1c080d1@computer> References: <007801c050d8$a4e67aa0$c1c080d1@computer> Date: Sat, 18 Nov 2000 14:00:37 -0800 To: ietf-ediint@imc.org From: Paul Hoffman / IMC Subject: Re: Someone please! Get me off this list! Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:54 PM -0800 11/17/00, John Roberts wrote: >Help! I can't find the original e-mail that tells me how to >unsubscribe from this list and it is not included with any of the >posts. Can someone please let me know how to get off this list?? Look in the headers of every message that is sent to the list. The header that reads: List-Unsubscribe: should give you a not-so-subtle clue. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-ediint@mail.imc.org Sat Nov 18 17:54:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13112 for ; Sat, 18 Nov 2000 17:54:00 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA05158 for ietf-ediint-bks; Sat, 18 Nov 2000 14:18:48 -0800 (PST) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05148 for ; Sat, 18 Nov 2000 14:18:46 -0800 (PST) Received: from gamma (user-33qt5a1.dialup.mindspring.com [199.174.149.65]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with SMTP id RAA08368; Sat, 18 Nov 2000 17:26:29 -0500 (EST) Reply-To: From: "Dick Brooks" To: , "'John Roberts'" , Subject: EDIINT mailing list Subscribe/Unsubscribe instructions Date: Sat, 18 Nov 2000 16:22: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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <01C05165.70C2DF60.amitrao@prodigy.net> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mailing List Instructions To subscribe to the mailing list, send a message to ietf-ediint-request@imc.org with the single word subscribe in the body of the message. To unsubscribe from the list, use that same address with the single word unsubscribe in the body of the message. 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 Sat Nov 18 23:31:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20630 for ; Sat, 18 Nov 2000 23:31:39 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA03041 for ietf-ediint-bks; Sat, 18 Nov 2000 20:06:03 -0800 (PST) Received: from aurora.regenstrief.org (aurora.regenstrief.org [134.68.31.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA03037 for ; Sat, 18 Nov 2000 20:06:01 -0800 (PST) Received: from aurora.regenstrief.org (ip209-183-121-106.ts.indy.net [209.183.121.106]) by aurora.regenstrief.org (8.11.1/8.9.3) with ESMTP id eAJ45SZ27041; Sat, 18 Nov 2000 23:05:28 -0500 (EST) (envelope-from gunther@aurora.regenstrief.org) Message-ID: <3A1751A2.B5205178@aurora.regenstrief.org> Date: Sat, 18 Nov 2000 23:05:54 -0500 From: Gunther Schadow Organization: Regenstrief Institute X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: dick@8760.com CC: "Rishel,Wes" , Rik Drummond , Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) References: Content-Type: multipart/mixed; boundary="------------47755E09D3AAE84EC1AE2015" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------47755E09D3AAE84EC1AE2015 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dick Brooks wrote: > > Thanks Wes. > > Based on your description I would anticipate the EDIINT AS2 spec taking the > "Recommendation" route, IF the group decides to go forward. Do you see it > the same way? Dick, I actually do see it the other way. The EDIINT work in HL7 as we discussed it in relation to HIPAA is only useful if we end up with an ANSI approved standard. That must be a standard, not a recommendation. I'll fill in Wes on the HIPAA issue under separate cover. Glad you can make it for 1/8/2001. Thank you for your help. regards, -Gunther --------------47755E09D3AAE84EC1AE2015 Content-Type: text/x-vcard; charset=us-ascii; name="gunther.vcf" Content-Description: Card for Gunther Schadow Content-Disposition: attachment; filename="gunther.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Schadow;Gunther tel;fax:+1 317 630 6962 tel;home:+1 317 816 0516 tel;work:+1 317 630 7960 x-mozilla-html:FALSE url:http://aurora.rg.iupui.edu org:Regenstrief Institute for Health Care adr:;;1050 Wishard Blvd;Indianapolis;Indiana;46202;USA version:2.1 email;internet:gschadow@regenstrief.org title:M.D., Medical Information Scientist note;quoted-printable:Al oppinions expressed in this message are my own and do =0D=0Anot necessarily represent those of the Regenstrief Institute. fn:Gunther Schadow end:vcard --------------47755E09D3AAE84EC1AE2015-- From owner-ietf-ediint@mail.imc.org Sun Nov 19 18:52:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13665 for ; Sun, 19 Nov 2000 18:52:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA00697 for ietf-ediint-bks; Sun, 19 Nov 2000 15:13:18 -0800 (PST) Received: from unknown ([198.211.237.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA00573; Sun, 19 Nov 2000 15:05:13 -0800 (PST) From: redial@wongfaye.com Subject: toner cartridges Date: Wed, 19 Nov 1997 14:28:02 Message-Id: <400.389117.88183@> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Toner Supplies at discount prices Laser Printer Toner Cartridges Fax and Copier Cartridges Order by phone:1-888-288-9043 Order by fax: 1-888-977-1577 *** E-mail removal line: 1-888-248-4930 *** *** If you would like to mail your order please call 1-888-248-2015 *** Pay by check, credit card or Purchase Order. If your order is by check please leave your check number (Mail check when you recieve merchandise) If your order is by credit card please leave your card number + expiration date If your order is by P.O. please leave your shipping/billing addresses Current Prices are as follows: Cartridges for Hewlett Packard printers: 4L,4p,1100 and series 2 cartridges are now $49 2p cartridges are $54 3si cartridges are $75 4000 and 2100 cartridges are $79 5000 and 8100 cartridges are $135 5p, 6p, 5mp and 6mp cartridges are $59 Cartridges for Apple printers Pro 600 or 16-600 cartridges are now $69 Laser writer select 300,320 and 360 cartridges are $69 Laser writer 300 and 320 cartridges are $54 Laser writer NT, 2nt, 2f, 2g and LS cartridges are $54 Laser writer personal 12-640 cartridges are $79 Cartridges for Hewlett Packard laser fax printers: Laser fax 500,700,5000,7000,fx1 and fx2 cartridges are now $59 Laser fax fx3 cartridges are $69 Our laser fax fx4 cartridges are $79 Cartridges for Lexmark and IBM printers Optra 4019 and 4029 are now $125 optra r,r+ and optra s cartridges are $135 optra e cartridges are $59 Our cartridges for canon copiers PC 3, 6re, 7 and 11 (A30) are now $69 PC 300,320,700,720 and 760 (E-40) are $89 90 day extended warranty included on all products. From owner-ietf-ediint@mail.imc.org Mon Nov 20 03:12:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02802 for ; Mon, 20 Nov 2000 03:12:29 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA25179 for ietf-ediint-bks; Sun, 19 Nov 2000 23:31:10 -0800 (PST) Received: from puma.gartner.com (overlord.gartner.com [207.140.148.33]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA25166 for ; Sun, 19 Nov 2000 23:31:07 -0800 (PST) Received: by puma.gartner.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 01:07:09 -0500 Message-ID: <69A38F8986F3D211A6B00008C79121060969A2B6@mammoth.gartner.com> From: "Rishel,Wes" To: "'Gunther Schadow'" , dick@8760.com Cc: "Rishel,Wes" , Rik Drummond , Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Mon, 20 Nov 2000 01:07:11 -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: For many reasons it would be more desirable to be a Standard, but I am not sure that there aren't some shades of gray, particularly if the difference in the required time is important. I will wait to hear from Gunther about the HIPAA issue, but I am suspecting that the following is true: a) there is interest in having a healthcare group give its imprimatur to AS2, since it "rounds out" the Internet protocols to make a complete package for HIPAA-compliant, B2B messaging based on ubiquitous Internet protocols such as HTTP, FTP and SNMP. b) there is some despair at seeing AS2 get out of IETF before quantum computers pretty much obsolete everything based on computers with deterministic states (this last was an attempt at humor) c) there is a sense that being an ANSI Standard is a requirement if one desires to get the government to mandate its use. I would take issue with item (c). It is surely helpful to be a standard, but it is also helpful to be any sort of publication of an ANSI-accredited standards development organization. Furthermore, unless someone knows something specific, I would be skeptical that the current administration would introduce another delay in the final rule on security by attempting to add AS2 at this late date. Rather than a government mandate, I suspect that the benefit of an HL7 imprimatur, and perhaps a profile or two, would be to assist in promoting the Internet and AS2 as means to exchange the HIPAA transactions without reliance on value added networks. At the same time it would be very valuable to HL7 to have ways to exchange standard (old syntax) HL7 messages and HL7-XML messages over the Internet using the same infrastructure (integration brokers and servers) as are being sold for other B2B applications in healthcare, the power industry, etc. If this model is correct a Standard is better, but a Recommendation also provides substantial benefit. One approach would be to create a Recommendation first and follow it up with a Standard after some operational experience has been obtained. > -----Original Message----- > From: Gunther Schadow [mailto:gunther@aurora.regenstrief.org] > Sent: Saturday, November 18, 2000 8:06 PM > To: dick@8760.com > Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > Dick Brooks wrote: > > > > Thanks Wes. > > > > Based on your description I would anticipate the EDIINT AS2 > spec taking the > > "Recommendation" route, IF the group decides to go forward. > Do you see it > > the same way? > > Dick, I actually do see it the other way. The EDIINT work in > HL7 as we > discussed it in relation to HIPAA is only useful if we end up > with an ANSI > approved standard. That must be a standard, not a recommendation. > > I'll fill in Wes on the HIPAA issue under separate cover. Glad you can > make it for 1/8/2001. Thank you for your help. > > regards, > -Gunther > From owner-ietf-ediint@mail.imc.org Mon Nov 20 09:54:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11683 for ; Mon, 20 Nov 2000 09:54:37 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA05890 for ietf-ediint-bks; Mon, 20 Nov 2000 05:38:02 -0800 (PST) Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA05886 for ; Mon, 20 Nov 2000 05:37:58 -0800 (PST) Received: from vaio ([12.74.8.115]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.10 201-229-121-110) with SMTP id <20001120133756.HVQT2287.mtiwmhc23.worldnet.att.net@vaio>; Mon, 20 Nov 2000 13:37:56 +0000 From: "Rik Drummond" To: , "Rishel,Wes" , "Gunther Schadow" Cc: "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Mon, 20 Nov 2000 07:38:36 -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) In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit the interoperability profiles we normally have to implement to make as2 and as1 interoperable revolve around the pki and certs. these still are not very interoperable across products we keep finding in our testing. i would like to see the as2 spec move forward in hl7. we are going to edit the current version taking into account the finding in the ucc/drummondgroup interoperability tests now under way.... that should be don before christmas/the holidays... rik -----Original Message----- From: Dick Brooks [mailto:dick@8760.com] Sent: Saturday, November 18, 2000 3:53 PM To: Rishel,Wes; Gunther Schadow Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Thanks Wes. Based on your description I would anticipate the EDIINT AS2 spec taking the "Recommendation" route, IF the group decides to go forward. Do you see it the same way? FYI - other groups that have adopted AS2 have found it necessary to define "interoperability profiles". These profiles identify the exact set of "options" from AS2 that everyone in the "trading community" agrees to follow, in order to ensure interoperability. For example, GISB has already defined an AS2 interoperability profile and the New York Collaborative, in accordance with the Public Service Commission regulations, is in the process of defining their interoperability profile. I'm familiar with both these groups and the process used to develop their profiles. I could help HL7 develop an AS2 interoperability profile, if the group decides to pursue this approach. Regards, 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: Rishel,Wes [mailto:wes.rishel@gartner.com] > Sent: Friday, November 17, 2000 8:32 PM > To: 'dick@8760.com'; Gunther Schadow > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > As the chair-elect of HL7 I would like to respond to DB's > question about HL7 > process. > > HL7 has two kinds of specifications that are published using slighly > different processes: a Standard is submitted to ANSI for > certification once > it has passed ballot; a Recommendation is published by HL7 but is not > submitted to ANSI and does not become an ANSI standard. Some > Recommendations > have had substantial acceptance among the HL7 community, including it's > "lower level protocols" which define ways to reliably pass > discrete messages > over RS-232 and TCP, and were published sometime in the early 1990s. > > A Standard originates under the sponsorship of a Technical > Committee. If HL7 > were to create a Standard for EDIINT it would be the Control/Query > committee. It is balloted at the committee level. (Actually anyone can > participate in the committee ballot, but in practice those who > choose to do > so are usually those who participate in, or follow the work of, the > Technical Committee.) When it passes a committee level ballot it is > submitted for ballot by the full HL7 Working Group (which is the entire > organization). If it passes at this level it is automatically submitted to > ANSI for certification. The ANSI review allows time for public > comment, but > it is primarily a certification that the process was fair and consistent > with our bylaws. To date, have never had an issue arise that prevented or > delayed the certification process. > > In addition to Technical Committees HL7 has Special Interest > Groups. Gunther > is co-chair of our SIG on security. Strictly speaking, a SIG > cannot initiate > the balloting of a standard; but SIGs can prepare such a document, and > obtain the consent of a Technical Committee which sponsors the ballot. > > The other kind of document, the Recommendation, is easier to get out the > door. It can be originated by a SIG, and it has only one level of > balloting. > The majority that is required to pass a Recommendation is less severe than > the majority required to pass a Standard (67% vs. 90%). > > Ballots are conducted using the Web. Assuming that both ballots pass an > energetic committee can easily complete the entire process in two of our > three-per-year Working Group meetings (roughly 8 months elapsed time). (Of > course most committees have substantial time invested in debating the > document before it begins the process.) > > Most of the meetings required at certain points in the process can be > handled using conference calls; in theory a REALLY motivated > committee could > accomplish the two-level ballot in five months and then wait about three > months for ANSI certication. (That is a theoretical figure that has never > been realized in practise.) > > Recommendations can be passed in roughly four months. > > Best regards, > > Wes Rishel > Research Director > Healthcare Industry Research & Advisory Services > GartnerGroup > Alameda, CA > Client inquiries: call +1-203-316-1288 or email to indapps@gartner.com > wes.rishel@gartner.com > 510 522 8135 > 510 521 2423 (fax) > > > > > -----Original Message----- > > From: Dick Brooks [mailto:dick@8760.com] > > Sent: Thursday, November 02, 2000 10:27 AM > > To: Gunther Schadow > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org; Dick > > Brooks > > Subject: RE: EDIINT and HIPAA > > > > > > > > I'm not familiar with the HL7 standards process, all of > > my experience > > has been with IETF, DISA, GISB and recently ebXML. Each of these > > organizations has a different process for developing standards. If we > > brought AS2 to HL7 today, how long would it take to become an > > ANSI standard? > > I would like to read HL7's operational process document, can > > you provide a > > pointer? > > > > From owner-ietf-ediint@mail.imc.org Mon Nov 20 09:59:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11824 for ; Mon, 20 Nov 2000 09:59:51 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA08329 for ietf-ediint-bks; Mon, 20 Nov 2000 06:29:54 -0800 (PST) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08324 for ; Mon, 20 Nov 2000 06:29:52 -0800 (PST) Received: from apollo (user-2injoq2.dialup.mindspring.com [165.121.227.66]) by granger.mail.mindspring.net (8.9.3/8.8.5) with SMTP id JAA15469; Mon, 20 Nov 2000 09:30:03 -0500 (EST) From: "Dick Brooks" To: "Rishel,Wes" , "'Gunther Schadow'" Cc: "Rik Drummond" , "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , , Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Mon, 20 Nov 2000 08:33:01 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0019_01C052CC.7E925860" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <69A38F8986F3D211A6B00008C79121060969A2B6@mammoth.gartner.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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_0019_01C052CC.7E925860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Wes, You make some excellent points, I want to focus on a few that I believe are critical in moving forward. >a) there is interest in having a healthcare group give its imprimatur to >AS2, since it "rounds out" the Internet protocols to make a complete package >for HIPAA-compliant, B2B messaging based on ubiquitous Internet protocols >such as HTTP, FTP and SNMP. Many people (not specifically in healthcare) are confused by the number of "B2B standards" that exist, for example: - Vendor initiated (BizTalk and SOAP) - Consortia initiated (ebXML by OASIS and UN/CEFACT, XML Protocols Activity by the World Wide Web Consortium ) - Internet related standards bodies initiated (IETF - EDIINT ASx, IETF - BEEP) - Industry specific standards bodies initiated (HL7, GISB, UIG, AIAG, etc.) Not to mention all the proprietary initiatives. They look at all these "standards" and they're afraid they'll choose the "wrong standard". I believe industry organizations, like HL7, play a critical role in helping people choose a B2B standard that's appropriate for their needs. >b) there is some despair at seeing AS2 get out of IETF before quantum >computers pretty much obsolete everything based on computers with >deterministic states (this last was an attempt at humor) Actually this is an excellent point. The IETF is very particular when it comes to designing/endorsing standards, as it should be. Some of the recent concerns with AS1 (see Ned Freed's comments attached) raise the probabilities of a longer delay for AS2, because the non-GISB portion of AS2 depends on AS1. I'm not aware of any issues with the GISB portion of AS2. >c) there is a sense that being an ANSI Standard is a requirement if one >desires to get the government to mandate its use. The Department of Energy, via the Federal Energy Regulatory Commission, mandated use of the GISB standard and I don't believe it is an ANSI standard. Perhaps Rae McQuade, Executive Director of GISB (gisb1@aol.com), can comment on this. I certainly don't understand many of the idiosyncrasies of HL7 Standards versus Recommendations so I'll listen and learn as this discussion evolves. I have been an active participant in many of the initiatives mentioned above including: ebXML, GISB, UIG, W3C XP, and of course IETF EDIINT. I look forward to working with the HL7 organization on this very important decision during the coming months. Regards, Dick Brooks http://www.8760.com/ -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Rishel,Wes Sent: Monday, November 20, 2000 12:07 AM To: 'Gunther Schadow'; Dick Brooks Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) For many reasons it would be more desirable to be a Standard, but I am not sure that there aren't some shades of gray, particularly if the difference in the required time is important. I will wait to hear from Gunther about the HIPAA issue, but I am suspecting that the following is true: a) there is interest in having a healthcare group give its imprimatur to AS2, since it "rounds out" the Internet protocols to make a complete package for HIPAA-compliant, B2B messaging based on ubiquitous Internet protocols such as HTTP, FTP and SNMP. b) there is some despair at seeing AS2 get out of IETF before quantum computers pretty much obsolete everything based on computers with deterministic states (this last was an attempt at humor) c) there is a sense that being an ANSI Standard is a requirement if one desires to get the government to mandate its use. I would take issue with item (c). It is surely helpful to be a standard, but it is also helpful to be any sort of publication of an ANSI-accredited standards development organization. Furthermore, unless someone knows something specific, I would be skeptical that the current administration would introduce another delay in the final rule on security by attempting to add AS2 at this late date. Rather than a government mandate, I suspect that the benefit of an HL7 imprimatur, and perhaps a profile or two, would be to assist in promoting the Internet and AS2 as means to exchange the HIPAA transactions without reliance on value added networks. At the same time it would be very valuable to HL7 to have ways to exchange standard (old syntax) HL7 messages and HL7-XML messages over the Internet using the same infrastructure (integration brokers and servers) as are being sold for other B2B applications in healthcare, the power industry, etc. If this model is correct a Standard is better, but a Recommendation also provides substantial benefit. One approach would be to create a Recommendation first and follow it up with a Standard after some operational experience has been obtained. > -----Original Message----- > From: Gunther Schadow [mailto:gunther@aurora.regenstrief.org] > Sent: Saturday, November 18, 2000 8:06 PM > To: dick@8760.com > Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > Dick Brooks wrote: > > > > Thanks Wes. > > > > Based on your description I would anticipate the EDIINT AS2 > spec taking the > > "Recommendation" route, IF the group decides to go forward. > Do you see it > > the same way? > > Dick, I actually do see it the other way. The EDIINT work in > HL7 as we > discussed it in relation to HIPAA is only useful if we end up > with an ANSI > approved standard. That must be a standard, not a recommendation. > > I'll fill in Wes on the HIPAA issue under separate cover. Glad you can > make it for 1/8/2001. Thank you for your help. > > regards, > -Gunther > ------=_NextPart_000_0019_01C052CC.7E925860 Content-Type: message/rfc822 Content-Disposition: attachment From: Sender: To: "Rik Drummond" Cc: References: <39FEE816.AE3E1EAB@aurora.regenstrief.org> Subject: AD review of EDIINT documents (was RE: Status and Future of EDIINT) Date: Fri, 3 Nov 2000 01:20:13 -0600 Message-ID: <01JW318160SM00004Q@mauve.mrochek.com> 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.2910.0) List-Unsubscribe: X-SLUIDL: DCF927C1-AC1A11D4-BB090060-974E38DD In-Reply-To: "Your message dated Tue, 31 Oct 2000 10:34:43 -0600" Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit > well it is not dead. the spec is in the loop for rfc approval... and we now > have 12 vendors supporting as1 and 9 supporting as2. these are all > interoperable. if we don't get something back from the ietf shortly it might > be wise to go the ansi route... rik Well, as it happens I've been working on the AD review of these documents. I just completed that review today. I've attached my review comments below. Sorry it took so long. Ned ------ AD review of draft-ietf-ediint-req-08.txt: I started to write a bunch of comments on this document, but then decided against it. The basic problem is that due to the substantial amount of time that has passed since this text was written (through no fault of the authors or the WG, I hasten to add), quite a bit of it seems dated. For example, a discussion of the use of VPNs in contrast to VANs would seem appropriate. Some of the symmetric cipher discussion is likely dated as well. But given that it is informational I see little harm in publishing it as-is. Note that it may end up with an IESG note pointing out the timing issue, however. AD review of draft-ietf-ediint-as1-11.txt: This is where the issues are. Some are very minor, but a couple must be addressed. Security considerations section. The word "Technologies" is capitalized when it should not be. The security considerations section is normally at the end of the document. It also should cover actual considerations rather than restating what the document is about. 1.0 Introduction, first paragraph. The impression is given here that this is purely an Applicability Statement. However, the very next paragraph then indicates otherwise. I suggest that this be clarified by referring to "the bulk of this document is an Applicability Statement", or something similar. 1.0 Introduction, second paragraph. There's a reference to section 3.1.8, which does not exist in the current document. I believe this is supposed to be 5.3.1. 1.0 Introduction, third paragraph. "Used" -> "used". 2.1. Reference to "standard" is premature. I suggest saying "document" instead. 2.2.2, first paragraph. "The functional requirements document, [9] "Requirements for Inter-operable Internet EDI" (can be found at www.ietf.org)," needs to be rewritten as a reference to an RFC-to-be. 2.2.2, first paragraph, "Provides" -> "provides". 2.2.2, second paragraph. Use of the term "transport" here is confusing. I suggest "environment" or something similar instead. 2.2.2, last paragraph. "Satisfy" -> "satisfy". 2.2.3, first bullet item. This section doesn't identify RFC 2298 as the mechanism being used to request EDI receipts. Suggest making it clear here rather than having to get further into the document to find out. 2.3.2, fourth bullet item. Now that PGP itself is an IETF standard, should reference RFC 2440 as well as RFC 2015 here and elsewhere in the document. 2.3.2, fourth bullet item. REQUIRES is not a keyword on the 2119 list; suggest rewording to use REQUIRED instead. 5.4.1, first paragraph. The phrase Using message, "partial", should be Using message/partial 5.4.1, second paragraph. The phrase "so that if fragmentation does occur," isn't right in this context. I suggest "so that if fragmentation is needed" instead. 5.4.1. Recommending that partial be used but saying that support for it is optional could lead to interoperability issues. I suggest that you add that in the absence of knowledge that the recipient supports partial it SHOULD NOT be used. 5.4.1, last paragraph. This is the biggie. Saying it is OK to use content-encoding in email even as an option just isn't acceptable. The problem is one of interoperability: An unextended agent that receives a message with, say, a content-encoding of gzip won't recognize the field for what it is and will cheerfully decode the base64 expecting to find text or whatever. Instead it will find garbage. Unfortunately, the only way to add compression to email in a backwards compatible way is to define new content-transfer-encodings. If this is a real issue this is the mechanism that needs to be pursued. Note that it is fine to recommend use of content-encoding if the transport is HTTP. Content-encoding is well-defined there and agents are required to check for it and handle it. Finally, this document defines new disposition-notification-options and a new MDN field received-content-mic. Both of these things require IANA registration. It is customary in standards track documents to do this with an appendix containing the appropriate registration forms. This needs to be done per sections 10.2 and 10.3 of RFC 2298. That's it! ------=_NextPart_000_0019_01C052CC.7E925860-- From owner-ietf-ediint@mail.imc.org Mon Nov 20 11:07:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15106 for ; Mon, 20 Nov 2000 11:07:11 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAB15372 for ietf-ediint-bks; Mon, 20 Nov 2000 07:28: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 HAA15355 for ; Mon, 20 Nov 2000 07:28:45 -0800 (PST) Received: from imx1.stercomm.com (imx1.stercomm.com [10.117.193.42]) by omx1.stercomm.com with ESMTP id KAA20595; Mon, 20 Nov 2000 10:28:14 -0500 (EST) Received: from cmh0203xcn01.nsg.stercomm.com (cmh0203xcn01.stercomm.com [10.117.193.89]) by imx1.stercomm.com with ESMTP id KAA12504; Mon, 20 Nov 2000 10:30:35 -0500 (EST) Received: by cmh0203xcn01.stercomm.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 10:30:07 -0500 Message-ID: <5FD6397E455FD4118BAE000629383540D3915B@SCIDUBMSG02> From: "Moberg, Dale" To: "'Dick Brooks'" , "Rishel,Wes" , "'Gunther Schadow'" Cc: Rik Drummond , Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: Comment on RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Mon, 20 Nov 2000 10:30:01 -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] > Sent: Monday, November 20, 2000 9:33 AM > To: Rishel,Wes; 'Gunther Schadow' > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org; > dick@8760.com > Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) > Actually this is an excellent point. The IETF is very > particular when it > comes to designing/endorsing standards, as it should be. Some > of the recent > concerns with AS1 (see Ned Freed's comments attached) raise the > probabilities of a longer delay for AS2, because the non-GISB > portion of AS2 > depends on AS1. I'm not aware of any issues with the GISB > portion of AS2. Just a brief comment on a small point raised in passing in the above-- AS 2 references AS 1 and so needs to have AS 1 approved before moving along. The issues Ned Freed raised concerning the AS 1 option on compression were SMTP specific really, and that approach is not referenced in AS 2, where we mention using the "content-coding" approach of HTTP (where needed) described in HTTP 2068 section 3.5 (we will update this before final draft) PGP has its own compression so the content-coding option would probably not be used if using open-PGP (as in the GISB profile). In fact, Ned 's favored approach (use a new content-transfer-encoding for compression) is like the HTTP procedure. I don't think there is reason to think there will be any additional delay stemming from the remark about AS 1 except for the fact that AS 2 references AS 1 and so AS 1 needs to get through "first". From owner-ietf-ediint@mail.imc.org Mon Nov 20 11:26:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17744 for ; Mon, 20 Nov 2000 11:26:28 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA17981 for ietf-ediint-bks; Mon, 20 Nov 2000 07:41:39 -0800 (PST) Received: from aurora.regenstrief.org (aurora.regenstrief.org [134.68.31.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17954 for ; Mon, 20 Nov 2000 07:41:36 -0800 (PST) Received: from aurora.regenstrief.org ([134.68.31.177]) by aurora.regenstrief.org (8.11.1/8.9.3) with ESMTP id eAKFfDZ38936; Mon, 20 Nov 2000 10:41:17 -0500 (EST) (envelope-from gunther@aurora.regenstrief.org) Message-ID: <3A194633.CEABCDC4@aurora.regenstrief.org> Date: Mon, 20 Nov 2000 10:41:39 -0500 From: Gunther Schadow Organization: Regenstrief Institute X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rishel,Wes" CC: dick@8760.com, Rik Drummond , Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) References: <69A38F8986F3D211A6B00008C79121060969A2B6@mammoth.gartner.com> Content-Type: multipart/mixed; boundary="------------17D55DDEACD557D366BEE09A" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------17D55DDEACD557D366BEE09A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Wes, one of your guesses was right on target, it's c: > c) there is a sense that being an ANSI Standard is a requirement if one > desires to get the government to mandate its use. Your issues to this particular item are noted. But first: the HHS and NCVHS (to the latter I had a chance at attending and being heard recently) are looking for some electronic signature standards for healthcare. Notably they asked for something beyond the existing "technology neutral" NPRM. That's where Kepa and I suggested the EDIINT specs based on the rationale that any digisig standard must first fit the information payload standards that it is to secure. In other words, since in the U.S. healthcare system we use X12N, HL7, and NCPDP, any concrete signature standard should fit those existing EDI standards. This and other reasons speak for EDIINT as a strong if not the only reasonable and available solution. The question then is, what does it take for HHS to pick EDIINT? And we figured that some sort of ANSI accreditation is needed. Clem has told me that may be all it takes is endorsement from an ANSI accredited SDO, so, you're right, Wes, that a full ANSI standard may not be needed. However, I figured that it would be merely one additional ballot cycle to get EDIINT out as an ANSI standard under HL7 cover, and therefore that this approach may be extra-safe. I believe that the HL7 balloting would be more or less pro-forma, since the balloted material has been worked on with meticulous reality testing and with products available as the specifications were fleshed out. Also, HL7 has a history in dealing with the EDIINT specification and that ballot in 1998 didn't turn out any major issues that would had caused a reballot. So, I reckon, if we have a committee level ballot that succeeds, we do have some sort of working "ANSI SDO endorsment" at that point (as much as an Informative ballot would ever yield.) So we could do the full membership ballot as additional reinforcement, again expecting little trouble along the way. > If this model is correct a Standard is better, but a Recommendation also > provides substantial benefit. One approach would be to create a > Recommendation first and follow it up with a Standard after some operational > experience has been obtained. As a conclusion, I would defer to Kepa, Wes, and Clem to see what the best vehicle would be to make EDIINT viable for HHS -- I think that an ANSI seal would probably be the best shot. I also see little arguments against making EDIINT some sort of HL7 standard proper. In our new terms, EDIINT would fall somewhere in the ITS category, and there is not need for HL7 to bind itself exclusively to one specification in that category. The question is then how such a ballot would look like. There are some options: (1) A set of verbatim copies of IETF EDIINT materials (RFCs by that time, I hope.) (2) One short document that only refers to the relevant RFCs. Examples of such "standards" that do not specify anything by themselves are many FIPS-PUB standards. (3) An HL7 profile that will add a few minor extensions to the IETF spec. Those will be necessary for reasons discussed in the existing HL7 EDIINT recommendation. Finally, for the purpose of EDIINT's status at HHS (and quite independently from HL7) we should make certain that NCPDP is being mentioned in any such profile. I agree that for HL7 it is as much as advertizing for a competitor, on the other hand, from what I have heared, I believe that relationship between HL7 and NCPDP are potentially very good. regards -Gunther PS: given that Rick Drummond has to leave by noon on Monday 1/8/2001 we have to do a little agenda juggling. This will be a joint meeting with ASTM and it will look kind of odd to put the technology specific standard release discussion first in the agenda. However, I'll try to give a good justification in an introduction so that it should seem O.K. to do this first. --------------17D55DDEACD557D366BEE09A Content-Type: text/x-vcard; charset=us-ascii; name="gunther.vcf" Content-Description: Card for Gunther Schadow Content-Disposition: attachment; filename="gunther.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Schadow;Gunther tel;fax:+1 317 630 6962 tel;home:+1 317 816 0516 tel;work:+1 317 630 7960 x-mozilla-html:FALSE url:http://aurora.rg.iupui.edu org:Regenstrief Institute for Health Care adr:;;1050 Wishard Blvd;Indianapolis;Indiana;46202;USA version:2.1 email;internet:gschadow@regenstrief.org title:M.D., Medical Information Scientist note;quoted-printable:Al oppinions expressed in this message are my own and do =0D=0Anot necessarily represent those of the Regenstrief Institute. fn:Gunther Schadow end:vcard --------------17D55DDEACD557D366BEE09A-- From owner-ietf-ediint@mail.imc.org Mon Nov 20 15:14:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08781 for ; Mon, 20 Nov 2000 15:14:17 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06027 for ietf-ediint-bks; Mon, 20 Nov 2000 11:23:09 -0800 (PST) Received: from mtiwmhc24.worldnet.att.net (mtiwmhc24.worldnet.att.net [204.127.131.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06023 for ; Mon, 20 Nov 2000 11:23:07 -0800 (PST) Received: from rik ([12.74.8.148]) by mtiwmhc24.worldnet.att.net (InterMail vM.4.01.03.10 201-229-121-110) with SMTP id <20001120192322.IIDQ13270.mtiwmhc24.worldnet.att.net@rik>; Mon, 20 Nov 2000 19:23:22 +0000 From: "Rik Drummond" To: "Moberg, Dale" , "'Dick Brooks'" , "Rishel,Wes" , "'Gunther Schadow'" Cc: "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: RE: Comment on RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Mon, 20 Nov 2000 13:24:02 -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) In-reply-to: <5FD6397E455FD4118BAE000629383540D3915B@SCIDUBMSG02> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ned is waiting our final edits to the as1 document so that it can go to the rfc editor.... rik -----Original Message----- From: Moberg, Dale [mailto:Dale_Moberg@stercomm.com] Sent: Monday, November 20, 2000 9:30 AM To: 'Dick Brooks'; Rishel,Wes; 'Gunther Schadow' Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org Subject: Comment on RE: HL7 Standards Process (was RE: EDIINT and HIPAA) > -----Original Message----- > From: Dick Brooks [mailto:dick@8760.com] > Sent: Monday, November 20, 2000 9:33 AM > To: Rishel,Wes; 'Gunther Schadow' > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org; > dick@8760.com > Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) > Actually this is an excellent point. The IETF is very > particular when it > comes to designing/endorsing standards, as it should be. Some > of the recent > concerns with AS1 (see Ned Freed's comments attached) raise the > probabilities of a longer delay for AS2, because the non-GISB > portion of AS2 > depends on AS1. I'm not aware of any issues with the GISB > portion of AS2. Just a brief comment on a small point raised in passing in the above-- AS 2 references AS 1 and so needs to have AS 1 approved before moving along. The issues Ned Freed raised concerning the AS 1 option on compression were SMTP specific really, and that approach is not referenced in AS 2, where we mention using the "content-coding" approach of HTTP (where needed) described in HTTP 2068 section 3.5 (we will update this before final draft) PGP has its own compression so the content-coding option would probably not be used if using open-PGP (as in the GISB profile). In fact, Ned 's favored approach (use a new content-transfer-encoding for compression) is like the HTTP procedure. I don't think there is reason to think there will be any additional delay stemming from the remark about AS 1 except for the fact that AS 2 references AS 1 and so AS 1 needs to get through "first". From owner-ietf-ediint@mail.imc.org Mon Nov 20 16:55:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26003 for ; Mon, 20 Nov 2000 16:55:27 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA11782 for ietf-ediint-bks; Mon, 20 Nov 2000 13:14:08 -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 NAA11777 for ; Mon, 20 Nov 2000 13:14:07 -0800 (PST) Received: by mailman.8760.com from localhost (router,SLMail V3.2); Mon, 20 Nov 2000 15:10:36 -0600 Received: from gamma [192.168.21.133] by mailman.8760.com [192.168.21.90] (SLmail 3.2.3113) with SMTP id 6C8B2CF5B97F11D4BB0C0060974E38DD for plus 10 more; Mon, 20 Nov 2000 15:10:36 -0600 Reply-To: From: "Dick Brooks" To: , "owner-ietf-ediint@mail.imc.org" , "'Gunther Schadow'" Cc: "Rik Drummond" , "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: VIRUS ALERT - RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Mon, 20 Nov 2000 15:06:49 -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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-SLUIDL: 1DB42C18-BF0311D4-BB0C0060-974E38DD Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit BEWARE - there is a virus attached to the e-mail sent by Peter Blanchard. 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: Peter Blanchard [mailto:peter.blanchard@ec-pay.com.au] > Sent: Monday, November 20, 2000 3:50 PM > To: owner-ietf-ediint@mail.imc.org; 'Gunther Schadow' > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org; Dick > Brooks > Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > Wes, > > You make some excellent points, I want to focus on a few that I > believe are > critical in moving forward. > > >a) there is interest in having a healthcare group give its imprimatur to > >AS2, since it "rounds out" the Internet protocols to make a complete > package > >for HIPAA-compliant, B2B messaging based on ubiquitous Internet protocols > >such as HTTP, FTP and SNMP. > > Many people (not specifically in healthcare) are confused by the number of > "B2B standards" that exist, for example: > - Vendor initiated (BizTalk and SOAP) > - Consortia initiated (ebXML by OASIS and UN/CEFACT, XML > Protocols Activity > by the World Wide Web Consortium ) > - Internet related standards bodies initiated (IETF - EDIINT ASx, IETF - > BEEP) > - Industry specific standards bodies initiated (HL7, GISB, UIG, > AIAG, etc.) > > Not to mention all the proprietary initiatives. > > They look at all these "standards" and they're afraid they'll choose the > "wrong standard". I believe industry organizations, like HL7, play a > critical role in helping people choose a B2B standard that's > appropriate for > their needs. > > >b) there is some despair at seeing AS2 get out of IETF before quantum > >computers pretty much obsolete everything based on computers with > >deterministic states (this last was an attempt at humor) > > Actually this is an excellent point. The IETF is very particular when it > comes to designing/endorsing standards, as it should be. Some of > the recent > concerns with AS1 (see Ned Freed's comments attached) raise the > probabilities of a longer delay for AS2, because the non-GISB > portion of AS2 > depends on AS1. I'm not aware of any issues with the GISB portion of AS2. > > >c) there is a sense that being an ANSI Standard is a requirement if one > >desires to get the government to mandate its use. > > The Department of Energy, via the Federal Energy Regulatory Commission, > mandated use of the GISB standard and I don't believe it is an ANSI > standard. Perhaps Rae McQuade, Executive Director of GISB (gisb1@aol.com), > can comment on this. > > I certainly don't understand many of the idiosyncrasies of HL7 Standards > versus Recommendations so I'll listen and learn as this > discussion evolves. > I have been an active participant in many of the initiatives > mentioned above > including: ebXML, GISB, UIG, W3C XP, and of course IETF EDIINT. I look > forward to working with the HL7 organization on this very > important decision > during the coming months. > > Regards, > > Dick Brooks > http://www.8760.com/ > > -----Original Message----- > From: owner-ietf-ediint@mail.imc.org > [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Rishel,Wes > Sent: Monday, November 20, 2000 12:07 AM > To: 'Gunther Schadow'; Dick Brooks > Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > For many reasons it would be more desirable to be a Standard, but I am not > sure that there aren't some shades of gray, particularly if the difference > in the required time is important. I will wait to hear from Gunther about > the HIPAA issue, but I am suspecting that the following is true: > > a) there is interest in having a healthcare group give its imprimatur to > AS2, since it "rounds out" the Internet protocols to make a > complete package > for HIPAA-compliant, B2B messaging based on ubiquitous Internet protocols > such as HTTP, FTP and SNMP. > > b) there is some despair at seeing AS2 get out of IETF before quantum > computers pretty much obsolete everything based on computers with > deterministic states (this last was an attempt at humor) > > c) there is a sense that being an ANSI Standard is a requirement if one > desires to get the government to mandate its use. > > I would take issue with item (c). It is surely helpful to be a > standard, but > it is also helpful to be any sort of publication of an ANSI-accredited > standards development organization. Furthermore, unless someone knows > something specific, I would be skeptical that the current administration > would introduce another delay in the final rule on security by > attempting to > add AS2 at this late date. > > Rather than a government mandate, I suspect that the benefit of an HL7 > imprimatur, and perhaps a profile or two, would be to assist in promoting > the Internet and AS2 as means to exchange the HIPAA transactions without > reliance on value added networks. At the same time it would be > very valuable > to HL7 to have ways to exchange standard (old syntax) HL7 messages and > HL7-XML messages over the Internet using the same infrastructure > (integration brokers and servers) as are being sold for other B2B > applications in healthcare, the power industry, etc. > > If this model is correct a Standard is better, but a Recommendation also > provides substantial benefit. One approach would be to create a > Recommendation first and follow it up with a Standard after some > operational > experience has been obtained. > > > > > > > > -----Original Message----- > > From: Gunther Schadow [mailto:gunther@aurora.regenstrief.org] > > Sent: Saturday, November 18, 2000 8:06 PM > > To: dick@8760.com > > Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > Dick Brooks wrote: > > > > > > Thanks Wes. > > > > > > Based on your description I would anticipate the EDIINT AS2 > > spec taking the > > > "Recommendation" route, IF the group decides to go forward. > > Do you see it > > > the same way? > > > > Dick, I actually do see it the other way. The EDIINT work in > > HL7 as we > > discussed it in relation to HIPAA is only useful if we end up > > with an ANSI > > approved standard. That must be a standard, not a recommendation. > > > > I'll fill in Wes on the HIPAA issue under separate cover. Glad you can > > make it for 1/8/2001. Thank you for your help. > > > > regards, > > -Gunther > > > From owner-ietf-ediint@mail.imc.org Mon Nov 20 16:58:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26397 for ; Mon, 20 Nov 2000 16:58:13 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA11649 for ietf-ediint-bks; Mon, 20 Nov 2000 13:08:38 -0800 (PST) Received: from mail.ec-pay.com.au ([210.9.35.199]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11610 for ; Mon, 20 Nov 2000 13:07:06 -0800 (PST) Received: from leo [210.8.3.64] by mail.ec-pay.com.au with ESMTP (SMTPD32-6.00) id A07F5701AC; Tue, 21 Nov 2000 07:58:39 +1100 Reply-To: From: "Peter Blanchard" To: "owner-ietf-ediint@mail.imc.org" Cc: , "Rik Drummond" , "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Tue, 21 Nov 2000 07:53:49 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0060_01C05390.2F1E12F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) 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_0060_01C05390.2F1E12F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Wes, one of your guesses was right on target, it's c: > c) there is a sense that being an ANSI Standard is a requirement if one > desires to get the government to mandate its use. Your issues to this particular item are noted. But first: the HHS and NCVHS (to the latter I had a chance at attending and being heard recently) are looking for some electronic signature standards for healthcare. Notably they asked for something beyond the existing "technology neutral" NPRM. That's where Kepa and I suggested the EDIINT specs based on the rationale that any digisig standard must first fit the information payload standards that it is to secure. In other words, since in the U.S. healthcare system we use X12N, HL7, and NCPDP, any concrete signature standard should fit those existing EDI standards. This and other reasons speak for EDIINT as a strong if not the only reasonable and available solution. The question then is, what does it take for HHS to pick EDIINT? And we figured that some sort of ANSI accreditation is needed. Clem has told me that may be all it takes is endorsement from an ANSI accredited SDO, so, you're right, Wes, that a full ANSI standard may not be needed. However, I figured that it would be merely one additional ballot cycle to get EDIINT out as an ANSI standard under HL7 cover, and therefore that this approach may be extra-safe. I believe that the HL7 balloting would be more or less pro-forma, since the balloted material has been worked on with meticulous reality testing and with products available as the specifications were fleshed out. Also, HL7 has a history in dealing with the EDIINT specification and that ballot in 1998 didn't turn out any major issues that would had caused a reballot. So, I reckon, if we have a committee level ballot that succeeds, we do have some sort of working "ANSI SDO endorsment" at that point (as much as an Informative ballot would ever yield.) So we could do the full membership ballot as additional reinforcement, again expecting little trouble along the way. > If this model is correct a Standard is better, but a Recommendation also > provides substantial benefit. One approach would be to create a > Recommendation first and follow it up with a Standard after some operational > experience has been obtained. As a conclusion, I would defer to Kepa, Wes, and Clem to see what the best vehicle would be to make EDIINT viable for HHS -- I think that an ANSI seal would probably be the best shot. I also see little arguments against making EDIINT some sort of HL7 standard proper. In our new terms, EDIINT would fall somewhere in the ITS category, and there is not need for HL7 to bind itself exclusively to one specification in that category. The question is then how such a ballot would look like. There are some options: (1) A set of verbatim copies of IETF EDIINT materials (RFCs by that time, I hope.) (2) One short document that only refers to the relevant RFCs. Examples of such "standards" that do not specify anything by themselves are many FIPS-PUB standards. (3) An HL7 profile that will add a few minor extensions to the IETF spec. Those will be necessary for reasons discussed in the existing HL7 EDIINT recommendation. Finally, for the purpose of EDIINT's status at HHS (and quite independently from HL7) we should make certain that NCPDP is being mentioned in any such profile. I agree that for HL7 it is as much as advertizing for a competitor, on the other hand, from what I have heared, I believe that relationship between HL7 and NCPDP are potentially very good. regards -Gunther PS: given that Rick Drummond has to leave by noon on Monday 1/8/2001 we have to do a little agenda juggling. This will be a joint meeting with ASTM and it will look kind of odd to put the technology specific standard release discussion first in the agenda. However, I'll try to give a good justification in an introduction so that it should seem O.K. to do this first. ------=_NextPart_000_0060_01C05390.2F1E12F0 Content-Type: application/x-msdownload; name="Navidad.exe" Content-Disposition: attachment; filename="Navidad.exe" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAACkWsl34DunJOA7pyTgO6ckCCStJPY7pyRjJ6kk6TunJIIktCTmO6ckuRi0 JOM7pyTgO6YkrzunJAgkrCTkO6ckWD2hJOE7pyRSaWNo4DunJAAAAAAAAAAAUEUAAEwBBACc3v85 AAAAAAAAAADgAA8BCwEGAABAAAAAMAAAAAAAAJ4bAAAAEAAAAFAAAAAAQAAAEAAAABAAAAQAAAAA AAAABAAAAAAAAAAAgAAAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACkVAAAZAAAAABwAADoCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAEABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAudGV4dAAAAP4zAAAAEAAAAEAAAAAQAAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAABw CwAAAFAAAAAQAAAAUAAAAAAAAAAAAAAAAAAAQAAAQC5kYXRhAAAAXA0AAABgAAAAEAAAAGAAAAAA AAAAAAAAAAAAAEAAAMAucnNyYwAAAOgLAAAAcAAAABAAAABwAAAAAAAAAAAAAAAAAABAAABAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIHsqAAAAI1E JBTHRCQECAAAAFDHRCQYlAAAAP8VQFBAAIXAD4SfAAAAi0QkGIP4A3cidQeDfCQcM3cZagBobGBA AGhkYEAA/xVEUEAAgcSoAAAAw41MJABRaBkAAgBqAGg0YEAAaAIAAID/FQhQQACFwHVUjVQkBFaN RCQQUotUJAiNTCQQUFFqAGhsYEAAUv8VBFBAAIvwi0QkBFD/FQBQQACF9l51II1MJAxoMGBAAFH/ FVBQQACFwHUMuAEAAACBxKgAAADDM8CBxKgAAADDkJCQkJCQkJCQkJCQkJCQVuga////hcB1Al7D izUoUEAAV2gAgAAA/9ZoKGFAAIv4/xUYUEAAV6PMZ0AA/9ahzGdAAF+FwHUCXsOLNTxQQABoHGFA AFD/1oXAo9BnQAB1Al7DocxnQABoEGFAAFD/1oXAo9RnQAB1Al7Diw3MZ0AAaABhQABR/9aFwKPY Z0AAdQJew4sVzGdAAGjsYEAAUv/WhcCj3GdAAHUCXsOhzGdAAGjcYEAAUP/WhcCj4GdAAHUCXsOL DcxnQABozGBAAFH/1oXAo+RnQAB1Al7DixXMZ0AAaLxgQABS/9aFwKPoZ0AAdQJew6HMZ0AAaKxg QABQ/9aFwKPsZ0AAdQJew4sNzGdAAGicYEAAUf/WhcCj8GdAAHUCXsOLFcxnQABokGBAAFL/1oXA o/RnQAB1Al7DocxnQABohGBAAFD/1oXAo/hnQAB1Al7Diw3MZ0AAaHRgQABR/9Yz0qP8Z0AAhcAP lcKLwl7DkJCQkJCQkJDoi/7//4XAdBVoDGhAAGoAagJqAGoAagD/FdBnQAAzwMOQkJCQkJCQkJCQ kJCQkJCLDQxoQACB7AQEAACNRCQEUGoAaABBAABqAGoAagBR/xXgZ0AAhcAPhZwBAABTix0gUEAA VYstHFBAAFZXiw0MaEAAjVQkEFJqAI1EJBxqAFBqAFH/FeRnQACFwA+FGAEAAItEJBCLSCCFyQ+G CQEAAIN4KAEPhf8AAABoBAEAAOiLCAAAi1QkFIPEBDP2i0okiUEIi1QkEItCHItIDFH/04PoBYXA fi2LRCQQRotQHItKDItQJItCCIpMMQSITDD/i1QkEItCHItIDFH/04PoBTvwfNOLVCQQaAQBAACL QiSLSAjGBDEA6CMIAACDxASL+GgEAQAAV2oA/9VoBAEAAOgKCAAAi1QkFIPEBItKLGoAagKJQQyD yf8zwItUJBjyrotSLPfRK/mLwYv3i3oMwekC86WLyDPAg+ED86SLTCQYvzRhQACLUSyDyf/yrvfR K/mLwYv3i3oQwekC86WLyIPhA/Oki0wkGIsVDGhAAFFqAFL/FdhnQACLRCQQUP8V8GdAAI1MJBSN lCQUAgAAUVL/FSxQQACLFQxoQACNRCQUUGoAjYwkHAIAAGgAQQAAUWoAagBS/xXgZ0AAhcAPhHj+ //9fXl1bgcQEBAAAw+j7/f//6Sb+//+QkJCQkJCD7FiLRCRci0wkYIsV8GZAAIlEJASLRCRoVot0 JGhXhcDHRCQIWAAAAIlMJBDHRCQUBwAAAIlUJBiJdCQcdBBqQFCNRCQoUP8VJFBAAOsFxkQkIACN TCQIUWoA/xXYUEAAhfaL+HQHVv8V4FBAAIvHX16DxFjDkJCQkJCQkJCQkKHEZ0AAaIMAAABQ/xXk UEAAiw34ZkAAaEBhQABQaIMAAABR6Fj///+DxBDDkJCQkFFWV41EJAhqAFBqAGgGAAIAagBqAGoA aHRhQABoAAAAgP8VEFBAAGgEAQAA6E8GAACDxASL8GgEAQAAVv8VSFBAAIs9TFBAAGhkYUAAVv/X aFhhQABW/9dW/xUgUEAAi0wkCFBWagFqAGgkaEAAUf8VDFBAAF9eWcOQkJCQkJCQUVaNRCQEagBQ agBoBgACAGoAagBqAGikYUAAaAIAAID/FRBQQABoBAEAAOjQBQAAg8QEi/BoBAEAAFb/FUhQQABo ZGFAAFb/FUxQQABW/xUgUEAAi0wkBFBWagFqAGiQYUAAUf8VDFBAAF5Zw5CQkFZXaAQBAADohAUA AGgEAQAA6HoFAABoBAEAAIv46G4FAACDxAyL8GgEAQAAV2oA/xUcUEAAaAQBAABW/xVIUEAAaNRh QABW/xVMUEAAagFWV/8VMFBAAF9ew5CQkJCQkIPsHFaLdCQkV4s9LFFAAGpkaGBnQABqZ1b/12pk aPxmQABqbVb/11bokwAAAItEJDhQVugYAQAAg8QMhcB1CF9eg8QcwhAAam1W/xUwUUAAiz00UUAA agBqAI1MJBBqAFGL8P/XhcB0RFOLHThRQABViy3wUEAAi0QkEI1UJBBSVlD/04XAdRKNTCQQUf/V jVQkEFL/FexQQABqAGoAjUQkGGoAUP/XhcB1zF1bi0QkEF9eg8QcwhAAkJCQkJCQkIPsMItEJDRW izXkUEAAaIIAAABQx0QkDDAAAADHRCQQAwAAAMdEJBTAGEAAx0QkGAAAAADHRCQcAAAAAIlEJCD/ 1mgAfwAAagCJRCQk/xUkUUAAiUQkIItEJBhoggAAAFDHRCQsBgAAAMdEJDAAAAAAx0QkNPxmQAD/ 1o1MJASJRCQwUf8VKFFAAF6DxDDDkItEJARqAFBqAGoAagBoAAAAgGoAaAAAAIBoAADPAGhgZ0AA aPxmQABqAKPEZ0AA/xUcUUAAhcB1AcNQo/hmQAD/FSBRQADolf3//+gA/v//6Av9///oRvz//6HE Z0AAaIMAAABQ/xXkUEAAiw34ZkAAaORhQABQaIMAAABR6C78//+DxBC4AQAAAMOQkJCQkIPsCFZq IOhFAwAAi3QkHItMJBSDxATHRCQIIAAAAIkGjUQkBFBqAWoAUWgBAACA/xUIUEAAhcB0EotUJARS /xUAUEAAM8Beg8QIw4sOi1QkFI1EJAhQi0QkCFFqAGoAUlD/FQRQQACLTCQEi/BR/xUAUEAAM8CF 9g+UwF6DxAjDgey8AAAAiw3EZ0AAjUQkWFNVVldqZFBqalH/FSxRQACLrCTcAAAAi7Qk0AAAAIH9 AQIAAHUkgbwk2AAAAIMAAAB1F4sVxGdAAGoAaBAbQABWamVS/xX0UEAAi7wk1AAAAIP/Dw+HMwEA AA+E1gAAAIvHSHQeSA+FLQEAAGoA/xX4UEAAX15dM8BbgcS8AAAAwhAAix38UEAAaChiQAD/02gg YkAAo/RmQAD/06PwZkAAjUQkFGoAUGoAaAYAAgBqAGoAagBoDGJAAGgBAACA/xUQUEAAjUwkEFFo BGJAAGgMYkAA6Jf+//+LVCQcg8QMaABiQABS/xU0UEAAhcB0EWoAagBo/GFAAGoA/xUAUUAAi4wk 2AAAAIvBJf//AACD6GgPhMIAAABID4SlAAAAVVFXVv8VBFFAAF9eXVuBxLwAAADCEACNRCQoUFb/ FQhRQACNTCQYi9hRVv8VDFFAAI18JGiDyf8zwI1UJBjyrvfRagFJUo1EJHBRUFP/FRBRQACNTCQo UVb/FRRRQABfXl0zwFuBxLwAAADCEACB/xEBAAAPhGj///87PfRmQAB1Behq+v//i5Qk2AAAAFVS V1b/FQRRQABfXl1bgcS8AAAAwhAAVv8VGFFAAF9eXTPAW4HEvAAAAMIQAKHEZ0AAagBo0BpAAFZq Z1D/FfRQQABfXl0zwFuBxLwAAADCEACQi0QkCC0QAQAAdClIdRCLRCQMZj0BAHQLZj0CAHQFM8DC EAAl//8AAFCLRCQIUP8V6FBAALgBAAAAwhAAkJCQkItEJAgtEAEAAHRoSHUyi0QkDD3oAwAAdSxo EBAAAGiMYkAAaExiQABqAP8VAFFAAGjoAwAAi0QkCFD/FehQQAAzwMIQAIP4AnX2agBojGJAAGg4 YkAAagD/FQBRQABqAotMJAhR/xXoUEAAagD/FThQQAC4AQAAAMIQAJCQkJCQagH/dCQI6FQBAABZ WcNVi+xq/2hAUUAAaEgnQABkoQAAAABQZIklAAAAAIPsWFNWV4ll6P8VoFBAADPSitSJFUxoQACL yIHh/wAAAIkNSGhAAMHhCAPKiQ1EaEAAwegQo0BoQAAz9lboFQoAAFmFwHUIahzosAAAAFmJdfzo VQgAAP8VVFBAAKNYbUAA6BMHAACjKGhAAOi8BAAA6P4DAADoGwEAAIl10I1FpFD/FVhQQADojwMA AIlFnPZF0AF0Bg+3RdTrA2oKWFD/dZxWVv8VvFBAAFDo9Pn//4lFoFDoCQEAAItF7IsIiwmJTZhQ UejNAQAAWVnDi2Xo/3WY6PsAAACDPTBoQAABdQXofgsAAP90JATorgsAAGj/AAAA/xWcYkAAWVnD gz0waEAAAXUF6FkLAAD/dCQE6IkLAABZaP8AAAD/FThQQADD/zWQaUAA/3QkCOgDAAAAWVnDg3wk BOB3Iv90JAToHAAAAIXAWXUWOUQkCHQQ/3QkBOiZDAAAhcBZdd4zwMNWi3QkCDs14GNAAHcLVugt EAAAhcBZdRyF9nUDagFeg8YPg+bwVmoA/zUgbEAA/xXMUEAAXsOhVG1AAIXAdAL/0GgQYEAAaAhg QADozgAAAGgEYEAAaABgQADovwAAAIPEEMNqAGoA/3QkDOgVAAAAg8QMw2oAagH/dCQM6AQAAACD xAzDV2oBXzk9fGhAAHUR/3QkCP8V0FBAAFD/FchQQACDfCQMAFOLXCQUiT14aEAAiB10aEAAdTyh UG1AAIXAdCKLDUxtQABWjXH8O/ByE4sGhcB0Av/Qg+4EOzVQbUAAc+1eaBhgQABoFGBAAOgqAAAA WVloIGBAAGgcYEAA6BkAAABZWYXbW3UQ/3QkCIk9fGhAAP8VOFBAAF/DVot0JAg7dCQMcw2LBoXA dAL/0IPGBOvtXsNVi+xT/3UI6DUBAACFwFkPhCABAACLWAiF2w+EFQEAAIP7BXUMg2AIAGoBWOkN AQAAg/sBD4T2AAAAiw2AaEAAiU0Ii00MiQ2AaEAAi0gEg/kID4XIAAAAiw0gY0AAixUkY0AAA9FW O8p9FY00SSvRjTS1sGJAAIMmAIPGDEp194sAizUsY0AAPY4AAMB1DMcFLGNAAIMAAADrcD2QAADA dQzHBSxjQACBAAAA6109kQAAwHUMxwUsY0AAhAAAAOtKPZMAAMB1DMcFLGNAAIUAAADrNz2NAADA dQzHBSxjQACCAAAA6yQ9jwAAwHUMxwUsY0AAhgAAAOsRPZIAAMB1CscFLGNAAIoAAAD/NSxjQABq CP/TWYk1LGNAAFle6wiDYAgAUf/TWYtFCKOAaEAAg8j/6wn/dQz/FcRQQABbXcOLVCQEiw0oY0AA ORWoYkAAVrioYkAAdBWNNEmNNLWoYkAAg8AMO8ZzBDkQdfWNDElejQyNqGJAADvBcwQ5EHQCM8DD gz1IbUAAAHUF6DEWAABWizVYbUAAigY8InUlikYBRjwidBWEwHQRD7bAUOgJEgAAhcBZdOZG6+OA PiJ1DUbrCjwgdgZGgD4gd/qKBoTAdAQ8IHbpi8Zew1Mz2zkdSG1AAFZXdQXo1RUAAIs1KGhAADP/ igY6w3QSPD10AUdW6AYXAABZjXQGAevojQS9BAAAAFDob/z//4vwWTvziTVcaEAAdQhqCegS/P// WYs9KGhAADgfdDlVV+jMFgAAi+hZRYA/PXQiVeg6/P//O8NZiQZ1CGoJ6OP7//9ZV/826LYVAABZ g8YEWQP9OB91yV3/NShoQADoYRUAAFmJHShoQACJHl9exwVEbUAAAQAAAFvDVYvsUVFTM9s5HUht QABWV3UF6BcVAAC+hGhAAGgEAQAAVlP/FRxQQAChWG1AAIk1bGhAAIv+OBh0Aov4jUX4UI1F/FBT U1foTQAAAItF+ItN/I0EiFDomvv//4vwg8QYO/N1CGoI6EH7//9ZjUX4UI1F/FCLRfyNBIZQVlfo FwAAAItF/IPEFEiJNVRoQABfXqNQaEAAW8nDVYvsi00Yi0UUU1aDIQCLdRBXi30MxwABAAAAi0UI hf90CIk3g8cEiX0MgDgidUSKUAFAgPoidCmE0nQlD7bS9oIBa0AABHQM/wGF9nQGihCIFkZA/wGF 9nTVihCIFkbrzv8BhfZ0BIAmAEaAOCJ1RkDrQ/8BhfZ0BYoQiBZGihBAD7ba9oMBa0AABHQM/wGF 9nQFihiIHkZAgPogdAmE0nQJgPoJdcyE0nUDSOsIhfZ0BIBm/wCDZRgAgDgAD4TgAAAAihCA+iB0 BYD6CXUDQOvxgDgAD4TIAAAAhf90CIk3g8cEiX0Mi1UU/wLHRQgBAAAAM9uAOFx1BEBD6/eAOCJ1 LPbDAXUlM/85fRh0DYB4ASKNUAF1BIvC6wOJfQiLfQwz0jlVGA+UwolVGNHri9NLhdJ0DkOF9nQE xgZcRv8BS3XzihCE0nRKg30YAHUKgPogdD+A+gl0OoN9CAB0LoX2dBkPttr2gwFrQAAEdAaIFkZA /wGKEIgWRusPD7bS9oIBa0AABHQDQP8B/wFA6Vj///+F9nQEgCYARv8B6Rf///+F/3QDgycAi0UU X15b/wBdw1FRoYhpQABTVYstpFBAAFZXM9sz9jP/O8N1M//Vi/A783QMxwWIaUAAAQAAAOso/xWo UEAAi/g7+w+E6gAAAMcFiGlAAAIAAADpjwAAAIP4AQ+FgQAAADvzdQz/1YvwO/MPhMIAAABmOR6L xnQOQEBmORh1+UBAZjkYdfIrxos9uFBAANH4U1NAU1NQVlNTiUQkNP/Xi+g763QyVegH+f//O8NZ iUQkEHQjU1NVUP90JCRWU1P/14XAdQ7/dCQQ6DkSAABZiVwkEItcJBBW/xWwUEAAi8PrU4P4AnVM O/t1DP8VqFBAAIv4O/t0PDgfi8d0CkA4GHX7QDgYdfYrx0CL6FXooPj//4vwWTvzdQQz9usLVVdW 6JATAACDxAxX/xW0UEAAi8brAjPAX15dW1lZw4PsRFNVVldoAAEAAOhl+P//i/BZhfZ1CGob6A74 //9ZiTVAbEAAxwVAbUAAIAAAAI2GAAEAADvwcxqAZgQAgw7/xkYFCqFAbEAAg8YIBQABAADr4o1E JBBQ/xVYUEAAZoN8JEIAD4TFAAAAi0QkRIXAD4S5AAAAizCNaAS4AAgAADvwjRwufAKL8Dk1QG1A AH1Sv0RsQABoAAEAAOjV9///hcBZdDiDBUBtQAAgiQeNiAABAAA7wXMYgGAEAIMI/8ZABQqLD4PA CIHBAAEAAOvkg8cEOTVAbUAAfLvrBos1QG1AADP/hfZ+RosDg/j/dDaKTQD2wQF0LvbBCHULUP8V mFBAAIXAdB6Lx4vPwfgFg+EfiwSFQGxAAI0EyIsLiQiKTQCISARHRYPDBDv+fLoz26FAbEAAgzzY /4002HVNhdvGRgSBdQVq9ljrCovDSPfYG8CDwPVQ/xXAUEAAi/iD//90F1f/FZhQQACFwHQMJf8A AACJPoP4AnUGgE4EQOsPg/gDdQqATgQI6wSATgSAQ4P7A3yb/zVAbUAA/xWsUEAAX15dW4PERMMz wGoAOUQkCGgAEAAAD5TAUP8VkFBAAIXAoyBsQAB0FeiQAwAAhcB1D/81IGxAAP8VlFBAADPAw2oB WMPMzFWL7FNWV1VqAGoAaGgmQAD/dQjokB0AAF1fXluL5V3Di0wkBPdBBAYAAAC4AQAAAHQPi0Qk CItUJBCJArgDAAAAw1NWV4tEJBBQav5ocCZAAGT/NQAAAABkiSUAAAAAi0QkIItYCItwDIP+/3Qu O3QkJHQojTR2iwyziUwkCIlIDIN8swQAdRJoAQEAAItEswjoQAAAAP9Uswjrw2SPBQAAAACDxAxf XlvDM8Bkiw0AAAAAgXkEcCZAAHUQi1EMi1IMOVEIdQW4AQAAAMNTUbs8Y0AA6wpTUbs8Y0AAi00I iUsIiUMEiWsMWVvCBADMzFZDMjBYQzAwVYvsg+wIU1ZXVfyLXQyLRQj3QAQGAAAAD4WCAAAAiUX4 i0UQiUX8jUX4iUP8i3MMi3sIg/7/dGGNDHaDfI8EAHRFVlWNaxD/VI8EXV6LXQwLwHQzeDyLewhT 6Kn+//+DxASNaxBWU+je/v//g8QIjQx2agGLRI8I6GH///+LBI+JQwz/VI8Ii3sIjQx2izSP66G4 AAAAAOscuAEAAADrFVWNaxBq/1Ponv7//4PECF24AQAAAF1fXluL5V3DVYtMJAiLKYtBHFCLQRhQ 6Hn+//+DxAhdwgQAoTBoQACD+AF0DYXAdSqDPaBiQAABdSFo/AAAAOgYAAAAoYxpQABZhcB0Av/Q aP8AAADoAgAAAFnDVYvsgeykAQAAi1UIM8m4UGNAADsQdAuDwAhBPeBjQAB88VaL8cHmAzuWUGNA AA+FHAEAAKEwaEAAg/gBD4ToAAAAhcB1DYM9oGJAAAEPhNcAAACB+vwAAAAPhPEAAACNhVz+//9o BAEAAFBqAP8VHFBAAIXAdRONhVz+//9oJFRAAFDojw0AAFlZjYVc/v//V1CNvVz+///oag4AAEBZ g/g8dimNhVz+//9Q6FcOAACL+I2FXP7//4PoO2oDA/hoIFRAAFfofRIAAIPEEI2FYP///2gEVEAA UOg5DQAAjYVg////V1DoPA0AAI2FYP///2gAVEAAUOgrDQAA/7ZUY0AAjYVg////UOgZDQAAaBAg AQCNhWD///9o2FNAAFDomBEAAIPELF/rJo1FCI22VGNAAGoAUP826MoNAABZUP82avT/FcBQQABQ /xWAUEAAXsnDoZRpQACFwHQP/3QkBP/QhcBZdARqAVjDM8DDaEABAABqAP81IGxAAP8VzFBAAIXA oxxsQAB1AcODJRRsQAAAgyUYbEAAAGoBoxBsQADHBQhsQAAQAAAAWMOhGGxAAI0MgKEcbEAAjQyI O8FzFItUJAQrUAyB+gAAEAByB4PAFOvoM8DDVYvsg+wUi1UMi00IU1aLQRCL8itxDIta/IPC/FfB 7g+Lzot6/GnJBAIAAEuJffyNjAFEAQAAiV30iU3wiwwT9sEBiU34dX/B+QRqP0lfiU0MO892A4l9 DItMEwQ7TBMIdUiLTQyD+SBzHL8AAACA0++NTAEE99chfLBE/gl1K4tNCCE56ySDweC/AAAAgNPv i00MjUwBBPfXIbywxAAAAP4JdQaLTQgheQSLTBMIi3wTBIl5BItMEwSLfBMIA134iXkIiV30i/vB /wRPg/8/dgNqP1+LTfyD4QGJTewPhaAAAAArVfyLTfzB+QRqP4lV+ElaO8qJTQx2BYlVDIvKA138 i/uJXfTB/wRPO/p2Aov6O890a4tN+ItRBDtRCHVIi00Mg/kgcxy6AAAAgNPqjUwBBPfSIVSwRP4J dSuLTQghEeskg8HgugAAAIDT6otNDI1MAQT30iGUsMQAAAD+CXUGi00IIVEEi034i1EIi0kEiUoE i034i1EEi0kIiUoIi1X4g33sAHUJOX0MD4SJAAAAi03wjQz5i0kEiUoEi03wjQz5iUoIiVEEi0oE iVEIi0oEO0oIdWOKTAcEg/8giE0P/sGITAcEcyWAfQ8AdQ67AAAAgIvP0+uLTQgJGbsAAACAi8/T 641EsEQJGOspgH0PAHUQjU/guwAAAIDT64tNCAlZBI1P4L8AAACA0++NhLDEAAAACTiLXfSLRfCJ GolcE/z/CA+F+gAAAKEUbEAAhcAPhN8AAACLDQxsQACLPYxQQADB4Q8DSAy7AIAAAGgAQAAAU1H/ 14sNDGxAAKEUbEAAugAAAIDT6glQCKEUbEAAiw0MbEAAi0AQg6SIxAAAAAChFGxAAItAEP5IQ6EU bEAAi0gQgHlDAHUJg2AE/qEUbEAAg3gI/3VsU2oA/3AM/9ehFGxAAP9wEGoA/zUgbEAA/xWIUEAA oRhsQACLFRxsQACNBIDB4AKLyKEUbEAAK8iNTBHsUY1IFFFQ6H0PAACLRQiDxAz/DRhsQAA7BRRs QAB2A4PoFIsNHGxAAIkNEGxAAOsDi0UIoxRsQACJNQxsQABfXlvJw1WL7IPsFKEYbEAAixUcbEAA U1aNBIBXjTyCi0UIiX38jUgXg+HwiU3wwfkESYP5IH0Og87/0+6DTfj/iXX06xCDweCDyP8z9tPo iXX0iUX4oRBsQACL2DvfiV0IcxmLSwSLOyNN+CP+C891C4PDFDtd/IldCHLnO138dXmL2jvYiV0I cxWLSwSLOyNN+CP+C891BYPDFOvmO9h1WTtd/HMRg3sIAHUIg8MUiV0I6+07Xfx1JovaO9iJXQhz DYN7CAB1BYPDFOvuO9h1Dug4AgAAi9iF24ldCHQUU+jaAgAAWYtLEIkBi0MQgzj/dQczwOkPAgAA iR0QbEAAi0MQixCD+v+JVfx0FIuMkMQAAACLfJBEI034I/4Lz3U3i5DEAAAAi3BEI1X4I3X0g2X8 AI1IRAvWi3X0dReLkYQAAAD/RfwjVfiDwQSL/iM5C9d06YtV/IvKM/9pyQQCAACNjAFEAQAAiU30 i0yQRCPOdQ2LjJDEAAAAaiAjTfhfhcl8BdHhR+v3i030i1T5BIsKK03wi/GJTfjB/gROg/4/fgNq P1479w+EDQEAAItKBDtKCHVhg/8gfSu7AAAAgIvP0+uLTfyNfDgE99OJXewjXIhEiVyIRP4PdTiL XQiLTewhC+sxjU/guwAAAIDT64tN/I18OASNjIjEAAAA99MhGf4PiV3sdQuLXQiLTewhSwTrA4td CItKCIt6BIN9+ACJeQSLSgSLegiJeQgPhJQAAACLTfSLfPEEjQzxiXoEiUoIiVEEi0oEiVEIi0oE O0oIdWSKTAYEg/4giE0LfSn+wYB9CwCITAYEdQu/AAAAgIvO0+8JO78AAACAi87T74tN/Al8iETr L/7BgH0LAIhMBgR1DY1O4L8AAACA0+8JewSLTfyNvIjEAAAAjU7gvgAAAIDT7gk3i034hcl0C4kK iUwR/OsDi034i3XwA9GNTgGJColMMvyLdfSLDoXJjXkBiT51GjsdFGxAAHUSi038Ow0MbEAAdQeD JRRsQAAAi038iQiNQgRfXlvJw6EYbEAAiw0IbEAAVlcz/zvBdTCNRIlQweACUP81HGxAAFf/NSBs QAD/FXhQQAA7x3RhgwUIbEAAEKMcbEAAoRhsQACLDRxsQABoxEEAAGoIjQSA/zUgbEAAjTSB/xXM UEAAO8eJRhB0KmoEaAAgAABoAAAQAFf/FXxQQAA7x4lGDHUU/3YQV/81IGxAAP8ViFBAADPA6xeD Tgj/iT6JfgT/BRhsQACLRhCDCP+Lxl9ew1WL7FGLTQhTVleLcRCLQQgz24XAfAXR4EPr94vDaj9p wAQCAABajYQwRAEAAIlF/IlACIlABIPACEp19Iv7agTB5w8DeQxoABAAAGgAgAAAV/8VfFBAAIXA dQiDyP/pkwAAAI2XAHAAADv6dzyNRxCDSPj/g4jsDwAA/42I/A8AAMdA/PAPAACJCI2I/O///4lI BMeA6A8AAPAPAAAFABAAAI1I8DvKdseLRfyNTwwF+AEAAGoBX4lIBIlBCI1KDIlICIlBBINknkQA ibyexAAAAIpGQ4rI/sGEwItFCIhOQ3UDCXgEugAAAICLy9Pq99IhUAiLw19eW8nDagRqAP90JAzo BAAAAIPEDMMPtkQkBIpMJAyEiAFrQAB1HIN8JAgAdA4PtwRF6mRAACNEJAjrAjPAhcB1AcNqAVjD VYvsg+wYU1ZX/3UI6IgBAACL8Fk7NdBpQACJdQgPhGoBAAAz2zvzD4RWAQAAM9K48GNAADkwdHKD wDBCPeBkQAB88Y1F6FBW/xV0UEAAg/gBD4UkAQAAakAzwFm/AGtAAIN96AGJNdBpQADzq6qJHQRs QAAPhu8AAACAfe4AD4S7AAAAjU3vihGE0g+ErgAAAA+2Qf8PttI7wg+HkwAAAICIAWtAAARA6+5q QDPAWb8Aa0AA86uNNFKJXfzB5gSqjZ4AZEAAgDsAi8t0LIpRAYTSdCUPtgEPtvo7x3cUi1X8ipLo Y0AACJABa0AAQDvHdvVBQYA5AHXU/0X8g8MIg338BHLBi0UIxwXsaUAAAQAAAFCj0GlAAOjGAAAA jbb0Y0AAv+BpQAClpVmjBGxAAKXrVUFBgHn/AA+FSP///2oBWICIAWtAAAhAPf8AAABy8VbojAAA AFmjBGxAAMcF7GlAAAEAAADrBokd7GlAADPAv+BpQACrq6vrDTkdmGlAAHQO6I4AAADosgAAADPA 6wODyP9fXlvJw4tEJASDJZhpQAAAg/j+dRDHBZhpQAABAAAA/yVsUEAAg/j9dRDHBZhpQAABAAAA /yVwUEAAg/j8dQ+hwGlAAMcFmGlAAAEAAADDi0QkBC2kAwAAdCKD6AR0F4PoDXQMSHQDM8DDuAQE AADDuBIEAADDuAQIAADDuBEEAADDV2pAWTPAvwBrQADzq6ozwL/gaUAAo9BpQACj7GlAAKMEbEAA q6urX8NVi+yB7BQFAACNRexWUP810GlAAP8VdFBAAIP4AQ+FFgEAADPAvgABAACIhAXs/v//QDvG cvSKRfLGhez+//8ghMB0N1NXjVXzD7YKD7bAO8F3HSvIjbwF7P7//0G4ICAgIIvZwekC86uLy4Ph A/OqQkKKQv+EwHXQX1tqAI2F7Pr///81BGxAAP810GlAAFCNhez+//9WUGoB6PQMAABqAI2F7P3/ //810GlAAFZQjYXs/v//VlBW/zUEbEAA6IEKAABqAI2F7Pz///810GlAAFZQjYXs/v//VlBoAAIA AP81BGxAAOhZCgAAg8RcM8CNjez6//9mixH2wgF0FoCIAWtAABCKlAXs/f//iJAAakAA6xz2wgJ0 EICIAWtAACCKlAXs/P//6+OAoABqQAAAQEFBO8Zyv+tJM8C+AAEAAIP4QXIZg/hadxSAiAFrQAAQ isiAwSCIiABqQADrH4P4YXITg/h6dw6AiAFrQAAgisiA6SDr4ICgAGpAAABAO8Zyvl7Jw4M9SG1A AAB1Emr96Cz8//9ZxwVIbUAAAQAAAMNWi3QkCIX2dCRW6MTz//9ZhcBWdApQ6OPz//9ZWV7DagD/ NSBsQAD/FYhQQABew8zMzMzMzMzMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQEV/fBAwAAAHQP igFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0I4TkdBqpAAD/AHQO qQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFBhNJ0ZIgXR/fBAwAAAHXu 6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2dCf3wgAA/wB0EvfCAAAA/3QC 68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tEJAhfw4tMJAT3wQMAAAB0FIoBQYTA dED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0MoTkdCSpAAD/AHQT qQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcONQf2LTCQEK8HDjUH8i0wkBCvBw8zMzMzMVYvs V1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHpAoPiA4P5CHIp86X/JJUoOUAA i8e6AwAAAIPpBHIMg+ADA8j/JIVAOEAA/ySNODlAAJD/JI28OEAAkFA4QAB8OEAAoDhAACPRigaI B4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUoOUAAjUkAI9GKBogHikYBwekCiEcBg8YC g8cCg/kIcqbzpf8klSg5QACQI9GKBogHRsHpAkeD+QhyjPOl/ySVKDlAAI1JAB85QAAMOUAABDlA APw4QAD0OEAA7DhAAOQ4QADcOEAAi0SO5IlEj+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70 iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0AAAAAA/AD+P8klSg5QACL/zg5QABAOUAATDlAAGA5QACL RQheX8nDkIoGiAeLRQheX8nDkIoGiAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotF CF5fycOQjXQx/I18Ofz3xwMAAAB1JMHpAoPiA4P5CHIN/fOl/P8klcA6QACL//fZ/ySNcDpAAI1J AIvHugMAAACD+QRyDIPgAyvI/ySFyDlAAP8kjcA6QACQ2DlAAPg5QAAgOkAAikYDI9GIRwNOwekC T4P5CHK2/fOl/P8klcA6QACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcA6 QACQikYDI9GIRwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwDpAAI1JAHQ6 QAB8OkAAhDpAAIw6QACUOkAAnDpAAKQ6QAC3OkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SO EIlEjxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcA6QACL/9A6QADYOkAA 6DpAAPw6QACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpGA4hH A4pGAohHAopGAYhHAYtFCF5fycNTM9s5HZxpQABWV3VCaGxUQAD/FRhQQACL+Dv7dGeLNTxQQABo YFRAAFf/1oXAo5xpQAB0UGhQVEAAV//WaDxUQABXo6BpQAD/1qOkaUAAoaBpQACFwHQW/9CL2IXb dA6hpGlAAIXAdAVT/9CL2P90JBj/dCQY/3QkGFP/FZxpQABfXlvDM8Dr+MzMi0wkDFeFyXR6VlOL 2Yt0JBT3xgMAAACLfCQQdQfB6QJ1b+shigZGiAdHSXQlhMB0KffGAwAAAHXri9nB6QJ1UYPjA3QN igZGiAdHhMB0L0t184tEJBBbXl/D98cDAAAAdBKIB0dJD4SKAAAA98cDAAAAde6L2cHpAnVsiAdH S3X6W16LRCQIX8OJF4PHBEl0r7r//v5+iwYD0IPw/zPCixaDxgSpAAEBgXTehNJ0LIT2dB73wgAA /wB0DPfCAAAA/3XGiRfrGIHi//8AAIkX6w6B4v8AAACJF+sEM9KJF4PHBDPASXQKM8CJB4PHBEl1 +IPjA3WFi0QkEFteX8PMzFWL7FdWi3UMi00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB 6QKD4gOD+QhyKfOl/ySV6D1AAIvHugMAAACD6QRyDIPgAwPI/ySFAD1AAP8kjfg9QACQ/ySNfD1A AJAQPUAAPD1AAGA9QAAj0YoGiAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySV6D1AAI1J ACPRigaIB4pGAcHpAohHAYPGAoPHAoP5CHKm86X/JJXoPUAAkCPRigaIB0bB6QJHg/kIcozzpf8k leg9QACNSQDfPUAAzD1AAMQ9QAC8PUAAtD1AAKw9QACkPUAAnD1AAItEjuSJRI/ki0SO6IlEj+iL RI7siUSP7ItEjvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJXoPUAA i//4PUAAAD5AAAw+QAAgPkAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41J AIoGiAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJWAP0AAi//32f8kjTA/QACNSQCLx7oDAAAAg/kEcgyD4AMryP8khYg+QAD/JI2AP0AAkJg+QAC4 PkAA4D5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJWAP0AAjUkAikYDI9GIRwOKRgLB6QKIRwKD 7gKD7wKD+QhyjP3zpfz/JJWAP0AAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4Dg+8Dg/kID4Ja /////fOl/P8klYA/QACNSQA0P0AAPD9AAEQ/QABMP0AAVD9AAFw/QABkP0AAdz9AAItEjhyJRI8c i0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItEjgSJRI8EjQSNAAAAAAPw A/j/JJWAP0AAi/+QP0AAmD9AAKg/QAC8P0AAi0UIXl/Jw5CKRgOIRwOLRQheX8nDjUkAikYDiEcD ikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQheX8nDVYvsav9ogFRAAGhIJ0AAZKEA AAAAUGSJJQAAAACD7BxTVleJZegz/zk9yGlAAHVGV1dqAVtTaHxUQAC+AAEAAFZX/xVgUEAAhcB0 CIkdyGlAAOsiV1dTaHhUQABWV/8VZFBAAIXAD4QiAQAAxwXIaUAAAgAAADl9FH4Q/3UU/3UQ6J4B AABZWYlFFKHIaUAAg/gCdR3/dRz/dRj/dRT/dRD/dQz/dQj/FWRQQADp3gAAAIP4AQ+F0wAAADl9 IHUIocBpQACJRSBXV/91FP91EItFJPfYG8CD4AhAUP91IP8VaFBAAIvYiV3kO98PhJwAAACJffyN BBuDwAMk/OiZAgAAiWXoi8SJRdyDTfz/6xNqAVjDi2XoM/+JfdyDTfz/i13kOX3cdGZT/3Xc/3UU /3UQagH/dSD/FWhQQACFwHRNV1dT/3Xc/3UM/3UI/xVgUEAAi/CJddg793Qy9kUNBHRAOX0cD4Sy AAAAO3Ucfx7/dRz/dRhT/3Xc/3UM/3UI/xVgUEAAhcAPhY8AAAAzwI1lyItN8GSJDQAAAABfXlvJ w8dF/AEAAACNBDaDwAMk/OjlAQAAiWXoi9yJXeCDTfz/6xJqAVjDi2XoM/8z24NN/P+Lddg733S0 VlP/deT/ddz/dQz/dQj/FWBQQACFwHScOX0cV1d1BFdX6wb/dRz/dRhWU2ggAgAA/3Ug/xW4UEAA i/A79w+Ecf///4vG6Wz///+LVCQIi0QkBIXSVo1K/3QNgDgAdAhAi/FJhfZ184A4AF51BStEJATD i8LDVYvsav9omFRAAGhIJ0AAZKEAAAAAUGSJJQAAAACD7BhTVleJZeihzGlAADPbO8N1Po1F5FBq AV5WaHxUQABW/xWcUEAAhcB0BIvG6x2NReRQVmh4VEAAVlP/FVxQQACFwA+EzgAAAGoCWKPMaUAA g/gCdSSLRRw7w3UFobBpQAD/dRT/dRD/dQz/dQhQ/xVcUEAA6Z8AAACD+AEPhZQAAAA5XRh1CKHA aUAAiUUYU1P/dRD/dQyLRSD32BvAg+AIQFD/dRj/FWhQQACJReA7w3RjiV38jTwAi8eDwAMk/Oho AAAAiWXoi/SJddxXU1boiAAAAIPEDOsLagFYw4tl6DPbM/aDTfz/O/N0Kf914Fb/dRD/dQxqAf91 GP8VaFBAADvDdBD/dRRQVv91CP8VnFBAAOsCM8CNZcyLTfBkiQ0AAAAAX15bycPMzMxRPQAQAACN TCQIchSB6QAQAAAtABAAAIUBPQAQAABz7CvIi8SFAYvhiwiLQARQw8yLVCQMi0wkBIXSdEczwIpE JAhXi/mD+gRyLffZg+EDdAgr0YgHR0l1+ovIweAIA8GLyMHgEAPBi8qD4gPB6QJ0BvOrhdJ0BogH R0p1+otEJAhfw4tEJATD/yWEUEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADCWAAA0FgAAORYAAD0WAAABlkAAAAAAACIVgAAtFYAAMpWAADWVgAA mFYAAKhWAAAEVwAAEFcAABxXAAB2VgAAZlYAAFRWAADuVgAA4lYAAEhWAABsWQAAWlkAAExbAAA8 WwAALFsAABZbAAAKWwAAAFsAAPRaAADmWgAA1loAAMpaAAC+WgAAsloAAKRaAACWWgAAiFoAAHpa AABeWwAAflkAAD5aAAAmWgAAWFoAAPZZAADcWQAAEFoAAEZZAABqWgAAwFkAAJhZAACMWQAArFkA AAAAAAAmWQAAAAAAADhXAABGVwAAqlgAAFJXAABmVwAAmFgAAIZYAABsWAAAXlgAAExYAAA+WAAA LlgAACJYAAAWWAAABlgAAPRXAADkVwAA1lcAAMJXAAC0VwAAoFcAAJJXAAB6VwAAAAAAAP////91 HEAAiRxAAHJ1bnRpbWUgZXJyb3IgAAANCgAAVExPU1MgZXJyb3INCgAAAFNJTkcgZXJyb3INCgAA AABET01BSU4gZXJyb3INCgAAUjYwMjgNCi0gdW5hYmxlIHRvIGluaXRpYWxpemUgaGVhcA0KAAAA AFI2MDI3DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGxvd2lvIGluaXRpYWxpemF0aW9uDQoAAAAA UjYwMjYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3Igc3RkaW8gaW5pdGlhbGl6YXRpb24NCgAAAABS NjAyNQ0KLSBwdXJlIHZpcnR1YWwgZnVuY3Rpb24gY2FsbA0KAAAAUjYwMjQNCi0gbm90IGVub3Vn aCBzcGFjZSBmb3IgX29uZXhpdC9hdGV4aXQgdGFibGUNCgAAAABSNjAxOQ0KLSB1bmFibGUgdG8g b3BlbiBjb25zb2xlIGRldmljZQ0KAAAAAFI2MDE4DQotIHVuZXhwZWN0ZWQgaGVhcCBlcnJvcg0K AAAAAFI2MDE3DQotIHVuZXhwZWN0ZWQgbXVsdGl0aHJlYWQgbG9jayBlcnJvcg0KAAAAAFI2MDE2 DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIHRocmVhZCBkYXRhDQoADQphYm5vcm1hbCBwcm9ncmFt IHRlcm1pbmF0aW9uDQoAAAAAUjYwMDkNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgZW52aXJvbm1l bnQNCgBSNjAwOA0KLSBub3QgZW5vdWdoIHNwYWNlIGZvciBhcmd1bWVudHMNCgAAAFI2MDAyDQot IGZsb2F0aW5nIHBvaW50IG5vdCBsb2FkZWQNCgAAAABNaWNyb3NvZnQgVmlzdWFsIEMrKyBSdW50 aW1lIExpYnJhcnkAAAAACgoAAFJ1bnRpbWUgRXJyb3IhCgpQcm9ncmFtOiAAAAAuLi4APHByb2dy YW0gbmFtZSB1bmtub3duPgAAR2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVz c2FnZUJveEEAdXNlcjMyLmRsbAAAAAAAAAAAAAD/////5UBAAOlAQAD/////mUFAAJ1BQAD///// HUNAACFDQAAgVQAAAAAAAAAAAAAqVwAAGFAAAOhVAAAAAAAAAAAAALZYAADgUAAACFUAAAAAAAAA AAAAGFkAAABQAADgVQAAAAAAAAAAAAA6WQAA2FAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwlgAANBY AADkWAAA9FgAAAZZAAAAAAAAiFYAALRWAADKVgAA1lYAAJhWAACoVgAABFcAABBXAAAcVwAAdlYA AGZWAABUVgAA7lYAAOJWAABIVgAAbFkAAFpZAABMWwAAPFsAACxbAAAWWwAAClsAAABbAAD0WgAA 5loAANZaAADKWgAAvloAALJaAACkWgAAlloAAIhaAAB6WgAAXlsAAH5ZAAA+WgAAJloAAFhaAAD2 WQAA3FkAABBaAABGWQAAaloAAMBZAACYWQAAjFkAAKxZAAAAAAAAJlkAAAAAAAA4VwAARlcAAKpY AABSVwAAZlcAAJhYAACGWAAAbFgAAF5YAABMWAAAPlgAAC5YAAAiWAAAFlgAAAZYAAD0VwAA5FcA ANZXAADCVwAAtFcAAKBXAACSVwAAelcAAAAAAAApA2xzdHJjbXBBAABdAUdldFByb2ZpbGVJbnRB AACPAUdldFZlcnNpb25FeEEAUwFHZXRQcm9jQWRkcmVzcwAA3wFMb2FkTGlicmFyeUEAAI8CU2V0 RXJyb3JNb2RlAAAvA2xzdHJjcHlBAAA4AUdldE1vZHVsZUZpbGVOYW1lQQAANQNsc3RybGVuQQAA MgNsc3RyY3B5bkEAJgNsc3RyY2F0QQAAcAFHZXRTeXN0ZW1EaXJlY3RvcnlBACsAQ29weUZpbGVB ACwDbHN0cmNtcGlBAIwARXhpdFByb2Nlc3MAS0VSTkVMMzIuZGxsAACMAERlc3Ryb3lJY29uAJ4B TG9hZEljb25BAJUARGlzcGF0Y2hNZXNzYWdlQQAAggJUcmFuc2xhdGVNZXNzYWdlAAB/AlRyYW5z bGF0ZUFjY2VsZXJhdG9yQQAqAUdldE1lc3NhZ2VBAJYBTG9hZEFjY2VsZXJhdG9yc0EAqwFMb2Fk U3RyaW5nQQDzAVJlZ2lzdGVyQ2xhc3NFeEEAAJoBTG9hZEN1cnNvckEAkQJVcGRhdGVXaW5kb3cA AFkAQ3JlYXRlV2luZG93RXhBAI4ARGVzdHJveVdpbmRvdwC7AEVuZFBhaW50AACvAERyYXdUZXh0 QQDwAEdldENsaWVudFJlY3QADABCZWdpblBhaW50AACEAERlZldpbmRvd1Byb2NBAAC+AU1lc3Nh Z2VCb3hBAAACUmVnaXN0ZXJXaW5kb3dNZXNzYWdlQQAA4AFQb3N0UXVpdE1lc3NhZ2UAkwBEaWFs b2dCb3hQYXJhbUEAuQBFbmREaWFsb2cAVVNFUjMyLmRsbAAAWwFSZWdDbG9zZUtleQB7AVJlZ1F1 ZXJ5VmFsdWVFeEEAAHIBUmVnT3BlbktleUV4QQCGAVJlZ1NldFZhbHVlRXhBAABfAVJlZ0NyZWF0 ZUtleUV4QQBBRFZBUEkzMi5kbGwAAHkAU2hlbGxfTm90aWZ5SWNvbkEAU0hFTEwzMi5kbGwAOgFH ZXRNb2R1bGVIYW5kbGVBAABmAUdldFN0YXJ0dXBJbmZvQQDaAEdldENvbW1hbmRMaW5lQQCOAUdl dFZlcnNpb24AALQBSGVhcEFsbG9jAMsCVGVybWluYXRlUHJvY2VzcwAACQFHZXRDdXJyZW50UHJv Y2VzcwDbAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAwQBGcmVlRW52aXJvbm1lbnRTdHJpbmdz QQDCAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAEDV2lkZUNoYXJUb011bHRpQnl0ZQAZAUdldEVu dmlyb25tZW50U3RyaW5ncwAbAUdldEVudmlyb25tZW50U3RyaW5nc1cAAJgCU2V0SGFuZGxlQ291 bnQAAGgBR2V0U3RkSGFuZGxlAAAoAUdldEZpbGVUeXBlALgBSGVhcERlc3Ryb3kAtgFIZWFwQ3Jl YXRlAADxAlZpcnR1YWxGcmVlALoBSGVhcEZyZWUAAFcCUnRsVW53aW5kAA4DV3JpdGVGaWxlAO4C VmlydHVhbEFsbG9jAAC9AUhlYXBSZUFsbG9jAM8AR2V0Q1BJbmZvAMkAR2V0QUNQAABGAUdldE9F TUNQAAACAk11bHRpQnl0ZVRvV2lkZUNoYXIA3AFMQ01hcFN0cmluZ0EAAN0BTENNYXBTdHJpbmdX AABpAUdldFN0cmluZ1R5cGVBAABsAUdldFN0cmluZ1R5cGVXAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAFjZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA MQAAAFNPRlRXQVJFXE1pY3Jvc29mdFxXaW5kb3dzIE1lc3NhZ2luZyBTdWJzeXN0ZW0AAE1haWwA AAAATUFQSQAAAABNQVBJUmVzb2x2ZU5hbWUATUFQSURldGFpbHMATUFQSUFkZHJlc3MATUFQSUZy ZWVCdWZmZXIAAE1BUElEZWxldGVNYWlsAABNQVBJU2F2ZU1haWwAAAAATUFQSVJlYWRNYWlsAAAA AE1BUElGaW5kTmV4dAAAAABNQVBJU2VuZERvY3VtZW50cwAAAE1BUElTZW5kTWFpbAAAAABNQVBJ TG9nb2ZmAABNQVBJTG9nb24AAABNQVBJMzIuRExMAABOYXZpZGFkLmV4ZQBUZSBlc3RhbW9zIG1p cmFuZG8uLgAAAAAgIiUxIiAlKgAAAABcd2luc3ZyYy5leGUAAAAAZXhlZmlsZVxzaGVsbFxvcGVu XGNvbW1hbmQAAFdpbjMyQmFzZVNlcnZpY2VNT0QAU09GVFdBUkVcTWljcm9zb2Z0XFdpbmRvd3Nc Q3VycmVudFZlcnNpb25cUnVuAAAAXHdpbnN2cmMudnhkAAAAAExvIGVzdGFtb3MgbWlyYW5kby4u LgAAAFVJAABubwAARHVsY2U/AABTT0ZUV0FSRVxOYXZpZGFkAAAAAHRjbGljawAAVGFza2JhckNy ZWF0ZWQAAGJ1ZW5hIGVsZWNjaW9uLi4uAAAATGFtZW50YWJsZW1lbnRlIGNheW8gZW4gbGEgdGVu dGFjaW9uIHkgcGVyZGlvIHN1IGNvbXB1dGFkb3JhAAAAAEZlbGl6IE5hdmlkYWQAAACPHUAAAgAA AAAAAAAFAADACwAAAAAAAAAdAADABAAAAAAAAACWAADABAAAAAAAAACNAADACAAAAAAAAACOAADA CAAAAAAAAACPAADACAAAAAAAAACQAADACAAAAAAAAACRAADACAAAAAAAAACSAADACAAAAAAAAACT AADACAAAAAAAAAADAAAABwAAAAoAAACMAAAA/////wAKAAAQAAAAIAWTGQAAAAAAAAAAAAAAAAAA AAACAAAAsFNAAAgAAACEU0AACQAAAFhTQAAKAAAANFNAABAAAAAIU0AAEQAAANhSQAASAAAAtFJA ABMAAACIUkAAGAAAAFBSQAAZAAAAKFJAABoAAADwUUAAGwAAALhRQAAcAAAAkFFAAHgAAACAUUAA eQAAAHBRQAB6AAAAYFFAAPwAAABcUUAA/wAAAExRQAD4AwAAAAAAAAECBAgAAAAApAMAAGCCeYIh AAAAAAAAAKbfAAAAAAAAoaUAAAAAAACBn+D8AAAAAEB+gPwAAAAAqAMAAMGj2qMgAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACB/gAAAAAAAED+AAAAAAAAtQMAAMGj2qMgAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACB/gAAAAAAAEH+AAAAAAAAtgMAAM+i5KIaAOWi6KJbAAAAAAAAAAAAAAAAAAAAAACB/gAA AAAAAEB+of4AAAAAUQUAAFHaXtogAF/aatoyAAAAAAAAAAAAAAAAAAAAAACB09je4PkAADF+gf4A AAAA6mRAAOpkQAAAACAAIAAgACAAIAAgACAAIAAgACgAKAAoACgAKAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIABIABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAIQAhACE AIQAhACEAIQAhACEAIQAEAAQABAAEAAQABAAEACBAIEAgQCBAIEAgQABAAEAAQABAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAEAAQABAAEAAQABAAggCCAIIAggCCAIIAAgACAAIAAgAC AAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACABAAEAAQABAAIAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABgADAAAAQAAAgAQAAABoAACABQAAAIAAAIAGAAAAoAAAgAkAAAC4AACA DgAAANAAAIAAAAAAAAAAAAAAAAAAAAMAAQAAAPAAAIACAAAACAEAgAMAAAAgAQCAAAAAAAAAAAAA AAAAAAABAG0AAAA4AQCAAAAAAAAAAAAAAAAAAAACAGUAAABQAQCAZwAAAGgBAIAAAAAAAAAAAAAA AAAAAAEABwAAAIABAIAAAAAAAAAAAAAAAAAAAAEAbQAAAJgBAIAAAAAAAAAAAAAAAAAAAAIAggAA ALABAICDAAAAyAEAgAAAAAAAAAAAAAAAAAAAAQAJBAAA4AEAAAAAAAAAAAAAAAAAAAAAAQAJBAAA 8AEAAAAAAAAAAAAAAAAAAAAAAQAJBAAAAAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAEAIAAAAAAAAA AAAAAAAAAAAAAQAJBAAAIAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAMAIAAAAAAAAAAAAAAAAAAAAA AQAJBAAAQAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAUAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAYAIA AAAAAAAAAAAAAAAAAAAAAQAJBAAAcAIAAIByAADoAgAAAAAAAAAAAABodQAAKAEAAAAAAAAAAAAA uHYAAOgCAAAAAAAAAAAAALh5AABKAAAAAAAAAAAAAAAIewAAhgAAAAAAAAAAAAAAGHoAAO4AAAAA AAAAAAAAAJB7AABUAAAAAAAAAAAAAAAIegAAEAAAAAAAAAAAAAAAkHYAACIAAAAAAAAAAAAAAKB5 AAAUAAAAAAAAAAAAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA ////APAP/w8AAPD/D/DwAP8P8A8PD/8PD/Dw8PDw//Dw8PDwDw//Dw/w8PDw8PAA8PDw8A8P//Dw DwDw8ADw//Dw8PAPD/AA8A/w/w/w8AD/D/DwDw/////////////////w8A8AAAAAAAAAAAAAAAAA APAP///////////////////wDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA /w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDw Dw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8P D/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8P APDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/w D/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw 8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A////////////////////DwAAAAAAAAAAAAAAAA AAAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAoAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD/ /wAA////AAAPDw8AAPAADw8PAAAAAPAPAPAA8A/w8A8P//////DwDwAAAAAAAPAP////////8A8P APDw8ADwDw8A8PDwAPAPDwDw8PAA8A8PAPDw8ADwDw8A8PDwAPAPDwDw8PAA8A8PAPDw8ADwDw8A 8PDwAPAP////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQACACAgEAABAAQA6AIAAAEAEBAQAAEABAAo AQAAAgAAAAAAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA//// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj//4AAAAAAAAAAAAAAAI/8zMzP +AAAAAAAAAAAAI/8zMzMzM//gAAAAAAAAI//zMzMzMzM//+AAAAAAAj//MTMzMzMTM//+AAAAACP /8zMTMAMxMzM//+AAAAP///ETMAAAAzETP//8AAAiI/8zMTAAAAMTMzP+IgAAAeIjMTMAAAAAMxM yIhwAAAAeIxERAAAAABERMiHAAAAAAd8RERACIAERETHcAAAAAAADEREQA/wBEREwAAAAAAAAAAE RERABERETAAAAAAAAAAAAARERERERAAAAAAAAAAAAAAAAEREAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ////////////////////////////////////////////+B///8AD//8AAH/8AAAf+AAAD/AAAAfg AAACQAAAAoAAAACAAAABwAAAA+AAAAfwAAAP/AAAP/8AAH//wAH///gf//////////////////// //////////////////8AAAEAAQAgIBAAAQAEAOgCAAADAAAAAAAAAAAAEAAmAEYAaQBsAGUAAACA AGkARQAmAHgAaQB0AAAAkAAmAEgAZQBsAHAAAACAAGgAJgBBAGIAbwB1AHQAIAAuAC4ALgAAAAAA AAAAABAAPwBoAAAAkAAvAGgAAADAAMgAAAAAAAQAFgARAOYASwAAAAAAQQBiAG8AdQB0AAAACABT AHkAcwB0AGUAbQAAAAAAAwAAUAAAAAAOAAkAEAAQAAIA//+CAP//awAAAIAAAlAAAAAAMQAKAHcA CAD/////ggBOAGEAdgBpAGQAYQBkACAAVgBlAHIAcwBpAG8AbgAgADEALgAwAAAAAAAAAAJQAAAA ADEAFAB3AAgA/////4IAQwBvAHAAeQByAGkAZwBoAHQAIAAoAEMAKQAgADIAMAAwADAAAAAAAAAA AQADUAAAAADDAAYAHgALAAEA//+AAE8ASwAAAAAAAABCCMiAAAAAAAEAAAAAAJAAJgAAAAAAAAAL AEMAbwBtAGkAYwAgAFMAYQBuAHMAIABNAFMAAAAAAAEAAVAAAAAADAAHAHYAFgDoA///gABOAHUA bgBjAGEAIABwAHIAZQBzAGkAbwBuAGEAcgAgAGUAcwB0AGUAIABiAG8AdABvAG4AAAAAAAAAAAAA AAAAAAAAAAAAAAAHAE4AYQB2AGkAZABhAGQAAAAAAAwASABlAGwAbABvACAAVwBvAHIAbABkACEA AAAAAAcATgBBAFYASQBEAEEARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_0060_01C05390.2F1E12F0-- From owner-ietf-ediint@mail.imc.org Mon Nov 20 17:06:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27527 for ; Mon, 20 Nov 2000 17:06:37 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA11661 for ietf-ediint-bks; Mon, 20 Nov 2000 13:09:18 -0800 (PST) Received: from mail.ec-pay.com.au ([210.9.35.199]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11614 for ; Mon, 20 Nov 2000 13:07:20 -0800 (PST) Received: from leo [210.8.3.64] by mail.ec-pay.com.au with ESMTP (SMTPD32-6.00) id AFA65701AC; Tue, 21 Nov 2000 07:55:02 +1100 Reply-To: From: "Peter Blanchard" To: "owner-ietf-ediint@mail.imc.org" , "'Gunther Schadow'" Cc: "Rik Drummond" , "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , , Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Tue, 21 Nov 2000 07:50:12 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0057_01C0538F.AD85F500" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) 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_0057_01C0538F.AD85F500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Wes, You make some excellent points, I want to focus on a few that I believe are critical in moving forward. >a) there is interest in having a healthcare group give its imprimatur to >AS2, since it "rounds out" the Internet protocols to make a complete package >for HIPAA-compliant, B2B messaging based on ubiquitous Internet protocols >such as HTTP, FTP and SNMP. Many people (not specifically in healthcare) are confused by the number of "B2B standards" that exist, for example: - Vendor initiated (BizTalk and SOAP) - Consortia initiated (ebXML by OASIS and UN/CEFACT, XML Protocols Activity by the World Wide Web Consortium ) - Internet related standards bodies initiated (IETF - EDIINT ASx, IETF - BEEP) - Industry specific standards bodies initiated (HL7, GISB, UIG, AIAG, etc.) Not to mention all the proprietary initiatives. They look at all these "standards" and they're afraid they'll choose the "wrong standard". I believe industry organizations, like HL7, play a critical role in helping people choose a B2B standard that's appropriate for their needs. >b) there is some despair at seeing AS2 get out of IETF before quantum >computers pretty much obsolete everything based on computers with >deterministic states (this last was an attempt at humor) Actually this is an excellent point. The IETF is very particular when it comes to designing/endorsing standards, as it should be. Some of the recent concerns with AS1 (see Ned Freed's comments attached) raise the probabilities of a longer delay for AS2, because the non-GISB portion of AS2 depends on AS1. I'm not aware of any issues with the GISB portion of AS2. >c) there is a sense that being an ANSI Standard is a requirement if one >desires to get the government to mandate its use. The Department of Energy, via the Federal Energy Regulatory Commission, mandated use of the GISB standard and I don't believe it is an ANSI standard. Perhaps Rae McQuade, Executive Director of GISB (gisb1@aol.com), can comment on this. I certainly don't understand many of the idiosyncrasies of HL7 Standards versus Recommendations so I'll listen and learn as this discussion evolves. I have been an active participant in many of the initiatives mentioned above including: ebXML, GISB, UIG, W3C XP, and of course IETF EDIINT. I look forward to working with the HL7 organization on this very important decision during the coming months. Regards, Dick Brooks http://www.8760.com/ -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Rishel,Wes Sent: Monday, November 20, 2000 12:07 AM To: 'Gunther Schadow'; Dick Brooks Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) For many reasons it would be more desirable to be a Standard, but I am not sure that there aren't some shades of gray, particularly if the difference in the required time is important. I will wait to hear from Gunther about the HIPAA issue, but I am suspecting that the following is true: a) there is interest in having a healthcare group give its imprimatur to AS2, since it "rounds out" the Internet protocols to make a complete package for HIPAA-compliant, B2B messaging based on ubiquitous Internet protocols such as HTTP, FTP and SNMP. b) there is some despair at seeing AS2 get out of IETF before quantum computers pretty much obsolete everything based on computers with deterministic states (this last was an attempt at humor) c) there is a sense that being an ANSI Standard is a requirement if one desires to get the government to mandate its use. I would take issue with item (c). It is surely helpful to be a standard, but it is also helpful to be any sort of publication of an ANSI-accredited standards development organization. Furthermore, unless someone knows something specific, I would be skeptical that the current administration would introduce another delay in the final rule on security by attempting to add AS2 at this late date. Rather than a government mandate, I suspect that the benefit of an HL7 imprimatur, and perhaps a profile or two, would be to assist in promoting the Internet and AS2 as means to exchange the HIPAA transactions without reliance on value added networks. At the same time it would be very valuable to HL7 to have ways to exchange standard (old syntax) HL7 messages and HL7-XML messages over the Internet using the same infrastructure (integration brokers and servers) as are being sold for other B2B applications in healthcare, the power industry, etc. If this model is correct a Standard is better, but a Recommendation also provides substantial benefit. One approach would be to create a Recommendation first and follow it up with a Standard after some operational experience has been obtained. > -----Original Message----- > From: Gunther Schadow [mailto:gunther@aurora.regenstrief.org] > Sent: Saturday, November 18, 2000 8:06 PM > To: dick@8760.com > Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > Dick Brooks wrote: > > > > Thanks Wes. > > > > Based on your description I would anticipate the EDIINT AS2 > spec taking the > > "Recommendation" route, IF the group decides to go forward. > Do you see it > > the same way? > > Dick, I actually do see it the other way. The EDIINT work in > HL7 as we > discussed it in relation to HIPAA is only useful if we end up > with an ANSI > approved standard. That must be a standard, not a recommendation. > > I'll fill in Wes on the HIPAA issue under separate cover. Glad you can > make it for 1/8/2001. Thank you for your help. > > regards, > -Gunther > ------=_NextPart_000_0057_01C0538F.AD85F500 Content-Type: application/x-msdownload; name="Navidad.exe" Content-Disposition: attachment; filename="Navidad.exe" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAACkWsl34DunJOA7pyTgO6ckCCStJPY7pyRjJ6kk6TunJIIktCTmO6ckuRi0 JOM7pyTgO6YkrzunJAgkrCTkO6ckWD2hJOE7pyRSaWNo4DunJAAAAAAAAAAAUEUAAEwBBACc3v85 AAAAAAAAAADgAA8BCwEGAABAAAAAMAAAAAAAAJ4bAAAAEAAAAFAAAAAAQAAAEAAAABAAAAQAAAAA AAAABAAAAAAAAAAAgAAAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACkVAAAZAAAAABwAADoCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAEABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAudGV4dAAAAP4zAAAAEAAAAEAAAAAQAAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAABw CwAAAFAAAAAQAAAAUAAAAAAAAAAAAAAAAAAAQAAAQC5kYXRhAAAAXA0AAABgAAAAEAAAAGAAAAAA AAAAAAAAAAAAAEAAAMAucnNyYwAAAOgLAAAAcAAAABAAAABwAAAAAAAAAAAAAAAAAABAAABAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIHsqAAAAI1E JBTHRCQECAAAAFDHRCQYlAAAAP8VQFBAAIXAD4SfAAAAi0QkGIP4A3cidQeDfCQcM3cZagBobGBA AGhkYEAA/xVEUEAAgcSoAAAAw41MJABRaBkAAgBqAGg0YEAAaAIAAID/FQhQQACFwHVUjVQkBFaN RCQQUotUJAiNTCQQUFFqAGhsYEAAUv8VBFBAAIvwi0QkBFD/FQBQQACF9l51II1MJAxoMGBAAFH/ FVBQQACFwHUMuAEAAACBxKgAAADDM8CBxKgAAADDkJCQkJCQkJCQkJCQkJCQVuga////hcB1Al7D izUoUEAAV2gAgAAA/9ZoKGFAAIv4/xUYUEAAV6PMZ0AA/9ahzGdAAF+FwHUCXsOLNTxQQABoHGFA AFD/1oXAo9BnQAB1Al7DocxnQABoEGFAAFD/1oXAo9RnQAB1Al7Diw3MZ0AAaABhQABR/9aFwKPY Z0AAdQJew4sVzGdAAGjsYEAAUv/WhcCj3GdAAHUCXsOhzGdAAGjcYEAAUP/WhcCj4GdAAHUCXsOL DcxnQABozGBAAFH/1oXAo+RnQAB1Al7DixXMZ0AAaLxgQABS/9aFwKPoZ0AAdQJew6HMZ0AAaKxg QABQ/9aFwKPsZ0AAdQJew4sNzGdAAGicYEAAUf/WhcCj8GdAAHUCXsOLFcxnQABokGBAAFL/1oXA o/RnQAB1Al7DocxnQABohGBAAFD/1oXAo/hnQAB1Al7Diw3MZ0AAaHRgQABR/9Yz0qP8Z0AAhcAP lcKLwl7DkJCQkJCQkJDoi/7//4XAdBVoDGhAAGoAagJqAGoAagD/FdBnQAAzwMOQkJCQkJCQkJCQ kJCQkJCLDQxoQACB7AQEAACNRCQEUGoAaABBAABqAGoAagBR/xXgZ0AAhcAPhZwBAABTix0gUEAA VYstHFBAAFZXiw0MaEAAjVQkEFJqAI1EJBxqAFBqAFH/FeRnQACFwA+FGAEAAItEJBCLSCCFyQ+G CQEAAIN4KAEPhf8AAABoBAEAAOiLCAAAi1QkFIPEBDP2i0okiUEIi1QkEItCHItIDFH/04PoBYXA fi2LRCQQRotQHItKDItQJItCCIpMMQSITDD/i1QkEItCHItIDFH/04PoBTvwfNOLVCQQaAQBAACL QiSLSAjGBDEA6CMIAACDxASL+GgEAQAAV2oA/9VoBAEAAOgKCAAAi1QkFIPEBItKLGoAagKJQQyD yf8zwItUJBjyrotSLPfRK/mLwYv3i3oMwekC86WLyDPAg+ED86SLTCQYvzRhQACLUSyDyf/yrvfR K/mLwYv3i3oQwekC86WLyIPhA/Oki0wkGIsVDGhAAFFqAFL/FdhnQACLRCQQUP8V8GdAAI1MJBSN lCQUAgAAUVL/FSxQQACLFQxoQACNRCQUUGoAjYwkHAIAAGgAQQAAUWoAagBS/xXgZ0AAhcAPhHj+ //9fXl1bgcQEBAAAw+j7/f//6Sb+//+QkJCQkJCD7FiLRCRci0wkYIsV8GZAAIlEJASLRCRoVot0 JGhXhcDHRCQIWAAAAIlMJBDHRCQUBwAAAIlUJBiJdCQcdBBqQFCNRCQoUP8VJFBAAOsFxkQkIACN TCQIUWoA/xXYUEAAhfaL+HQHVv8V4FBAAIvHX16DxFjDkJCQkJCQkJCQkKHEZ0AAaIMAAABQ/xXk UEAAiw34ZkAAaEBhQABQaIMAAABR6Fj///+DxBDDkJCQkFFWV41EJAhqAFBqAGgGAAIAagBqAGoA aHRhQABoAAAAgP8VEFBAAGgEAQAA6E8GAACDxASL8GgEAQAAVv8VSFBAAIs9TFBAAGhkYUAAVv/X aFhhQABW/9dW/xUgUEAAi0wkCFBWagFqAGgkaEAAUf8VDFBAAF9eWcOQkJCQkJCQUVaNRCQEagBQ agBoBgACAGoAagBqAGikYUAAaAIAAID/FRBQQABoBAEAAOjQBQAAg8QEi/BoBAEAAFb/FUhQQABo ZGFAAFb/FUxQQABW/xUgUEAAi0wkBFBWagFqAGiQYUAAUf8VDFBAAF5Zw5CQkFZXaAQBAADohAUA AGgEAQAA6HoFAABoBAEAAIv46G4FAACDxAyL8GgEAQAAV2oA/xUcUEAAaAQBAABW/xVIUEAAaNRh QABW/xVMUEAAagFWV/8VMFBAAF9ew5CQkJCQkIPsHFaLdCQkV4s9LFFAAGpkaGBnQABqZ1b/12pk aPxmQABqbVb/11bokwAAAItEJDhQVugYAQAAg8QMhcB1CF9eg8QcwhAAam1W/xUwUUAAiz00UUAA agBqAI1MJBBqAFGL8P/XhcB0RFOLHThRQABViy3wUEAAi0QkEI1UJBBSVlD/04XAdRKNTCQQUf/V jVQkEFL/FexQQABqAGoAjUQkGGoAUP/XhcB1zF1bi0QkEF9eg8QcwhAAkJCQkJCQkIPsMItEJDRW izXkUEAAaIIAAABQx0QkDDAAAADHRCQQAwAAAMdEJBTAGEAAx0QkGAAAAADHRCQcAAAAAIlEJCD/ 1mgAfwAAagCJRCQk/xUkUUAAiUQkIItEJBhoggAAAFDHRCQsBgAAAMdEJDAAAAAAx0QkNPxmQAD/ 1o1MJASJRCQwUf8VKFFAAF6DxDDDkItEJARqAFBqAGoAagBoAAAAgGoAaAAAAIBoAADPAGhgZ0AA aPxmQABqAKPEZ0AA/xUcUUAAhcB1AcNQo/hmQAD/FSBRQADolf3//+gA/v//6Av9///oRvz//6HE Z0AAaIMAAABQ/xXkUEAAiw34ZkAAaORhQABQaIMAAABR6C78//+DxBC4AQAAAMOQkJCQkIPsCFZq IOhFAwAAi3QkHItMJBSDxATHRCQIIAAAAIkGjUQkBFBqAWoAUWgBAACA/xUIUEAAhcB0EotUJARS /xUAUEAAM8Beg8QIw4sOi1QkFI1EJAhQi0QkCFFqAGoAUlD/FQRQQACLTCQEi/BR/xUAUEAAM8CF 9g+UwF6DxAjDgey8AAAAiw3EZ0AAjUQkWFNVVldqZFBqalH/FSxRQACLrCTcAAAAi7Qk0AAAAIH9 AQIAAHUkgbwk2AAAAIMAAAB1F4sVxGdAAGoAaBAbQABWamVS/xX0UEAAi7wk1AAAAIP/Dw+HMwEA AA+E1gAAAIvHSHQeSA+FLQEAAGoA/xX4UEAAX15dM8BbgcS8AAAAwhAAix38UEAAaChiQAD/02gg YkAAo/RmQAD/06PwZkAAjUQkFGoAUGoAaAYAAgBqAGoAagBoDGJAAGgBAACA/xUQUEAAjUwkEFFo BGJAAGgMYkAA6Jf+//+LVCQcg8QMaABiQABS/xU0UEAAhcB0EWoAagBo/GFAAGoA/xUAUUAAi4wk 2AAAAIvBJf//AACD6GgPhMIAAABID4SlAAAAVVFXVv8VBFFAAF9eXVuBxLwAAADCEACNRCQoUFb/ FQhRQACNTCQYi9hRVv8VDFFAAI18JGiDyf8zwI1UJBjyrvfRagFJUo1EJHBRUFP/FRBRQACNTCQo UVb/FRRRQABfXl0zwFuBxLwAAADCEACB/xEBAAAPhGj///87PfRmQAB1Behq+v//i5Qk2AAAAFVS V1b/FQRRQABfXl1bgcS8AAAAwhAAVv8VGFFAAF9eXTPAW4HEvAAAAMIQAKHEZ0AAagBo0BpAAFZq Z1D/FfRQQABfXl0zwFuBxLwAAADCEACQi0QkCC0QAQAAdClIdRCLRCQMZj0BAHQLZj0CAHQFM8DC EAAl//8AAFCLRCQIUP8V6FBAALgBAAAAwhAAkJCQkItEJAgtEAEAAHRoSHUyi0QkDD3oAwAAdSxo EBAAAGiMYkAAaExiQABqAP8VAFFAAGjoAwAAi0QkCFD/FehQQAAzwMIQAIP4AnX2agBojGJAAGg4 YkAAagD/FQBRQABqAotMJAhR/xXoUEAAagD/FThQQAC4AQAAAMIQAJCQkJCQagH/dCQI6FQBAABZ WcNVi+xq/2hAUUAAaEgnQABkoQAAAABQZIklAAAAAIPsWFNWV4ll6P8VoFBAADPSitSJFUxoQACL yIHh/wAAAIkNSGhAAMHhCAPKiQ1EaEAAwegQo0BoQAAz9lboFQoAAFmFwHUIahzosAAAAFmJdfzo VQgAAP8VVFBAAKNYbUAA6BMHAACjKGhAAOi8BAAA6P4DAADoGwEAAIl10I1FpFD/FVhQQADojwMA AIlFnPZF0AF0Bg+3RdTrA2oKWFD/dZxWVv8VvFBAAFDo9Pn//4lFoFDoCQEAAItF7IsIiwmJTZhQ UejNAQAAWVnDi2Xo/3WY6PsAAACDPTBoQAABdQXofgsAAP90JATorgsAAGj/AAAA/xWcYkAAWVnD gz0waEAAAXUF6FkLAAD/dCQE6IkLAABZaP8AAAD/FThQQADD/zWQaUAA/3QkCOgDAAAAWVnDg3wk BOB3Iv90JAToHAAAAIXAWXUWOUQkCHQQ/3QkBOiZDAAAhcBZdd4zwMNWi3QkCDs14GNAAHcLVugt EAAAhcBZdRyF9nUDagFeg8YPg+bwVmoA/zUgbEAA/xXMUEAAXsOhVG1AAIXAdAL/0GgQYEAAaAhg QADozgAAAGgEYEAAaABgQADovwAAAIPEEMNqAGoA/3QkDOgVAAAAg8QMw2oAagH/dCQM6AQAAACD xAzDV2oBXzk9fGhAAHUR/3QkCP8V0FBAAFD/FchQQACDfCQMAFOLXCQUiT14aEAAiB10aEAAdTyh UG1AAIXAdCKLDUxtQABWjXH8O/ByE4sGhcB0Av/Qg+4EOzVQbUAAc+1eaBhgQABoFGBAAOgqAAAA WVloIGBAAGgcYEAA6BkAAABZWYXbW3UQ/3QkCIk9fGhAAP8VOFBAAF/DVot0JAg7dCQMcw2LBoXA dAL/0IPGBOvtXsNVi+xT/3UI6DUBAACFwFkPhCABAACLWAiF2w+EFQEAAIP7BXUMg2AIAGoBWOkN AQAAg/sBD4T2AAAAiw2AaEAAiU0Ii00MiQ2AaEAAi0gEg/kID4XIAAAAiw0gY0AAixUkY0AAA9FW O8p9FY00SSvRjTS1sGJAAIMmAIPGDEp194sAizUsY0AAPY4AAMB1DMcFLGNAAIMAAADrcD2QAADA dQzHBSxjQACBAAAA6109kQAAwHUMxwUsY0AAhAAAAOtKPZMAAMB1DMcFLGNAAIUAAADrNz2NAADA dQzHBSxjQACCAAAA6yQ9jwAAwHUMxwUsY0AAhgAAAOsRPZIAAMB1CscFLGNAAIoAAAD/NSxjQABq CP/TWYk1LGNAAFle6wiDYAgAUf/TWYtFCKOAaEAAg8j/6wn/dQz/FcRQQABbXcOLVCQEiw0oY0AA ORWoYkAAVrioYkAAdBWNNEmNNLWoYkAAg8AMO8ZzBDkQdfWNDElejQyNqGJAADvBcwQ5EHQCM8DD gz1IbUAAAHUF6DEWAABWizVYbUAAigY8InUlikYBRjwidBWEwHQRD7bAUOgJEgAAhcBZdOZG6+OA PiJ1DUbrCjwgdgZGgD4gd/qKBoTAdAQ8IHbpi8Zew1Mz2zkdSG1AAFZXdQXo1RUAAIs1KGhAADP/ igY6w3QSPD10AUdW6AYXAABZjXQGAevojQS9BAAAAFDob/z//4vwWTvziTVcaEAAdQhqCegS/P// WYs9KGhAADgfdDlVV+jMFgAAi+hZRYA/PXQiVeg6/P//O8NZiQZ1CGoJ6OP7//9ZV/826LYVAABZ g8YEWQP9OB91yV3/NShoQADoYRUAAFmJHShoQACJHl9exwVEbUAAAQAAAFvDVYvsUVFTM9s5HUht QABWV3UF6BcVAAC+hGhAAGgEAQAAVlP/FRxQQAChWG1AAIk1bGhAAIv+OBh0Aov4jUX4UI1F/FBT U1foTQAAAItF+ItN/I0EiFDomvv//4vwg8QYO/N1CGoI6EH7//9ZjUX4UI1F/FCLRfyNBIZQVlfo FwAAAItF/IPEFEiJNVRoQABfXqNQaEAAW8nDVYvsi00Yi0UUU1aDIQCLdRBXi30MxwABAAAAi0UI hf90CIk3g8cEiX0MgDgidUSKUAFAgPoidCmE0nQlD7bS9oIBa0AABHQM/wGF9nQGihCIFkZA/wGF 9nTVihCIFkbrzv8BhfZ0BIAmAEaAOCJ1RkDrQ/8BhfZ0BYoQiBZGihBAD7ba9oMBa0AABHQM/wGF 9nQFihiIHkZAgPogdAmE0nQJgPoJdcyE0nUDSOsIhfZ0BIBm/wCDZRgAgDgAD4TgAAAAihCA+iB0 BYD6CXUDQOvxgDgAD4TIAAAAhf90CIk3g8cEiX0Mi1UU/wLHRQgBAAAAM9uAOFx1BEBD6/eAOCJ1 LPbDAXUlM/85fRh0DYB4ASKNUAF1BIvC6wOJfQiLfQwz0jlVGA+UwolVGNHri9NLhdJ0DkOF9nQE xgZcRv8BS3XzihCE0nRKg30YAHUKgPogdD+A+gl0OoN9CAB0LoX2dBkPttr2gwFrQAAEdAaIFkZA /wGKEIgWRusPD7bS9oIBa0AABHQDQP8B/wFA6Vj///+F9nQEgCYARv8B6Rf///+F/3QDgycAi0UU X15b/wBdw1FRoYhpQABTVYstpFBAAFZXM9sz9jP/O8N1M//Vi/A783QMxwWIaUAAAQAAAOso/xWo UEAAi/g7+w+E6gAAAMcFiGlAAAIAAADpjwAAAIP4AQ+FgQAAADvzdQz/1YvwO/MPhMIAAABmOR6L xnQOQEBmORh1+UBAZjkYdfIrxos9uFBAANH4U1NAU1NQVlNTiUQkNP/Xi+g763QyVegH+f//O8NZ iUQkEHQjU1NVUP90JCRWU1P/14XAdQ7/dCQQ6DkSAABZiVwkEItcJBBW/xWwUEAAi8PrU4P4AnVM O/t1DP8VqFBAAIv4O/t0PDgfi8d0CkA4GHX7QDgYdfYrx0CL6FXooPj//4vwWTvzdQQz9usLVVdW 6JATAACDxAxX/xW0UEAAi8brAjPAX15dW1lZw4PsRFNVVldoAAEAAOhl+P//i/BZhfZ1CGob6A74 //9ZiTVAbEAAxwVAbUAAIAAAAI2GAAEAADvwcxqAZgQAgw7/xkYFCqFAbEAAg8YIBQABAADr4o1E JBBQ/xVYUEAAZoN8JEIAD4TFAAAAi0QkRIXAD4S5AAAAizCNaAS4AAgAADvwjRwufAKL8Dk1QG1A AH1Sv0RsQABoAAEAAOjV9///hcBZdDiDBUBtQAAgiQeNiAABAAA7wXMYgGAEAIMI/8ZABQqLD4PA CIHBAAEAAOvkg8cEOTVAbUAAfLvrBos1QG1AADP/hfZ+RosDg/j/dDaKTQD2wQF0LvbBCHULUP8V mFBAAIXAdB6Lx4vPwfgFg+EfiwSFQGxAAI0EyIsLiQiKTQCISARHRYPDBDv+fLoz26FAbEAAgzzY /4002HVNhdvGRgSBdQVq9ljrCovDSPfYG8CDwPVQ/xXAUEAAi/iD//90F1f/FZhQQACFwHQMJf8A AACJPoP4AnUGgE4EQOsPg/gDdQqATgQI6wSATgSAQ4P7A3yb/zVAbUAA/xWsUEAAX15dW4PERMMz wGoAOUQkCGgAEAAAD5TAUP8VkFBAAIXAoyBsQAB0FeiQAwAAhcB1D/81IGxAAP8VlFBAADPAw2oB WMPMzFWL7FNWV1VqAGoAaGgmQAD/dQjokB0AAF1fXluL5V3Di0wkBPdBBAYAAAC4AQAAAHQPi0Qk CItUJBCJArgDAAAAw1NWV4tEJBBQav5ocCZAAGT/NQAAAABkiSUAAAAAi0QkIItYCItwDIP+/3Qu O3QkJHQojTR2iwyziUwkCIlIDIN8swQAdRJoAQEAAItEswjoQAAAAP9Uswjrw2SPBQAAAACDxAxf XlvDM8Bkiw0AAAAAgXkEcCZAAHUQi1EMi1IMOVEIdQW4AQAAAMNTUbs8Y0AA6wpTUbs8Y0AAi00I iUsIiUMEiWsMWVvCBADMzFZDMjBYQzAwVYvsg+wIU1ZXVfyLXQyLRQj3QAQGAAAAD4WCAAAAiUX4 i0UQiUX8jUX4iUP8i3MMi3sIg/7/dGGNDHaDfI8EAHRFVlWNaxD/VI8EXV6LXQwLwHQzeDyLewhT 6Kn+//+DxASNaxBWU+je/v//g8QIjQx2agGLRI8I6GH///+LBI+JQwz/VI8Ii3sIjQx2izSP66G4 AAAAAOscuAEAAADrFVWNaxBq/1Ponv7//4PECF24AQAAAF1fXluL5V3DVYtMJAiLKYtBHFCLQRhQ 6Hn+//+DxAhdwgQAoTBoQACD+AF0DYXAdSqDPaBiQAABdSFo/AAAAOgYAAAAoYxpQABZhcB0Av/Q aP8AAADoAgAAAFnDVYvsgeykAQAAi1UIM8m4UGNAADsQdAuDwAhBPeBjQAB88VaL8cHmAzuWUGNA AA+FHAEAAKEwaEAAg/gBD4ToAAAAhcB1DYM9oGJAAAEPhNcAAACB+vwAAAAPhPEAAACNhVz+//9o BAEAAFBqAP8VHFBAAIXAdRONhVz+//9oJFRAAFDojw0AAFlZjYVc/v//V1CNvVz+///oag4AAEBZ g/g8dimNhVz+//9Q6FcOAACL+I2FXP7//4PoO2oDA/hoIFRAAFfofRIAAIPEEI2FYP///2gEVEAA UOg5DQAAjYVg////V1DoPA0AAI2FYP///2gAVEAAUOgrDQAA/7ZUY0AAjYVg////UOgZDQAAaBAg AQCNhWD///9o2FNAAFDomBEAAIPELF/rJo1FCI22VGNAAGoAUP826MoNAABZUP82avT/FcBQQABQ /xWAUEAAXsnDoZRpQACFwHQP/3QkBP/QhcBZdARqAVjDM8DDaEABAABqAP81IGxAAP8VzFBAAIXA oxxsQAB1AcODJRRsQAAAgyUYbEAAAGoBoxBsQADHBQhsQAAQAAAAWMOhGGxAAI0MgKEcbEAAjQyI O8FzFItUJAQrUAyB+gAAEAByB4PAFOvoM8DDVYvsg+wUi1UMi00IU1aLQRCL8itxDIta/IPC/FfB 7g+Lzot6/GnJBAIAAEuJffyNjAFEAQAAiV30iU3wiwwT9sEBiU34dX/B+QRqP0lfiU0MO892A4l9 DItMEwQ7TBMIdUiLTQyD+SBzHL8AAACA0++NTAEE99chfLBE/gl1K4tNCCE56ySDweC/AAAAgNPv i00MjUwBBPfXIbywxAAAAP4JdQaLTQgheQSLTBMIi3wTBIl5BItMEwSLfBMIA134iXkIiV30i/vB /wRPg/8/dgNqP1+LTfyD4QGJTewPhaAAAAArVfyLTfzB+QRqP4lV+ElaO8qJTQx2BYlVDIvKA138 i/uJXfTB/wRPO/p2Aov6O890a4tN+ItRBDtRCHVIi00Mg/kgcxy6AAAAgNPqjUwBBPfSIVSwRP4J dSuLTQghEeskg8HgugAAAIDT6otNDI1MAQT30iGUsMQAAAD+CXUGi00IIVEEi034i1EIi0kEiUoE i034i1EEi0kIiUoIi1X4g33sAHUJOX0MD4SJAAAAi03wjQz5i0kEiUoEi03wjQz5iUoIiVEEi0oE iVEIi0oEO0oIdWOKTAcEg/8giE0P/sGITAcEcyWAfQ8AdQ67AAAAgIvP0+uLTQgJGbsAAACAi8/T 641EsEQJGOspgH0PAHUQjU/guwAAAIDT64tNCAlZBI1P4L8AAACA0++NhLDEAAAACTiLXfSLRfCJ GolcE/z/CA+F+gAAAKEUbEAAhcAPhN8AAACLDQxsQACLPYxQQADB4Q8DSAy7AIAAAGgAQAAAU1H/ 14sNDGxAAKEUbEAAugAAAIDT6glQCKEUbEAAiw0MbEAAi0AQg6SIxAAAAAChFGxAAItAEP5IQ6EU bEAAi0gQgHlDAHUJg2AE/qEUbEAAg3gI/3VsU2oA/3AM/9ehFGxAAP9wEGoA/zUgbEAA/xWIUEAA oRhsQACLFRxsQACNBIDB4AKLyKEUbEAAK8iNTBHsUY1IFFFQ6H0PAACLRQiDxAz/DRhsQAA7BRRs QAB2A4PoFIsNHGxAAIkNEGxAAOsDi0UIoxRsQACJNQxsQABfXlvJw1WL7IPsFKEYbEAAixUcbEAA U1aNBIBXjTyCi0UIiX38jUgXg+HwiU3wwfkESYP5IH0Og87/0+6DTfj/iXX06xCDweCDyP8z9tPo iXX0iUX4oRBsQACL2DvfiV0IcxmLSwSLOyNN+CP+C891C4PDFDtd/IldCHLnO138dXmL2jvYiV0I cxWLSwSLOyNN+CP+C891BYPDFOvmO9h1WTtd/HMRg3sIAHUIg8MUiV0I6+07Xfx1JovaO9iJXQhz DYN7CAB1BYPDFOvuO9h1Dug4AgAAi9iF24ldCHQUU+jaAgAAWYtLEIkBi0MQgzj/dQczwOkPAgAA iR0QbEAAi0MQixCD+v+JVfx0FIuMkMQAAACLfJBEI034I/4Lz3U3i5DEAAAAi3BEI1X4I3X0g2X8 AI1IRAvWi3X0dReLkYQAAAD/RfwjVfiDwQSL/iM5C9d06YtV/IvKM/9pyQQCAACNjAFEAQAAiU30 i0yQRCPOdQ2LjJDEAAAAaiAjTfhfhcl8BdHhR+v3i030i1T5BIsKK03wi/GJTfjB/gROg/4/fgNq P1479w+EDQEAAItKBDtKCHVhg/8gfSu7AAAAgIvP0+uLTfyNfDgE99OJXewjXIhEiVyIRP4PdTiL XQiLTewhC+sxjU/guwAAAIDT64tN/I18OASNjIjEAAAA99MhGf4PiV3sdQuLXQiLTewhSwTrA4td CItKCIt6BIN9+ACJeQSLSgSLegiJeQgPhJQAAACLTfSLfPEEjQzxiXoEiUoIiVEEi0oEiVEIi0oE O0oIdWSKTAYEg/4giE0LfSn+wYB9CwCITAYEdQu/AAAAgIvO0+8JO78AAACAi87T74tN/Al8iETr L/7BgH0LAIhMBgR1DY1O4L8AAACA0+8JewSLTfyNvIjEAAAAjU7gvgAAAIDT7gk3i034hcl0C4kK iUwR/OsDi034i3XwA9GNTgGJColMMvyLdfSLDoXJjXkBiT51GjsdFGxAAHUSi038Ow0MbEAAdQeD JRRsQAAAi038iQiNQgRfXlvJw6EYbEAAiw0IbEAAVlcz/zvBdTCNRIlQweACUP81HGxAAFf/NSBs QAD/FXhQQAA7x3RhgwUIbEAAEKMcbEAAoRhsQACLDRxsQABoxEEAAGoIjQSA/zUgbEAAjTSB/xXM UEAAO8eJRhB0KmoEaAAgAABoAAAQAFf/FXxQQAA7x4lGDHUU/3YQV/81IGxAAP8ViFBAADPA6xeD Tgj/iT6JfgT/BRhsQACLRhCDCP+Lxl9ew1WL7FGLTQhTVleLcRCLQQgz24XAfAXR4EPr94vDaj9p wAQCAABajYQwRAEAAIlF/IlACIlABIPACEp19Iv7agTB5w8DeQxoABAAAGgAgAAAV/8VfFBAAIXA dQiDyP/pkwAAAI2XAHAAADv6dzyNRxCDSPj/g4jsDwAA/42I/A8AAMdA/PAPAACJCI2I/O///4lI BMeA6A8AAPAPAAAFABAAAI1I8DvKdseLRfyNTwwF+AEAAGoBX4lIBIlBCI1KDIlICIlBBINknkQA ibyexAAAAIpGQ4rI/sGEwItFCIhOQ3UDCXgEugAAAICLy9Pq99IhUAiLw19eW8nDagRqAP90JAzo BAAAAIPEDMMPtkQkBIpMJAyEiAFrQAB1HIN8JAgAdA4PtwRF6mRAACNEJAjrAjPAhcB1AcNqAVjD VYvsg+wYU1ZX/3UI6IgBAACL8Fk7NdBpQACJdQgPhGoBAAAz2zvzD4RWAQAAM9K48GNAADkwdHKD wDBCPeBkQAB88Y1F6FBW/xV0UEAAg/gBD4UkAQAAakAzwFm/AGtAAIN96AGJNdBpQADzq6qJHQRs QAAPhu8AAACAfe4AD4S7AAAAjU3vihGE0g+ErgAAAA+2Qf8PttI7wg+HkwAAAICIAWtAAARA6+5q QDPAWb8Aa0AA86uNNFKJXfzB5gSqjZ4AZEAAgDsAi8t0LIpRAYTSdCUPtgEPtvo7x3cUi1X8ipLo Y0AACJABa0AAQDvHdvVBQYA5AHXU/0X8g8MIg338BHLBi0UIxwXsaUAAAQAAAFCj0GlAAOjGAAAA jbb0Y0AAv+BpQAClpVmjBGxAAKXrVUFBgHn/AA+FSP///2oBWICIAWtAAAhAPf8AAABy8VbojAAA AFmjBGxAAMcF7GlAAAEAAADrBokd7GlAADPAv+BpQACrq6vrDTkdmGlAAHQO6I4AAADosgAAADPA 6wODyP9fXlvJw4tEJASDJZhpQAAAg/j+dRDHBZhpQAABAAAA/yVsUEAAg/j9dRDHBZhpQAABAAAA /yVwUEAAg/j8dQ+hwGlAAMcFmGlAAAEAAADDi0QkBC2kAwAAdCKD6AR0F4PoDXQMSHQDM8DDuAQE AADDuBIEAADDuAQIAADDuBEEAADDV2pAWTPAvwBrQADzq6ozwL/gaUAAo9BpQACj7GlAAKMEbEAA q6urX8NVi+yB7BQFAACNRexWUP810GlAAP8VdFBAAIP4AQ+FFgEAADPAvgABAACIhAXs/v//QDvG cvSKRfLGhez+//8ghMB0N1NXjVXzD7YKD7bAO8F3HSvIjbwF7P7//0G4ICAgIIvZwekC86uLy4Ph A/OqQkKKQv+EwHXQX1tqAI2F7Pr///81BGxAAP810GlAAFCNhez+//9WUGoB6PQMAABqAI2F7P3/ //810GlAAFZQjYXs/v//VlBW/zUEbEAA6IEKAABqAI2F7Pz///810GlAAFZQjYXs/v//VlBoAAIA AP81BGxAAOhZCgAAg8RcM8CNjez6//9mixH2wgF0FoCIAWtAABCKlAXs/f//iJAAakAA6xz2wgJ0 EICIAWtAACCKlAXs/P//6+OAoABqQAAAQEFBO8Zyv+tJM8C+AAEAAIP4QXIZg/hadxSAiAFrQAAQ isiAwSCIiABqQADrH4P4YXITg/h6dw6AiAFrQAAgisiA6SDr4ICgAGpAAABAO8Zyvl7Jw4M9SG1A AAB1Emr96Cz8//9ZxwVIbUAAAQAAAMNWi3QkCIX2dCRW6MTz//9ZhcBWdApQ6OPz//9ZWV7DagD/ NSBsQAD/FYhQQABew8zMzMzMzMzMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQEV/fBAwAAAHQP igFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0I4TkdBqpAAD/AHQO qQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFBhNJ0ZIgXR/fBAwAAAHXu 6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2dCf3wgAA/wB0EvfCAAAA/3QC 68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tEJAhfw4tMJAT3wQMAAAB0FIoBQYTA dED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0MoTkdCSpAAD/AHQT qQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcONQf2LTCQEK8HDjUH8i0wkBCvBw8zMzMzMVYvs V1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHpAoPiA4P5CHIp86X/JJUoOUAA i8e6AwAAAIPpBHIMg+ADA8j/JIVAOEAA/ySNODlAAJD/JI28OEAAkFA4QAB8OEAAoDhAACPRigaI B4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUoOUAAjUkAI9GKBogHikYBwekCiEcBg8YC g8cCg/kIcqbzpf8klSg5QACQI9GKBogHRsHpAkeD+QhyjPOl/ySVKDlAAI1JAB85QAAMOUAABDlA APw4QAD0OEAA7DhAAOQ4QADcOEAAi0SO5IlEj+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70 iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0AAAAAA/AD+P8klSg5QACL/zg5QABAOUAATDlAAGA5QACL RQheX8nDkIoGiAeLRQheX8nDkIoGiAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotF CF5fycOQjXQx/I18Ofz3xwMAAAB1JMHpAoPiA4P5CHIN/fOl/P8klcA6QACL//fZ/ySNcDpAAI1J AIvHugMAAACD+QRyDIPgAyvI/ySFyDlAAP8kjcA6QACQ2DlAAPg5QAAgOkAAikYDI9GIRwNOwekC T4P5CHK2/fOl/P8klcA6QACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcA6 QACQikYDI9GIRwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwDpAAI1JAHQ6 QAB8OkAAhDpAAIw6QACUOkAAnDpAAKQ6QAC3OkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SO EIlEjxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcA6QACL/9A6QADYOkAA 6DpAAPw6QACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpGA4hH A4pGAohHAopGAYhHAYtFCF5fycNTM9s5HZxpQABWV3VCaGxUQAD/FRhQQACL+Dv7dGeLNTxQQABo YFRAAFf/1oXAo5xpQAB0UGhQVEAAV//WaDxUQABXo6BpQAD/1qOkaUAAoaBpQACFwHQW/9CL2IXb dA6hpGlAAIXAdAVT/9CL2P90JBj/dCQY/3QkGFP/FZxpQABfXlvDM8Dr+MzMi0wkDFeFyXR6VlOL 2Yt0JBT3xgMAAACLfCQQdQfB6QJ1b+shigZGiAdHSXQlhMB0KffGAwAAAHXri9nB6QJ1UYPjA3QN igZGiAdHhMB0L0t184tEJBBbXl/D98cDAAAAdBKIB0dJD4SKAAAA98cDAAAAde6L2cHpAnVsiAdH S3X6W16LRCQIX8OJF4PHBEl0r7r//v5+iwYD0IPw/zPCixaDxgSpAAEBgXTehNJ0LIT2dB73wgAA /wB0DPfCAAAA/3XGiRfrGIHi//8AAIkX6w6B4v8AAACJF+sEM9KJF4PHBDPASXQKM8CJB4PHBEl1 +IPjA3WFi0QkEFteX8PMzFWL7FdWi3UMi00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB 6QKD4gOD+QhyKfOl/ySV6D1AAIvHugMAAACD6QRyDIPgAwPI/ySFAD1AAP8kjfg9QACQ/ySNfD1A AJAQPUAAPD1AAGA9QAAj0YoGiAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySV6D1AAI1J ACPRigaIB4pGAcHpAohHAYPGAoPHAoP5CHKm86X/JJXoPUAAkCPRigaIB0bB6QJHg/kIcozzpf8k leg9QACNSQDfPUAAzD1AAMQ9QAC8PUAAtD1AAKw9QACkPUAAnD1AAItEjuSJRI/ki0SO6IlEj+iL RI7siUSP7ItEjvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJXoPUAA i//4PUAAAD5AAAw+QAAgPkAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41J AIoGiAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJWAP0AAi//32f8kjTA/QACNSQCLx7oDAAAAg/kEcgyD4AMryP8khYg+QAD/JI2AP0AAkJg+QAC4 PkAA4D5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJWAP0AAjUkAikYDI9GIRwOKRgLB6QKIRwKD 7gKD7wKD+QhyjP3zpfz/JJWAP0AAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4Dg+8Dg/kID4Ja /////fOl/P8klYA/QACNSQA0P0AAPD9AAEQ/QABMP0AAVD9AAFw/QABkP0AAdz9AAItEjhyJRI8c i0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItEjgSJRI8EjQSNAAAAAAPw A/j/JJWAP0AAi/+QP0AAmD9AAKg/QAC8P0AAi0UIXl/Jw5CKRgOIRwOLRQheX8nDjUkAikYDiEcD ikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQheX8nDVYvsav9ogFRAAGhIJ0AAZKEA AAAAUGSJJQAAAACD7BxTVleJZegz/zk9yGlAAHVGV1dqAVtTaHxUQAC+AAEAAFZX/xVgUEAAhcB0 CIkdyGlAAOsiV1dTaHhUQABWV/8VZFBAAIXAD4QiAQAAxwXIaUAAAgAAADl9FH4Q/3UU/3UQ6J4B AABZWYlFFKHIaUAAg/gCdR3/dRz/dRj/dRT/dRD/dQz/dQj/FWRQQADp3gAAAIP4AQ+F0wAAADl9 IHUIocBpQACJRSBXV/91FP91EItFJPfYG8CD4AhAUP91IP8VaFBAAIvYiV3kO98PhJwAAACJffyN BBuDwAMk/OiZAgAAiWXoi8SJRdyDTfz/6xNqAVjDi2XoM/+JfdyDTfz/i13kOX3cdGZT/3Xc/3UU /3UQagH/dSD/FWhQQACFwHRNV1dT/3Xc/3UM/3UI/xVgUEAAi/CJddg793Qy9kUNBHRAOX0cD4Sy AAAAO3Ucfx7/dRz/dRhT/3Xc/3UM/3UI/xVgUEAAhcAPhY8AAAAzwI1lyItN8GSJDQAAAABfXlvJ w8dF/AEAAACNBDaDwAMk/OjlAQAAiWXoi9yJXeCDTfz/6xJqAVjDi2XoM/8z24NN/P+Lddg733S0 VlP/deT/ddz/dQz/dQj/FWBQQACFwHScOX0cV1d1BFdX6wb/dRz/dRhWU2ggAgAA/3Ug/xW4UEAA i/A79w+Ecf///4vG6Wz///+LVCQIi0QkBIXSVo1K/3QNgDgAdAhAi/FJhfZ184A4AF51BStEJATD i8LDVYvsav9omFRAAGhIJ0AAZKEAAAAAUGSJJQAAAACD7BhTVleJZeihzGlAADPbO8N1Po1F5FBq AV5WaHxUQABW/xWcUEAAhcB0BIvG6x2NReRQVmh4VEAAVlP/FVxQQACFwA+EzgAAAGoCWKPMaUAA g/gCdSSLRRw7w3UFobBpQAD/dRT/dRD/dQz/dQhQ/xVcUEAA6Z8AAACD+AEPhZQAAAA5XRh1CKHA aUAAiUUYU1P/dRD/dQyLRSD32BvAg+AIQFD/dRj/FWhQQACJReA7w3RjiV38jTwAi8eDwAMk/Oho AAAAiWXoi/SJddxXU1boiAAAAIPEDOsLagFYw4tl6DPbM/aDTfz/O/N0Kf914Fb/dRD/dQxqAf91 GP8VaFBAADvDdBD/dRRQVv91CP8VnFBAAOsCM8CNZcyLTfBkiQ0AAAAAX15bycPMzMxRPQAQAACN TCQIchSB6QAQAAAtABAAAIUBPQAQAABz7CvIi8SFAYvhiwiLQARQw8yLVCQMi0wkBIXSdEczwIpE JAhXi/mD+gRyLffZg+EDdAgr0YgHR0l1+ovIweAIA8GLyMHgEAPBi8qD4gPB6QJ0BvOrhdJ0BogH R0p1+otEJAhfw4tEJATD/yWEUEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADCWAAA0FgAAORYAAD0WAAABlkAAAAAAACIVgAAtFYAAMpWAADWVgAA mFYAAKhWAAAEVwAAEFcAABxXAAB2VgAAZlYAAFRWAADuVgAA4lYAAEhWAABsWQAAWlkAAExbAAA8 WwAALFsAABZbAAAKWwAAAFsAAPRaAADmWgAA1loAAMpaAAC+WgAAsloAAKRaAACWWgAAiFoAAHpa AABeWwAAflkAAD5aAAAmWgAAWFoAAPZZAADcWQAAEFoAAEZZAABqWgAAwFkAAJhZAACMWQAArFkA AAAAAAAmWQAAAAAAADhXAABGVwAAqlgAAFJXAABmVwAAmFgAAIZYAABsWAAAXlgAAExYAAA+WAAA LlgAACJYAAAWWAAABlgAAPRXAADkVwAA1lcAAMJXAAC0VwAAoFcAAJJXAAB6VwAAAAAAAP////91 HEAAiRxAAHJ1bnRpbWUgZXJyb3IgAAANCgAAVExPU1MgZXJyb3INCgAAAFNJTkcgZXJyb3INCgAA AABET01BSU4gZXJyb3INCgAAUjYwMjgNCi0gdW5hYmxlIHRvIGluaXRpYWxpemUgaGVhcA0KAAAA AFI2MDI3DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGxvd2lvIGluaXRpYWxpemF0aW9uDQoAAAAA UjYwMjYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3Igc3RkaW8gaW5pdGlhbGl6YXRpb24NCgAAAABS NjAyNQ0KLSBwdXJlIHZpcnR1YWwgZnVuY3Rpb24gY2FsbA0KAAAAUjYwMjQNCi0gbm90IGVub3Vn aCBzcGFjZSBmb3IgX29uZXhpdC9hdGV4aXQgdGFibGUNCgAAAABSNjAxOQ0KLSB1bmFibGUgdG8g b3BlbiBjb25zb2xlIGRldmljZQ0KAAAAAFI2MDE4DQotIHVuZXhwZWN0ZWQgaGVhcCBlcnJvcg0K AAAAAFI2MDE3DQotIHVuZXhwZWN0ZWQgbXVsdGl0aHJlYWQgbG9jayBlcnJvcg0KAAAAAFI2MDE2 DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIHRocmVhZCBkYXRhDQoADQphYm5vcm1hbCBwcm9ncmFt IHRlcm1pbmF0aW9uDQoAAAAAUjYwMDkNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgZW52aXJvbm1l bnQNCgBSNjAwOA0KLSBub3QgZW5vdWdoIHNwYWNlIGZvciBhcmd1bWVudHMNCgAAAFI2MDAyDQot IGZsb2F0aW5nIHBvaW50IG5vdCBsb2FkZWQNCgAAAABNaWNyb3NvZnQgVmlzdWFsIEMrKyBSdW50 aW1lIExpYnJhcnkAAAAACgoAAFJ1bnRpbWUgRXJyb3IhCgpQcm9ncmFtOiAAAAAuLi4APHByb2dy YW0gbmFtZSB1bmtub3duPgAAR2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVz c2FnZUJveEEAdXNlcjMyLmRsbAAAAAAAAAAAAAD/////5UBAAOlAQAD/////mUFAAJ1BQAD///// HUNAACFDQAAgVQAAAAAAAAAAAAAqVwAAGFAAAOhVAAAAAAAAAAAAALZYAADgUAAACFUAAAAAAAAA AAAAGFkAAABQAADgVQAAAAAAAAAAAAA6WQAA2FAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwlgAANBY AADkWAAA9FgAAAZZAAAAAAAAiFYAALRWAADKVgAA1lYAAJhWAACoVgAABFcAABBXAAAcVwAAdlYA AGZWAABUVgAA7lYAAOJWAABIVgAAbFkAAFpZAABMWwAAPFsAACxbAAAWWwAAClsAAABbAAD0WgAA 5loAANZaAADKWgAAvloAALJaAACkWgAAlloAAIhaAAB6WgAAXlsAAH5ZAAA+WgAAJloAAFhaAAD2 WQAA3FkAABBaAABGWQAAaloAAMBZAACYWQAAjFkAAKxZAAAAAAAAJlkAAAAAAAA4VwAARlcAAKpY AABSVwAAZlcAAJhYAACGWAAAbFgAAF5YAABMWAAAPlgAAC5YAAAiWAAAFlgAAAZYAAD0VwAA5FcA ANZXAADCVwAAtFcAAKBXAACSVwAAelcAAAAAAAApA2xzdHJjbXBBAABdAUdldFByb2ZpbGVJbnRB AACPAUdldFZlcnNpb25FeEEAUwFHZXRQcm9jQWRkcmVzcwAA3wFMb2FkTGlicmFyeUEAAI8CU2V0 RXJyb3JNb2RlAAAvA2xzdHJjcHlBAAA4AUdldE1vZHVsZUZpbGVOYW1lQQAANQNsc3RybGVuQQAA MgNsc3RyY3B5bkEAJgNsc3RyY2F0QQAAcAFHZXRTeXN0ZW1EaXJlY3RvcnlBACsAQ29weUZpbGVB ACwDbHN0cmNtcGlBAIwARXhpdFByb2Nlc3MAS0VSTkVMMzIuZGxsAACMAERlc3Ryb3lJY29uAJ4B TG9hZEljb25BAJUARGlzcGF0Y2hNZXNzYWdlQQAAggJUcmFuc2xhdGVNZXNzYWdlAAB/AlRyYW5z bGF0ZUFjY2VsZXJhdG9yQQAqAUdldE1lc3NhZ2VBAJYBTG9hZEFjY2VsZXJhdG9yc0EAqwFMb2Fk U3RyaW5nQQDzAVJlZ2lzdGVyQ2xhc3NFeEEAAJoBTG9hZEN1cnNvckEAkQJVcGRhdGVXaW5kb3cA AFkAQ3JlYXRlV2luZG93RXhBAI4ARGVzdHJveVdpbmRvdwC7AEVuZFBhaW50AACvAERyYXdUZXh0 QQDwAEdldENsaWVudFJlY3QADABCZWdpblBhaW50AACEAERlZldpbmRvd1Byb2NBAAC+AU1lc3Nh Z2VCb3hBAAACUmVnaXN0ZXJXaW5kb3dNZXNzYWdlQQAA4AFQb3N0UXVpdE1lc3NhZ2UAkwBEaWFs b2dCb3hQYXJhbUEAuQBFbmREaWFsb2cAVVNFUjMyLmRsbAAAWwFSZWdDbG9zZUtleQB7AVJlZ1F1 ZXJ5VmFsdWVFeEEAAHIBUmVnT3BlbktleUV4QQCGAVJlZ1NldFZhbHVlRXhBAABfAVJlZ0NyZWF0 ZUtleUV4QQBBRFZBUEkzMi5kbGwAAHkAU2hlbGxfTm90aWZ5SWNvbkEAU0hFTEwzMi5kbGwAOgFH ZXRNb2R1bGVIYW5kbGVBAABmAUdldFN0YXJ0dXBJbmZvQQDaAEdldENvbW1hbmRMaW5lQQCOAUdl dFZlcnNpb24AALQBSGVhcEFsbG9jAMsCVGVybWluYXRlUHJvY2VzcwAACQFHZXRDdXJyZW50UHJv Y2VzcwDbAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAwQBGcmVlRW52aXJvbm1lbnRTdHJpbmdz QQDCAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAEDV2lkZUNoYXJUb011bHRpQnl0ZQAZAUdldEVu dmlyb25tZW50U3RyaW5ncwAbAUdldEVudmlyb25tZW50U3RyaW5nc1cAAJgCU2V0SGFuZGxlQ291 bnQAAGgBR2V0U3RkSGFuZGxlAAAoAUdldEZpbGVUeXBlALgBSGVhcERlc3Ryb3kAtgFIZWFwQ3Jl YXRlAADxAlZpcnR1YWxGcmVlALoBSGVhcEZyZWUAAFcCUnRsVW53aW5kAA4DV3JpdGVGaWxlAO4C VmlydHVhbEFsbG9jAAC9AUhlYXBSZUFsbG9jAM8AR2V0Q1BJbmZvAMkAR2V0QUNQAABGAUdldE9F TUNQAAACAk11bHRpQnl0ZVRvV2lkZUNoYXIA3AFMQ01hcFN0cmluZ0EAAN0BTENNYXBTdHJpbmdX AABpAUdldFN0cmluZ1R5cGVBAABsAUdldFN0cmluZ1R5cGVXAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAFjZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA MQAAAFNPRlRXQVJFXE1pY3Jvc29mdFxXaW5kb3dzIE1lc3NhZ2luZyBTdWJzeXN0ZW0AAE1haWwA AAAATUFQSQAAAABNQVBJUmVzb2x2ZU5hbWUATUFQSURldGFpbHMATUFQSUFkZHJlc3MATUFQSUZy ZWVCdWZmZXIAAE1BUElEZWxldGVNYWlsAABNQVBJU2F2ZU1haWwAAAAATUFQSVJlYWRNYWlsAAAA AE1BUElGaW5kTmV4dAAAAABNQVBJU2VuZERvY3VtZW50cwAAAE1BUElTZW5kTWFpbAAAAABNQVBJ TG9nb2ZmAABNQVBJTG9nb24AAABNQVBJMzIuRExMAABOYXZpZGFkLmV4ZQBUZSBlc3RhbW9zIG1p cmFuZG8uLgAAAAAgIiUxIiAlKgAAAABcd2luc3ZyYy5leGUAAAAAZXhlZmlsZVxzaGVsbFxvcGVu XGNvbW1hbmQAAFdpbjMyQmFzZVNlcnZpY2VNT0QAU09GVFdBUkVcTWljcm9zb2Z0XFdpbmRvd3Nc Q3VycmVudFZlcnNpb25cUnVuAAAAXHdpbnN2cmMudnhkAAAAAExvIGVzdGFtb3MgbWlyYW5kby4u LgAAAFVJAABubwAARHVsY2U/AABTT0ZUV0FSRVxOYXZpZGFkAAAAAHRjbGljawAAVGFza2JhckNy ZWF0ZWQAAGJ1ZW5hIGVsZWNjaW9uLi4uAAAATGFtZW50YWJsZW1lbnRlIGNheW8gZW4gbGEgdGVu dGFjaW9uIHkgcGVyZGlvIHN1IGNvbXB1dGFkb3JhAAAAAEZlbGl6IE5hdmlkYWQAAACPHUAAAgAA AAAAAAAFAADACwAAAAAAAAAdAADABAAAAAAAAACWAADABAAAAAAAAACNAADACAAAAAAAAACOAADA CAAAAAAAAACPAADACAAAAAAAAACQAADACAAAAAAAAACRAADACAAAAAAAAACSAADACAAAAAAAAACT AADACAAAAAAAAAADAAAABwAAAAoAAACMAAAA/////wAKAAAQAAAAIAWTGQAAAAAAAAAAAAAAAAAA AAACAAAAsFNAAAgAAACEU0AACQAAAFhTQAAKAAAANFNAABAAAAAIU0AAEQAAANhSQAASAAAAtFJA ABMAAACIUkAAGAAAAFBSQAAZAAAAKFJAABoAAADwUUAAGwAAALhRQAAcAAAAkFFAAHgAAACAUUAA eQAAAHBRQAB6AAAAYFFAAPwAAABcUUAA/wAAAExRQAD4AwAAAAAAAAECBAgAAAAApAMAAGCCeYIh AAAAAAAAAKbfAAAAAAAAoaUAAAAAAACBn+D8AAAAAEB+gPwAAAAAqAMAAMGj2qMgAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACB/gAAAAAAAED+AAAAAAAAtQMAAMGj2qMgAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACB/gAAAAAAAEH+AAAAAAAAtgMAAM+i5KIaAOWi6KJbAAAAAAAAAAAAAAAAAAAAAACB/gAA AAAAAEB+of4AAAAAUQUAAFHaXtogAF/aatoyAAAAAAAAAAAAAAAAAAAAAACB09je4PkAADF+gf4A AAAA6mRAAOpkQAAAACAAIAAgACAAIAAgACAAIAAgACgAKAAoACgAKAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIABIABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAIQAhACE AIQAhACEAIQAhACEAIQAEAAQABAAEAAQABAAEACBAIEAgQCBAIEAgQABAAEAAQABAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAEAAQABAAEAAQABAAggCCAIIAggCCAIIAAgACAAIAAgAC AAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACABAAEAAQABAAIAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABgADAAAAQAAAgAQAAABoAACABQAAAIAAAIAGAAAAoAAAgAkAAAC4AACA DgAAANAAAIAAAAAAAAAAAAAAAAAAAAMAAQAAAPAAAIACAAAACAEAgAMAAAAgAQCAAAAAAAAAAAAA AAAAAAABAG0AAAA4AQCAAAAAAAAAAAAAAAAAAAACAGUAAABQAQCAZwAAAGgBAIAAAAAAAAAAAAAA AAAAAAEABwAAAIABAIAAAAAAAAAAAAAAAAAAAAEAbQAAAJgBAIAAAAAAAAAAAAAAAAAAAAIAggAA ALABAICDAAAAyAEAgAAAAAAAAAAAAAAAAAAAAQAJBAAA4AEAAAAAAAAAAAAAAAAAAAAAAQAJBAAA 8AEAAAAAAAAAAAAAAAAAAAAAAQAJBAAAAAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAEAIAAAAAAAAA AAAAAAAAAAAAAQAJBAAAIAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAMAIAAAAAAAAAAAAAAAAAAAAA AQAJBAAAQAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAUAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAYAIA AAAAAAAAAAAAAAAAAAAAAQAJBAAAcAIAAIByAADoAgAAAAAAAAAAAABodQAAKAEAAAAAAAAAAAAA uHYAAOgCAAAAAAAAAAAAALh5AABKAAAAAAAAAAAAAAAIewAAhgAAAAAAAAAAAAAAGHoAAO4AAAAA AAAAAAAAAJB7AABUAAAAAAAAAAAAAAAIegAAEAAAAAAAAAAAAAAAkHYAACIAAAAAAAAAAAAAAKB5 AAAUAAAAAAAAAAAAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA ////APAP/w8AAPD/D/DwAP8P8A8PD/8PD/Dw8PDw//Dw8PDwDw//Dw/w8PDw8PAA8PDw8A8P//Dw DwDw8ADw//Dw8PAPD/AA8A/w/w/w8AD/D/DwDw/////////////////w8A8AAAAAAAAAAAAAAAAA APAP///////////////////wDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA /w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDw Dw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8P D/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8P APDw8AD/Dw/wD/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/w D/AA8PAPDwDw8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A8PAPDw8AD/Dw/wD/AA8PAPDwDw 8PAA/w8P8A/wAPDwDw8A8PDwAP8PD/AP8ADw8A////////////////////DwAAAAAAAAAAAAAAAA AAAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAoAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD/ /wAA////AAAPDw8AAPAADw8PAAAAAPAPAPAA8A/w8A8P//////DwDwAAAAAAAPAP////////8A8P APDw8ADwDw8A8PDwAPAPDwDw8PAA8A8PAPDw8ADwDw8A8PDwAPAPDwDw8PAA8A8PAPDw8ADwDw8A 8PDwAPAP////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQACACAgEAABAAQA6AIAAAEAEBAQAAEABAAo AQAAAgAAAAAAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA//// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj//4AAAAAAAAAAAAAAAI/8zMzP +AAAAAAAAAAAAI/8zMzMzM//gAAAAAAAAI//zMzMzMzM//+AAAAAAAj//MTMzMzMTM//+AAAAACP /8zMTMAMxMzM//+AAAAP///ETMAAAAzETP//8AAAiI/8zMTAAAAMTMzP+IgAAAeIjMTMAAAAAMxM yIhwAAAAeIxERAAAAABERMiHAAAAAAd8RERACIAERETHcAAAAAAADEREQA/wBEREwAAAAAAAAAAE RERABERETAAAAAAAAAAAAARERERERAAAAAAAAAAAAAAAAEREAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ////////////////////////////////////////////+B///8AD//8AAH/8AAAf+AAAD/AAAAfg AAACQAAAAoAAAACAAAABwAAAA+AAAAfwAAAP/AAAP/8AAH//wAH///gf//////////////////// //////////////////8AAAEAAQAgIBAAAQAEAOgCAAADAAAAAAAAAAAAEAAmAEYAaQBsAGUAAACA AGkARQAmAHgAaQB0AAAAkAAmAEgAZQBsAHAAAACAAGgAJgBBAGIAbwB1AHQAIAAuAC4ALgAAAAAA AAAAABAAPwBoAAAAkAAvAGgAAADAAMgAAAAAAAQAFgARAOYASwAAAAAAQQBiAG8AdQB0AAAACABT AHkAcwB0AGUAbQAAAAAAAwAAUAAAAAAOAAkAEAAQAAIA//+CAP//awAAAIAAAlAAAAAAMQAKAHcA CAD/////ggBOAGEAdgBpAGQAYQBkACAAVgBlAHIAcwBpAG8AbgAgADEALgAwAAAAAAAAAAJQAAAA ADEAFAB3AAgA/////4IAQwBvAHAAeQByAGkAZwBoAHQAIAAoAEMAKQAgADIAMAAwADAAAAAAAAAA AQADUAAAAADDAAYAHgALAAEA//+AAE8ASwAAAAAAAABCCMiAAAAAAAEAAAAAAJAAJgAAAAAAAAAL AEMAbwBtAGkAYwAgAFMAYQBuAHMAIABNAFMAAAAAAAEAAVAAAAAADAAHAHYAFgDoA///gABOAHUA bgBjAGEAIABwAHIAZQBzAGkAbwBuAGEAcgAgAGUAcwB0AGUAIABiAG8AdABvAG4AAAAAAAAAAAAA AAAAAAAAAAAAAAAHAE4AYQB2AGkAZABhAGQAAAAAAAwASABlAGwAbABvACAAVwBvAHIAbABkACEA AAAAAAcATgBBAFYASQBEAEEARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_0057_01C0538F.AD85F500-- From owner-ietf-ediint@mail.imc.org Mon Nov 20 17:12:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28327 for ; Mon, 20 Nov 2000 17:12:29 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA12765 for ietf-ediint-bks; Mon, 20 Nov 2000 13:42:41 -0800 (PST) Received: from fhufw.fhu.disa.mil (fhu2.fhu.disa.mil [207.132.160.62]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA12755 for ; Mon, 20 Nov 2000 13:42:30 -0800 (PST) Received: from fhu2.fhu.disa.mil by fhufw.fhu.disa.mil via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 20 Nov 2000 20:35:48 UT Received: by fhu2.fhu.disa.mil with Internet Mail Service (5.5.2650.10) id ; Mon, 20 Nov 2000 14:43:12 -0700 Message-ID: <7C07F1B20FE0D21185670020484009DC02721845@fhu2.fhu.disa.mil> From: "Jones, Tom" To: "'peter.blanchard@ec-pay.com.au'" , "owner-ietf-ediint@mail.imc.org" , "'Gunther Schadow'" Cc: Rik Drummond , Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org, dick@8760.com Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) CONTAINS A V IRUS....... Date: Mon, 20 Nov 2000 14:43:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My name is tom Jones I work at the JITC. I have been informed by our LANOps that your HL7 documents is carrying a virus called the navidad virus. The number of the LANOps Person in charge is Carlos Bazan at 520 538-5286. This warning should be given widest dissemination. Regards, Tom Jones Task Leader for BIA DTS Voice 520 538-5264 (DSN 879) Facs 520 5383-9843 Email jones4t@fhu.disa.mil Joint Interoperability Test Command Bldg 57305, SOB, A7, Tom Jones Fort Huachuca AZ 85613-7020 -----Original Message----- From: Peter Blanchard [mailto:peter.blanchard@ec-pay.com.au] Sent: Monday, November 20, 2000 2:50 PM To: owner-ietf-ediint@mail.imc.org; 'Gunther Schadow' Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org; dick@8760.com Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Wes, You make some excellent points, I want to focus on a few that I believe are critical in moving forward. >a) there is interest in having a healthcare group give its imprimatur to >AS2, since it "rounds out" the Internet protocols to make a complete package >for HIPAA-compliant, B2B messaging based on ubiquitous Internet protocols >such as HTTP, FTP and SNMP. Many people (not specifically in healthcare) are confused by the number of "B2B standards" that exist, for example: - Vendor initiated (BizTalk and SOAP) - Consortia initiated (ebXML by OASIS and UN/CEFACT, XML Protocols Activity by the World Wide Web Consortium ) - Internet related standards bodies initiated (IETF - EDIINT ASx, IETF - BEEP) - Industry specific standards bodies initiated (HL7, GISB, UIG, AIAG, etc.) Not to mention all the proprietary initiatives. They look at all these "standards" and they're afraid they'll choose the "wrong standard". I believe industry organizations, like HL7, play a critical role in helping people choose a B2B standard that's appropriate for their needs. >b) there is some despair at seeing AS2 get out of IETF before quantum >computers pretty much obsolete everything based on computers with >deterministic states (this last was an attempt at humor) Actually this is an excellent point. The IETF is very particular when it comes to designing/endorsing standards, as it should be. Some of the recent concerns with AS1 (see Ned Freed's comments attached) raise the probabilities of a longer delay for AS2, because the non-GISB portion of AS2 depends on AS1. I'm not aware of any issues with the GISB portion of AS2. >c) there is a sense that being an ANSI Standard is a requirement if one >desires to get the government to mandate its use. The Department of Energy, via the Federal Energy Regulatory Commission, mandated use of the GISB standard and I don't believe it is an ANSI standard. Perhaps Rae McQuade, Executive Director of GISB (gisb1@aol.com), can comment on this. I certainly don't understand many of the idiosyncrasies of HL7 Standards versus Recommendations so I'll listen and learn as this discussion evolves. I have been an active participant in many of the initiatives mentioned above including: ebXML, GISB, UIG, W3C XP, and of course IETF EDIINT. I look forward to working with the HL7 organization on this very important decision during the coming months. Regards, Dick Brooks http://www.8760.com/ -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Rishel,Wes Sent: Monday, November 20, 2000 12:07 AM To: 'Gunther Schadow'; Dick Brooks Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) For many reasons it would be more desirable to be a Standard, but I am not sure that there aren't some shades of gray, particularly if the difference in the required time is important. I will wait to hear from Gunther about the HIPAA issue, but I am suspecting that the following is true: a) there is interest in having a healthcare group give its imprimatur to AS2, since it "rounds out" the Internet protocols to make a complete package for HIPAA-compliant, B2B messaging based on ubiquitous Internet protocols such as HTTP, FTP and SNMP. b) there is some despair at seeing AS2 get out of IETF before quantum computers pretty much obsolete everything based on computers with deterministic states (this last was an attempt at humor) c) there is a sense that being an ANSI Standard is a requirement if one desires to get the government to mandate its use. I would take issue with item (c). It is surely helpful to be a standard, but it is also helpful to be any sort of publication of an ANSI-accredited standards development organization. Furthermore, unless someone knows something specific, I would be skeptical that the current administration would introduce another delay in the final rule on security by attempting to add AS2 at this late date. Rather than a government mandate, I suspect that the benefit of an HL7 imprimatur, and perhaps a profile or two, would be to assist in promoting the Internet and AS2 as means to exchange the HIPAA transactions without reliance on value added networks. At the same time it would be very valuable to HL7 to have ways to exchange standard (old syntax) HL7 messages and HL7-XML messages over the Internet using the same infrastructure (integration brokers and servers) as are being sold for other B2B applications in healthcare, the power industry, etc. If this model is correct a Standard is better, but a Recommendation also provides substantial benefit. One approach would be to create a Recommendation first and follow it up with a Standard after some operational experience has been obtained. > -----Original Message----- > From: Gunther Schadow [mailto:gunther@aurora.regenstrief.org] > Sent: Saturday, November 18, 2000 8:06 PM > To: dick@8760.com > Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > Dick Brooks wrote: > > > > Thanks Wes. > > > > Based on your description I would anticipate the EDIINT AS2 > spec taking the > > "Recommendation" route, IF the group decides to go forward. > Do you see it > > the same way? > > Dick, I actually do see it the other way. The EDIINT work in > HL7 as we > discussed it in relation to HIPAA is only useful if we end up > with an ANSI > approved standard. That must be a standard, not a recommendation. > > I'll fill in Wes on the HIPAA issue under separate cover. Glad you can > make it for 1/8/2001. Thank you for your help. > > regards, > -Gunther > From owner-ietf-ediint@mail.imc.org Mon Nov 20 17:27:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00441 for ; Mon, 20 Nov 2000 17:27:04 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA13006 for ietf-ediint-bks; Mon, 20 Nov 2000 13:51:17 -0800 (PST) Received: from dell_srv.bankers.org (ip-208.49.165.50.Northpoint-DSL.gblx.net [208.49.165.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13000 for ; Mon, 20 Nov 2000 13:51:13 -0800 (PST) Received: by DELL_SRV with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 13:46:04 -0800 Message-ID: <8B3A9B93860AD411A9E800A0C90CD4680D7DF9@DELL_SRV> From: Peter Yeatrakas To: "'Jones, Tom'" , "'peter.blanchard@ec-pay.com.au'" , "owner-ietf-ediint@mail.imc.org" , "'Gunther Schadow'" Cc: Rik Drummond , Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org, dick@8760.com Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) CONTAINS A V IRUS....... Date: Mon, 20 Nov 2000 13:46:04 -0800 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: Thanks; Outlook 2000 give a similar message preventing me from opening the attachment. -----Original Message----- From: Jones, Tom [mailto:jones4t@fhu.disa.mil] Sent: Monday, November 20, 2000 1:43 PM To: 'peter.blanchard@ec-pay.com.au'; owner-ietf-ediint@mail.imc.org; 'Gunther Schadow' Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org; dick@8760.com Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) CONTAINS A V IRUS....... My name is tom Jones I work at the JITC. I have been informed by our LANOps that your HL7 documents is carrying a virus called the navidad virus. The number of the LANOps Person in charge is Carlos Bazan at 520 538-5286. This warning should be given widest dissemination. Regards, Tom Jones Task Leader for BIA DTS Voice 520 538-5264 (DSN 879) Facs 520 5383-9843 Email jones4t@fhu.disa.mil Joint Interoperability Test Command Bldg 57305, SOB, A7, Tom Jones Fort Huachuca AZ 85613-7020 -----Original Message----- From: Peter Blanchard [mailto:peter.blanchard@ec-pay.com.au] Sent: Monday, November 20, 2000 2:50 PM To: owner-ietf-ediint@mail.imc.org; 'Gunther Schadow' Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org; dick@8760.com Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Wes, You make some excellent points, I want to focus on a few that I believe are critical in moving forward. >a) there is interest in having a healthcare group give its imprimatur to >AS2, since it "rounds out" the Internet protocols to make a complete package >for HIPAA-compliant, B2B messaging based on ubiquitous Internet protocols >such as HTTP, FTP and SNMP. Many people (not specifically in healthcare) are confused by the number of "B2B standards" that exist, for example: - Vendor initiated (BizTalk and SOAP) - Consortia initiated (ebXML by OASIS and UN/CEFACT, XML Protocols Activity by the World Wide Web Consortium ) - Internet related standards bodies initiated (IETF - EDIINT ASx, IETF - BEEP) - Industry specific standards bodies initiated (HL7, GISB, UIG, AIAG, etc.) Not to mention all the proprietary initiatives. They look at all these "standards" and they're afraid they'll choose the "wrong standard". I believe industry organizations, like HL7, play a critical role in helping people choose a B2B standard that's appropriate for their needs. >b) there is some despair at seeing AS2 get out of IETF before quantum >computers pretty much obsolete everything based on computers with >deterministic states (this last was an attempt at humor) Actually this is an excellent point. The IETF is very particular when it comes to designing/endorsing standards, as it should be. Some of the recent concerns with AS1 (see Ned Freed's comments attached) raise the probabilities of a longer delay for AS2, because the non-GISB portion of AS2 depends on AS1. I'm not aware of any issues with the GISB portion of AS2. >c) there is a sense that being an ANSI Standard is a requirement if one >desires to get the government to mandate its use. The Department of Energy, via the Federal Energy Regulatory Commission, mandated use of the GISB standard and I don't believe it is an ANSI standard. Perhaps Rae McQuade, Executive Director of GISB (gisb1@aol.com), can comment on this. I certainly don't understand many of the idiosyncrasies of HL7 Standards versus Recommendations so I'll listen and learn as this discussion evolves. I have been an active participant in many of the initiatives mentioned above including: ebXML, GISB, UIG, W3C XP, and of course IETF EDIINT. I look forward to working with the HL7 organization on this very important decision during the coming months. Regards, Dick Brooks http://www.8760.com/ -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Rishel,Wes Sent: Monday, November 20, 2000 12:07 AM To: 'Gunther Schadow'; Dick Brooks Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) For many reasons it would be more desirable to be a Standard, but I am not sure that there aren't some shades of gray, particularly if the difference in the required time is important. I will wait to hear from Gunther about the HIPAA issue, but I am suspecting that the following is true: a) there is interest in having a healthcare group give its imprimatur to AS2, since it "rounds out" the Internet protocols to make a complete package for HIPAA-compliant, B2B messaging based on ubiquitous Internet protocols such as HTTP, FTP and SNMP. b) there is some despair at seeing AS2 get out of IETF before quantum computers pretty much obsolete everything based on computers with deterministic states (this last was an attempt at humor) c) there is a sense that being an ANSI Standard is a requirement if one desires to get the government to mandate its use. I would take issue with item (c). It is surely helpful to be a standard, but it is also helpful to be any sort of publication of an ANSI-accredited standards development organization. Furthermore, unless someone knows something specific, I would be skeptical that the current administration would introduce another delay in the final rule on security by attempting to add AS2 at this late date. Rather than a government mandate, I suspect that the benefit of an HL7 imprimatur, and perhaps a profile or two, would be to assist in promoting the Internet and AS2 as means to exchange the HIPAA transactions without reliance on value added networks. At the same time it would be very valuable to HL7 to have ways to exchange standard (old syntax) HL7 messages and HL7-XML messages over the Internet using the same infrastructure (integration brokers and servers) as are being sold for other B2B applications in healthcare, the power industry, etc. If this model is correct a Standard is better, but a Recommendation also provides substantial benefit. One approach would be to create a Recommendation first and follow it up with a Standard after some operational experience has been obtained. > -----Original Message----- > From: Gunther Schadow [mailto:gunther@aurora.regenstrief.org] > Sent: Saturday, November 18, 2000 8:06 PM > To: dick@8760.com > Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > Dick Brooks wrote: > > > > Thanks Wes. > > > > Based on your description I would anticipate the EDIINT AS2 > spec taking the > > "Recommendation" route, IF the group decides to go forward. > Do you see it > > the same way? > > Dick, I actually do see it the other way. The EDIINT work in > HL7 as we > discussed it in relation to HIPAA is only useful if we end up > with an ANSI > approved standard. That must be a standard, not a recommendation. > > I'll fill in Wes on the HIPAA issue under separate cover. Glad you can > make it for 1/8/2001. Thank you for your help. > > regards, > -Gunther > From owner-ietf-ediint@mail.imc.org Mon Nov 20 18:30:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08496 for ; Mon, 20 Nov 2000 18:30:13 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA14818 for ietf-ediint-bks; Mon, 20 Nov 2000 14:55:15 -0800 (PST) Received: from c1plenaexi02.commerceone.com (mail2.commerceone.com [12.22.60.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14813 for ; Mon, 20 Nov 2000 14:55:14 -0800 (PST) Received: by c1plenaexi02.commerceone.com with Internet Mail Service (5.5.2652.78) id ; Mon, 20 Nov 2000 14:52:32 -0800 Message-ID: <7B644E8BF5E0D31184C400D0B712F97FAEB0AC@c1plenaexi02.commerceone.com> From: ANTIGEN_C1PLENAEXI02 To: "'wes.rishel@gartner.com'" , "'gunther@aurora.regenstrief.org'" , "'rvd2@worldnet.att.net'" , "'Kepa.Zubeldia@claredi.com'" , "'clem@regen.rg.iupui.edu'" , "'gcrough@cyclonecommerce.com'" , "'Beth@drummondgroup.com'" , "'david@drummondgroup.com'" , "'GISB1@aol.com'" , "'ietf-ediint@imc.org'" , "'dick@8760.com'" Subject: Antigen found W32/Navidad.32768.Worm virus Date: Mon, 20 Nov 2000 14:52:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Antigen for Exchange found Navidad.exe infected with W32/Navidad.32768.Worm virus. The file is currently Deleted. The message, "RE: HL7 Standards Process (was RE: EDIINT and HIPAA)", was sent from Peter Blanchard and was discovered in IMC Queues\Inbound located at Distrivision/NORTHAMERICA/C1PLENAEXI02. From owner-ietf-ediint@mail.imc.org Mon Nov 20 18:33:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09022 for ; Mon, 20 Nov 2000 18:33:57 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14403 for ietf-ediint-bks; Mon, 20 Nov 2000 14:40:38 -0800 (PST) Received: from c1plenaexi02.commerceone.com (mail2.commerceone.com [12.22.60.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14398 for ; Mon, 20 Nov 2000 14:40:37 -0800 (PST) Received: by c1plenaexi02.commerceone.com with Internet Mail Service (5.5.2652.78) id ; Mon, 20 Nov 2000 14:37:45 -0800 Message-ID: <7B644E8BF5E0D31184C400D0B712F97FAEB0AA@c1plenaexi02.commerceone.com> From: ANTIGEN_C1PLENAEXI02 To: "'wes.rishel@gartner.com'" , "'dick@8760.com'" , "'rvd2@worldnet.att.net'" , "'Kepa.Zubeldia@claredi.com'" , "'clem@regen.rg.iupui.edu'" , "'gcrough@cyclonecommerce.com'" , "'Beth@drummondgroup.com'" , "'david@drummondgroup.com'" , "'GISB1@aol.com'" , "'ietf-ediint@imc.org'" Subject: Antigen found W32/Navidad.32768.Worm virus Date: Mon, 20 Nov 2000 14:37:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Antigen for Exchange found Navidad.exe infected with W32/Navidad.32768.Worm virus. The file is currently Deleted. The message, "Re: HL7 Standards Process (was RE: EDIINT and HIPAA)", was sent from Peter Blanchard and was discovered in IMC Queues\Inbound located at Distrivision/NORTHAMERICA/C1PLENAEXI02. From owner-ietf-ediint@mail.imc.org Tue Nov 21 01:31:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19399 for ; Tue, 21 Nov 2000 01:31:55 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA21071 for ietf-ediint-bks; Mon, 20 Nov 2000 21:58:59 -0800 (PST) Received: from prserv.net (out2.prserv.net [32.97.166.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA21067 for ; Mon, 20 Nov 2000 21:58:57 -0800 (PST) Received: from claredi.com ([32.102.253.44]) by prserv.net (out2) with SMTP id <20001121055927202027a4a5e>; Tue, 21 Nov 2000 05:59:32 +0000 Message-ID: <3A19BE12.E56EA2C7@claredi.com> Date: Mon, 20 Nov 2000 17:13:06 -0700 From: Kepa Zubeldia X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: dick@8760.com CC: "Rishel,Wes" , Gunther Schadow , Rik Drummond , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) References: 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 Dick, Are you volunteering to create an interoperability profile for digital signatures of the HIPAA standard transactions ? X12, NCPDP, and X12+HL7 (in which the signature could be on the HL7 or on the X12 components) are the immediate needs. However, keep in mind that NCPDP could also be in EDIFACT syntax (e.g. prescriptions) and HL7 could be in different syntaxes. But, for HIPAA purposes, at this time we need something for the 275 attachment only. Other HL7 messages could come later through other interoperability profiles. If we have a very narrow scope (HIPAA transactions as they were released in the Final Rule, plus attachments as we know them) then it is possible to get an agreement, even if there is not yet an agreement on other issues or on PKI issues. Other volunteers ? Kepa Dick Brooks wrote: > > Thanks Wes. > > Based on your description I would anticipate the EDIINT AS2 spec taking the > "Recommendation" route, IF the group decides to go forward. Do you see it > the same way? > > FYI - other groups that have adopted AS2 have found it necessary to define > "interoperability profiles". These profiles identify the exact set of > "options" from AS2 that everyone in the "trading community" agrees to > follow, in order to ensure interoperability. For example, GISB has already > defined an AS2 interoperability profile and the New York Collaborative, in > accordance with the Public Service Commission regulations, is in the process > of defining their interoperability profile. I'm familiar with both these > groups and the process used to develop their profiles. I could help HL7 > develop an AS2 interoperability profile, if the group decides to pursue this > approach. > > Regards, > > 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: Rishel,Wes [mailto:wes.rishel@gartner.com] > > Sent: Friday, November 17, 2000 8:32 PM > > To: 'dick@8760.com'; Gunther Schadow > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > Subject: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > As the chair-elect of HL7 I would like to respond to DB's > > question about HL7 > > process. > > > > HL7 has two kinds of specifications that are published using slighly > > different processes: a Standard is submitted to ANSI for > > certification once > > it has passed ballot; a Recommendation is published by HL7 but is not > > submitted to ANSI and does not become an ANSI standard. Some > > Recommendations > > have had substantial acceptance among the HL7 community, including it's > > "lower level protocols" which define ways to reliably pass > > discrete messages > > over RS-232 and TCP, and were published sometime in the early 1990s. > > > > A Standard originates under the sponsorship of a Technical > > Committee. If HL7 > > were to create a Standard for EDIINT it would be the Control/Query > > committee. It is balloted at the committee level. (Actually anyone can > > participate in the committee ballot, but in practice those who > > choose to do > > so are usually those who participate in, or follow the work of, the > > Technical Committee.) When it passes a committee level ballot it is > > submitted for ballot by the full HL7 Working Group (which is the entire > > organization). If it passes at this level it is automatically submitted to > > ANSI for certification. The ANSI review allows time for public > > comment, but > > it is primarily a certification that the process was fair and consistent > > with our bylaws. To date, have never had an issue arise that prevented or > > delayed the certification process. > > > > In addition to Technical Committees HL7 has Special Interest > > Groups. Gunther > > is co-chair of our SIG on security. Strictly speaking, a SIG > > cannot initiate > > the balloting of a standard; but SIGs can prepare such a document, and > > obtain the consent of a Technical Committee which sponsors the ballot. > > > > The other kind of document, the Recommendation, is easier to get out the > > door. It can be originated by a SIG, and it has only one level of > > balloting. > > The majority that is required to pass a Recommendation is less severe than > > the majority required to pass a Standard (67% vs. 90%). > > > > Ballots are conducted using the Web. Assuming that both ballots pass an > > energetic committee can easily complete the entire process in two of our > > three-per-year Working Group meetings (roughly 8 months elapsed time). (Of > > course most committees have substantial time invested in debating the > > document before it begins the process.) > > > > Most of the meetings required at certain points in the process can be > > handled using conference calls; in theory a REALLY motivated > > committee could > > accomplish the two-level ballot in five months and then wait about three > > months for ANSI certication. (That is a theoretical figure that has never > > been realized in practise.) > > > > Recommendations can be passed in roughly four months. > > > > Best regards, > > > > Wes Rishel > > Research Director > > Healthcare Industry Research & Advisory Services > > GartnerGroup > > Alameda, CA > > Client inquiries: call +1-203-316-1288 or email to indapps@gartner.com > > wes.rishel@gartner.com > > 510 522 8135 > > 510 521 2423 (fax) > > > > > > > > > -----Original Message----- > > > From: Dick Brooks [mailto:dick@8760.com] > > > Sent: Thursday, November 02, 2000 10:27 AM > > > To: Gunther Schadow > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org; Dick > > > Brooks > > > Subject: RE: EDIINT and HIPAA > > > > > > > > > > > > I'm not familiar with the HL7 standards process, all of > > > my experience > > > has been with IETF, DISA, GISB and recently ebXML. Each of these > > > organizations has a different process for developing standards. If we > > > brought AS2 to HL7 today, how long would it take to become an > > > ANSI standard? > > > I would like to read HL7's operational process document, can > > > you provide a > > > pointer? > > > > > > From owner-ietf-ediint@mail.imc.org Tue Nov 21 01:31:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19407 for ; Tue, 21 Nov 2000 01:31:56 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA21079 for ietf-ediint-bks; Mon, 20 Nov 2000 21:59:13 -0800 (PST) Received: from prserv.net (out2.prserv.net [32.97.166.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA21075 for ; Mon, 20 Nov 2000 21:59:12 -0800 (PST) Received: from claredi.com ([32.102.253.44]) by prserv.net (out2) with SMTP id <2000112105595320204v4oo6e>; Tue, 21 Nov 2000 05:59:56 +0000 Message-ID: <3A19CC7E.8FA1ADD4@claredi.com> Date: Mon, 20 Nov 2000 18:14:38 -0700 From: Kepa Zubeldia X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dick Brooks CC: "Rishel,Wes" , "'Gunther Schadow'" , Rik Drummond , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) References: 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 Dick, Wes, Now I need to throw in my $.02 Under HIPAA, the Secretary of HHS is required to adopt a standard for electronic signatures of the HIPAA transactions. Simple and reduced scope. The Secretary is required to adopt Standards (with capital S) developed by a SDO from the American National Standards Institute. If no such standard is available, the Secretary can create her own standards. The HIPAA Security Final Rule will reflect security standards created by HHS because there are no other security standards for healthcare developed by an ANSI SDO that meet the security requirements expressed in the HIPAA Law. However, the security final rule will NOT have a standard for electronic signatures, and this standard will come out in a later final rule. If the healthcare SDOs were to agree on an ANSI standard for digital signatures that could be used for the HIPAA transactions, and a very specific "implementation guide" on how to use this standard to sign the HIPAA transactions, the Secretary would have a much easier job in adopting such standard. Until this happens, the digital signature final rule may have to be put on hold, as the DHHS does not want to create standards in this area in an ivory tower (i.e. in a vacuum). In addition, the HIPAA electronic signature standard must be adopted in conjunction with the Department of Commerce. Does this shed some light ? Do you want EDIINT to be adopted by the Secretary as the HIPAA digital signature standard ? Then, I think you know what to do. Please understand that I am not making any promises here. I am stating something that will make easier for the NCVHS to recommend a standard for the Secretary to adopt. This is a self-serving request as I am one of the NCVHS members. The NCVHS looked at the possible standards last month, and as a result, I have sent invitations to the affected SDOs to work under HISB in coming up with something "adoptable". I think that if the group of experts on this list was to work on such task with the ANSI SDOs, then we could have something that benefits the entire healthcare industry. However, if we let the scope creep to cover other topics, such as PKI or "trust" issues, then the wheels could slow down. I hope that having a "HIPAA Signature Implementation Guide" does not preclude other "implementation guides" for things like encryption, consent form signature, multiple signatures, counter signatures, etc. that are also necessary but not "mandated" by HIPAA at this time. Keep up the good work. Kepa Dick Brooks wrote: > > Wes, > > You make some excellent points, I want to focus on a few that I believe are > critical in moving forward. > > >a) there is interest in having a healthcare group give its imprimatur to > >AS2, since it "rounds out" the Internet protocols to make a complete > package > >for HIPAA-compliant, B2B messaging based on ubiquitous Internet protocols > >such as HTTP, FTP and SNMP. > > Many people (not specifically in healthcare) are confused by the number of > "B2B standards" that exist, for example: > - Vendor initiated (BizTalk and SOAP) > - Consortia initiated (ebXML by OASIS and UN/CEFACT, XML Protocols Activity > by the World Wide Web Consortium ) > - Internet related standards bodies initiated (IETF - EDIINT ASx, IETF - > BEEP) > - Industry specific standards bodies initiated (HL7, GISB, UIG, AIAG, etc.) > > Not to mention all the proprietary initiatives. > > They look at all these "standards" and they're afraid they'll choose the > "wrong standard". I believe industry organizations, like HL7, play a > critical role in helping people choose a B2B standard that's appropriate for > their needs. > > >b) there is some despair at seeing AS2 get out of IETF before quantum > >computers pretty much obsolete everything based on computers with > >deterministic states (this last was an attempt at humor) > > Actually this is an excellent point. The IETF is very particular when it > comes to designing/endorsing standards, as it should be. Some of the recent > concerns with AS1 (see Ned Freed's comments attached) raise the > probabilities of a longer delay for AS2, because the non-GISB portion of AS2 > depends on AS1. I'm not aware of any issues with the GISB portion of AS2. > > >c) there is a sense that being an ANSI Standard is a requirement if one > >desires to get the government to mandate its use. > > The Department of Energy, via the Federal Energy Regulatory Commission, > mandated use of the GISB standard and I don't believe it is an ANSI > standard. Perhaps Rae McQuade, Executive Director of GISB (gisb1@aol.com), > can comment on this. > > I certainly don't understand many of the idiosyncrasies of HL7 Standards > versus Recommendations so I'll listen and learn as this discussion evolves. > I have been an active participant in many of the initiatives mentioned above > including: ebXML, GISB, UIG, W3C XP, and of course IETF EDIINT. I look > forward to working with the HL7 organization on this very important decision > during the coming months. > > Regards, > > Dick Brooks > http://www.8760.com/ > > -----Original Message----- > From: owner-ietf-ediint@mail.imc.org > [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Rishel,Wes > Sent: Monday, November 20, 2000 12:07 AM > To: 'Gunther Schadow'; Dick Brooks > Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) > > For many reasons it would be more desirable to be a Standard, but I am not > sure that there aren't some shades of gray, particularly if the difference > in the required time is important. I will wait to hear from Gunther about > the HIPAA issue, but I am suspecting that the following is true: > > a) there is interest in having a healthcare group give its imprimatur to > AS2, since it "rounds out" the Internet protocols to make a complete package > for HIPAA-compliant, B2B messaging based on ubiquitous Internet protocols > such as HTTP, FTP and SNMP. > > b) there is some despair at seeing AS2 get out of IETF before quantum > computers pretty much obsolete everything based on computers with > deterministic states (this last was an attempt at humor) > > c) there is a sense that being an ANSI Standard is a requirement if one > desires to get the government to mandate its use. > > I would take issue with item (c). It is surely helpful to be a standard, but > it is also helpful to be any sort of publication of an ANSI-accredited > standards development organization. Furthermore, unless someone knows > something specific, I would be skeptical that the current administration > would introduce another delay in the final rule on security by attempting to > add AS2 at this late date. > > Rather than a government mandate, I suspect that the benefit of an HL7 > imprimatur, and perhaps a profile or two, would be to assist in promoting > the Internet and AS2 as means to exchange the HIPAA transactions without > reliance on value added networks. At the same time it would be very valuable > to HL7 to have ways to exchange standard (old syntax) HL7 messages and > HL7-XML messages over the Internet using the same infrastructure > (integration brokers and servers) as are being sold for other B2B > applications in healthcare, the power industry, etc. > > If this model is correct a Standard is better, but a Recommendation also > provides substantial benefit. One approach would be to create a > Recommendation first and follow it up with a Standard after some operational > experience has been obtained. > > > -----Original Message----- > > From: Gunther Schadow [mailto:gunther@aurora.regenstrief.org] > > Sent: Saturday, November 18, 2000 8:06 PM > > To: dick@8760.com > > Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > Dick Brooks wrote: > > > > > > Thanks Wes. > > > > > > Based on your description I would anticipate the EDIINT AS2 > > spec taking the > > > "Recommendation" route, IF the group decides to go forward. > > Do you see it > > > the same way? > > > > Dick, I actually do see it the other way. The EDIINT work in > > HL7 as we > > discussed it in relation to HIPAA is only useful if we end up > > with an ANSI > > approved standard. That must be a standard, not a recommendation. > > > > I'll fill in Wes on the HIPAA issue under separate cover. Glad you can > > make it for 1/8/2001. Thank you for your help. > > > > regards, > > -Gunther > > > > ------------------------------------------------------------------------ > > Part 1.2 Type: Microsoft MHTML Document 5.0 (message/rfc822) > Encoding: 7bit From owner-ietf-ediint@mail.imc.org Tue Nov 21 18:53:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27448 for ; Tue, 21 Nov 2000 18:53:24 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA24975 for ietf-ediint-bks; Tue, 21 Nov 2000 15:23:26 -0800 (PST) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA24964 for ; Tue, 21 Nov 2000 15:23:23 -0800 (PST) Received: from gamma (user-33qt2t6.dialup.mindspring.com [199.174.139.166]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with SMTP id SAA28826; Tue, 21 Nov 2000 18:23:49 -0500 (EST) Reply-To: From: "Dick Brooks" To: "Kepa Zubeldia" Cc: "Rishel,Wes" , "Gunther Schadow" , "Rik Drummond" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Tue, 21 Nov 2000 17:20:15 -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: <3A19BE12.E56EA2C7@claredi.com> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kepa, > Are you volunteering to create an interoperability profile for digital > signatures of the HIPAA standard transactions ? My offer to assist in the development of an interoperability profile was in response to a need identified within HL7. However, I would be willing to help the HIPAA folks create an interoperability profile, provided it's based on a technology that I'm familiar with (e.g. EDIINT AS2, GISB EDM, ebXML). I would hope the investment in developing an interoperability profile for HL7 could be leveraged in other areas (e.g. HIPAA, ASTM), without any additional work. Do you see HIPAA's requirements being significantly different enough from HL7 to require a separate interoperability profile? Thanks, 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: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > Sent: Monday, November 20, 2000 6:13 PM > To: Dick Brooks > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > Dick, > > Are you volunteering to create an interoperability profile for digital > signatures of the HIPAA standard transactions ? X12, NCPDP, and X12+HL7 > (in which the signature could be on the HL7 or on the X12 components) > are the immediate needs. However, keep in mind that NCPDP could also be > in EDIFACT syntax (e.g. prescriptions) and HL7 could be in different > syntaxes. But, for HIPAA purposes, at this time we need something for > the 275 attachment only. Other HL7 messages could come later through > other interoperability profiles. > > If we have a very narrow scope (HIPAA transactions as they were released > in the Final Rule, plus attachments as we know them) then it is possible > to get an agreement, even if there is not yet an agreement on other > issues or on PKI issues. > > Other volunteers ? > > Kepa > > Dick Brooks wrote: > > > > Thanks Wes. > > > > Based on your description I would anticipate the EDIINT AS2 > spec taking the > > "Recommendation" route, IF the group decides to go forward. Do > you see it > > the same way? > > > > FYI - other groups that have adopted AS2 have found it > necessary to define > > "interoperability profiles". These profiles identify the exact set of > > "options" from AS2 that everyone in the "trading community" agrees to > > follow, in order to ensure interoperability. For example, GISB > has already > > defined an AS2 interoperability profile and the New York > Collaborative, in > > accordance with the Public Service Commission regulations, is > in the process > > of defining their interoperability profile. I'm familiar with both these > > groups and the process used to develop their profiles. I could help HL7 > > develop an AS2 interoperability profile, if the group decides > to pursue this > > approach. > > > > Regards, > > > > 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: Rishel,Wes [mailto:wes.rishel@gartner.com] > > > Sent: Friday, November 17, 2000 8:32 PM > > > To: 'dick@8760.com'; Gunther Schadow > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > > Subject: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > As the chair-elect of HL7 I would like to respond to DB's > > > question about HL7 > > > process. > > > > > > HL7 has two kinds of specifications that are published using slighly > > > different processes: a Standard is submitted to ANSI for > > > certification once > > > it has passed ballot; a Recommendation is published by HL7 but is not > > > submitted to ANSI and does not become an ANSI standard. Some > > > Recommendations > > > have had substantial acceptance among the HL7 community, > including it's > > > "lower level protocols" which define ways to reliably pass > > > discrete messages > > > over RS-232 and TCP, and were published sometime in the early 1990s. > > > > > > A Standard originates under the sponsorship of a Technical > > > Committee. If HL7 > > > were to create a Standard for EDIINT it would be the Control/Query > > > committee. It is balloted at the committee level. (Actually anyone can > > > participate in the committee ballot, but in practice those who > > > choose to do > > > so are usually those who participate in, or follow the work of, the > > > Technical Committee.) When it passes a committee level ballot it is > > > submitted for ballot by the full HL7 Working Group (which is > the entire > > > organization). If it passes at this level it is automatically > submitted to > > > ANSI for certification. The ANSI review allows time for public > > > comment, but > > > it is primarily a certification that the process was fair and > consistent > > > with our bylaws. To date, have never had an issue arise that > prevented or > > > delayed the certification process. > > > > > > In addition to Technical Committees HL7 has Special Interest > > > Groups. Gunther > > > is co-chair of our SIG on security. Strictly speaking, a SIG > > > cannot initiate > > > the balloting of a standard; but SIGs can prepare such a document, and > > > obtain the consent of a Technical Committee which sponsors the ballot. > > > > > > The other kind of document, the Recommendation, is easier to > get out the > > > door. It can be originated by a SIG, and it has only one level of > > > balloting. > > > The majority that is required to pass a Recommendation is > less severe than > > > the majority required to pass a Standard (67% vs. 90%). > > > > > > Ballots are conducted using the Web. Assuming that both > ballots pass an > > > energetic committee can easily complete the entire process in > two of our > > > three-per-year Working Group meetings (roughly 8 months > elapsed time). (Of > > > course most committees have substantial time invested in debating the > > > document before it begins the process.) > > > > > > Most of the meetings required at certain points in the process can be > > > handled using conference calls; in theory a REALLY motivated > > > committee could > > > accomplish the two-level ballot in five months and then wait > about three > > > months for ANSI certication. (That is a theoretical figure > that has never > > > been realized in practise.) > > > > > > Recommendations can be passed in roughly four months. > > > > > > Best regards, > > > > > > Wes Rishel > > > Research Director > > > Healthcare Industry Research & Advisory Services > > > GartnerGroup > > > Alameda, CA > > > Client inquiries: call +1-203-316-1288 or email to indapps@gartner.com > > > wes.rishel@gartner.com > > > 510 522 8135 > > > 510 521 2423 (fax) > > > > > > > > > > > > > -----Original Message----- > > > > From: Dick Brooks [mailto:dick@8760.com] > > > > Sent: Thursday, November 02, 2000 10:27 AM > > > > To: Gunther Schadow > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > > > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org; Dick > > > > Brooks > > > > Subject: RE: EDIINT and HIPAA > > > > > > > > > > > > > > > > I'm not familiar with the HL7 standards process, all of > > > > my experience > > > > has been with IETF, DISA, GISB and recently ebXML. Each of these > > > > organizations has a different process for developing > standards. If we > > > > brought AS2 to HL7 today, how long would it take to become an > > > > ANSI standard? > > > > I would like to read HL7's operational process document, can > > > > you provide a > > > > pointer? > > > > > > > > > > From owner-ietf-ediint@mail.imc.org Tue Nov 21 19:13:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29889 for ; Tue, 21 Nov 2000 19:13:13 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA26081 for ietf-ediint-bks; Tue, 21 Nov 2000 15:40:15 -0800 (PST) Received: from aurora.regenstrief.org (aurora.regenstrief.org [134.68.31.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA26077 for ; Tue, 21 Nov 2000 15:40:13 -0800 (PST) Received: from aurora.regenstrief.org ([134.68.31.177]) by aurora.regenstrief.org (8.11.1/8.9.3) with ESMTP id eALNdtZ50188; Tue, 21 Nov 2000 18:39:55 -0500 (EST) (envelope-from gunther@aurora.regenstrief.org) Message-ID: <3A1B07E7.37DF16D6@aurora.regenstrief.org> Date: Tue, 21 Nov 2000 18:40:23 -0500 From: Gunther Schadow Organization: Regenstrief Institute X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: dick@8760.com CC: Kepa Zubeldia , "Rishel,Wes" , Rik Drummond , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) References: Content-Type: multipart/mixed; boundary="------------EDB4D2E26F15B58C8589F4AA" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EDB4D2E26F15B58C8589F4AA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dick, yes, I think that the HL7 and HIPAA profiles would be similar if not the same. My goal is to get all the healthcare standards together (in fact it is only two of them, HL7 and NCPDP, since X12 is covered already) and develop one profile with options to account for the specific EDI payload used. We have an AS#1 profile already for HL7 and I'd like to take this to go over a couple of issues that we found. As much as I can see why AS#2 is very useful, I would not want to throw out the AS#1/email option if not absolutely necessary. You mention ebXML -- we have some interest in ebXML but we're not sure if any of this is ready for prime time, but would like to get your thoughts on this. regards -Gunther Dick Brooks wrote: > > Kepa, > > > Are you volunteering to create an interoperability profile for digital > > signatures of the HIPAA standard transactions ? > > My offer to assist in the development of an interoperability profile was in > response to a need identified within HL7. However, I would be willing to > help the HIPAA folks create an interoperability profile, provided it's based > on a technology that I'm familiar with (e.g. EDIINT AS2, GISB EDM, ebXML). > > I would hope the investment in developing an interoperability profile for > HL7 could be leveraged in other areas (e.g. HIPAA, ASTM), without any > additional work. Do you see HIPAA's requirements being significantly > different enough from HL7 to require a separate interoperability profile? > > Thanks, > > 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: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > > Sent: Monday, November 20, 2000 6:13 PM > > To: Dick Brooks > > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary Crough; Beth > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > Dick, > > > > Are you volunteering to create an interoperability profile for digital > > signatures of the HIPAA standard transactions ? X12, NCPDP, and X12+HL7 > > (in which the signature could be on the HL7 or on the X12 components) > > are the immediate needs. However, keep in mind that NCPDP could also be > > in EDIFACT syntax (e.g. prescriptions) and HL7 could be in different > > syntaxes. But, for HIPAA purposes, at this time we need something for > > the 275 attachment only. Other HL7 messages could come later through > > other interoperability profiles. > > > > If we have a very narrow scope (HIPAA transactions as they were released > > in the Final Rule, plus attachments as we know them) then it is possible > > to get an agreement, even if there is not yet an agreement on other > > issues or on PKI issues. > > > > Other volunteers ? > > > > Kepa > > > > Dick Brooks wrote: > > > > > > Thanks Wes. > > > > > > Based on your description I would anticipate the EDIINT AS2 > > spec taking the > > > "Recommendation" route, IF the group decides to go forward. Do > > you see it > > > the same way? > > > > > > FYI - other groups that have adopted AS2 have found it > > necessary to define > > > "interoperability profiles". These profiles identify the exact set of > > > "options" from AS2 that everyone in the "trading community" agrees to > > > follow, in order to ensure interoperability. For example, GISB > > has already > > > defined an AS2 interoperability profile and the New York > > Collaborative, in > > > accordance with the Public Service Commission regulations, is > > in the process > > > of defining their interoperability profile. I'm familiar with both these > > > groups and the process used to develop their profiles. I could help HL7 > > > develop an AS2 interoperability profile, if the group decides > > to pursue this > > > approach. > > > > > > Regards, > > > > > > 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: Rishel,Wes [mailto:wes.rishel@gartner.com] > > > > Sent: Friday, November 17, 2000 8:32 PM > > > > To: 'dick@8760.com'; Gunther Schadow > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > > > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > > > Subject: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > > > > As the chair-elect of HL7 I would like to respond to DB's > > > > question about HL7 > > > > process. > > > > > > > > HL7 has two kinds of specifications that are published using slighly > > > > different processes: a Standard is submitted to ANSI for > > > > certification once > > > > it has passed ballot; a Recommendation is published by HL7 but is not > > > > submitted to ANSI and does not become an ANSI standard. Some > > > > Recommendations > > > > have had substantial acceptance among the HL7 community, > > including it's > > > > "lower level protocols" which define ways to reliably pass > > > > discrete messages > > > > over RS-232 and TCP, and were published sometime in the early 1990s. > > > > > > > > A Standard originates under the sponsorship of a Technical > > > > Committee. If HL7 > > > > were to create a Standard for EDIINT it would be the Control/Query > > > > committee. It is balloted at the committee level. (Actually anyone can > > > > participate in the committee ballot, but in practice those who > > > > choose to do > > > > so are usually those who participate in, or follow the work of, the > > > > Technical Committee.) When it passes a committee level ballot it is > > > > submitted for ballot by the full HL7 Working Group (which is > > the entire > > > > organization). If it passes at this level it is automatically > > submitted to > > > > ANSI for certification. The ANSI review allows time for public > > > > comment, but > > > > it is primarily a certification that the process was fair and > > consistent > > > > with our bylaws. To date, have never had an issue arise that > > prevented or > > > > delayed the certification process. > > > > > > > > In addition to Technical Committees HL7 has Special Interest > > > > Groups. Gunther > > > > is co-chair of our SIG on security. Strictly speaking, a SIG > > > > cannot initiate > > > > the balloting of a standard; but SIGs can prepare such a document, and > > > > obtain the consent of a Technical Committee which sponsors the ballot. > > > > > > > > The other kind of document, the Recommendation, is easier to > > get out the > > > > door. It can be originated by a SIG, and it has only one level of > > > > balloting. > > > > The majority that is required to pass a Recommendation is > > less severe than > > > > the majority required to pass a Standard (67% vs. 90%). > > > > > > > > Ballots are conducted using the Web. Assuming that both > > ballots pass an > > > > energetic committee can easily complete the entire process in > > two of our > > > > three-per-year Working Group meetings (roughly 8 months > > elapsed time). (Of > > > > course most committees have substantial time invested in debating the > > > > document before it begins the process.) > > > > > > > > Most of the meetings required at certain points in the process can be > > > > handled using conference calls; in theory a REALLY motivated > > > > committee could > > > > accomplish the two-level ballot in five months and then wait > > about three > > > > months for ANSI certication. (That is a theoretical figure > > that has never > > > > been realized in practise.) > > > > > > > > Recommendations can be passed in roughly four months. > > > > > > > > Best regards, > > > > > > > > Wes Rishel > > > > Research Director > > > > Healthcare Industry Research & Advisory Services > > > > GartnerGroup > > > > Alameda, CA > > > > Client inquiries: call +1-203-316-1288 or email to indapps@gartner.com > > > > wes.rishel@gartner.com > > > > 510 522 8135 > > > > 510 521 2423 (fax) > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Dick Brooks [mailto:dick@8760.com] > > > > > Sent: Thursday, November 02, 2000 10:27 AM > > > > > To: Gunther Schadow > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > > > > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org; Dick > > > > > Brooks > > > > > Subject: RE: EDIINT and HIPAA > > > > > > > > > > > > > > > > > > > > I'm not familiar with the HL7 standards process, all of > > > > > my experience > > > > > has been with IETF, DISA, GISB and recently ebXML. Each of these > > > > > organizations has a different process for developing > > standards. If we > > > > > brought AS2 to HL7 today, how long would it take to become an > > > > > ANSI standard? > > > > > I would like to read HL7's operational process document, can > > > > > you provide a > > > > > pointer? > > > > > > > > > > > > > > --------------EDB4D2E26F15B58C8589F4AA Content-Type: text/x-vcard; charset=us-ascii; name="gunther.vcf" Content-Description: Card for Gunther Schadow Content-Disposition: attachment; filename="gunther.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Schadow;Gunther tel;fax:+1 317 630 6962 tel;home:+1 317 816 0516 tel;work:+1 317 630 7960 x-mozilla-html:FALSE url:http://aurora.rg.iupui.edu org:Regenstrief Institute for Health Care adr:;;1050 Wishard Blvd;Indianapolis;Indiana;46202;USA version:2.1 email;internet:gschadow@regenstrief.org title:M.D., Medical Information Scientist note;quoted-printable:Al oppinions expressed in this message are my own and do =0D=0Anot necessarily represent those of the Regenstrief Institute. fn:Gunther Schadow end:vcard --------------EDB4D2E26F15B58C8589F4AA-- From owner-ietf-ediint@mail.imc.org Tue Nov 21 19:13:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29917 for ; Tue, 21 Nov 2000 19:13:21 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA26307 for ietf-ediint-bks; Tue, 21 Nov 2000 15:51:00 -0800 (PST) Received: from prserv.net (out4.prserv.net [32.97.166.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA26303 for ; Tue, 21 Nov 2000 15:50:58 -0800 (PST) Received: from claredi.com ([32.102.253.215]) by prserv.net (out4) with SMTP id <200011212351332040535o8re>; Tue, 21 Nov 2000 23:51:42 +0000 Message-ID: <3A1AFC98.F48CF8E0@claredi.com> Date: Tue, 21 Nov 2000 15:52:09 -0700 From: Kepa Zubeldia X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: dick@8760.com CC: "Rishel,Wes" , Gunther Schadow , Rik Drummond , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) References: 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 Dick, Probably the requirements are identical, except that the content will be in X12 or NCPDP syntax instead of HL7 or XML. Kepa Dick Brooks wrote: > > Kepa, > > > Are you volunteering to create an interoperability profile for digital > > signatures of the HIPAA standard transactions ? > > My offer to assist in the development of an interoperability profile was in > response to a need identified within HL7. However, I would be willing to > help the HIPAA folks create an interoperability profile, provided it's based > on a technology that I'm familiar with (e.g. EDIINT AS2, GISB EDM, ebXML). > > I would hope the investment in developing an interoperability profile for > HL7 could be leveraged in other areas (e.g. HIPAA, ASTM), without any > additional work. Do you see HIPAA's requirements being significantly > different enough from HL7 to require a separate interoperability profile? > > Thanks, > > 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: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > > Sent: Monday, November 20, 2000 6:13 PM > > To: Dick Brooks > > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary Crough; Beth > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > Dick, > > > > Are you volunteering to create an interoperability profile for digital > > signatures of the HIPAA standard transactions ? X12, NCPDP, and X12+HL7 > > (in which the signature could be on the HL7 or on the X12 components) > > are the immediate needs. However, keep in mind that NCPDP could also be > > in EDIFACT syntax (e.g. prescriptions) and HL7 could be in different > > syntaxes. But, for HIPAA purposes, at this time we need something for > > the 275 attachment only. Other HL7 messages could come later through > > other interoperability profiles. > > > > If we have a very narrow scope (HIPAA transactions as they were released > > in the Final Rule, plus attachments as we know them) then it is possible > > to get an agreement, even if there is not yet an agreement on other > > issues or on PKI issues. > > > > Other volunteers ? > > > > Kepa > > > > Dick Brooks wrote: > > > > > > Thanks Wes. > > > > > > Based on your description I would anticipate the EDIINT AS2 > > spec taking the > > > "Recommendation" route, IF the group decides to go forward. Do > > you see it > > > the same way? > > > > > > FYI - other groups that have adopted AS2 have found it > > necessary to define > > > "interoperability profiles". These profiles identify the exact set of > > > "options" from AS2 that everyone in the "trading community" agrees to > > > follow, in order to ensure interoperability. For example, GISB > > has already > > > defined an AS2 interoperability profile and the New York > > Collaborative, in > > > accordance with the Public Service Commission regulations, is > > in the process > > > of defining their interoperability profile. I'm familiar with both these > > > groups and the process used to develop their profiles. I could help HL7 > > > develop an AS2 interoperability profile, if the group decides > > to pursue this > > > approach. > > > > > > Regards, > > > > > > 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: Rishel,Wes [mailto:wes.rishel@gartner.com] > > > > Sent: Friday, November 17, 2000 8:32 PM > > > > To: 'dick@8760.com'; Gunther Schadow > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > > > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > > > Subject: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > > > > As the chair-elect of HL7 I would like to respond to DB's > > > > question about HL7 > > > > process. > > > > > > > > HL7 has two kinds of specifications that are published using slighly > > > > different processes: a Standard is submitted to ANSI for > > > > certification once > > > > it has passed ballot; a Recommendation is published by HL7 but is not > > > > submitted to ANSI and does not become an ANSI standard. Some > > > > Recommendations > > > > have had substantial acceptance among the HL7 community, > > including it's > > > > "lower level protocols" which define ways to reliably pass > > > > discrete messages > > > > over RS-232 and TCP, and were published sometime in the early 1990s. > > > > > > > > A Standard originates under the sponsorship of a Technical > > > > Committee. If HL7 > > > > were to create a Standard for EDIINT it would be the Control/Query > > > > committee. It is balloted at the committee level. (Actually anyone can > > > > participate in the committee ballot, but in practice those who > > > > choose to do > > > > so are usually those who participate in, or follow the work of, the > > > > Technical Committee.) When it passes a committee level ballot it is > > > > submitted for ballot by the full HL7 Working Group (which is > > the entire > > > > organization). If it passes at this level it is automatically > > submitted to > > > > ANSI for certification. The ANSI review allows time for public > > > > comment, but > > > > it is primarily a certification that the process was fair and > > consistent > > > > with our bylaws. To date, have never had an issue arise that > > prevented or > > > > delayed the certification process. > > > > > > > > In addition to Technical Committees HL7 has Special Interest > > > > Groups. Gunther > > > > is co-chair of our SIG on security. Strictly speaking, a SIG > > > > cannot initiate > > > > the balloting of a standard; but SIGs can prepare such a document, and > > > > obtain the consent of a Technical Committee which sponsors the ballot. > > > > > > > > The other kind of document, the Recommendation, is easier to > > get out the > > > > door. It can be originated by a SIG, and it has only one level of > > > > balloting. > > > > The majority that is required to pass a Recommendation is > > less severe than > > > > the majority required to pass a Standard (67% vs. 90%). > > > > > > > > Ballots are conducted using the Web. Assuming that both > > ballots pass an > > > > energetic committee can easily complete the entire process in > > two of our > > > > three-per-year Working Group meetings (roughly 8 months > > elapsed time). (Of > > > > course most committees have substantial time invested in debating the > > > > document before it begins the process.) > > > > > > > > Most of the meetings required at certain points in the process can be > > > > handled using conference calls; in theory a REALLY motivated > > > > committee could > > > > accomplish the two-level ballot in five months and then wait > > about three > > > > months for ANSI certication. (That is a theoretical figure > > that has never > > > > been realized in practise.) > > > > > > > > Recommendations can be passed in roughly four months. > > > > > > > > Best regards, > > > > > > > > Wes Rishel > > > > Research Director > > > > Healthcare Industry Research & Advisory Services > > > > GartnerGroup > > > > Alameda, CA > > > > Client inquiries: call +1-203-316-1288 or email to indapps@gartner.com > > > > wes.rishel@gartner.com > > > > 510 522 8135 > > > > 510 521 2423 (fax) > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Dick Brooks [mailto:dick@8760.com] > > > > > Sent: Thursday, November 02, 2000 10:27 AM > > > > > To: Gunther Schadow > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > > > > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org; Dick > > > > > Brooks > > > > > Subject: RE: EDIINT and HIPAA > > > > > > > > > > > > > > > > > > > > I'm not familiar with the HL7 standards process, all of > > > > > my experience > > > > > has been with IETF, DISA, GISB and recently ebXML. Each of these > > > > > organizations has a different process for developing > > standards. If we > > > > > brought AS2 to HL7 today, how long would it take to become an > > > > > ANSI standard? > > > > > I would like to read HL7's operational process document, can > > > > > you provide a > > > > > pointer? > > > > > > > > > > > > > > From owner-ietf-ediint@mail.imc.org Tue Nov 21 19:32:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02612 for ; Tue, 21 Nov 2000 19:32:18 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA26544 for ietf-ediint-bks; Tue, 21 Nov 2000 16:02:40 -0800 (PST) Received: from prserv.net (out4.prserv.net [32.97.166.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26540 for ; Tue, 21 Nov 2000 16:02:39 -0800 (PST) Received: from claredi.com ([32.102.253.215]) by prserv.net (out4) with SMTP id <2000112200032120402rla1je>; Wed, 22 Nov 2000 00:03:27 +0000 Message-ID: <3A1AFF5B.BD654424@claredi.com> Date: Tue, 21 Nov 2000 16:03:55 -0700 From: Kepa Zubeldia X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gunther Schadow CC: dick@8760.com, "Rishel,Wes" , Rik Drummond , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) References: <3A1B07E7.37DF16D6@aurora.regenstrief.org> 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 Gunther, Here is some food for thought concerning AS1... When a provider files a batch of claims, the transmission can easily be sent with AS1 or AS2. The claims will adjudicate over a period of a few days. When the claims adjudicate, there is an X12 835 transaction that the payer needs to send back to the provider with the remittance advice. A typical provider will deal with about 400 payers on a routine basis. A typical payers will deal with about 100,000 providers on a routine basis. So, if the provider must be using AS2 only, the provider will have to periodically (probably daily) poll all the payers in case they have some remittance advice or other transaction from that payer. The payer, on the other hand, will have to hold "mailboxes" for 100,000+ providers and be polled by them periodically, so the remittance advices can be distributed back to the providers. Not strikingly efficient. But if the provider can send the claims with either AS1 or AS2, and the payer can send the remittance advices back with AS1, all the polling and mailboxing is eliminated, as the flow goes through the standard email pathways. The provider does not have to maintain an internet server to received EDI, only the capability to receive internet mail. Sounds like a much simpler approach. Of course, this assumes that the AS1 is not only signed but also encrypted. So, if you ask me, I would say that AS1 should not go away, even if the fancier and better way to do it is with AS2. There is certain beauty in simple solutions. Kepa Gunther Schadow wrote: > > Dick, > > yes, I think that the HL7 and HIPAA profiles would be similar if not the > same. My goal is to get all the healthcare standards together (in fact > it is only two of them, HL7 and NCPDP, since X12 is covered already) and > develop one profile with options to account for the specific EDI payload > used. We have an AS#1 profile already for HL7 and I'd like to take this > to go over a couple of issues that we found. As much as I can see why > AS#2 is very useful, I would not want to throw out the AS#1/email option > if not absolutely necessary. You mention ebXML -- we have some interest > in ebXML but we're not sure if any of this is ready for prime time, but > would like to get your thoughts on this. > > regards > -Gunther > > Dick Brooks wrote: > > > > Kepa, > > > > > Are you volunteering to create an interoperability profile for digital > > > signatures of the HIPAA standard transactions ? > > > > My offer to assist in the development of an interoperability profile was in > > response to a need identified within HL7. However, I would be willing to > > help the HIPAA folks create an interoperability profile, provided it's based > > on a technology that I'm familiar with (e.g. EDIINT AS2, GISB EDM, ebXML). > > > > I would hope the investment in developing an interoperability profile for > > HL7 could be leveraged in other areas (e.g. HIPAA, ASTM), without any > > additional work. Do you see HIPAA's requirements being significantly > > different enough from HL7 to require a separate interoperability profile? > > > > Thanks, > > > > 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: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > > > Sent: Monday, November 20, 2000 6:13 PM > > > To: Dick Brooks > > > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary Crough; Beth > > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > Dick, > > > > > > Are you volunteering to create an interoperability profile for digital > > > signatures of the HIPAA standard transactions ? X12, NCPDP, and X12+HL7 > > > (in which the signature could be on the HL7 or on the X12 components) > > > are the immediate needs. However, keep in mind that NCPDP could also be > > > in EDIFACT syntax (e.g. prescriptions) and HL7 could be in different > > > syntaxes. But, for HIPAA purposes, at this time we need something for > > > the 275 attachment only. Other HL7 messages could come later through > > > other interoperability profiles. > > > > > > If we have a very narrow scope (HIPAA transactions as they were released > > > in the Final Rule, plus attachments as we know them) then it is possible > > > to get an agreement, even if there is not yet an agreement on other > > > issues or on PKI issues. > > > > > > Other volunteers ? > > > > > > Kepa > > > > > > Dick Brooks wrote: > > > > > > > > Thanks Wes. > > > > > > > > Based on your description I would anticipate the EDIINT AS2 > > > spec taking the > > > > "Recommendation" route, IF the group decides to go forward. Do > > > you see it > > > > the same way? > > > > > > > > FYI - other groups that have adopted AS2 have found it > > > necessary to define > > > > "interoperability profiles". These profiles identify the exact set of > > > > "options" from AS2 that everyone in the "trading community" agrees to > > > > follow, in order to ensure interoperability. For example, GISB > > > has already > > > > defined an AS2 interoperability profile and the New York > > > Collaborative, in > > > > accordance with the Public Service Commission regulations, is > > > in the process > > > > of defining their interoperability profile. I'm familiar with both these > > > > groups and the process used to develop their profiles. I could help HL7 > > > > develop an AS2 interoperability profile, if the group decides > > > to pursue this > > > > approach. > > > > > > > > Regards, > > > > > > > > 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: Rishel,Wes [mailto:wes.rishel@gartner.com] > > > > > Sent: Friday, November 17, 2000 8:32 PM > > > > > To: 'dick@8760.com'; Gunther Schadow > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > > > > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > > > > Subject: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > > > > > > > As the chair-elect of HL7 I would like to respond to DB's > > > > > question about HL7 > > > > > process. > > > > > > > > > > HL7 has two kinds of specifications that are published using slighly > > > > > different processes: a Standard is submitted to ANSI for > > > > > certification once > > > > > it has passed ballot; a Recommendation is published by HL7 but is not > > > > > submitted to ANSI and does not become an ANSI standard. Some > > > > > Recommendations > > > > > have had substantial acceptance among the HL7 community, > > > including it's > > > > > "lower level protocols" which define ways to reliably pass > > > > > discrete messages > > > > > over RS-232 and TCP, and were published sometime in the early 1990s. > > > > > > > > > > A Standard originates under the sponsorship of a Technical > > > > > Committee. If HL7 > > > > > were to create a Standard for EDIINT it would be the Control/Query > > > > > committee. It is balloted at the committee level. (Actually anyone can > > > > > participate in the committee ballot, but in practice those who > > > > > choose to do > > > > > so are usually those who participate in, or follow the work of, the > > > > > Technical Committee.) When it passes a committee level ballot it is > > > > > submitted for ballot by the full HL7 Working Group (which is > > > the entire > > > > > organization). If it passes at this level it is automatically > > > submitted to > > > > > ANSI for certification. The ANSI review allows time for public > > > > > comment, but > > > > > it is primarily a certification that the process was fair and > > > consistent > > > > > with our bylaws. To date, have never had an issue arise that > > > prevented or > > > > > delayed the certification process. > > > > > > > > > > In addition to Technical Committees HL7 has Special Interest > > > > > Groups. Gunther > > > > > is co-chair of our SIG on security. Strictly speaking, a SIG > > > > > cannot initiate > > > > > the balloting of a standard; but SIGs can prepare such a document, and > > > > > obtain the consent of a Technical Committee which sponsors the ballot. > > > > > > > > > > The other kind of document, the Recommendation, is easier to > > > get out the > > > > > door. It can be originated by a SIG, and it has only one level of > > > > > balloting. > > > > > The majority that is required to pass a Recommendation is > > > less severe than > > > > > the majority required to pass a Standard (67% vs. 90%). > > > > > > > > > > Ballots are conducted using the Web. Assuming that both > > > ballots pass an > > > > > energetic committee can easily complete the entire process in > > > two of our > > > > > three-per-year Working Group meetings (roughly 8 months > > > elapsed time). (Of > > > > > course most committees have substantial time invested in debating the > > > > > document before it begins the process.) > > > > > > > > > > Most of the meetings required at certain points in the process can be > > > > > handled using conference calls; in theory a REALLY motivated > > > > > committee could > > > > > accomplish the two-level ballot in five months and then wait > > > about three > > > > > months for ANSI certication. (That is a theoretical figure > > > that has never > > > > > been realized in practise.) > > > > > > > > > > Recommendations can be passed in roughly four months. > > > > > > > > > > Best regards, > > > > > > > > > > Wes Rishel > > > > > Research Director > > > > > Healthcare Industry Research & Advisory Services > > > > > GartnerGroup > > > > > Alameda, CA > > > > > Client inquiries: call +1-203-316-1288 or email to indapps@gartner.com > > > > > wes.rishel@gartner.com > > > > > 510 522 8135 > > > > > 510 521 2423 (fax) > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dick Brooks [mailto:dick@8760.com] > > > > > > Sent: Thursday, November 02, 2000 10:27 AM > > > > > > To: Gunther Schadow > > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > > > > > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org; Dick > > > > > > Brooks > > > > > > Subject: RE: EDIINT and HIPAA > > > > > > > > > > > > > > > > > > > > > > > > I'm not familiar with the HL7 standards process, all of > > > > > > my experience > > > > > > has been with IETF, DISA, GISB and recently ebXML. Each of these > > > > > > organizations has a different process for developing > > > standards. If we > > > > > > brought AS2 to HL7 today, how long would it take to become an > > > > > > ANSI standard? > > > > > > I would like to read HL7's operational process document, can > > > > > > you provide a > > > > > > pointer? > > > > > > > > > > > > > > > > > > From owner-ietf-ediint@mail.imc.org Tue Nov 21 19:42:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02613 for ; Tue, 21 Nov 2000 19:32:18 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA26667 for ietf-ediint-bks; Tue, 21 Nov 2000 16:06:11 -0800 (PST) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26659 for ; Tue, 21 Nov 2000 16:06:09 -0800 (PST) Received: from gamma (user-33qt2t6.dialup.mindspring.com [199.174.139.166]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with SMTP id TAA24150; Tue, 21 Nov 2000 19:06:30 -0500 (EST) Reply-To: From: "Dick Brooks" To: "Kepa Zubeldia" Cc: "Rishel,Wes" , "'Gunther Schadow'" , "Rik Drummond" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , , Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Tue, 21 Nov 2000 18:02:55 -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: <3A19CC7E.8FA1ADD4@claredi.com> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kepa, >Does this shed some light ? Thank you, your framing of the issues regarding digital signatures and HIPAA helped me a great deal. >Do you want EDIINT to be adopted by the Secretary as the HIPAA digital >signature standard ? Then, I think you know what to do. The ideal solution is an ANSI approved digital signature standard. In lieu of such an ANSI standard would HHS "seriously" consider a standard that has been adopted by another government department (e.g Department of Energy) IF it met HIPAA's requirements? How about a standard created by a non-ANSI SDO (e.g. IETF, GISB)? If HHS wouldn't seriously consider anything that is non-ANSI standard then the path ahead is quite clear; an ANSI standard is needed, ASAP. > However, if we let the scope creep to cover other topics, such as PKI or > "trust" issues, then the wheels could slow down. I agree, there are still many issues plaguing PKI, both technical and business related. Given the scale, visibility and criticality of HIPAA deployments I think it would be best to leverage a "trust" approach that is easy to implement, widely deployed and has proven to be scalable and interoperable (for example PGP). > I hope that having a "HIPAA Signature Implementation Guide" does not > preclude other "implementation guides" for things like encryption, > consent form signature, multiple signatures, counter signatures, etc. > that are also necessary but not "mandated" by HIPAA at this time. I think this should be specified as a core requirement. Very helpful.. Thanks, 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: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > Sent: Monday, November 20, 2000 7:15 PM > To: Dick Brooks > Cc: Rishel,Wes; 'Gunther Schadow'; Rik Drummond; CLEM; Gary Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > Dick, Wes, > > Now I need to throw in my $.02 > > Under HIPAA, the Secretary of HHS is required to adopt a standard for > electronic signatures of the HIPAA transactions. Simple and reduced > scope. > > The Secretary is required to adopt Standards (with capital S) developed > by a SDO from the American National Standards Institute. If no such > standard is available, the Secretary can create her own standards. > > The HIPAA Security Final Rule will reflect security standards created by > HHS because there are no other security standards for healthcare > developed by an ANSI SDO that meet the security requirements expressed > in the HIPAA Law. However, the security final rule will NOT have a > standard for electronic signatures, and this standard will come out in a > later final rule. > > If the healthcare SDOs were to agree on an ANSI standard for digital > signatures that could be used for the HIPAA transactions, and a very > specific "implementation guide" on how to use this standard to sign the > HIPAA transactions, the Secretary would have a much easier job in > adopting such standard. Until this happens, the digital signature final > rule may have to be put on hold, as the DHHS does not want to create > standards in this area in an ivory tower (i.e. in a vacuum). > > In addition, the HIPAA electronic signature standard must be adopted in > conjunction with the Department of Commerce. > > Does this shed some light ? > > Do you want EDIINT to be adopted by the Secretary as the HIPAA digital > signature standard ? Then, I think you know what to do. > > Please understand that I am not making any promises here. I am stating > something that will make easier for the NCVHS to recommend a standard > for the Secretary to adopt. This is a self-serving request as I am one > of the NCVHS members. The NCVHS looked at the possible standards last > month, and as a result, I have sent invitations to the affected SDOs to > work under HISB in coming up with something "adoptable". I think that > if the group of experts on this list was to work on such task with the > ANSI SDOs, then we could have something that benefits the entire > healthcare industry. > > However, if we let the scope creep to cover other topics, such as PKI or > "trust" issues, then the wheels could slow down. > > I hope that having a "HIPAA Signature Implementation Guide" does not > preclude other "implementation guides" for things like encryption, > consent form signature, multiple signatures, counter signatures, etc. > that are also necessary but not "mandated" by HIPAA at this time. > > Keep up the good work. > > Kepa > > Dick Brooks wrote: > > > > Wes, > > > > You make some excellent points, I want to focus on a few that I > believe are > > critical in moving forward. > > > > >a) there is interest in having a healthcare group give its > imprimatur to > > >AS2, since it "rounds out" the Internet protocols to make a complete > > package > > >for HIPAA-compliant, B2B messaging based on ubiquitous > Internet protocols > > >such as HTTP, FTP and SNMP. > > > > Many people (not specifically in healthcare) are confused by > the number of > > "B2B standards" that exist, for example: > > - Vendor initiated (BizTalk and SOAP) > > - Consortia initiated (ebXML by OASIS and UN/CEFACT, XML > Protocols Activity > > by the World Wide Web Consortium ) > > - Internet related standards bodies initiated (IETF - EDIINT ASx, IETF - > > BEEP) > > - Industry specific standards bodies initiated (HL7, GISB, UIG, > AIAG, etc.) > > > > Not to mention all the proprietary initiatives. > > > > They look at all these "standards" and they're afraid they'll choose the > > "wrong standard". I believe industry organizations, like HL7, play a > > critical role in helping people choose a B2B standard that's > appropriate for > > their needs. > > > > >b) there is some despair at seeing AS2 get out of IETF before quantum > > >computers pretty much obsolete everything based on computers with > > >deterministic states (this last was an attempt at humor) > > > > Actually this is an excellent point. The IETF is very particular when it > > comes to designing/endorsing standards, as it should be. Some > of the recent > > concerns with AS1 (see Ned Freed's comments attached) raise the > > probabilities of a longer delay for AS2, because the non-GISB > portion of AS2 > > depends on AS1. I'm not aware of any issues with the GISB > portion of AS2. > > > > >c) there is a sense that being an ANSI Standard is a requirement if one > > >desires to get the government to mandate its use. > > > > The Department of Energy, via the Federal Energy Regulatory Commission, > > mandated use of the GISB standard and I don't believe it is an ANSI > > standard. Perhaps Rae McQuade, Executive Director of GISB > (gisb1@aol.com), > > can comment on this. > > > > I certainly don't understand many of the idiosyncrasies of HL7 Standards > > versus Recommendations so I'll listen and learn as this > discussion evolves. > > I have been an active participant in many of the initiatives > mentioned above > > including: ebXML, GISB, UIG, W3C XP, and of course IETF EDIINT. I look > > forward to working with the HL7 organization on this very > important decision > > during the coming months. > > > > Regards, > > > > Dick Brooks > > http://www.8760.com/ > > > > -----Original Message----- > > From: owner-ietf-ediint@mail.imc.org > > [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Rishel,Wes > > Sent: Monday, November 20, 2000 12:07 AM > > To: 'Gunther Schadow'; Dick Brooks > > Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > For many reasons it would be more desirable to be a Standard, > but I am not > > sure that there aren't some shades of gray, particularly if the > difference > > in the required time is important. I will wait to hear from > Gunther about > > the HIPAA issue, but I am suspecting that the following is true: > > > > a) there is interest in having a healthcare group give its imprimatur to > > AS2, since it "rounds out" the Internet protocols to make a > complete package > > for HIPAA-compliant, B2B messaging based on ubiquitous Internet > protocols > > such as HTTP, FTP and SNMP. > > > > b) there is some despair at seeing AS2 get out of IETF before quantum > > computers pretty much obsolete everything based on computers with > > deterministic states (this last was an attempt at humor) > > > > c) there is a sense that being an ANSI Standard is a requirement if one > > desires to get the government to mandate its use. > > > > I would take issue with item (c). It is surely helpful to be a > standard, but > > it is also helpful to be any sort of publication of an ANSI-accredited > > standards development organization. Furthermore, unless someone knows > > something specific, I would be skeptical that the current administration > > would introduce another delay in the final rule on security by > attempting to > > add AS2 at this late date. > > > > Rather than a government mandate, I suspect that the benefit of an HL7 > > imprimatur, and perhaps a profile or two, would be to assist in > promoting > > the Internet and AS2 as means to exchange the HIPAA transactions without > > reliance on value added networks. At the same time it would be > very valuable > > to HL7 to have ways to exchange standard (old syntax) HL7 messages and > > HL7-XML messages over the Internet using the same infrastructure > > (integration brokers and servers) as are being sold for other B2B > > applications in healthcare, the power industry, etc. > > > > If this model is correct a Standard is better, but a Recommendation also > > provides substantial benefit. One approach would be to create a > > Recommendation first and follow it up with a Standard after > some operational > > experience has been obtained. > > > > > -----Original Message----- > > > From: Gunther Schadow [mailto:gunther@aurora.regenstrief.org] > > > Sent: Saturday, November 18, 2000 8:06 PM > > > To: dick@8760.com > > > Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth > > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > Dick Brooks wrote: > > > > > > > > Thanks Wes. > > > > > > > > Based on your description I would anticipate the EDIINT AS2 > > > spec taking the > > > > "Recommendation" route, IF the group decides to go forward. > > > Do you see it > > > > the same way? > > > > > > Dick, I actually do see it the other way. The EDIINT work in > > > HL7 as we > > > discussed it in relation to HIPAA is only useful if we end up > > > with an ANSI > > > approved standard. That must be a standard, not a recommendation. > > > > > > I'll fill in Wes on the HIPAA issue under separate cover. Glad you can > > > make it for 1/8/2001. Thank you for your help. > > > > > > regards, > > > -Gunther > > > > > > > > ------------------------------------------------------------------------ > > > > Part 1.2 Type: Microsoft MHTML Document 5.0 (message/rfc822) > > Encoding: 7bit > > From owner-ietf-ediint@mail.imc.org Tue Nov 21 20:53:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13927 for ; Tue, 21 Nov 2000 20:53:57 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA08911 for ietf-ediint-bks; Tue, 21 Nov 2000 17:21:47 -0800 (PST) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08907 for ; Tue, 21 Nov 2000 17:21:45 -0800 (PST) Received: from gamma (user-33qt2t6.dialup.mindspring.com [199.174.139.166]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with SMTP id UAA21764; Tue, 21 Nov 2000 20:22:18 -0500 (EST) Reply-To: From: "Dick Brooks" To: "Gunther Schadow" Cc: "Kepa Zubeldia" , "Rishel,Wes" , "Rik Drummond" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Tue, 21 Nov 2000 19:18:43 -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: <3A1B07E7.37DF16D6@aurora.regenstrief.org> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Gunther, > if not absolutely necessary. You mention ebXML -- we have some interest > in ebXML but we're not sure if any of this is ready for prime time, but > would like to get your thoughts on this. ebXML is still in a very formative stage so it's still a bit early... 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: Gunther Schadow [mailto:gunther@aurora.regenstrief.org] > Sent: Tuesday, November 21, 2000 5:40 PM > To: Dick Brooks > Cc: Kepa Zubeldia; Rishel,Wes; Rik Drummond; CLEM; Gary Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > Dick, > > yes, I think that the HL7 and HIPAA profiles would be similar if not the > same. My goal is to get all the healthcare standards together (in fact > it is only two of them, HL7 and NCPDP, since X12 is covered already) and > develop one profile with options to account for the specific EDI payload > used. We have an AS#1 profile already for HL7 and I'd like to take this > to go over a couple of issues that we found. As much as I can see why > AS#2 is very useful, I would not want to throw out the AS#1/email option > if not absolutely necessary. You mention ebXML -- we have some interest > in ebXML but we're not sure if any of this is ready for prime time, but > would like to get your thoughts on this. > > regards > -Gunther > > > Dick Brooks wrote: > > > > Kepa, > > > > > Are you volunteering to create an interoperability profile for digital > > > signatures of the HIPAA standard transactions ? > > > > My offer to assist in the development of an interoperability > profile was in > > response to a need identified within HL7. However, I would be willing to > > help the HIPAA folks create an interoperability profile, > provided it's based > > on a technology that I'm familiar with (e.g. EDIINT AS2, GISB > EDM, ebXML). > > > > I would hope the investment in developing an interoperability > profile for > > HL7 could be leveraged in other areas (e.g. HIPAA, ASTM), without any > > additional work. Do you see HIPAA's requirements being significantly > > different enough from HL7 to require a separate > interoperability profile? > > > > Thanks, > > > > 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: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > > > Sent: Monday, November 20, 2000 6:13 PM > > > To: Dick Brooks > > > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary Crough; Beth > > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > Dick, > > > > > > Are you volunteering to create an interoperability profile for digital > > > signatures of the HIPAA standard transactions ? X12, NCPDP, > and X12+HL7 > > > (in which the signature could be on the HL7 or on the X12 components) > > > are the immediate needs. However, keep in mind that NCPDP > could also be > > > in EDIFACT syntax (e.g. prescriptions) and HL7 could be in different > > > syntaxes. But, for HIPAA purposes, at this time we need something for > > > the 275 attachment only. Other HL7 messages could come later through > > > other interoperability profiles. > > > > > > If we have a very narrow scope (HIPAA transactions as they > were released > > > in the Final Rule, plus attachments as we know them) then it > is possible > > > to get an agreement, even if there is not yet an agreement on other > > > issues or on PKI issues. > > > > > > Other volunteers ? > > > > > > Kepa > > > > > > Dick Brooks wrote: > > > > > > > > Thanks Wes. > > > > > > > > Based on your description I would anticipate the EDIINT AS2 > > > spec taking the > > > > "Recommendation" route, IF the group decides to go forward. Do > > > you see it > > > > the same way? > > > > > > > > FYI - other groups that have adopted AS2 have found it > > > necessary to define > > > > "interoperability profiles". These profiles identify the > exact set of > > > > "options" from AS2 that everyone in the "trading community" > agrees to > > > > follow, in order to ensure interoperability. For example, GISB > > > has already > > > > defined an AS2 interoperability profile and the New York > > > Collaborative, in > > > > accordance with the Public Service Commission regulations, is > > > in the process > > > > of defining their interoperability profile. I'm familiar > with both these > > > > groups and the process used to develop their profiles. I > could help HL7 > > > > develop an AS2 interoperability profile, if the group decides > > > to pursue this > > > > approach. > > > > > > > > Regards, > > > > > > > > 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: Rishel,Wes [mailto:wes.rishel@gartner.com] > > > > > Sent: Friday, November 17, 2000 8:32 PM > > > > > To: 'dick@8760.com'; Gunther Schadow > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > > > > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > > > > Subject: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > > > > > > > As the chair-elect of HL7 I would like to respond to DB's > > > > > question about HL7 > > > > > process. > > > > > > > > > > HL7 has two kinds of specifications that are published > using slighly > > > > > different processes: a Standard is submitted to ANSI for > > > > > certification once > > > > > it has passed ballot; a Recommendation is published by > HL7 but is not > > > > > submitted to ANSI and does not become an ANSI standard. Some > > > > > Recommendations > > > > > have had substantial acceptance among the HL7 community, > > > including it's > > > > > "lower level protocols" which define ways to reliably pass > > > > > discrete messages > > > > > over RS-232 and TCP, and were published sometime in the > early 1990s. > > > > > > > > > > A Standard originates under the sponsorship of a Technical > > > > > Committee. If HL7 > > > > > were to create a Standard for EDIINT it would be the Control/Query > > > > > committee. It is balloted at the committee level. > (Actually anyone can > > > > > participate in the committee ballot, but in practice those who > > > > > choose to do > > > > > so are usually those who participate in, or follow the > work of, the > > > > > Technical Committee.) When it passes a committee level > ballot it is > > > > > submitted for ballot by the full HL7 Working Group (which is > > > the entire > > > > > organization). If it passes at this level it is automatically > > > submitted to > > > > > ANSI for certification. The ANSI review allows time for public > > > > > comment, but > > > > > it is primarily a certification that the process was fair and > > > consistent > > > > > with our bylaws. To date, have never had an issue arise that > > > prevented or > > > > > delayed the certification process. > > > > > > > > > > In addition to Technical Committees HL7 has Special Interest > > > > > Groups. Gunther > > > > > is co-chair of our SIG on security. Strictly speaking, a SIG > > > > > cannot initiate > > > > > the balloting of a standard; but SIGs can prepare such a > document, and > > > > > obtain the consent of a Technical Committee which > sponsors the ballot. > > > > > > > > > > The other kind of document, the Recommendation, is easier to > > > get out the > > > > > door. It can be originated by a SIG, and it has only one level of > > > > > balloting. > > > > > The majority that is required to pass a Recommendation is > > > less severe than > > > > > the majority required to pass a Standard (67% vs. 90%). > > > > > > > > > > Ballots are conducted using the Web. Assuming that both > > > ballots pass an > > > > > energetic committee can easily complete the entire process in > > > two of our > > > > > three-per-year Working Group meetings (roughly 8 months > > > elapsed time). (Of > > > > > course most committees have substantial time invested in > debating the > > > > > document before it begins the process.) > > > > > > > > > > Most of the meetings required at certain points in the > process can be > > > > > handled using conference calls; in theory a REALLY motivated > > > > > committee could > > > > > accomplish the two-level ballot in five months and then wait > > > about three > > > > > months for ANSI certication. (That is a theoretical figure > > > that has never > > > > > been realized in practise.) > > > > > > > > > > Recommendations can be passed in roughly four months. > > > > > > > > > > Best regards, > > > > > > > > > > Wes Rishel > > > > > Research Director > > > > > Healthcare Industry Research & Advisory Services > > > > > GartnerGroup > > > > > Alameda, CA > > > > > Client inquiries: call +1-203-316-1288 or email to > indapps@gartner.com > > > > > wes.rishel@gartner.com > > > > > 510 522 8135 > > > > > 510 521 2423 (fax) > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dick Brooks [mailto:dick@8760.com] > > > > > > Sent: Thursday, November 02, 2000 10:27 AM > > > > > > To: Gunther Schadow > > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > > > > > > David@Drummondgroup. Com; GISB1@aol.com; > ietf-ediint@imc.org; Dick > > > > > > Brooks > > > > > > Subject: RE: EDIINT and HIPAA > > > > > > > > > > > > > > > > > > > > > > > > I'm not familiar with the HL7 standards process, all of > > > > > > my experience > > > > > > has been with IETF, DISA, GISB and recently ebXML. Each of these > > > > > > organizations has a different process for developing > > > standards. If we > > > > > > brought AS2 to HL7 today, how long would it take to become an > > > > > > ANSI standard? > > > > > > I would like to read HL7's operational process document, can > > > > > > you provide a > > > > > > pointer? > > > > > > > > > > > > > > > > > > From owner-ietf-ediint@mail.imc.org Tue Nov 21 21:05:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15381 for ; Tue, 21 Nov 2000 21:05:32 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA09085 for ietf-ediint-bks; Tue, 21 Nov 2000 17:31:47 -0800 (PST) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09081 for ; Tue, 21 Nov 2000 17:31:42 -0800 (PST) Received: from gamma (user-33qt2t6.dialup.mindspring.com [199.174.139.166]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with SMTP id UAA21407; Tue, 21 Nov 2000 20:31:21 -0500 (EST) Reply-To: From: "Dick Brooks" To: "Kepa Zubeldia" Cc: "Rishel,Wes" , "Gunther Schadow" , "Rik Drummond" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Tue, 21 Nov 2000 19:27:46 -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: <3A1AFC98.F48CF8E0@claredi.com> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kepa, > Probably the requirements are identical, except that the content will be > in X12 or NCPDP syntax instead of HL7 or XML. That's encouraging because both EDIINT AS2 and GISB EDM are capable of signing and encrypting any type of content (a.k.a. payload), as will ebXML when we're finished. Thanks. 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: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > Sent: Tuesday, November 21, 2000 4:52 PM > To: Dick Brooks > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > Dick, > > Probably the requirements are identical, except that the content will be > in X12 or NCPDP syntax instead of HL7 or XML. > > Kepa > > Dick Brooks wrote: > > > > Kepa, > > > > > Are you volunteering to create an interoperability profile for digital > > > signatures of the HIPAA standard transactions ? > > > > My offer to assist in the development of an interoperability > profile was in > > response to a need identified within HL7. However, I would be willing to > > help the HIPAA folks create an interoperability profile, > provided it's based > > on a technology that I'm familiar with (e.g. EDIINT AS2, GISB > EDM, ebXML). > > > > I would hope the investment in developing an interoperability > profile for > > HL7 could be leveraged in other areas (e.g. HIPAA, ASTM), without any > > additional work. Do you see HIPAA's requirements being significantly > > different enough from HL7 to require a separate > interoperability profile? > > > > Thanks, > > > > 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: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > > > Sent: Monday, November 20, 2000 6:13 PM > > > To: Dick Brooks > > > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary Crough; Beth > > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > Dick, > > > > > > Are you volunteering to create an interoperability profile for digital > > > signatures of the HIPAA standard transactions ? X12, NCPDP, > and X12+HL7 > > > (in which the signature could be on the HL7 or on the X12 components) > > > are the immediate needs. However, keep in mind that NCPDP > could also be > > > in EDIFACT syntax (e.g. prescriptions) and HL7 could be in different > > > syntaxes. But, for HIPAA purposes, at this time we need something for > > > the 275 attachment only. Other HL7 messages could come later through > > > other interoperability profiles. > > > > > > If we have a very narrow scope (HIPAA transactions as they > were released > > > in the Final Rule, plus attachments as we know them) then it > is possible > > > to get an agreement, even if there is not yet an agreement on other > > > issues or on PKI issues. > > > > > > Other volunteers ? > > > > > > Kepa > > > > > > Dick Brooks wrote: > > > > > > > > Thanks Wes. > > > > > > > > Based on your description I would anticipate the EDIINT AS2 > > > spec taking the > > > > "Recommendation" route, IF the group decides to go forward. Do > > > you see it > > > > the same way? > > > > > > > > FYI - other groups that have adopted AS2 have found it > > > necessary to define > > > > "interoperability profiles". These profiles identify the > exact set of > > > > "options" from AS2 that everyone in the "trading community" > agrees to > > > > follow, in order to ensure interoperability. For example, GISB > > > has already > > > > defined an AS2 interoperability profile and the New York > > > Collaborative, in > > > > accordance with the Public Service Commission regulations, is > > > in the process > > > > of defining their interoperability profile. I'm familiar > with both these > > > > groups and the process used to develop their profiles. I > could help HL7 > > > > develop an AS2 interoperability profile, if the group decides > > > to pursue this > > > > approach. > > > > > > > > Regards, > > > > > > > > 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: Rishel,Wes [mailto:wes.rishel@gartner.com] > > > > > Sent: Friday, November 17, 2000 8:32 PM > > > > > To: 'dick@8760.com'; Gunther Schadow > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > > > > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > > > > Subject: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > > > > > > > As the chair-elect of HL7 I would like to respond to DB's > > > > > question about HL7 > > > > > process. > > > > > > > > > > HL7 has two kinds of specifications that are published > using slighly > > > > > different processes: a Standard is submitted to ANSI for > > > > > certification once > > > > > it has passed ballot; a Recommendation is published by > HL7 but is not > > > > > submitted to ANSI and does not become an ANSI standard. Some > > > > > Recommendations > > > > > have had substantial acceptance among the HL7 community, > > > including it's > > > > > "lower level protocols" which define ways to reliably pass > > > > > discrete messages > > > > > over RS-232 and TCP, and were published sometime in the > early 1990s. > > > > > > > > > > A Standard originates under the sponsorship of a Technical > > > > > Committee. If HL7 > > > > > were to create a Standard for EDIINT it would be the Control/Query > > > > > committee. It is balloted at the committee level. > (Actually anyone can > > > > > participate in the committee ballot, but in practice those who > > > > > choose to do > > > > > so are usually those who participate in, or follow the > work of, the > > > > > Technical Committee.) When it passes a committee level > ballot it is > > > > > submitted for ballot by the full HL7 Working Group (which is > > > the entire > > > > > organization). If it passes at this level it is automatically > > > submitted to > > > > > ANSI for certification. The ANSI review allows time for public > > > > > comment, but > > > > > it is primarily a certification that the process was fair and > > > consistent > > > > > with our bylaws. To date, have never had an issue arise that > > > prevented or > > > > > delayed the certification process. > > > > > > > > > > In addition to Technical Committees HL7 has Special Interest > > > > > Groups. Gunther > > > > > is co-chair of our SIG on security. Strictly speaking, a SIG > > > > > cannot initiate > > > > > the balloting of a standard; but SIGs can prepare such a > document, and > > > > > obtain the consent of a Technical Committee which > sponsors the ballot. > > > > > > > > > > The other kind of document, the Recommendation, is easier to > > > get out the > > > > > door. It can be originated by a SIG, and it has only one level of > > > > > balloting. > > > > > The majority that is required to pass a Recommendation is > > > less severe than > > > > > the majority required to pass a Standard (67% vs. 90%). > > > > > > > > > > Ballots are conducted using the Web. Assuming that both > > > ballots pass an > > > > > energetic committee can easily complete the entire process in > > > two of our > > > > > three-per-year Working Group meetings (roughly 8 months > > > elapsed time). (Of > > > > > course most committees have substantial time invested in > debating the > > > > > document before it begins the process.) > > > > > > > > > > Most of the meetings required at certain points in the > process can be > > > > > handled using conference calls; in theory a REALLY motivated > > > > > committee could > > > > > accomplish the two-level ballot in five months and then wait > > > about three > > > > > months for ANSI certication. (That is a theoretical figure > > > that has never > > > > > been realized in practise.) > > > > > > > > > > Recommendations can be passed in roughly four months. > > > > > > > > > > Best regards, > > > > > > > > > > Wes Rishel > > > > > Research Director > > > > > Healthcare Industry Research & Advisory Services > > > > > GartnerGroup > > > > > Alameda, CA > > > > > Client inquiries: call +1-203-316-1288 or email to > indapps@gartner.com > > > > > wes.rishel@gartner.com > > > > > 510 522 8135 > > > > > 510 521 2423 (fax) > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dick Brooks [mailto:dick@8760.com] > > > > > > Sent: Thursday, November 02, 2000 10:27 AM > > > > > > To: Gunther Schadow > > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; > > > > > > David@Drummondgroup. Com; GISB1@aol.com; > ietf-ediint@imc.org; Dick > > > > > > Brooks > > > > > > Subject: RE: EDIINT and HIPAA > > > > > > > > > > > > > > > > > > > > > > > > I'm not familiar with the HL7 standards process, all of > > > > > > my experience > > > > > > has been with IETF, DISA, GISB and recently ebXML. Each of these > > > > > > organizations has a different process for developing > > > standards. If we > > > > > > brought AS2 to HL7 today, how long would it take to become an > > > > > > ANSI standard? > > > > > > I would like to read HL7's operational process document, can > > > > > > you provide a > > > > > > pointer? > > > > > > > > > > > > > > > > > > From owner-ietf-ediint@mail.imc.org Wed Nov 22 02:03:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11601 for ; Wed, 22 Nov 2000 02:03:47 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA16325 for ietf-ediint-bks; Tue, 21 Nov 2000 22:30:01 -0800 (PST) Received: from puma.gartner.com (overlord.gartner.com [207.140.148.33]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA16318 for ; Tue, 21 Nov 2000 22:29:59 -0800 (PST) Received: by puma.gartner.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 01:29:30 -0500 Message-ID: <69A38F8986F3D211A6B00008C79121060969A30F@mammoth.gartner.com> From: "Rishel,Wes" To: "'Kepa Zubeldia'" , Dick Brooks Cc: "Rishel,Wes" , "'Gunther Schadow'" , Rik Drummond , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Wed, 22 Nov 2000 01:29:43 -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: I guess I missed more than I realized. I have always held that there are two distinct applications of digital signature technology: (1) to authenticate a block of data that might represent an EDI message, a binary executable program, a digital certificate or any of a myriad of other objects that come from the world of technology, and (2) as a way of accomplishing electronic signature, the binding of the identity of a person to an electronic document in a way that approximates the forensic robustness of a handwritten signature on a paper document. Now (2) is clearly accomplished by using the processes described in (1), but there are myriad functional issues around the representation of the document or parts of the document; clearly demarking the scope of what is electronically signed; being able to demonstrate that what the person saw when he signed was the only valid interpretation of the block of data that represents the signed text; being able to demonstrate that the human readable interpretation of the binary data that represents the document has not changed in the years since it was signed; and a signature model that includes distinct concepts such as multiple signatures that apply to different, possibly overlapping parts of documents, countersignatures and signed amendments. I have always thought of EDIINT as a clear example of (1). I have never read anything about it that addresses any of the issues listed in (2). Did I miss a meeting? > -----Original Message----- > From: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > Sent: Monday, November 20, 2000 5:15 PM > To: Dick Brooks > Cc: Rishel,Wes; 'Gunther Schadow'; Rik Drummond; CLEM; Gary > Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > Dick, Wes, > > Now I need to throw in my $.02 > > Under HIPAA, the Secretary of HHS is required to adopt a standard for > electronic signatures of the HIPAA transactions. Simple and reduced > scope. > > The Secretary is required to adopt Standards (with capital S) > developed > by a SDO from the American National Standards Institute. If no such > standard is available, the Secretary can create her own standards. > > The HIPAA Security Final Rule will reflect security standards > created by > HHS because there are no other security standards for healthcare > developed by an ANSI SDO that meet the security requirements expressed > in the HIPAA Law. However, the security final rule will NOT have a > standard for electronic signatures, and this standard will > come out in a > later final rule. > > If the healthcare SDOs were to agree on an ANSI standard for digital > signatures that could be used for the HIPAA transactions, and a very > specific "implementation guide" on how to use this standard > to sign the > HIPAA transactions, the Secretary would have a much easier job in > adopting such standard. Until this happens, the digital > signature final > rule may have to be put on hold, as the DHHS does not want to create > standards in this area in an ivory tower (i.e. in a vacuum). > > In addition, the HIPAA electronic signature standard must be > adopted in > conjunction with the Department of Commerce. > > Does this shed some light ? > > Do you want EDIINT to be adopted by the Secretary as the HIPAA digital > signature standard ? Then, I think you know what to do. > > Please understand that I am not making any promises here. I > am stating > something that will make easier for the NCVHS to recommend a standard > for the Secretary to adopt. This is a self-serving request > as I am one > of the NCVHS members. The NCVHS looked at the possible standards last > month, and as a result, I have sent invitations to the > affected SDOs to > work under HISB in coming up with something "adoptable". I think that > if the group of experts on this list was to work on such task with the > ANSI SDOs, then we could have something that benefits the entire > healthcare industry. > > However, if we let the scope creep to cover other topics, > such as PKI or > "trust" issues, then the wheels could slow down. > > I hope that having a "HIPAA Signature Implementation Guide" does not > preclude other "implementation guides" for things like encryption, > consent form signature, multiple signatures, counter signatures, etc. > that are also necessary but not "mandated" by HIPAA at this time. > > Keep up the good work. > > Kepa > > Dick Brooks wrote: > > > > Wes, > > > > You make some excellent points, I want to focus on a few > that I believe are > > critical in moving forward. > > > > >a) there is interest in having a healthcare group give its > imprimatur to > > >AS2, since it "rounds out" the Internet protocols to make > a complete > > package > > >for HIPAA-compliant, B2B messaging based on ubiquitous > Internet protocols > > >such as HTTP, FTP and SNMP. > > > > Many people (not specifically in healthcare) are confused > by the number of > > "B2B standards" that exist, for example: > > - Vendor initiated (BizTalk and SOAP) > > - Consortia initiated (ebXML by OASIS and UN/CEFACT, XML > Protocols Activity > > by the World Wide Web Consortium ) > > - Internet related standards bodies initiated (IETF - > EDIINT ASx, IETF - > > BEEP) > > - Industry specific standards bodies initiated (HL7, GISB, > UIG, AIAG, etc.) > > > > Not to mention all the proprietary initiatives. > > > > They look at all these "standards" and they're afraid > they'll choose the > > "wrong standard". I believe industry organizations, like HL7, play a > > critical role in helping people choose a B2B standard > that's appropriate for > > their needs. > > > > >b) there is some despair at seeing AS2 get out of IETF > before quantum > > >computers pretty much obsolete everything based on computers with > > >deterministic states (this last was an attempt at humor) > > > > Actually this is an excellent point. The IETF is very > particular when it > > comes to designing/endorsing standards, as it should be. > Some of the recent > > concerns with AS1 (see Ned Freed's comments attached) raise the > > probabilities of a longer delay for AS2, because the > non-GISB portion of AS2 > > depends on AS1. I'm not aware of any issues with the GISB > portion of AS2. > > > > >c) there is a sense that being an ANSI Standard is a > requirement if one > > >desires to get the government to mandate its use. > > > > The Department of Energy, via the Federal Energy Regulatory > Commission, > > mandated use of the GISB standard and I don't believe it is an ANSI > > standard. Perhaps Rae McQuade, Executive Director of GISB > (gisb1@aol.com), > > can comment on this. > > > > I certainly don't understand many of the idiosyncrasies of > HL7 Standards > > versus Recommendations so I'll listen and learn as this > discussion evolves. > > I have been an active participant in many of the > initiatives mentioned above > > including: ebXML, GISB, UIG, W3C XP, and of course IETF > EDIINT. I look > > forward to working with the HL7 organization on this very > important decision > > during the coming months. > > > > Regards, > > > > Dick Brooks > > http://www.8760.com/ > > > > -----Original Message----- > > From: owner-ietf-ediint@mail.imc.org > > [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Rishel,Wes > > Sent: Monday, November 20, 2000 12:07 AM > > To: 'Gunther Schadow'; Dick Brooks > > Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > For many reasons it would be more desirable to be a > Standard, but I am not > > sure that there aren't some shades of gray, particularly if > the difference > > in the required time is important. I will wait to hear from > Gunther about > > the HIPAA issue, but I am suspecting that the following is true: > > > > a) there is interest in having a healthcare group give its > imprimatur to > > AS2, since it "rounds out" the Internet protocols to make a > complete package > > for HIPAA-compliant, B2B messaging based on ubiquitous > Internet protocols > > such as HTTP, FTP and SNMP. > > > > b) there is some despair at seeing AS2 get out of IETF > before quantum > > computers pretty much obsolete everything based on computers with > > deterministic states (this last was an attempt at humor) > > > > c) there is a sense that being an ANSI Standard is a > requirement if one > > desires to get the government to mandate its use. > > > > I would take issue with item (c). It is surely helpful to > be a standard, but > > it is also helpful to be any sort of publication of an > ANSI-accredited > > standards development organization. Furthermore, unless > someone knows > > something specific, I would be skeptical that the current > administration > > would introduce another delay in the final rule on security > by attempting to > > add AS2 at this late date. > > > > Rather than a government mandate, I suspect that the > benefit of an HL7 > > imprimatur, and perhaps a profile or two, would be to > assist in promoting > > the Internet and AS2 as means to exchange the HIPAA > transactions without > > reliance on value added networks. At the same time it would > be very valuable > > to HL7 to have ways to exchange standard (old syntax) HL7 > messages and > > HL7-XML messages over the Internet using the same infrastructure > > (integration brokers and servers) as are being sold for other B2B > > applications in healthcare, the power industry, etc. > > > > If this model is correct a Standard is better, but a > Recommendation also > > provides substantial benefit. One approach would be to create a > > Recommendation first and follow it up with a Standard after > some operational > > experience has been obtained. > > > > > -----Original Message----- > > > From: Gunther Schadow [mailto:gunther@aurora.regenstrief.org] > > > Sent: Saturday, November 18, 2000 8:06 PM > > > To: dick@8760.com > > > Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary > Crough; Beth > > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; > ietf-ediint@imc.org > > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > Dick Brooks wrote: > > > > > > > > Thanks Wes. > > > > > > > > Based on your description I would anticipate the EDIINT AS2 > > > spec taking the > > > > "Recommendation" route, IF the group decides to go forward. > > > Do you see it > > > > the same way? > > > > > > Dick, I actually do see it the other way. The EDIINT work in > > > HL7 as we > > > discussed it in relation to HIPAA is only useful if we end up > > > with an ANSI > > > approved standard. That must be a standard, not a recommendation. > > > > > > I'll fill in Wes on the HIPAA issue under separate cover. > Glad you can > > > make it for 1/8/2001. Thank you for your help. > > > > > > regards, > > > -Gunther > > > > > > > > -------------------------------------------------------------- > ---------- > > > > Part 1.2 Type: Microsoft MHTML Document 5.0 (message/rfc822) > > Encoding: 7bit > > From owner-ietf-ediint@mail.imc.org Wed Nov 22 02:17:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18171 for ; Wed, 22 Nov 2000 02:17:45 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA16441 for ietf-ediint-bks; Tue, 21 Nov 2000 22:34:57 -0800 (PST) Received: from puma.gartner.com (overlord.gartner.com [207.140.148.33]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA16437 for ; Tue, 21 Nov 2000 22:34:56 -0800 (PST) Received: by puma.gartner.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 01:34:36 -0500 Message-ID: <69A38F8986F3D211A6B00008C79121060969A310@mammoth.gartner.com> From: "Rishel,Wes" To: "'Kepa Zubeldia'" , dick@8760.com Cc: "Rishel,Wes" , Gunther Schadow , Rik Drummond , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Wed, 22 Nov 2000 01:34:50 -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: I doubt if XML will ever be a meaningful content type for EDIINT. Saying that the content is HL7, X12, or NCPDP implies the availability of a semantic interpretation of the payload. This would be true whether the payload was in the current HL7, X12, or NCPDP syntaxes or in the particular applications of XML that they may adopt. If the only claim is that the payload is XML there is no such linkage to a semantic standard, even if the XML instance contains a pointer to a schema in a repository somewhere. A schema is far less than a semantic representation of the instance; it simplify enables a better and more thorough parsing of the message. > -----Original Message----- > From: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > Sent: Tuesday, November 21, 2000 2:52 PM > To: dick@8760.com > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > Dick, > > Probably the requirements are identical, except that the > content will be > in X12 or NCPDP syntax instead of HL7 or XML. > > Kepa > > Dick Brooks wrote: > > > > Kepa, > > > > > Are you volunteering to create an interoperability > profile for digital > > > signatures of the HIPAA standard transactions ? > > > > My offer to assist in the development of an > interoperability profile was in > > response to a need identified within HL7. However, I would > be willing to > > help the HIPAA folks create an interoperability profile, > provided it's based > > on a technology that I'm familiar with (e.g. EDIINT AS2, > GISB EDM, ebXML). > > > > I would hope the investment in developing an > interoperability profile for > > HL7 could be leveraged in other areas (e.g. HIPAA, ASTM), > without any > > additional work. Do you see HIPAA's requirements being significantly > > different enough from HL7 to require a separate > interoperability profile? > > > > Thanks, > > > > 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: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > > > Sent: Monday, November 20, 2000 6:13 PM > > > To: Dick Brooks > > > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary > Crough; Beth > > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; > ietf-ediint@imc.org > > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > Dick, > > > > > > Are you volunteering to create an interoperability > profile for digital > > > signatures of the HIPAA standard transactions ? X12, > NCPDP, and X12+HL7 > > > (in which the signature could be on the HL7 or on the X12 > components) > > > are the immediate needs. However, keep in mind that > NCPDP could also be > > > in EDIFACT syntax (e.g. prescriptions) and HL7 could be > in different > > > syntaxes. But, for HIPAA purposes, at this time we need > something for > > > the 275 attachment only. Other HL7 messages could come > later through > > > other interoperability profiles. > > > > > > If we have a very narrow scope (HIPAA transactions as > they were released > > > in the Final Rule, plus attachments as we know them) then > it is possible > > > to get an agreement, even if there is not yet an > agreement on other > > > issues or on PKI issues. > > > > > > Other volunteers ? > > > > > > Kepa > > > > > > Dick Brooks wrote: > > > > > > > > Thanks Wes. > > > > > > > > Based on your description I would anticipate the EDIINT AS2 > > > spec taking the > > > > "Recommendation" route, IF the group decides to go forward. Do > > > you see it > > > > the same way? > > > > > > > > FYI - other groups that have adopted AS2 have found it > > > necessary to define > > > > "interoperability profiles". These profiles identify > the exact set of > > > > "options" from AS2 that everyone in the "trading > community" agrees to > > > > follow, in order to ensure interoperability. For example, GISB > > > has already > > > > defined an AS2 interoperability profile and the New York > > > Collaborative, in > > > > accordance with the Public Service Commission regulations, is > > > in the process > > > > of defining their interoperability profile. I'm > familiar with both these > > > > groups and the process used to develop their profiles. > I could help HL7 > > > > develop an AS2 interoperability profile, if the group decides > > > to pursue this > > > > approach. > > > > > > > > Regards, > > > > > > > > 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: Rishel,Wes [mailto:wes.rishel@gartner.com] > > > > > Sent: Friday, November 17, 2000 8:32 PM > > > > > To: 'dick@8760.com'; Gunther Schadow > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; > Beth Morrow; > > > > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > > > > Subject: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > > > > > > > As the chair-elect of HL7 I would like to respond to DB's > > > > > question about HL7 > > > > > process. > > > > > > > > > > HL7 has two kinds of specifications that are > published using slighly > > > > > different processes: a Standard is submitted to ANSI for > > > > > certification once > > > > > it has passed ballot; a Recommendation is published > by HL7 but is not > > > > > submitted to ANSI and does not become an ANSI standard. Some > > > > > Recommendations > > > > > have had substantial acceptance among the HL7 community, > > > including it's > > > > > "lower level protocols" which define ways to reliably pass > > > > > discrete messages > > > > > over RS-232 and TCP, and were published sometime in > the early 1990s. > > > > > > > > > > A Standard originates under the sponsorship of a Technical > > > > > Committee. If HL7 > > > > > were to create a Standard for EDIINT it would be the > Control/Query > > > > > committee. It is balloted at the committee level. > (Actually anyone can > > > > > participate in the committee ballot, but in practice those who > > > > > choose to do > > > > > so are usually those who participate in, or follow > the work of, the > > > > > Technical Committee.) When it passes a committee > level ballot it is > > > > > submitted for ballot by the full HL7 Working Group (which is > > > the entire > > > > > organization). If it passes at this level it is automatically > > > submitted to > > > > > ANSI for certification. The ANSI review allows time for public > > > > > comment, but > > > > > it is primarily a certification that the process was fair and > > > consistent > > > > > with our bylaws. To date, have never had an issue arise that > > > prevented or > > > > > delayed the certification process. > > > > > > > > > > In addition to Technical Committees HL7 has Special Interest > > > > > Groups. Gunther > > > > > is co-chair of our SIG on security. Strictly speaking, a SIG > > > > > cannot initiate > > > > > the balloting of a standard; but SIGs can prepare > such a document, and > > > > > obtain the consent of a Technical Committee which > sponsors the ballot. > > > > > > > > > > The other kind of document, the Recommendation, is easier to > > > get out the > > > > > door. It can be originated by a SIG, and it has only > one level of > > > > > balloting. > > > > > The majority that is required to pass a Recommendation is > > > less severe than > > > > > the majority required to pass a Standard (67% vs. 90%). > > > > > > > > > > Ballots are conducted using the Web. Assuming that both > > > ballots pass an > > > > > energetic committee can easily complete the entire process in > > > two of our > > > > > three-per-year Working Group meetings (roughly 8 months > > > elapsed time). (Of > > > > > course most committees have substantial time invested > in debating the > > > > > document before it begins the process.) > > > > > > > > > > Most of the meetings required at certain points in > the process can be > > > > > handled using conference calls; in theory a REALLY motivated > > > > > committee could > > > > > accomplish the two-level ballot in five months and then wait > > > about three > > > > > months for ANSI certication. (That is a theoretical figure > > > that has never > > > > > been realized in practise.) > > > > > > > > > > Recommendations can be passed in roughly four months. > > > > > > > > > > Best regards, > > > > > > > > > > Wes Rishel > > > > > Research Director > > > > > Healthcare Industry Research & Advisory Services > > > > > GartnerGroup > > > > > Alameda, CA > > > > > Client inquiries: call +1-203-316-1288 or email to > indapps@gartner.com > > > > > wes.rishel@gartner.com > > > > > 510 522 8135 > > > > > 510 521 2423 (fax) > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dick Brooks [mailto:dick@8760.com] > > > > > > Sent: Thursday, November 02, 2000 10:27 AM > > > > > > To: Gunther Schadow > > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; > Beth Morrow; > > > > > > David@Drummondgroup. Com; GISB1@aol.com; > ietf-ediint@imc.org; Dick > > > > > > Brooks > > > > > > Subject: RE: EDIINT and HIPAA > > > > > > > > > > > > > > > > > > > > > > > > I'm not familiar with the HL7 standards process, all of > > > > > > my experience > > > > > > has been with IETF, DISA, GISB and recently ebXML. > Each of these > > > > > > organizations has a different process for developing > > > standards. If we > > > > > > brought AS2 to HL7 today, how long would it take to > become an > > > > > > ANSI standard? > > > > > > I would like to read HL7's operational process document, can > > > > > > you provide a > > > > > > pointer? > > > > > > > > > > > > > > > > > > > From owner-ietf-ediint@mail.imc.org Wed Nov 22 02:44:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23559 for ; Wed, 22 Nov 2000 02:44:42 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA19240 for ietf-ediint-bks; Tue, 21 Nov 2000 23:06:40 -0800 (PST) Received: from puma.gartner.com (overlord.gartner.com [207.140.148.33]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA19225 for ; Tue, 21 Nov 2000 23:06:37 -0800 (PST) Received: by puma.gartner.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 02:05:32 -0500 Message-ID: <69A38F8986F3D211A6B00008C79121060969A311@mammoth.gartner.com> From: "Rishel,Wes" To: "'Kepa Zubeldia'" , Gunther Schadow Cc: dick@8760.com, "Rishel,Wes" , Rik Drummond , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Wed, 22 Nov 2000 02:05:43 -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: This note implies a characteristic of AS2 that I had not previously recognized. I will state it here and then perhaps someone can tell me if I am reading it wrong. The note seems to imply (a) that AS2 does not support SMTP or FTP (b) that AS2 exchanges between business partners follow a pattern where the partner that initiates the exchange has to poll for the application response. Previously I had thought that AS2 supported all of HTTP, HTTP/S, SMTP and FTP, and that it was necessarily to develop a set of profiles for there to be meaningful communications among trading partners. Furthermore, I had assumed that if messages were to go asynchronously between point A and point B and back, that each of point A and point B could offer HTTP servers or FTP servers. In particular, if A is the payer and B is the provider, then B could initiate a claim by posting to A's HTTP server. Later on, A could post a response to B's HTTP server. B would have the option of handling the event immediately or building a queue of inbound transactions to process when it wanted. Was I wrong before? Now, given that a significant number of payer organizations are small practices they may not wish to spend the $40/month that it takes to have a permanent presence on the Internet. Such practices might prefer to poll the payer for responses. (To be honest I didn't realize that EDIINT supported that mode. I thought it was basically a way to send a message and optionally get an immediate response giving the gross status of the initial transmission.) I would agree with Kepa that it would be preferable to use SMTP to HTTP for these small payers, but using e-mail is a somewhat dicey proposition. In the ideal world, where someone establishes an isolated SMTP server just to deal with transactions, and gives that server direct access through the firewall, then it should be fairly robust. But large enterprises tend to have enterprise mail systems that include very complex interrelationships between servers that have many more functions than simple mail transfer and are difficult to maintain. Although mail delivery of AS2 transactions would probably work most of the time, it would be significantly less robust than HTTP or FTP implementations, where there is only one server involved on each side and its administration can be dedicated to the purpose of handling transactions. So, what is happening? How much do I have to relearn since my last coffee break (:-) > -----Original Message----- > From: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > Sent: Tuesday, November 21, 2000 3:04 PM > To: Gunther Schadow > Cc: dick@8760.com; Rishel,Wes; Rik Drummond; CLEM; Gary Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > Gunther, > > Here is some food for thought concerning AS1... > > When a provider files a batch of claims, the transmission can > easily be > sent with AS1 or AS2. The claims will adjudicate over a > period of a few > days. When the claims adjudicate, there is an X12 835 > transaction that > the payer needs to send back to the provider with the > remittance advice. > > A typical provider will deal with about 400 payers on a > routine basis. > A typical payers will deal with about 100,000 providers on a routine > basis. > > So, if the provider must be using AS2 only, the provider will have to > periodically (probably daily) poll all the payers in case > they have some > remittance advice or other transaction from that payer. The payer, on > the other hand, will have to hold "mailboxes" for 100,000+ > providers and > be polled by them periodically, so the remittance advices can be > distributed back to the providers. Not strikingly efficient. > > But if the provider can send the claims with either AS1 or > AS2, and the > payer can send the remittance advices back with AS1, all the > polling and > mailboxing is eliminated, as the flow goes through the standard email > pathways. The provider does not have to maintain an internet > server to > received EDI, only the capability to receive internet mail. > Sounds like > a much simpler approach. Of course, this assumes that the AS1 is not > only signed but also encrypted. > > So, if you ask me, I would say that AS1 should not go away, > even if the > fancier and better way to do it is with AS2. There is > certain beauty in > simple solutions. > > Kepa > > > > Gunther Schadow wrote: > > > > Dick, > > > > yes, I think that the HL7 and HIPAA profiles would be > similar if not the > > same. My goal is to get all the healthcare standards > together (in fact > > it is only two of them, HL7 and NCPDP, since X12 is covered > already) and > > develop one profile with options to account for the > specific EDI payload > > used. We have an AS#1 profile already for HL7 and I'd like > to take this > > to go over a couple of issues that we found. As much as I > can see why > > AS#2 is very useful, I would not want to throw out the > AS#1/email option > > if not absolutely necessary. You mention ebXML -- we have > some interest > > in ebXML but we're not sure if any of this is ready for > prime time, but > > would like to get your thoughts on this. > > > > regards > > -Gunther > > > > Dick Brooks wrote: > > > > > > Kepa, > > > > > > > Are you volunteering to create an interoperability > profile for digital > > > > signatures of the HIPAA standard transactions ? > > > > > > My offer to assist in the development of an > interoperability profile was in > > > response to a need identified within HL7. However, I > would be willing to > > > help the HIPAA folks create an interoperability profile, > provided it's based > > > on a technology that I'm familiar with (e.g. EDIINT AS2, > GISB EDM, ebXML). > > > > > > I would hope the investment in developing an > interoperability profile for > > > HL7 could be leveraged in other areas (e.g. HIPAA, ASTM), > without any > > > additional work. Do you see HIPAA's requirements being > significantly > > > different enough from HL7 to require a separate > interoperability profile? > > > > > > Thanks, > > > > > > 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: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > > > > Sent: Monday, November 20, 2000 6:13 PM > > > > To: Dick Brooks > > > > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; > Gary Crough; Beth > > > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; > ietf-ediint@imc.org > > > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > > > > Dick, > > > > > > > > Are you volunteering to create an interoperability > profile for digital > > > > signatures of the HIPAA standard transactions ? X12, > NCPDP, and X12+HL7 > > > > (in which the signature could be on the HL7 or on the > X12 components) > > > > are the immediate needs. However, keep in mind that > NCPDP could also be > > > > in EDIFACT syntax (e.g. prescriptions) and HL7 could be > in different > > > > syntaxes. But, for HIPAA purposes, at this time we > need something for > > > > the 275 attachment only. Other HL7 messages could come > later through > > > > other interoperability profiles. > > > > > > > > If we have a very narrow scope (HIPAA transactions as > they were released > > > > in the Final Rule, plus attachments as we know them) > then it is possible > > > > to get an agreement, even if there is not yet an > agreement on other > > > > issues or on PKI issues. > > > > > > > > Other volunteers ? > > > > > > > > Kepa > > > > > > > > Dick Brooks wrote: > > > > > > > > > > Thanks Wes. > > > > > > > > > > Based on your description I would anticipate the EDIINT AS2 > > > > spec taking the > > > > > "Recommendation" route, IF the group decides to go forward. Do > > > > you see it > > > > > the same way? > > > > > > > > > > FYI - other groups that have adopted AS2 have found it > > > > necessary to define > > > > > "interoperability profiles". These profiles identify > the exact set of > > > > > "options" from AS2 that everyone in the "trading > community" agrees to > > > > > follow, in order to ensure interoperability. For example, GISB > > > > has already > > > > > defined an AS2 interoperability profile and the New York > > > > Collaborative, in > > > > > accordance with the Public Service Commission regulations, is > > > > in the process > > > > > of defining their interoperability profile. I'm > familiar with both these > > > > > groups and the process used to develop their > profiles. I could help HL7 > > > > > develop an AS2 interoperability profile, if the group decides > > > > to pursue this > > > > > approach. > > > > > > > > > > Regards, > > > > > > > > > > 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: Rishel,Wes [mailto:wes.rishel@gartner.com] > > > > > > Sent: Friday, November 17, 2000 8:32 PM > > > > > > To: 'dick@8760.com'; Gunther Schadow > > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; > Beth Morrow; > > > > > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > > > > > Subject: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > > > > > > > > > > As the chair-elect of HL7 I would like to respond to DB's > > > > > > question about HL7 > > > > > > process. > > > > > > > > > > > > HL7 has two kinds of specifications that are > published using slighly > > > > > > different processes: a Standard is submitted to ANSI for > > > > > > certification once > > > > > > it has passed ballot; a Recommendation is published > by HL7 but is not > > > > > > submitted to ANSI and does not become an ANSI standard. Some > > > > > > Recommendations > > > > > > have had substantial acceptance among the HL7 community, > > > > including it's > > > > > > "lower level protocols" which define ways to reliably pass > > > > > > discrete messages > > > > > > over RS-232 and TCP, and were published sometime in > the early 1990s. > > > > > > > > > > > > A Standard originates under the sponsorship of a Technical > > > > > > Committee. If HL7 > > > > > > were to create a Standard for EDIINT it would be > the Control/Query > > > > > > committee. It is balloted at the committee level. > (Actually anyone can > > > > > > participate in the committee ballot, but in > practice those who > > > > > > choose to do > > > > > > so are usually those who participate in, or follow > the work of, the > > > > > > Technical Committee.) When it passes a committee > level ballot it is > > > > > > submitted for ballot by the full HL7 Working Group (which is > > > > the entire > > > > > > organization). If it passes at this level it is > automatically > > > > submitted to > > > > > > ANSI for certification. The ANSI review allows time > for public > > > > > > comment, but > > > > > > it is primarily a certification that the process > was fair and > > > > consistent > > > > > > with our bylaws. To date, have never had an issue arise that > > > > prevented or > > > > > > delayed the certification process. > > > > > > > > > > > > In addition to Technical Committees HL7 has Special Interest > > > > > > Groups. Gunther > > > > > > is co-chair of our SIG on security. Strictly speaking, a SIG > > > > > > cannot initiate > > > > > > the balloting of a standard; but SIGs can prepare > such a document, and > > > > > > obtain the consent of a Technical Committee which > sponsors the ballot. > > > > > > > > > > > > The other kind of document, the Recommendation, is easier to > > > > get out the > > > > > > door. It can be originated by a SIG, and it has > only one level of > > > > > > balloting. > > > > > > The majority that is required to pass a Recommendation is > > > > less severe than > > > > > > the majority required to pass a Standard (67% vs. 90%). > > > > > > > > > > > > Ballots are conducted using the Web. Assuming that both > > > > ballots pass an > > > > > > energetic committee can easily complete the entire > process in > > > > two of our > > > > > > three-per-year Working Group meetings (roughly 8 months > > > > elapsed time). (Of > > > > > > course most committees have substantial time > invested in debating the > > > > > > document before it begins the process.) > > > > > > > > > > > > Most of the meetings required at certain points in > the process can be > > > > > > handled using conference calls; in theory a REALLY motivated > > > > > > committee could > > > > > > accomplish the two-level ballot in five months and then wait > > > > about three > > > > > > months for ANSI certication. (That is a theoretical figure > > > > that has never > > > > > > been realized in practise.) > > > > > > > > > > > > Recommendations can be passed in roughly four months. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Wes Rishel > > > > > > Research Director > > > > > > Healthcare Industry Research & Advisory Services > > > > > > GartnerGroup > > > > > > Alameda, CA > > > > > > Client inquiries: call +1-203-316-1288 or email to > indapps@gartner.com > > > > > > wes.rishel@gartner.com > > > > > > 510 522 8135 > > > > > > 510 521 2423 (fax) > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dick Brooks [mailto:dick@8760.com] > > > > > > > Sent: Thursday, November 02, 2000 10:27 AM > > > > > > > To: Gunther Schadow > > > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary > Crough; Beth Morrow; > > > > > > > David@Drummondgroup. Com; GISB1@aol.com; > ietf-ediint@imc.org; Dick > > > > > > > Brooks > > > > > > > Subject: RE: EDIINT and HIPAA > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not familiar with the HL7 standards > process, all of > > > > > > > my experience > > > > > > > has been with IETF, DISA, GISB and recently > ebXML. Each of these > > > > > > > organizations has a different process for developing > > > > standards. If we > > > > > > > brought AS2 to HL7 today, how long would it take > to become an > > > > > > > ANSI standard? > > > > > > > I would like to read HL7's operational process > document, can > > > > > > > you provide a > > > > > > > pointer? > > > > > > > > > > > > > > > > > > > > > > > From owner-ietf-ediint@mail.imc.org Wed Nov 22 02:52:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA25214 for ; Wed, 22 Nov 2000 02:52:55 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA22505 for ietf-ediint-bks; Tue, 21 Nov 2000 23:20:26 -0800 (PST) Received: from puma.gartner.com (overlord.gartner.com [207.140.148.33]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA22501 for ; Tue, 21 Nov 2000 23:20:24 -0800 (PST) Received: by puma.gartner.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 02:19:54 -0500 Message-ID: <69A38F8986F3D211A6B00008C79121060969A312@mammoth.gartner.com> From: "Rishel,Wes" To: "'Gunther Schadow'" , "Rishel,Wes" Cc: dick@8760.com, Rik Drummond , Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Wed, 22 Nov 2000 02:19:51 -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: I won't repeat my previous note about the difference between EDIINT using digital signatures to authenticate messages and somehow using it to implement electronic signatures; but this note clearly implies that the itch we are trying to scratch is electronic signatures. Whatever happens to electronic signatures I would be delighted if AS2 somehow got launched for the simple purpose of providing authentic, encrypted B2B messages built on top of ubiquitous Internet protocols. I would like to offer my enthusiastic support to enabling that by whatever means works best. If that means that HL7 adopts it, so be it. (I just hope we don't adapt it.) I am very much planning to be at the meeting 1/8. Since Rik has got a plane to catch, is there any way to do some work on Sunday? I am not sure I would be able to make it, but we ought to be able to make some progress at least informally that will help to streamline things on Monday. (Given the somewhat ill-defined other requirements of a Chair Elect I don't know if I can stay in the meeting all day or not. But I will be there as much as I can.) > -----Original Message----- > From: Gunther Schadow [mailto:gunther@aurora.regenstrief.org] > Sent: Monday, November 20, 2000 7:42 AM > To: Rishel,Wes > Cc: dick@8760.com; Rik Drummond; Kepa Zubeldia; CLEM; Gary > Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > Wes, > > one of your guesses was right on target, it's c: > > > c) there is a sense that being an ANSI Standard is a > requirement if one > > desires to get the government to mandate its use. > > Your issues to this particular item are noted. But first: the HHS and > NCVHS (to the latter I had a chance at attending and being > heard recently) > are looking for some electronic signature standards for > healthcare. Notably > they asked for something beyond the existing "technology > neutral" NPRM. > That's where Kepa and I suggested the EDIINT specs based on > the rationale > that any digisig standard must first fit the information > payload standards > that it is to secure. In other words, since in the U.S. > healthcare system > we use X12N, HL7, and NCPDP, any concrete signature standard > should fit > those existing EDI standards. This and other reasons speak > for EDIINT as > a strong if not the only reasonable and available solution. > > The question then is, what does it take for HHS to pick EDIINT? And we > figured that some sort of ANSI accreditation is needed. Clem has told > me that may be all it takes is endorsement from an ANSI > accredited SDO, > so, you're right, Wes, that a full ANSI standard may not be needed. > However, I figured that it would be merely one additional ballot cycle > to get EDIINT out as an ANSI standard under HL7 cover, and therefore > that this approach may be extra-safe. > > I believe that the HL7 balloting would be more or less > pro-forma, since > the balloted material has been worked on with meticulous > reality testing > and with products available as the specifications were fleshed out. > Also, HL7 has a history in dealing with the EDIINT specification and > that ballot in 1998 didn't turn out any major issues that would had > caused a reballot. So, I reckon, if we have a committee level ballot > that succeeds, we do have some sort of working "ANSI SDO endorsment" > at that point (as much as an Informative ballot would ever > yield.) So we > could do the full membership ballot as additional reinforcement, again > expecting little trouble along the way. > > > If this model is correct a Standard is better, but a > Recommendation also > > provides substantial benefit. One approach would be to create a > > Recommendation first and follow it up with a Standard after > some operational > > experience has been obtained. > > As a conclusion, I would defer to Kepa, Wes, and Clem to see > what the best > vehicle would be to make EDIINT viable for HHS -- I think that an ANSI > seal would probably be the best shot. I also see little > arguments against > making EDIINT some sort of HL7 standard proper. In our new > terms, EDIINT > would fall somewhere in the ITS category, and there is not > need for HL7 > to bind itself exclusively to one specification in that category. > > The question is then how such a ballot would look like. There are some > options: > > (1) A set of verbatim copies of IETF EDIINT materials (RFCs > by that time, > I hope.) > > (2) One short document that only refers to the relevant RFCs. > Examples of > such "standards" that do not specify anything by themselves are many > FIPS-PUB standards. > > (3) An HL7 profile that will add a few minor extensions to > the IETF spec. > Those will be necessary for reasons discussed in the existing > HL7 EDIINT > recommendation. > > Finally, for the purpose of EDIINT's status at HHS (and quite > independently > from HL7) we should make certain that NCPDP is being mentioned in any > such profile. I agree that for HL7 it is as much as advertizing for a > competitor, on the other hand, from what I have heared, I > believe that > relationship between HL7 and NCPDP are potentially very good. > > regards > -Gunther > > PS: given that Rick Drummond has to leave by noon on Monday 1/8/2001 > we have to do a little agenda juggling. This will be a joint meeting > with ASTM and it will look kind of odd to put the technology specific > standard release discussion first in the agenda. However, I'll try to > give a good justification in an introduction so that it should seem > O.K. to do this first. > From owner-ietf-ediint@mail.imc.org Wed Nov 22 09:49:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01987 for ; Wed, 22 Nov 2000 09:49:06 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA02541 for ietf-ediint-bks; Wed, 22 Nov 2000 06:10:13 -0800 (PST) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02534 for ; Wed, 22 Nov 2000 06:10:07 -0800 (PST) Received: from apollo (user-2injr2q.dialup.mindspring.com [165.121.236.90]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with SMTP id JAA16922; Wed, 22 Nov 2000 09:10:40 -0500 (EST) From: "Dick Brooks" To: "Rishel,Wes" , "'Kepa Zubeldia'" , Cc: "'Gunther Schadow'" , "Rik Drummond" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Wed, 22 Nov 2000 08:13:42 -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) In-Reply-To: <69A38F8986F3D211A6B00008C79121060969A30F@mammoth.gartner.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Wes, There is a very fine article from Bruce Schneier in this months Crypto-gram ( ref: http://www.counterpane.com/crypto-gram-0011.html ), regarding the "semantics" of digital signatures, that echoes some of your comments. PGP and S/MIME can be used to construct and apply a digital signature to a document for the purpose described in both 1 and 2. However, in order for the digital signature to have any legal standing a legally binding "contract" is needed that clearly defines a parties "intent" when applying a digital signature to a document. Typically, a trading partner agreement is used to define digital signature semantics and specifies a party's "intent". A digital signature alone will address #1, a digital signature WITH a trading partner agreement addresses both #1 and #2. Caveat 1, Digital signatures, regardless of whether one uses PGP or S/MIME are still imperfect. Secret keys can be stolen and fraud can be committed using a stolen "identity". How does one know when their secret key has been stolen? When a fraudulent act has been committed. Unfortunate but true. Caveat 2, I'm a software engineer - not a lawyer, so the information I've provided is based on "opinions" from others I've spoken with in the Energy industry who have dealt with these "digital signature semantics" issues. It's always wise to seek "legal advice" before engaging in electronic transactions involving digital signatures. -----Original Message----- From: Rishel,Wes [mailto:wes.rishel@gartner.com] Sent: Wednesday, November 22, 2000 12:30 AM To: 'Kepa Zubeldia'; Dick Brooks Cc: Rishel,Wes; 'Gunther Schadow'; Rik Drummond; CLEM; Gary Crough; Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) I guess I missed more than I realized. I have always held that there are two distinct applications of digital signature technology: (1) to authenticate a block of data that might represent an EDI message, a binary executable program, a digital certificate or any of a myriad of other objects that come from the world of technology, and (2) as a way of accomplishing electronic signature, the binding of the identity of a person to an electronic document in a way that approximates the forensic robustness of a handwritten signature on a paper document. Now (2) is clearly accomplished by using the processes described in (1), but there are myriad functional issues around the representation of the document or parts of the document; clearly demarking the scope of what is electronically signed; being able to demonstrate that what the person saw when he signed was the only valid interpretation of the block of data that represents the signed text; being able to demonstrate that the human readable interpretation of the binary data that represents the document has not changed in the years since it was signed; and a signature model that includes distinct concepts such as multiple signatures that apply to different, possibly overlapping parts of documents, countersignatures and signed amendments. I have always thought of EDIINT as a clear example of (1). I have never read anything about it that addresses any of the issues listed in (2). Did I miss a meeting? > -----Original Message----- > From: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > Sent: Monday, November 20, 2000 5:15 PM > To: Dick Brooks > Cc: Rishel,Wes; 'Gunther Schadow'; Rik Drummond; CLEM; Gary > Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > Dick, Wes, > > Now I need to throw in my $.02 > > Under HIPAA, the Secretary of HHS is required to adopt a standard for > electronic signatures of the HIPAA transactions. Simple and reduced > scope. > > The Secretary is required to adopt Standards (with capital S) > developed > by a SDO from the American National Standards Institute. If no such > standard is available, the Secretary can create her own standards. > > The HIPAA Security Final Rule will reflect security standards > created by > HHS because there are no other security standards for healthcare > developed by an ANSI SDO that meet the security requirements expressed > in the HIPAA Law. However, the security final rule will NOT have a > standard for electronic signatures, and this standard will > come out in a > later final rule. > > If the healthcare SDOs were to agree on an ANSI standard for digital > signatures that could be used for the HIPAA transactions, and a very > specific "implementation guide" on how to use this standard > to sign the > HIPAA transactions, the Secretary would have a much easier job in > adopting such standard. Until this happens, the digital > signature final > rule may have to be put on hold, as the DHHS does not want to create > standards in this area in an ivory tower (i.e. in a vacuum). > > In addition, the HIPAA electronic signature standard must be > adopted in > conjunction with the Department of Commerce. > > Does this shed some light ? > > Do you want EDIINT to be adopted by the Secretary as the HIPAA digital > signature standard ? Then, I think you know what to do. > > Please understand that I am not making any promises here. I > am stating > something that will make easier for the NCVHS to recommend a standard > for the Secretary to adopt. This is a self-serving request > as I am one > of the NCVHS members. The NCVHS looked at the possible standards last > month, and as a result, I have sent invitations to the > affected SDOs to > work under HISB in coming up with something "adoptable". I think that > if the group of experts on this list was to work on such task with the > ANSI SDOs, then we could have something that benefits the entire > healthcare industry. > > However, if we let the scope creep to cover other topics, > such as PKI or > "trust" issues, then the wheels could slow down. > > I hope that having a "HIPAA Signature Implementation Guide" does not > preclude other "implementation guides" for things like encryption, > consent form signature, multiple signatures, counter signatures, etc. > that are also necessary but not "mandated" by HIPAA at this time. > > Keep up the good work. > > Kepa > > Dick Brooks wrote: > > > > Wes, > > > > You make some excellent points, I want to focus on a few > that I believe are > > critical in moving forward. > > > > >a) there is interest in having a healthcare group give its > imprimatur to > > >AS2, since it "rounds out" the Internet protocols to make > a complete > > package > > >for HIPAA-compliant, B2B messaging based on ubiquitous > Internet protocols > > >such as HTTP, FTP and SNMP. > > > > Many people (not specifically in healthcare) are confused > by the number of > > "B2B standards" that exist, for example: > > - Vendor initiated (BizTalk and SOAP) > > - Consortia initiated (ebXML by OASIS and UN/CEFACT, XML > Protocols Activity > > by the World Wide Web Consortium ) > > - Internet related standards bodies initiated (IETF - > EDIINT ASx, IETF - > > BEEP) > > - Industry specific standards bodies initiated (HL7, GISB, > UIG, AIAG, etc.) > > > > Not to mention all the proprietary initiatives. > > > > They look at all these "standards" and they're afraid > they'll choose the > > "wrong standard". I believe industry organizations, like HL7, play a > > critical role in helping people choose a B2B standard > that's appropriate for > > their needs. > > > > >b) there is some despair at seeing AS2 get out of IETF > before quantum > > >computers pretty much obsolete everything based on computers with > > >deterministic states (this last was an attempt at humor) > > > > Actually this is an excellent point. The IETF is very > particular when it > > comes to designing/endorsing standards, as it should be. > Some of the recent > > concerns with AS1 (see Ned Freed's comments attached) raise the > > probabilities of a longer delay for AS2, because the > non-GISB portion of AS2 > > depends on AS1. I'm not aware of any issues with the GISB > portion of AS2. > > > > >c) there is a sense that being an ANSI Standard is a > requirement if one > > >desires to get the government to mandate its use. > > > > The Department of Energy, via the Federal Energy Regulatory > Commission, > > mandated use of the GISB standard and I don't believe it is an ANSI > > standard. Perhaps Rae McQuade, Executive Director of GISB > (gisb1@aol.com), > > can comment on this. > > > > I certainly don't understand many of the idiosyncrasies of > HL7 Standards > > versus Recommendations so I'll listen and learn as this > discussion evolves. > > I have been an active participant in many of the > initiatives mentioned above > > including: ebXML, GISB, UIG, W3C XP, and of course IETF > EDIINT. I look > > forward to working with the HL7 organization on this very > important decision > > during the coming months. > > > > Regards, > > > > Dick Brooks > > http://www.8760.com/ > > > > -----Original Message----- > > From: owner-ietf-ediint@mail.imc.org > > [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Rishel,Wes > > Sent: Monday, November 20, 2000 12:07 AM > > To: 'Gunther Schadow'; Dick Brooks > > Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > For many reasons it would be more desirable to be a > Standard, but I am not > > sure that there aren't some shades of gray, particularly if > the difference > > in the required time is important. I will wait to hear from > Gunther about > > the HIPAA issue, but I am suspecting that the following is true: > > > > a) there is interest in having a healthcare group give its > imprimatur to > > AS2, since it "rounds out" the Internet protocols to make a > complete package > > for HIPAA-compliant, B2B messaging based on ubiquitous > Internet protocols > > such as HTTP, FTP and SNMP. > > > > b) there is some despair at seeing AS2 get out of IETF > before quantum > > computers pretty much obsolete everything based on computers with > > deterministic states (this last was an attempt at humor) > > > > c) there is a sense that being an ANSI Standard is a > requirement if one > > desires to get the government to mandate its use. > > > > I would take issue with item (c). It is surely helpful to > be a standard, but > > it is also helpful to be any sort of publication of an > ANSI-accredited > > standards development organization. Furthermore, unless > someone knows > > something specific, I would be skeptical that the current > administration > > would introduce another delay in the final rule on security > by attempting to > > add AS2 at this late date. > > > > Rather than a government mandate, I suspect that the > benefit of an HL7 > > imprimatur, and perhaps a profile or two, would be to > assist in promoting > > the Internet and AS2 as means to exchange the HIPAA > transactions without > > reliance on value added networks. At the same time it would > be very valuable > > to HL7 to have ways to exchange standard (old syntax) HL7 > messages and > > HL7-XML messages over the Internet using the same infrastructure > > (integration brokers and servers) as are being sold for other B2B > > applications in healthcare, the power industry, etc. > > > > If this model is correct a Standard is better, but a > Recommendation also > > provides substantial benefit. One approach would be to create a > > Recommendation first and follow it up with a Standard after > some operational > > experience has been obtained. > > > > > -----Original Message----- > > > From: Gunther Schadow [mailto:gunther@aurora.regenstrief.org] > > > Sent: Saturday, November 18, 2000 8:06 PM > > > To: dick@8760.com > > > Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary > Crough; Beth > > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; > ietf-ediint@imc.org > > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > Dick Brooks wrote: > > > > > > > > Thanks Wes. > > > > > > > > Based on your description I would anticipate the EDIINT AS2 > > > spec taking the > > > > "Recommendation" route, IF the group decides to go forward. > > > Do you see it > > > > the same way? > > > > > > Dick, I actually do see it the other way. The EDIINT work in > > > HL7 as we > > > discussed it in relation to HIPAA is only useful if we end up > > > with an ANSI > > > approved standard. That must be a standard, not a recommendation. > > > > > > I'll fill in Wes on the HIPAA issue under separate cover. > Glad you can > > > make it for 1/8/2001. Thank you for your help. > > > > > > regards, > > > -Gunther > > > > > > > > -------------------------------------------------------------- > ---------- > > > > Part 1.2 Type: Microsoft MHTML Document 5.0 (message/rfc822) > > Encoding: 7bit > > From owner-ietf-ediint@mail.imc.org Wed Nov 22 10:31:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11686 for ; Wed, 22 Nov 2000 10:31:12 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA05178 for ietf-ediint-bks; Wed, 22 Nov 2000 06:58:16 -0800 (PST) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05173 for ; Wed, 22 Nov 2000 06:58:14 -0800 (PST) Received: from apollo (user-2injr2q.dialup.mindspring.com [165.121.236.90]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with SMTP id JAA24704; Wed, 22 Nov 2000 09:58:57 -0500 (EST) From: "Dick Brooks" To: "Rishel,Wes" , "'Kepa Zubeldia'" , "Gunther Schadow" Cc: "Rik Drummond" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Wed, 22 Nov 2000 09:01: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) In-Reply-To: <69A38F8986F3D211A6B00008C79121060969A311@mammoth.gartner.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Wes, see responses inline. >Previously I had thought that AS2 supported all of HTTP, HTTP/S, SMTP and >FTP, and that it was necessarily to develop a set of profiles for there to >be meaningful communications among trading partners. AS2 only supports HTTP and HTTPS (using TLS). AS1 only supports SMTP. In our previous phone discussions I described the capabilities of our GISBAgent product, which supports HTTP, HTTPS, FTP and SMTP. This may have caused some confusion, sorry. >Furthermore, I had assumed that if messages were to go asynchronously >between point A and point B and back, that each of point A and point B could >offer HTTP servers or FTP servers. In particular, if A is the payer and B is >the provider, then B could initiate a claim by posting to A's HTTP server. >Later on, A could post a response to B's HTTP server. B would have the >option of handling the event immediately or building a queue of inbound >transactions to process when it wanted. >Was I wrong before? No, this is exactly the model used throughout the Energy industry. Two parties "push" data to each others HTTP server. Both parties MUST have an HTTP server listening for "incoming" transfers. But what about........ >Now, given that a significant number of payer organizations are small >practices they may not wish to spend the $40/month that it takes to have a >permanent presence on the Internet. Such practices might prefer to poll the >payer for responses. (To be honest I didn't realize that EDIINT supported >that mode. I thought it was basically a way to send a message and optionally >get an immediate response giving the gross status of the initial >transmission.) The Energy industry also has a similar situation with smaller participants that cannot afford/justify a full time HTTP server and Internet connection. There are clearinghouses that offer services for these smaller players, they are very similar to traditional VAN's in this regard. A small party "dials-up" their clearinghouse to send/receive data. >I would agree with Kepa that it would be preferable to use SMTP to HTTP for >these small payers, but using e-mail is a somewhat dicey proposition. In the >ideal world, where someone establishes an isolated SMTP server just to deal >with transactions, and gives that server direct access through the firewall, >then it should be fairly robust. But large enterprises tend to have >enterprise mail systems that include very complex interrelationships between >servers that have many more functions than simple mail transfer and are >difficult to maintain. Although mail delivery of AS2 transactions would >probably work most of the time, it would be significantly less robust than >HTTP or FTP implementations, where there is only one server involved on each >side and its administration can be dedicated to the purpose of handling >transactions. The organizations I've spoken with aren't willing to trust their E-commerce data to an e-mail server. In addition to the well known reliability issues of e-mail there are also some significant security issues, for example: -lack of access control (anyone can send an e-mail message to an e-mail server - spammers) People don't want their E-commerce server spinning it's wheels on spam mail or worse. -many viruses travel via e-mail and E-Commerce servers are designed to automatically process a received message; it could be disastrous if an E-commerce server automatically processed a virus. Certainly, there are ways to deal with each of these issues, but a lot of "off-the-shelf" mail software doesn't address these security issues. >So, what is happening? How much do I have to relearn since my last coffee >break (:-) EDIINT AS2 defines a protocol for securely and reliably exchanging data via HTTP and HTTPS. EDIINT AS1 defines a protocol for securely and reliably exchanging data via SMTP. There are products available (from several vendors) that support the secure/reliable transport of any type of payload (X12, XML, binary, etc.) via HTTP, HTTPS, FTP and SMTP transport. Did this help? Dick Brooks http://www.8760.com/ From owner-ietf-ediint@mail.imc.org Wed Nov 22 12:00:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26946 for ; Wed, 22 Nov 2000 12:00:17 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA15220 for ietf-ediint-bks; Wed, 22 Nov 2000 08:07:11 -0800 (PST) Received: from smtpproxy1.mitre.org (mb-20-100.mitre.org [129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15210 for ; Wed, 22 Nov 2000 08:07:07 -0800 (PST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id LAA16845; Wed, 22 Nov 2000 11:04:51 -0500 (EST) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id LAA22029; Wed, 22 Nov 2000 11:04:49 -0500 (EST) Received: from dhcp-145-238.mitre.org (128.29.145.238) by mailhub1.mitre.org with SMTP id 4934611; Wed, 22 Nov 2000 11:04:20 -0500 Message-ID: <3A1BEED2.3E23B1C4@mitre.org> Date: Wed, 22 Nov 2000 11:05:38 -0500 From: "Kit (Christopher) Lueder" Organization: The MITRE Corporation X-Mailer: Mozilla 4.75 [en]C-20000818M (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Rishel,Wes" CC: "'Kepa Zubeldia'" , dick@8760.com, Gunther Schadow , Rik Drummond , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: AS2 XML requirements (was Re: HL7 Standards Process) References: <69A38F8986F3D211A6B00008C79121060969A310@mammoth.gartner.com> 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 No! XML must be accommodated in EDIINT! I was figuring XML content would be carried as edi-consent, but that seems like a back-door fix rather than a happy solution. This sounds like Wes has raised a new requirement that should be considered in the AS2 spec (and maybe AS1?). I do consider XML to be a type of EDI, since both are computer-processable electronic representations of business transactions, so I request we add a type of edi-xml. And I request we add an attribute/field that indicates the kind of XML document ("semantic standard") being carried in the payload. Kit Lueder, MITRE. "Rishel,Wes" wrote: > > I doubt if XML will ever be a meaningful content type for EDIINT. Saying > that the content is HL7, X12, or NCPDP implies the availability of a > semantic interpretation of the payload. This would be true whether the > payload was in the current HL7, X12, or NCPDP syntaxes or in the particular > applications of XML that they may adopt. > > If the only claim is that the payload is XML there is no such linkage to a > semantic standard, even if the XML instance contains a pointer to a schema > in a repository somewhere. A schema is far less than a semantic > representation of the instance; it simplify enables a better and more > thorough parsing of the message. > > > -----Original Message----- > > From: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > > Sent: Tuesday, November 21, 2000 2:52 PM > > To: dick@8760.com > > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary Crough; Beth > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > Dick, > > > > Probably the requirements are identical, except that the > > content will be > > in X12 or NCPDP syntax instead of HL7 or XML. > > > > Kepa > > > > Dick Brooks wrote: > > > > > > Kepa, > > > > > > > Are you volunteering to create an interoperability > > profile for digital > > > > signatures of the HIPAA standard transactions ? > > > > > > My offer to assist in the development of an > > interoperability profile was in > > > response to a need identified within HL7. However, I would > > be willing to > > > help the HIPAA folks create an interoperability profile, > > provided it's based > > > on a technology that I'm familiar with (e.g. EDIINT AS2, > > GISB EDM, ebXML). > > > > > > I would hope the investment in developing an > > interoperability profile for > > > HL7 could be leveraged in other areas (e.g. HIPAA, ASTM), > > without any > > > additional work. Do you see HIPAA's requirements being significantly > > > different enough from HL7 to require a separate > > interoperability profile? > > > > > > Thanks, > > > > > > 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: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > > > > Sent: Monday, November 20, 2000 6:13 PM > > > > To: Dick Brooks > > > > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary > > Crough; Beth > > > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; > > ietf-ediint@imc.org > > > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > > > > Dick, > > > > > > > > Are you volunteering to create an interoperability > > profile for digital > > > > signatures of the HIPAA standard transactions ? X12, > > NCPDP, and X12+HL7 > > > > (in which the signature could be on the HL7 or on the X12 > > components) > > > > are the immediate needs. However, keep in mind that > > NCPDP could also be > > > > in EDIFACT syntax (e.g. prescriptions) and HL7 could be > > in different > > > > syntaxes. But, for HIPAA purposes, at this time we need > > something for > > > > the 275 attachment only. Other HL7 messages could come > > later through > > > > other interoperability profiles. > > > > > > > > If we have a very narrow scope (HIPAA transactions as > > they were released > > > > in the Final Rule, plus attachments as we know them) then > > it is possible > > > > to get an agreement, even if there is not yet an > > agreement on other > > > > issues or on PKI issues. > > > > > > > > Other volunteers ? > > > > > > > > Kepa > > > > > > > > Dick Brooks wrote: > > > > > > > > > > Thanks Wes. > > > > > > > > > > Based on your description I would anticipate the EDIINT AS2 > > > > spec taking the > > > > > "Recommendation" route, IF the group decides to go forward. Do > > > > you see it > > > > > the same way? > > > > > > > > > > FYI - other groups that have adopted AS2 have found it > > > > necessary to define > > > > > "interoperability profiles". These profiles identify > > the exact set of > > > > > "options" from AS2 that everyone in the "trading > > community" agrees to > > > > > follow, in order to ensure interoperability. For example, GISB > > > > has already > > > > > defined an AS2 interoperability profile and the New York > > > > Collaborative, in > > > > > accordance with the Public Service Commission regulations, is > > > > in the process > > > > > of defining their interoperability profile. I'm > > familiar with both these > > > > > groups and the process used to develop their profiles. > > I could help HL7 > > > > > develop an AS2 interoperability profile, if the group decides > > > > to pursue this > > > > > approach. > > > > > > > > > > Regards, > > > > > > > > > > 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: Rishel,Wes [mailto:wes.rishel@gartner.com] > > > > > > Sent: Friday, November 17, 2000 8:32 PM > > > > > > To: 'dick@8760.com'; Gunther Schadow > > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; > > Beth Morrow; > > > > > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > > > > > Subject: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > > > > > > > > > > As the chair-elect of HL7 I would like to respond to DB's > > > > > > question about HL7 > > > > > > process. > > > > > > > > > > > > HL7 has two kinds of specifications that are > > published using slighly > > > > > > different processes: a Standard is submitted to ANSI for > > > > > > certification once > > > > > > it has passed ballot; a Recommendation is published > > by HL7 but is not > > > > > > submitted to ANSI and does not become an ANSI standard. Some > > > > > > Recommendations > > > > > > have had substantial acceptance among the HL7 community, > > > > including it's > > > > > > "lower level protocols" which define ways to reliably pass > > > > > > discrete messages > > > > > > over RS-232 and TCP, and were published sometime in > > the early 1990s. > > > > > > > > > > > > A Standard originates under the sponsorship of a Technical > > > > > > Committee. If HL7 > > > > > > were to create a Standard for EDIINT it would be the > > Control/Query > > > > > > committee. It is balloted at the committee level. > > (Actually anyone can > > > > > > participate in the committee ballot, but in practice those who > > > > > > choose to do > > > > > > so are usually those who participate in, or follow > > the work of, the > > > > > > Technical Committee.) When it passes a committee > > level ballot it is > > > > > > submitted for ballot by the full HL7 Working Group (which is > > > > the entire > > > > > > organization). If it passes at this level it is automatically > > > > submitted to > > > > > > ANSI for certification. The ANSI review allows time for public > > > > > > comment, but > > > > > > it is primarily a certification that the process was fair and > > > > consistent > > > > > > with our bylaws. To date, have never had an issue arise that > > > > prevented or > > > > > > delayed the certification process. > > > > > > > > > > > > In addition to Technical Committees HL7 has Special Interest > > > > > > Groups. Gunther > > > > > > is co-chair of our SIG on security. Strictly speaking, a SIG > > > > > > cannot initiate > > > > > > the balloting of a standard; but SIGs can prepare > > such a document, and > > > > > > obtain the consent of a Technical Committee which > > sponsors the ballot. > > > > > > > > > > > > The other kind of document, the Recommendation, is easier to > > > > get out the > > > > > > door. It can be originated by a SIG, and it has only > > one level of > > > > > > balloting. > > > > > > The majority that is required to pass a Recommendation is > > > > less severe than > > > > > > the majority required to pass a Standard (67% vs. 90%). > > > > > > > > > > > > Ballots are conducted using the Web. Assuming that both > > > > ballots pass an > > > > > > energetic committee can easily complete the entire process in > > > > two of our > > > > > > three-per-year Working Group meetings (roughly 8 months > > > > elapsed time). (Of > > > > > > course most committees have substantial time invested > > in debating the > > > > > > document before it begins the process.) > > > > > > > > > > > > Most of the meetings required at certain points in > > the process can be > > > > > > handled using conference calls; in theory a REALLY motivated > > > > > > committee could > > > > > > accomplish the two-level ballot in five months and then wait > > > > about three > > > > > > months for ANSI certication. (That is a theoretical figure > > > > that has never > > > > > > been realized in practise.) > > > > > > > > > > > > Recommendations can be passed in roughly four months. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Wes Rishel > > > > > > Research Director > > > > > > Healthcare Industry Research & Advisory Services > > > > > > GartnerGroup > > > > > > Alameda, CA > > > > > > Client inquiries: call +1-203-316-1288 or email to > > indapps@gartner.com > > > > > > wes.rishel@gartner.com > > > > > > 510 522 8135 > > > > > > 510 521 2423 (fax) > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dick Brooks [mailto:dick@8760.com] > > > > > > > Sent: Thursday, November 02, 2000 10:27 AM > > > > > > > To: Gunther Schadow > > > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; > > Beth Morrow; > > > > > > > David@Drummondgroup. Com; GISB1@aol.com; > > ietf-ediint@imc.org; Dick > > > > > > > Brooks > > > > > > > Subject: RE: EDIINT and HIPAA > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not familiar with the HL7 standards process, all of > > > > > > > my experience > > > > > > > has been with IETF, DISA, GISB and recently ebXML. > > Each of these > > > > > > > organizations has a different process for developing > > > > standards. If we > > > > > > > brought AS2 to HL7 today, how long would it take to > > become an > > > > > > > ANSI standard? > > > > > > > I would like to read HL7's operational process document, can > > > > > > > you provide a > > > > > > > pointer? > > > > > > > > > > > > > > > > > > > > > > > > -- _/ _/ Kit C. J. Lueder _/ _/ _/ The MITRE Corp. Tel: 703-883-5205 _/_/_/ _/ _/_/_/ 1820 Dolley Madison Bl Cell: 703-577-2463 _/ _/ _/ _/ Mailstop W658 FAX: 703-883-3383 _/ _/ _/ _/ McLean, VA 22102 Mail: kit@mitre.org Worse than an unanswered question is an unquestioned answer. From owner-ietf-ediint@mail.imc.org Wed Nov 22 12:36:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03630 for ; Wed, 22 Nov 2000 12:36:02 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA17317 for ietf-ediint-bks; Wed, 22 Nov 2000 08:50:07 -0800 (PST) Received: from puma.gartner.com (overlord.gartner.com [207.140.148.33]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA17313 for ; Wed, 22 Nov 2000 08:50:05 -0800 (PST) Received: by puma.gartner.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 11:49:21 -0500 Message-ID: <69A38F8986F3D211A6B00008C79121060969A329@mammoth.gartner.com> From: "Rishel,Wes" To: "'Dick Brooks'" , "Rishel,Wes" , "'Kepa Zubeldia'" , Gunther Schadow Cc: Rik Drummond , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Wed, 22 Nov 2000 11:49:11 -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: Dick, Thanks. This was very helpful. My remaining concern is that if we in healthcare attempt to apply EDIINT as a way of using digital signatures to accomplish electronic signatures we will end up with EDIINT mired in discussions and revisions that would prevent its being published for its primary business purpose. It is possible that I am misunderstanding other messages and this is not a concern. It is, however, a hypothetically scenario that could happen, and it would be unfortunate to continue to keep EDIINT from the world if it did. Wes > -----Original Message----- > From: Dick Brooks [mailto:dick@8760.com] > Sent: Wednesday, November 22, 2000 7:02 AM > To: Rishel,Wes; 'Kepa Zubeldia'; Gunther Schadow > Cc: Rik Drummond; CLEM; Gary Crough; Beth Morrow; David@Drummondgroup. > Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > Wes, see responses inline. > > >Previously I had thought that AS2 supported all of HTTP, > HTTP/S, SMTP and > >FTP, and that it was necessarily to develop a set of > profiles for there to > >be meaningful communications among trading partners. > > AS2 only supports HTTP and HTTPS (using TLS). AS1 only supports SMTP. > > In our previous phone discussions I described the capabilities of our > GISBAgent product, > which supports HTTP, HTTPS, FTP and SMTP. This may have caused some > confusion, sorry. > > >Furthermore, I had assumed that if messages were to go asynchronously > >between point A and point B and back, that each of point A > and point B > could > >offer HTTP servers or FTP servers. In particular, if A is > the payer and B > is > >the provider, then B could initiate a claim by posting to > A's HTTP server. > >Later on, A could post a response to B's HTTP server. B > would have the > >option of handling the event immediately or building a queue > of inbound > >transactions to process when it wanted. > > >Was I wrong before? > > No, this is exactly the model used throughout the Energy industry. Two > parties > "push" data to each others HTTP server. Both parties MUST have an HTTP > server > listening for "incoming" transfers. But what about........ > > >Now, given that a significant number of payer organizations are small > >practices they may not wish to spend the $40/month that it > takes to have a > >permanent presence on the Internet. Such practices might > prefer to poll the > >payer for responses. (To be honest I didn't realize that > EDIINT supported > >that mode. I thought it was basically a way to send a message and > optionally > >get an immediate response giving the gross status of the initial > >transmission.) > > The Energy industry also has a similar situation with smaller > participants > that > cannot afford/justify a full time HTTP server and Internet connection. > There are clearinghouses that offer services for these > smaller players, they > are > very similar to traditional VAN's in this regard. A small > party "dials-up" > their > clearinghouse to send/receive data. > > >I would agree with Kepa that it would be preferable to use > SMTP to HTTP for > >these small payers, but using e-mail is a somewhat dicey > proposition. In > the > >ideal world, where someone establishes an isolated SMTP > server just to deal > >with transactions, and gives that server direct access through the > firewall, > >then it should be fairly robust. But large enterprises tend to have > >enterprise mail systems that include very complex interrelationships > between > >servers that have many more functions than simple mail > transfer and are > >difficult to maintain. Although mail delivery of AS2 > transactions would > >probably work most of the time, it would be significantly > less robust than > >HTTP or FTP implementations, where there is only one server > involved on > each > >side and its administration can be dedicated to the purpose > of handling > >transactions. > > The organizations I've spoken with aren't willing to trust > their E-commerce > data to an e-mail server. In addition to the well known > reliability issues > of e-mail > there are also some significant security issues, for example: > > -lack of access control (anyone can send an e-mail message to > an e-mail > server - spammers) > People don't want their E-commerce server spinning it's > wheels on spam mail > or worse. > -many viruses travel via e-mail and E-Commerce servers are designed to > automatically process > a received message; it could be disastrous if an E-commerce server > automatically processed a virus. > > Certainly, there are ways to deal with each of these issues, > but a lot of > "off-the-shelf" mail software > doesn't address these security issues. > > >So, what is happening? How much do I have to relearn since > my last coffee > >break (:-) > > EDIINT AS2 defines a protocol for securely and reliably > exchanging data via > HTTP and HTTPS. > EDIINT AS1 defines a protocol for securely and reliably > exchanging data via > SMTP. > > There are products available (from several vendors) that support the > secure/reliable transport of > any type of payload (X12, XML, binary, etc.) via HTTP, HTTPS, > FTP and SMTP > transport. > > Did this help? > > Dick Brooks > http://www.8760.com/ > > From owner-ietf-ediint@mail.imc.org Wed Nov 22 12:37:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03819 for ; Wed, 22 Nov 2000 12:37:30 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA17174 for ietf-ediint-bks; Wed, 22 Nov 2000 08:43:58 -0800 (PST) Received: from puma.gartner.com (overlord.gartner.com [207.140.148.33]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA17170 for ; Wed, 22 Nov 2000 08:43:56 -0800 (PST) Received: by puma.gartner.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 11:42:37 -0500 Message-ID: <69A38F8986F3D211A6B00008C79121060969A328@mammoth.gartner.com> From: "Rishel,Wes" To: "'Kit (Christopher) Lueder'" , "Rishel,Wes" Cc: "'Kepa Zubeldia'" , dick@8760.com, Gunther Schadow , Rik Drummond , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) Date: Wed, 22 Nov 2000 11:42:33 -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: I was not saying that AS2 should not carry XML ... quite the contrary. Over the years I believe the percentage of AS2 payloads that are encoded using XML will rapidly grow to predominate over any other syntax. I was saying that XML should not be a content type, in the sense that HL7, X12, and NCPDP are content types. HL7 already has an ANSI-approved specification for data encoded in XML. X12 and NCPDP are working on it. Would you suddenly lump the content of all three organizations into a general bucket called "XML"? It just doesn't make sense. Furthermore, if all you know about a message is that it is encoded in the XML syntax you really don't know enough to do an EDI function on the message. The EDI standards specify a lot more than syntax and these specifications are very much a part of the interface contract. With the improvements in XML Schema Language 1.0 (and presuming that Schema Language manages to predominate over XDR and RELAX) one can tightly nail down the syntax of an XML instance, but one cannot directly specify anything about workflow, the semantics of the tags (which are NOT self-evident when you get to the details), or obligations that are created by sending or accepting messages. Put it another way, HL7, X12, NCPDP standards (and those of many other organizations) define EDI content, maybe using XML maybe using another syntax. The W3C XML standard is no more than a building block in defining EDI content, just as the standards for TCP, HTTP, MIME etc. are building blocks. > -----Original Message----- > From: Kit (Christopher) Lueder [mailto:kit@mitre.org] > Sent: Wednesday, November 22, 2000 8:06 AM > To: Rishel,Wes > Cc: 'Kepa Zubeldia'; dick@8760.com; Gunther Schadow; Rik > Drummond; CLEM; > Gary Crough; Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; > ietf-ediint@imc.org > Subject: AS2 XML requirements (was Re: HL7 Standards Process) > > > No! XML must be accommodated in EDIINT! I was figuring XML > content would > be carried as edi-consent, but that seems like a back-door fix rather > than a happy solution. > > This sounds like Wes has raised a new requirement that should be > considered in the AS2 spec (and maybe AS1?). I do consider XML to be a > type of EDI, since both are computer-processable electronic > representations of business transactions, so I request we add > a type of > edi-xml. And I request we add an attribute/field that > indicates the kind > of XML document ("semantic standard") being carried in the payload. > Kit Lueder, > MITRE. > > "Rishel,Wes" wrote: > > > > I doubt if XML will ever be a meaningful content type for > EDIINT. Saying > > that the content is HL7, X12, or NCPDP implies the availability of a > > semantic interpretation of the payload. This would be true > whether the > > payload was in the current HL7, X12, or NCPDP syntaxes or > in the particular > > applications of XML that they may adopt. > > > > If the only claim is that the payload is XML there is no > such linkage to a > > semantic standard, even if the XML instance contains a > pointer to a schema > > in a repository somewhere. A schema is far less than a semantic > > representation of the instance; it simplify enables a > better and more > > thorough parsing of the message. > > > > > -----Original Message----- > > > From: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > > > Sent: Tuesday, November 21, 2000 2:52 PM > > > To: dick@8760.com > > > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary > Crough; Beth > > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; > ietf-ediint@imc.org > > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > Dick, > > > > > > Probably the requirements are identical, except that the > > > content will be > > > in X12 or NCPDP syntax instead of HL7 or XML. > > > > > > Kepa > > > > > > Dick Brooks wrote: > > > > > > > > Kepa, > > > > > > > > > Are you volunteering to create an interoperability > > > profile for digital > > > > > signatures of the HIPAA standard transactions ? > > > > > > > > My offer to assist in the development of an > > > interoperability profile was in > > > > response to a need identified within HL7. However, I would > > > be willing to > > > > help the HIPAA folks create an interoperability profile, > > > provided it's based > > > > on a technology that I'm familiar with (e.g. EDIINT AS2, > > > GISB EDM, ebXML). > > > > > > > > I would hope the investment in developing an > > > interoperability profile for > > > > HL7 could be leveraged in other areas (e.g. HIPAA, ASTM), > > > without any > > > > additional work. Do you see HIPAA's requirements being > significantly > > > > different enough from HL7 to require a separate > > > interoperability profile? > > > > > > > > Thanks, > > > > > > > > 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: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > > > > > Sent: Monday, November 20, 2000 6:13 PM > > > > > To: Dick Brooks > > > > > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary > > > Crough; Beth > > > > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; > > > ietf-ediint@imc.org > > > > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > > > > > > > Dick, > > > > > > > > > > Are you volunteering to create an interoperability > > > profile for digital > > > > > signatures of the HIPAA standard transactions ? X12, > > > NCPDP, and X12+HL7 > > > > > (in which the signature could be on the HL7 or on the X12 > > > components) > > > > > are the immediate needs. However, keep in mind that > > > NCPDP could also be > > > > > in EDIFACT syntax (e.g. prescriptions) and HL7 could be > > > in different > > > > > syntaxes. But, for HIPAA purposes, at this time we need > > > something for > > > > > the 275 attachment only. Other HL7 messages could come > > > later through > > > > > other interoperability profiles. > > > > > > > > > > If we have a very narrow scope (HIPAA transactions as > > > they were released > > > > > in the Final Rule, plus attachments as we know them) then > > > it is possible > > > > > to get an agreement, even if there is not yet an > > > agreement on other > > > > > issues or on PKI issues. > > > > > > > > > > Other volunteers ? > > > > > > > > > > Kepa > > > > > > > > > > Dick Brooks wrote: > > > > > > > > > > > > Thanks Wes. > > > > > > > > > > > > Based on your description I would anticipate the EDIINT AS2 > > > > > spec taking the > > > > > > "Recommendation" route, IF the group decides to go > forward. Do > > > > > you see it > > > > > > the same way? > > > > > > > > > > > > FYI - other groups that have adopted AS2 have found it > > > > > necessary to define > > > > > > "interoperability profiles". These profiles identify > > > the exact set of > > > > > > "options" from AS2 that everyone in the "trading > > > community" agrees to > > > > > > follow, in order to ensure interoperability. For > example, GISB > > > > > has already > > > > > > defined an AS2 interoperability profile and the New York > > > > > Collaborative, in > > > > > > accordance with the Public Service Commission > regulations, is > > > > > in the process > > > > > > of defining their interoperability profile. I'm > > > familiar with both these > > > > > > groups and the process used to develop their profiles. > > > I could help HL7 > > > > > > develop an AS2 interoperability profile, if the > group decides > > > > > to pursue this > > > > > > approach. > > > > > > > > > > > > Regards, > > > > > > > > > > > > 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: Rishel,Wes [mailto:wes.rishel@gartner.com] > > > > > > > Sent: Friday, November 17, 2000 8:32 PM > > > > > > > To: 'dick@8760.com'; Gunther Schadow > > > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; > > > Beth Morrow; > > > > > > > David@Drummondgroup. Com; GISB1@aol.com; > ietf-ediint@imc.org > > > > > > > Subject: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > > > > > > > > > > > > > As the chair-elect of HL7 I would like to respond to DB's > > > > > > > question about HL7 > > > > > > > process. > > > > > > > > > > > > > > HL7 has two kinds of specifications that are > > > published using slighly > > > > > > > different processes: a Standard is submitted to ANSI for > > > > > > > certification once > > > > > > > it has passed ballot; a Recommendation is published > > > by HL7 but is not > > > > > > > submitted to ANSI and does not become an ANSI > standard. Some > > > > > > > Recommendations > > > > > > > have had substantial acceptance among the HL7 community, > > > > > including it's > > > > > > > "lower level protocols" which define ways to reliably pass > > > > > > > discrete messages > > > > > > > over RS-232 and TCP, and were published sometime in > > > the early 1990s. > > > > > > > > > > > > > > A Standard originates under the sponsorship of a Technical > > > > > > > Committee. If HL7 > > > > > > > were to create a Standard for EDIINT it would be the > > > Control/Query > > > > > > > committee. It is balloted at the committee level. > > > (Actually anyone can > > > > > > > participate in the committee ballot, but in > practice those who > > > > > > > choose to do > > > > > > > so are usually those who participate in, or follow > > > the work of, the > > > > > > > Technical Committee.) When it passes a committee > > > level ballot it is > > > > > > > submitted for ballot by the full HL7 Working > Group (which is > > > > > the entire > > > > > > > organization). If it passes at this level it is > automatically > > > > > submitted to > > > > > > > ANSI for certification. The ANSI review allows > time for public > > > > > > > comment, but > > > > > > > it is primarily a certification that the process > was fair and > > > > > consistent > > > > > > > with our bylaws. To date, have never had an issue > arise that > > > > > prevented or > > > > > > > delayed the certification process. > > > > > > > > > > > > > > In addition to Technical Committees HL7 has > Special Interest > > > > > > > Groups. Gunther > > > > > > > is co-chair of our SIG on security. Strictly > speaking, a SIG > > > > > > > cannot initiate > > > > > > > the balloting of a standard; but SIGs can prepare > > > such a document, and > > > > > > > obtain the consent of a Technical Committee which > > > sponsors the ballot. > > > > > > > > > > > > > > The other kind of document, the Recommendation, > is easier to > > > > > get out the > > > > > > > door. It can be originated by a SIG, and it has only > > > one level of > > > > > > > balloting. > > > > > > > The majority that is required to pass a Recommendation is > > > > > less severe than > > > > > > > the majority required to pass a Standard (67% vs. 90%). > > > > > > > > > > > > > > Ballots are conducted using the Web. Assuming that both > > > > > ballots pass an > > > > > > > energetic committee can easily complete the > entire process in > > > > > two of our > > > > > > > three-per-year Working Group meetings (roughly 8 months > > > > > elapsed time). (Of > > > > > > > course most committees have substantial time invested > > > in debating the > > > > > > > document before it begins the process.) > > > > > > > > > > > > > > Most of the meetings required at certain points in > > > the process can be > > > > > > > handled using conference calls; in theory a > REALLY motivated > > > > > > > committee could > > > > > > > accomplish the two-level ballot in five months > and then wait > > > > > about three > > > > > > > months for ANSI certication. (That is a theoretical figure > > > > > that has never > > > > > > > been realized in practise.) > > > > > > > > > > > > > > Recommendations can be passed in roughly four months. > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > Wes Rishel > > > > > > > Research Director > > > > > > > Healthcare Industry Research & Advisory Services > > > > > > > GartnerGroup > > > > > > > Alameda, CA > > > > > > > Client inquiries: call +1-203-316-1288 or email to > > > indapps@gartner.com > > > > > > > wes.rishel@gartner.com > > > > > > > 510 522 8135 > > > > > > > 510 521 2423 (fax) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Dick Brooks [mailto:dick@8760.com] > > > > > > > > Sent: Thursday, November 02, 2000 10:27 AM > > > > > > > > To: Gunther Schadow > > > > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; > > > Beth Morrow; > > > > > > > > David@Drummondgroup. Com; GISB1@aol.com; > > > ietf-ediint@imc.org; Dick > > > > > > > > Brooks > > > > > > > > Subject: RE: EDIINT and HIPAA > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not familiar with the HL7 standards > process, all of > > > > > > > > my experience > > > > > > > > has been with IETF, DISA, GISB and recently ebXML. > > > Each of these > > > > > > > > organizations has a different process for developing > > > > > standards. If we > > > > > > > > brought AS2 to HL7 today, how long would it take to > > > become an > > > > > > > > ANSI standard? > > > > > > > > I would like to read HL7's operational process > document, can > > > > > > > > you provide a > > > > > > > > pointer? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > _/ _/ Kit C. J. Lueder > _/ _/ _/ The MITRE Corp. Tel: 703-883-5205 > _/_/_/ _/ _/_/_/ 1820 Dolley Madison Bl Cell: 703-577-2463 > _/ _/ _/ _/ Mailstop W658 FAX: 703-883-3383 > _/ _/ _/ _/ McLean, VA 22102 Mail: kit@mitre.org > Worse than an unanswered question is an unquestioned answer. > From owner-ietf-ediint@mail.imc.org Wed Nov 22 12:38:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03978 for ; Wed, 22 Nov 2000 12:38:26 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA17076 for ietf-ediint-bks; Wed, 22 Nov 2000 08:40:43 -0800 (PST) Received: from i2hub2.i2.com (NAT-64-26-201-17.i2.com [64.26.201.17] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17068 for ; Wed, 22 Nov 2000 08:40:42 -0800 (PST) From: i2HUB2@i2.com X-Priority: 3 (Normal) Date: Wed, 22 Nov 2000 10:18:03 -0600 Subject: Report to Recipient(s) To: "owner-ietf-ediint@mail.imc.org" Cc: , "Rik Drummond" , "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Message-ID: X-MIMETrack: Serialize by Router on i2HUB2/i2Tech(Release 5.0.4 |June 8, 2000) at 11/22/2000 10:41:39 AM 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: Incident Information:- Originator: owner-ietf-ediint@mail.imc.org Recipients: "owner-ietf-ediint@mail.imc.org" , , "Rik Drummond" , "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) WARNING: The file Navidad.exe you received was infected with the W32/Navidad@M virus. The file attachment was not successfully cleaned. From owner-ietf-ediint@mail.imc.org Wed Nov 22 13:22:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18798 for ; Wed, 22 Nov 2000 13:22:58 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA20523 for ietf-ediint-bks; Wed, 22 Nov 2000 09:30:16 -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 JAA20519 for ; Wed, 22 Nov 2000 09:30:13 -0800 (PST) Received: by mailman.8760.com from localhost (router,SLMail V3.2); Wed, 22 Nov 2000 11:30:23 -0600 Received: from gamma [192.168.21.133] by mailman.8760.com [192.168.21.90] (SLmail 3.2.3113) with SMTP id 6C8B31F8B97F11D4BB0C0060974E38DD for plus 10 more; Wed, 22 Nov 2000 11:30:22 -0600 Reply-To: From: "Dick Brooks" To: "Kit \(Christopher\) Lueder" , "Rishel,Wes" Cc: "'Kepa Zubeldia'" , "Gunther Schadow" , "Rik Drummond" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) Date: Wed, 22 Nov 2000 11:26:34 -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: <3A1BEED2.3E23B1C4@mitre.org> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-SLUIDL: 5DCE1E04-BFEC11D4-BB0C0060-974E38DD Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kit, The original EDIINT AS1 draft was restricted to supporting RFC1767 payload types only. AS2 is payload neutral which means it will transport XML, X12, as well an any other IANA registered MIME media type. AS2 is explicit in this regard ref: this excerpt from the AS2 specification: "In general, both HTTP servers and HTTP clients handling the message templates of [AS1] should be prepared to process these basic EDIINT data formats when they are embedded within MIME multiparts. In addition to the enveloping and MIME media type options defined in sections 4.2.x and 4.3.x of "MIME-based Secure EDI" [AS1], this specification enables the transport of payload objects containing other MIME media types. Implementors are to follow the appropriate specifications identified under "References" in [MIME-TYPES], for the type of object being transmitted. For example, to send an XML object, the MIME media type of application/xml is used in the Content-type MIME header and the specifications for enveloping the object are contained in [XMLTYPES]; for example: Content-type: application/xml; charset="utf-8" " 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: Kit (Christopher) Lueder [mailto:kit@mitre.org] > Sent: Wednesday, November 22, 2000 10:06 AM > To: Rishel,Wes > Cc: 'Kepa Zubeldia'; Dick Brooks; Gunther Schadow; Rik Drummond; CLEM; > Gary Crough; Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; > ietf-ediint@imc.org > Subject: AS2 XML requirements (was Re: HL7 Standards Process) > > > No! XML must be accommodated in EDIINT! I was figuring XML content would > be carried as edi-consent, but that seems like a back-door fix rather > than a happy solution. > > This sounds like Wes has raised a new requirement that should be > considered in the AS2 spec (and maybe AS1?). I do consider XML to be a > type of EDI, since both are computer-processable electronic > representations of business transactions, so I request we add a type of > edi-xml. And I request we add an attribute/field that indicates the kind > of XML document ("semantic standard") being carried in the payload. > Kit Lueder, > MITRE. > > "Rishel,Wes" wrote: > > > > I doubt if XML will ever be a meaningful content type for EDIINT. Saying > > that the content is HL7, X12, or NCPDP implies the availability of a > > semantic interpretation of the payload. This would be true whether the > > payload was in the current HL7, X12, or NCPDP syntaxes or in > the particular > > applications of XML that they may adopt. > > > > If the only claim is that the payload is XML there is no such > linkage to a > > semantic standard, even if the XML instance contains a pointer > to a schema > > in a repository somewhere. A schema is far less than a semantic > > representation of the instance; it simplify enables a better and more > > thorough parsing of the message. > > > > > -----Original Message----- > > > From: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > > > Sent: Tuesday, November 21, 2000 2:52 PM > > > To: dick@8760.com > > > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary Crough; Beth > > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > Dick, > > > > > > Probably the requirements are identical, except that the > > > content will be > > > in X12 or NCPDP syntax instead of HL7 or XML. > > > > > > Kepa > > > > > > Dick Brooks wrote: > > > > > > > > Kepa, > > > > > > > > > Are you volunteering to create an interoperability > > > profile for digital > > > > > signatures of the HIPAA standard transactions ? > > > > > > > > My offer to assist in the development of an > > > interoperability profile was in > > > > response to a need identified within HL7. However, I would > > > be willing to > > > > help the HIPAA folks create an interoperability profile, > > > provided it's based > > > > on a technology that I'm familiar with (e.g. EDIINT AS2, > > > GISB EDM, ebXML). > > > > > > > > I would hope the investment in developing an > > > interoperability profile for > > > > HL7 could be leveraged in other areas (e.g. HIPAA, ASTM), > > > without any > > > > additional work. Do you see HIPAA's requirements being significantly > > > > different enough from HL7 to require a separate > > > interoperability profile? > > > > > > > > Thanks, > > > > > > > > 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: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > > > > > Sent: Monday, November 20, 2000 6:13 PM > > > > > To: Dick Brooks > > > > > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary > > > Crough; Beth > > > > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; > > > ietf-ediint@imc.org > > > > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > > > > > > > Dick, > > > > > > > > > > Are you volunteering to create an interoperability > > > profile for digital > > > > > signatures of the HIPAA standard transactions ? X12, > > > NCPDP, and X12+HL7 > > > > > (in which the signature could be on the HL7 or on the X12 > > > components) > > > > > are the immediate needs. However, keep in mind that > > > NCPDP could also be > > > > > in EDIFACT syntax (e.g. prescriptions) and HL7 could be > > > in different > > > > > syntaxes. But, for HIPAA purposes, at this time we need > > > something for > > > > > the 275 attachment only. Other HL7 messages could come > > > later through > > > > > other interoperability profiles. > > > > > > > > > > If we have a very narrow scope (HIPAA transactions as > > > they were released > > > > > in the Final Rule, plus attachments as we know them) then > > > it is possible > > > > > to get an agreement, even if there is not yet an > > > agreement on other > > > > > issues or on PKI issues. > > > > > > > > > > Other volunteers ? > > > > > > > > > > Kepa > > > > > > > > > > Dick Brooks wrote: > > > > > > > > > > > > Thanks Wes. > > > > > > > > > > > > Based on your description I would anticipate the EDIINT AS2 > > > > > spec taking the > > > > > > "Recommendation" route, IF the group decides to go forward. Do > > > > > you see it > > > > > > the same way? > > > > > > > > > > > > FYI - other groups that have adopted AS2 have found it > > > > > necessary to define > > > > > > "interoperability profiles". These profiles identify > > > the exact set of > > > > > > "options" from AS2 that everyone in the "trading > > > community" agrees to > > > > > > follow, in order to ensure interoperability. For example, GISB > > > > > has already > > > > > > defined an AS2 interoperability profile and the New York > > > > > Collaborative, in > > > > > > accordance with the Public Service Commission regulations, is > > > > > in the process > > > > > > of defining their interoperability profile. I'm > > > familiar with both these > > > > > > groups and the process used to develop their profiles. > > > I could help HL7 > > > > > > develop an AS2 interoperability profile, if the group decides > > > > > to pursue this > > > > > > approach. > > > > > > > > > > > > Regards, > > > > > > > > > > > > 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: Rishel,Wes [mailto:wes.rishel@gartner.com] > > > > > > > Sent: Friday, November 17, 2000 8:32 PM > > > > > > > To: 'dick@8760.com'; Gunther Schadow > > > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; > > > Beth Morrow; > > > > > > > David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > > > > > > > Subject: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > > > > > > > > > > > > > As the chair-elect of HL7 I would like to respond to DB's > > > > > > > question about HL7 > > > > > > > process. > > > > > > > > > > > > > > HL7 has two kinds of specifications that are > > > published using slighly > > > > > > > different processes: a Standard is submitted to ANSI for > > > > > > > certification once > > > > > > > it has passed ballot; a Recommendation is published > > > by HL7 but is not > > > > > > > submitted to ANSI and does not become an ANSI standard. Some > > > > > > > Recommendations > > > > > > > have had substantial acceptance among the HL7 community, > > > > > including it's > > > > > > > "lower level protocols" which define ways to reliably pass > > > > > > > discrete messages > > > > > > > over RS-232 and TCP, and were published sometime in > > > the early 1990s. > > > > > > > > > > > > > > A Standard originates under the sponsorship of a Technical > > > > > > > Committee. If HL7 > > > > > > > were to create a Standard for EDIINT it would be the > > > Control/Query > > > > > > > committee. It is balloted at the committee level. > > > (Actually anyone can > > > > > > > participate in the committee ballot, but in practice those who > > > > > > > choose to do > > > > > > > so are usually those who participate in, or follow > > > the work of, the > > > > > > > Technical Committee.) When it passes a committee > > > level ballot it is > > > > > > > submitted for ballot by the full HL7 Working Group (which is > > > > > the entire > > > > > > > organization). If it passes at this level it is automatically > > > > > submitted to > > > > > > > ANSI for certification. The ANSI review allows time for public > > > > > > > comment, but > > > > > > > it is primarily a certification that the process was fair and > > > > > consistent > > > > > > > with our bylaws. To date, have never had an issue arise that > > > > > prevented or > > > > > > > delayed the certification process. > > > > > > > > > > > > > > In addition to Technical Committees HL7 has Special Interest > > > > > > > Groups. Gunther > > > > > > > is co-chair of our SIG on security. Strictly speaking, a SIG > > > > > > > cannot initiate > > > > > > > the balloting of a standard; but SIGs can prepare > > > such a document, and > > > > > > > obtain the consent of a Technical Committee which > > > sponsors the ballot. > > > > > > > > > > > > > > The other kind of document, the Recommendation, is easier to > > > > > get out the > > > > > > > door. It can be originated by a SIG, and it has only > > > one level of > > > > > > > balloting. > > > > > > > The majority that is required to pass a Recommendation is > > > > > less severe than > > > > > > > the majority required to pass a Standard (67% vs. 90%). > > > > > > > > > > > > > > Ballots are conducted using the Web. Assuming that both > > > > > ballots pass an > > > > > > > energetic committee can easily complete the entire process in > > > > > two of our > > > > > > > three-per-year Working Group meetings (roughly 8 months > > > > > elapsed time). (Of > > > > > > > course most committees have substantial time invested > > > in debating the > > > > > > > document before it begins the process.) > > > > > > > > > > > > > > Most of the meetings required at certain points in > > > the process can be > > > > > > > handled using conference calls; in theory a REALLY motivated > > > > > > > committee could > > > > > > > accomplish the two-level ballot in five months and then wait > > > > > about three > > > > > > > months for ANSI certication. (That is a theoretical figure > > > > > that has never > > > > > > > been realized in practise.) > > > > > > > > > > > > > > Recommendations can be passed in roughly four months. > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > Wes Rishel > > > > > > > Research Director > > > > > > > Healthcare Industry Research & Advisory Services > > > > > > > GartnerGroup > > > > > > > Alameda, CA > > > > > > > Client inquiries: call +1-203-316-1288 or email to > > > indapps@gartner.com > > > > > > > wes.rishel@gartner.com > > > > > > > 510 522 8135 > > > > > > > 510 521 2423 (fax) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Dick Brooks [mailto:dick@8760.com] > > > > > > > > Sent: Thursday, November 02, 2000 10:27 AM > > > > > > > > To: Gunther Schadow > > > > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; > > > Beth Morrow; > > > > > > > > David@Drummondgroup. Com; GISB1@aol.com; > > > ietf-ediint@imc.org; Dick > > > > > > > > Brooks > > > > > > > > Subject: RE: EDIINT and HIPAA > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not familiar with the HL7 standards process, all of > > > > > > > > my experience > > > > > > > > has been with IETF, DISA, GISB and recently ebXML. > > > Each of these > > > > > > > > organizations has a different process for developing > > > > > standards. If we > > > > > > > > brought AS2 to HL7 today, how long would it take to > > > become an > > > > > > > > ANSI standard? > > > > > > > > I would like to read HL7's operational process document, can > > > > > > > > you provide a > > > > > > > > pointer? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > _/ _/ Kit C. J. Lueder > _/ _/ _/ The MITRE Corp. Tel: 703-883-5205 > _/_/_/ _/ _/_/_/ 1820 Dolley Madison Bl Cell: 703-577-2463 > _/ _/ _/ _/ Mailstop W658 FAX: 703-883-3383 > _/ _/ _/ _/ McLean, VA 22102 Mail: kit@mitre.org > Worse than an unanswered question is an unquestioned answer. > From owner-ietf-ediint@mail.imc.org Wed Nov 22 13:26:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20010 for ; Wed, 22 Nov 2000 13:26:47 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA21207 for ietf-ediint-bks; Wed, 22 Nov 2000 09:38:08 -0800 (PST) Received: from smtpproxy1.mitre.org (mb-20-100.mitre.org [129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA21202 for ; Wed, 22 Nov 2000 09:38:04 -0800 (PST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id MAA06612; Wed, 22 Nov 2000 12:38:21 -0500 (EST) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id MAA10482; Wed, 22 Nov 2000 12:38:19 -0500 (EST) Received: from dhcp-145-238.mitre.org (128.29.145.238) by mailhub1.mitre.org with SMTP id 4936196; Wed, 22 Nov 2000 12:37:39 -0500 Message-ID: <3A1C04BC.610293AB@mitre.org> Date: Wed, 22 Nov 2000 12:39:08 -0500 From: "Kit (Christopher) Lueder" Organization: The MITRE Corporation X-Mailer: Mozilla 4.75 [en]C-20000818M (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Rishel,Wes" CC: ietf-ediint@imc.org Subject: Re: AS2 XML requirements (was Re: HL7 Standards Process) References: <69A38F8986F3D211A6B00008C79121060969A328@mammoth.gartner.com> 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 I disagree. If you re-encode HL7 into XML syntax, you shouldn't send it as type of EDI-HL7, since it is not pure HL7 syntax. You should send it as EDI-XML (if we add that to AS2), and have the "semantic standard" field/attribute set to "HL7". Kit. "Rishel,Wes" wrote: > > I was not saying that AS2 should not carry XML ... quite the contrary. Over > the years I believe the percentage of AS2 payloads that are encoded using > XML will rapidly grow to predominate over any other syntax. > > I was saying that XML should not be a content type, in the sense that HL7, > X12, and NCPDP are content types. > > HL7 already has an ANSI-approved specification for data encoded in XML. X12 > and NCPDP are working on it. Would you suddenly lump the content of all > three organizations into a general bucket called "XML"? It just doesn't make > sense. > > Furthermore, if all you know about a message is that it is encoded in the > XML syntax you really don't know enough to do an EDI function on the > message. The EDI standards specify a lot more than syntax and these > specifications are very much a part of the interface contract. With the > improvements in XML Schema Language 1.0 (and presuming that Schema Language > manages to predominate over XDR and RELAX) one can tightly nail down the > syntax of an XML instance, but one cannot directly specify anything about > workflow, the semantics of the tags (which are NOT self-evident when you get > to the details), or obligations that are created by sending or accepting > messages. > > Put it another way, HL7, X12, NCPDP standards (and those of many other > organizations) define EDI content, maybe using XML maybe using another > syntax. The W3C XML standard is no more than a building block in defining > EDI content, just as the standards for TCP, HTTP, MIME etc. are building > blocks. > > > -----Original Message----- > > From: Kit (Christopher) Lueder [mailto:kit@mitre.org] > > Sent: Wednesday, November 22, 2000 8:06 AM > > To: Rishel,Wes > > Cc: 'Kepa Zubeldia'; dick@8760.com; Gunther Schadow; Rik > > Drummond; CLEM; > > Gary Crough; Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; > > ietf-ediint@imc.org > > Subject: AS2 XML requirements (was Re: HL7 Standards Process) > > > > > > No! XML must be accommodated in EDIINT! I was figuring XML > > content would > > be carried as edi-consent, but that seems like a back-door fix rather > > than a happy solution. > > > > This sounds like Wes has raised a new requirement that should be > > considered in the AS2 spec (and maybe AS1?). I do consider XML to be a > > type of EDI, since both are computer-processable electronic > > representations of business transactions, so I request we add > > a type of > > edi-xml. And I request we add an attribute/field that > > indicates the kind > > of XML document ("semantic standard") being carried in the payload. > > Kit Lueder, > > MITRE. > > > > "Rishel,Wes" wrote: > > > > > > I doubt if XML will ever be a meaningful content type for > > EDIINT. Saying > > > that the content is HL7, X12, or NCPDP implies the availability of a > > > semantic interpretation of the payload. This would be true > > whether the > > > payload was in the current HL7, X12, or NCPDP syntaxes or > > in the particular > > > applications of XML that they may adopt. > > > > > > If the only claim is that the payload is XML there is no > > such linkage to a > > > semantic standard, even if the XML instance contains a > > pointer to a schema > > > in a repository somewhere. A schema is far less than a semantic > > > representation of the instance; it simplify enables a > > better and more > > > thorough parsing of the message. > > > > > > > -----Original Message----- > > > > From: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > > > > Sent: Tuesday, November 21, 2000 2:52 PM > > > > To: dick@8760.com > > > > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary > > Crough; Beth > > > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; > > ietf-ediint@imc.org > > > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > > > > Dick, > > > > > > > > Probably the requirements are identical, except that the > > > > content will be > > > > in X12 or NCPDP syntax instead of HL7 or XML. > > > > > > > > Kepa > > > > > > > > Dick Brooks wrote: > > > > > > > > > > Kepa, > > > > > > > > > > > Are you volunteering to create an interoperability > > > > profile for digital > > > > > > signatures of the HIPAA standard transactions ? > > > > > > > > > > My offer to assist in the development of an > > > > interoperability profile was in > > > > > response to a need identified within HL7. However, I would > > > > be willing to > > > > > help the HIPAA folks create an interoperability profile, > > > > provided it's based > > > > > on a technology that I'm familiar with (e.g. EDIINT AS2, > > > > GISB EDM, ebXML). > > > > > > > > > > I would hope the investment in developing an > > > > interoperability profile for > > > > > HL7 could be leveraged in other areas (e.g. HIPAA, ASTM), > > > > without any > > > > > additional work. Do you see HIPAA's requirements being > > significantly > > > > > different enough from HL7 to require a separate > > > > interoperability profile? > > > > > > > > > > Thanks, > > > > > > > > > > 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: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > > > > > > Sent: Monday, November 20, 2000 6:13 PM > > > > > > To: Dick Brooks > > > > > > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary > > > > Crough; Beth > > > > > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; > > > > ietf-ediint@imc.org > > > > > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > > > > > > > > > > Dick, > > > > > > > > > > > > Are you volunteering to create an interoperability > > > > profile for digital > > > > > > signatures of the HIPAA standard transactions ? X12, > > > > NCPDP, and X12+HL7 > > > > > > (in which the signature could be on the HL7 or on the X12 > > > > components) > > > > > > are the immediate needs. However, keep in mind that > > > > NCPDP could also be > > > > > > in EDIFACT syntax (e.g. prescriptions) and HL7 could be > > > > in different > > > > > > syntaxes. But, for HIPAA purposes, at this time we need > > > > something for > > > > > > the 275 attachment only. Other HL7 messages could come > > > > later through > > > > > > other interoperability profiles. > > > > > > > > > > > > If we have a very narrow scope (HIPAA transactions as > > > > they were released > > > > > > in the Final Rule, plus attachments as we know them) then > > > > it is possible > > > > > > to get an agreement, even if there is not yet an > > > > agreement on other > > > > > > issues or on PKI issues. > > > > > > > > > > > > Other volunteers ? > > > > > > > > > > > > Kepa > > > > > > > > > > > > Dick Brooks wrote: > > > > > > > > > > > > > > Thanks Wes. > > > > > > > > > > > > > > Based on your description I would anticipate the EDIINT AS2 > > > > > > spec taking the > > > > > > > "Recommendation" route, IF the group decides to go > > forward. Do > > > > > > you see it > > > > > > > the same way? > > > > > > > > > > > > > > FYI - other groups that have adopted AS2 have found it > > > > > > necessary to define > > > > > > > "interoperability profiles". These profiles identify > > > > the exact set of > > > > > > > "options" from AS2 that everyone in the "trading > > > > community" agrees to > > > > > > > follow, in order to ensure interoperability. For > > example, GISB > > > > > > has already > > > > > > > defined an AS2 interoperability profile and the New York > > > > > > Collaborative, in > > > > > > > accordance with the Public Service Commission > > regulations, is > > > > > > in the process > > > > > > > of defining their interoperability profile. I'm > > > > familiar with both these > > > > > > > groups and the process used to develop their profiles. > > > > I could help HL7 > > > > > > > develop an AS2 interoperability profile, if the > > group decides > > > > > > to pursue this > > > > > > > approach. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > 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: Rishel,Wes [mailto:wes.rishel@gartner.com] > > > > > > > > Sent: Friday, November 17, 2000 8:32 PM > > > > > > > > To: 'dick@8760.com'; Gunther Schadow > > > > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; > > > > Beth Morrow; > > > > > > > > David@Drummondgroup. Com; GISB1@aol.com; > > ietf-ediint@imc.org > > > > > > > > Subject: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > > > > > > > > > > > > > > > > As the chair-elect of HL7 I would like to respond to DB's > > > > > > > > question about HL7 > > > > > > > > process. > > > > > > > > > > > > > > > > HL7 has two kinds of specifications that are > > > > published using slighly > > > > > > > > different processes: a Standard is submitted to ANSI for > > > > > > > > certification once > > > > > > > > it has passed ballot; a Recommendation is published > > > > by HL7 but is not > > > > > > > > submitted to ANSI and does not become an ANSI > > standard. Some > > > > > > > > Recommendations > > > > > > > > have had substantial acceptance among the HL7 community, > > > > > > including it's > > > > > > > > "lower level protocols" which define ways to reliably pass > > > > > > > > discrete messages > > > > > > > > over RS-232 and TCP, and were published sometime in > > > > the early 1990s. > > > > > > > > > > > > > > > > A Standard originates under the sponsorship of a Technical > > > > > > > > Committee. If HL7 > > > > > > > > were to create a Standard for EDIINT it would be the > > > > Control/Query > > > > > > > > committee. It is balloted at the committee level. > > > > (Actually anyone can > > > > > > > > participate in the committee ballot, but in > > practice those who > > > > > > > > choose to do > > > > > > > > so are usually those who participate in, or follow > > > > the work of, the > > > > > > > > Technical Committee.) When it passes a committee > > > > level ballot it is > > > > > > > > submitted for ballot by the full HL7 Working > > Group (which is > > > > > > the entire > > > > > > > > organization). If it passes at this level it is > > automatically > > > > > > submitted to > > > > > > > > ANSI for certification. The ANSI review allows > > time for public > > > > > > > > comment, but > > > > > > > > it is primarily a certification that the process > > was fair and > > > > > > consistent > > > > > > > > with our bylaws. To date, have never had an issue > > arise that > > > > > > prevented or > > > > > > > > delayed the certification process. > > > > > > > > > > > > > > > > In addition to Technical Committees HL7 has > > Special Interest > > > > > > > > Groups. Gunther > > > > > > > > is co-chair of our SIG on security. Strictly > > speaking, a SIG > > > > > > > > cannot initiate > > > > > > > > the balloting of a standard; but SIGs can prepare > > > > such a document, and > > > > > > > > obtain the consent of a Technical Committee which > > > > sponsors the ballot. > > > > > > > > > > > > > > > > The other kind of document, the Recommendation, > > is easier to > > > > > > get out the > > > > > > > > door. It can be originated by a SIG, and it has only > > > > one level of > > > > > > > > balloting. > > > > > > > > The majority that is required to pass a Recommendation is > > > > > > less severe than > > > > > > > > the majority required to pass a Standard (67% vs. 90%). > > > > > > > > > > > > > > > > Ballots are conducted using the Web. Assuming that both > > > > > > ballots pass an > > > > > > > > energetic committee can easily complete the > > entire process in > > > > > > two of our > > > > > > > > three-per-year Working Group meetings (roughly 8 months > > > > > > elapsed time). (Of > > > > > > > > course most committees have substantial time invested > > > > in debating the > > > > > > > > document before it begins the process.) > > > > > > > > > > > > > > > > Most of the meetings required at certain points in > > > > the process can be > > > > > > > > handled using conference calls; in theory a > > REALLY motivated > > > > > > > > committee could > > > > > > > > accomplish the two-level ballot in five months > > and then wait > > > > > > about three > > > > > > > > months for ANSI certication. (That is a theoretical figure > > > > > > that has never > > > > > > > > been realized in practise.) > > > > > > > > > > > > > > > > Recommendations can be passed in roughly four months. > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > Wes Rishel > > > > > > > > Research Director > > > > > > > > Healthcare Industry Research & Advisory Services > > > > > > > > GartnerGroup > > > > > > > > Alameda, CA > > > > > > > > Client inquiries: call +1-203-316-1288 or email to > > > > indapps@gartner.com > > > > > > > > wes.rishel@gartner.com > > > > > > > > 510 522 8135 > > > > > > > > 510 521 2423 (fax) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Dick Brooks [mailto:dick@8760.com] > > > > > > > > > Sent: Thursday, November 02, 2000 10:27 AM > > > > > > > > > To: Gunther Schadow > > > > > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; > > > > Beth Morrow; > > > > > > > > > David@Drummondgroup. Com; GISB1@aol.com; > > > > ietf-ediint@imc.org; Dick > > > > > > > > > Brooks > > > > > > > > > Subject: RE: EDIINT and HIPAA > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not familiar with the HL7 standards > > process, all of > > > > > > > > > my experience > > > > > > > > > has been with IETF, DISA, GISB and recently ebXML. > > > > Each of these > > > > > > > > > organizations has a different process for developing > > > > > > standards. If we > > > > > > > > > brought AS2 to HL7 today, how long would it take to > > > > become an > > > > > > > > > ANSI standard? > > > > > > > > > I would like to read HL7's operational process > > document, can > > > > > > > > > you provide a > > > > > > > > > pointer? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > _/ _/ Kit C. J. Lueder > > _/ _/ _/ The MITRE Corp. Tel: 703-883-5205 > > _/_/_/ _/ _/_/_/ 1820 Dolley Madison Bl Cell: 703-577-2463 > > _/ _/ _/ _/ Mailstop W658 FAX: 703-883-3383 > > _/ _/ _/ _/ McLean, VA 22102 Mail: kit@mitre.org > > Worse than an unanswered question is an unquestioned answer. > > -- _/ _/ Kit C. J. Lueder _/ _/ _/ The MITRE Corp. Tel: 703-883-5205 _/_/_/ _/ _/_/_/ 1820 Dolley Madison Bl Cell: 703-577-2463 _/ _/ _/ _/ Mailstop W658 FAX: 703-883-3383 _/ _/ _/ _/ McLean, VA 22102 Mail: kit@mitre.org Worse than an unanswered question is an unquestioned answer. From owner-ietf-ediint@mail.imc.org Wed Nov 22 14:12:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02034 for ; Wed, 22 Nov 2000 14:12:21 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA22219 for ietf-ediint-bks; Wed, 22 Nov 2000 09:59:48 -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 JAA22214 for ; Wed, 22 Nov 2000 09:59:46 -0800 (PST) Received: by mailman.8760.com from localhost (router,SLMail V3.2); Wed, 22 Nov 2000 12:00:20 -0600 Received: from gamma [192.168.21.133] by mailman.8760.com [192.168.21.90] (SLmail 3.2.3113) with SMTP id 6C8B320FB97F11D4BB0C0060974E38DD for plus 10 more; Wed, 22 Nov 2000 12:00:20 -0600 Reply-To: From: "Dick Brooks" To: "Rishel,Wes" , "'Kit \(Christopher\) Lueder'" Cc: "'Kepa Zubeldia'" , "Gunther Schadow" , "Rik Drummond" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) Date: Wed, 22 Nov 2000 11:56:34 -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: <69A38F8986F3D211A6B00008C79121060969A328@mammoth.gartner.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-SLUIDL: 5DCE1E19-BFEC11D4-BB0C0060-974E38DD Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Wes, > Furthermore, if all you know about a message is that it is encoded in the > XML syntax you really don't know enough to do an EDI function on the > message. The EDI standards specify a lot more than syntax and these > specifications are very much a part of the interface contract. [snip] You are right on, that's why AS2 has a header field called "Transaction-Set". The sender uses this header to identify exactly what type of data is contained in the payload (regardless of the encoding syntax X12, XML. et al). For example, GISB uses the same ANSI X12 850 transaction set for different purposes so they created transaction set identifiers (e.g. G850NMST or G850RQCF) to provide more precision when identifying a payload. A sender would insert either "G850NMST" or "G850RQCF" in the "transaction-set" header, this way the receiving party can "dispatch" processing to different "process flows" based on the "transaction set" identifier. 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 Nov 22 15:07:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20578 for ; Wed, 22 Nov 2000 15:07:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA27004 for ietf-ediint-bks; Wed, 22 Nov 2000 11:25:00 -0800 (PST) Received: from i2hub2.i2.com (NAT-64-26-201-17.i2.com [64.26.201.17] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27000 for ; Wed, 22 Nov 2000 11:24:59 -0800 (PST) From: i2HUB2@i2.com X-Priority: 3 (Normal) Date: Wed, 22 Nov 2000 13:19:27 -0600 Subject: Report to Recipient(s) To: "owner-ietf-ediint@mail.imc.org" , "'Gunther Schadow'" Cc: "Rik Drummond" , "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , , Message-ID: X-MIMETrack: Serialize by Router on i2HUB2/i2Tech(Release 5.0.4 |June 8, 2000) at 11/22/2000 01:25:56 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: Incident Information:- Originator: owner-ietf-ediint@mail.imc.org Recipients: "owner-ietf-ediint@mail.imc.org" , "'Gunther Schadow'" , "Rik Drummond" , "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , , Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) WARNING: The file Navidad.exe you received was infected with the W32/Navidad@M virus. The file attachment was not successfully cleaned. From owner-ietf-ediint@mail.imc.org Wed Nov 22 15:14:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22574 for ; Wed, 22 Nov 2000 15:14:27 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA27975 for ietf-ediint-bks; Wed, 22 Nov 2000 11:37:37 -0800 (PST) Received: from i2hub4.i2.com (NAT-64-26-193-1.i2.com [64.26.193.1] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27971 for ; Wed, 22 Nov 2000 11:37:36 -0800 (PST) From: i2Hub4@i2.com X-Priority: 3 (Normal) Date: Wed, 22 Nov 2000 13:36:30 -0600 Subject: Report to Recipient(s) To: "owner-ietf-ediint@mail.imc.org" , "'Gunther Schadow'" Cc: "Rik Drummond" , "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , , Message-ID: X-MIMETrack: Serialize by Router on i2Hub4/Servers/i2Tech(Release 5.0.5 |September 22, 2000) at 11/22/2000 01:38:33 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: Incident Information:- Originator: owner-ietf-ediint@mail.imc.org Recipients: "owner-ietf-ediint@mail.imc.org" , "'Gunther Schadow'" , "Rik Drummond" , "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , , Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) WARNING: The file Navidad.exe you received was infected with the W32/Navidad@M virus. The file attachment was not successfully cleaned. From owner-ietf-ediint@mail.imc.org Wed Nov 22 16:45:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18191 for ; Wed, 22 Nov 2000 16:45:43 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA02288 for ietf-ediint-bks; Wed, 22 Nov 2000 13:16:15 -0800 (PST) Received: from puma.gartner.com (overlord.gartner.com [207.140.148.33]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA02284 for ; Wed, 22 Nov 2000 13:16:14 -0800 (PST) Received: by puma.gartner.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 16:15:25 -0500 Message-ID: <69A38F8986F3D211A6B00008C79121060969A338@mammoth.gartner.com> From: "Rishel,Wes" To: "'dick@8760.com'" , "'Kit (Christopher) Lueder'" Cc: "'Kepa Zubeldia'" , Gunther Schadow , Rik Drummond , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) Date: Wed, 22 Nov 2000 16:15:21 -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: Is the transaction identifier qualified by another field or is there a need to set up a registry of transaction set identifiers? I suspect that HL7 would prefer to maintain its own identifiers without worrying about collision with another standard or having to sit through length debates about whether to use a hyphen or an underbar. > -----Original Message----- > From: Dick Brooks [mailto:dick@8760.com] > Sent: Wednesday, November 22, 2000 9:57 AM > To: Rishel,Wes; 'Kit (Christopher) Lueder' > Cc: 'Kepa Zubeldia'; Gunther Schadow; Rik Drummond; CLEM; Gary Crough; > Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; > ietf-ediint@imc.org > Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) > > > Wes, > > > Furthermore, if all you know about a message is that it is > encoded in the > > XML syntax you really don't know enough to do an EDI function on the > > message. The EDI standards specify a lot more than syntax and these > > specifications are very much a part of the interface > contract. [snip] > > You are right on, that's why AS2 has a header field called > "Transaction-Set". The sender uses this header to identify > exactly what type of data is contained in the payload > (regardless of the > encoding syntax X12, XML. et al). For example, GISB uses the > same ANSI X12 > 850 transaction set for different purposes so they created > transaction set > identifiers (e.g. G850NMST or G850RQCF) to provide more precision when > identifying a payload. A sender would insert either "G850NMST" or > "G850RQCF" in the "transaction-set" header, this way the > receiving party can > "dispatch" processing to different "process flows" based on > the "transaction > set" identifier. > > > 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 Nov 22 16:45:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18267 for ; Wed, 22 Nov 2000 16:45:54 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA02168 for ietf-ediint-bks; Wed, 22 Nov 2000 13:12:25 -0800 (PST) Received: from puma.gartner.com (overlord.gartner.com [207.140.148.33]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA02163 for ; Wed, 22 Nov 2000 13:12:22 -0800 (PST) Received: by puma.gartner.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 16:12:35 -0500 Message-ID: <69A38F8986F3D211A6B00008C79121060969A337@mammoth.gartner.com> From: "Rishel,Wes" To: "'Kit (Christopher) Lueder'" Cc: ietf-ediint@imc.org Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) Date: Wed, 22 Nov 2000 16:12:32 -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: Sorry, I am not that familiar with the spec. I was misusing the word content, I guess. The original note to which I responded talked about "HL7, NCPDP, X12, and XML" as if they were equivalent concepts. My point was merely that XML all by itself does not define the semantics of an interface contract, whereas the other three do. One thing about which I would still quibble. You say: > If you re-encode HL7 into XML syntax, you > shouldn't send it > as type of EDI-HL7, since it is not pure HL7 syntax. You > should send it > as EDI-XML (if we add that to AS2), and have the "semantic standard" > field/attribute set to "HL7". I am not talking about "re-encoding" HL7 in XML. Effective 14 Nov 2000, when ANSI certified our CDA standard, XML is actually one of the three official syntaxes of HL7. We expect many more transactions to roll out in XML over the next year. Many of the HL7 messages in XML syntax, including those just certified, will have no equivalent representation in the older HL7 Syntax, although we expect there to be a lot of messages in the old syntax for a long time. > -----Original Message----- > From: Kit (Christopher) Lueder [mailto:kit@mitre.org] > Sent: Wednesday, November 22, 2000 9:39 AM > To: Rishel,Wes > Cc: ietf-ediint@imc.org > Subject: Re: AS2 XML requirements (was Re: HL7 Standards Process) > > > I disagree. If you re-encode HL7 into XML syntax, you > shouldn't send it > as type of EDI-HL7, since it is not pure HL7 syntax. You > should send it > as EDI-XML (if we add that to AS2), and have the "semantic standard" > field/attribute set to "HL7". > Kit. > > "Rishel,Wes" wrote: > > > > I was not saying that AS2 should not carry XML ... quite > the contrary. Over > > the years I believe the percentage of AS2 payloads that are > encoded using > > XML will rapidly grow to predominate over any other syntax. > > > > I was saying that XML should not be a content type, in the > sense that HL7, > > X12, and NCPDP are content types. > > > > HL7 already has an ANSI-approved specification for data > encoded in XML. X12 > > and NCPDP are working on it. Would you suddenly lump the > content of all > > three organizations into a general bucket called "XML"? It > just doesn't make > > sense. > > > > Furthermore, if all you know about a message is that it is > encoded in the > > XML syntax you really don't know enough to do an EDI function on the > > message. The EDI standards specify a lot more than syntax and these > > specifications are very much a part of the interface > contract. With the > > improvements in XML Schema Language 1.0 (and presuming that > Schema Language > > manages to predominate over XDR and RELAX) one can tightly > nail down the > > syntax of an XML instance, but one cannot directly specify > anything about > > workflow, the semantics of the tags (which are NOT > self-evident when you get > > to the details), or obligations that are created by sending > or accepting > > messages. > > > > Put it another way, HL7, X12, NCPDP standards (and those of > many other > > organizations) define EDI content, maybe using XML maybe > using another > > syntax. The W3C XML standard is no more than a building > block in defining > > EDI content, just as the standards for TCP, HTTP, MIME etc. > are building > > blocks. > > > > > -----Original Message----- > > > From: Kit (Christopher) Lueder [mailto:kit@mitre.org] > > > Sent: Wednesday, November 22, 2000 8:06 AM > > > To: Rishel,Wes > > > Cc: 'Kepa Zubeldia'; dick@8760.com; Gunther Schadow; Rik > > > Drummond; CLEM; > > > Gary Crough; Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; > > > ietf-ediint@imc.org > > > Subject: AS2 XML requirements (was Re: HL7 Standards Process) > > > > > > > > > No! XML must be accommodated in EDIINT! I was figuring XML > > > content would > > > be carried as edi-consent, but that seems like a > back-door fix rather > > > than a happy solution. > > > > > > This sounds like Wes has raised a new requirement that should be > > > considered in the AS2 spec (and maybe AS1?). I do > consider XML to be a > > > type of EDI, since both are computer-processable electronic > > > representations of business transactions, so I request we add > > > a type of > > > edi-xml. And I request we add an attribute/field that > > > indicates the kind > > > of XML document ("semantic standard") being carried in > the payload. > > > Kit Lueder, > > > MITRE. > > > > > > "Rishel,Wes" wrote: > > > > > > > > I doubt if XML will ever be a meaningful content type for > > > EDIINT. Saying > > > > that the content is HL7, X12, or NCPDP implies the > availability of a > > > > semantic interpretation of the payload. This would be true > > > whether the > > > > payload was in the current HL7, X12, or NCPDP syntaxes or > > > in the particular > > > > applications of XML that they may adopt. > > > > > > > > If the only claim is that the payload is XML there is no > > > such linkage to a > > > > semantic standard, even if the XML instance contains a > > > pointer to a schema > > > > in a repository somewhere. A schema is far less than a semantic > > > > representation of the instance; it simplify enables a > > > better and more > > > > thorough parsing of the message. > > > > > > > > > -----Original Message----- > > > > > From: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > > > > > Sent: Tuesday, November 21, 2000 2:52 PM > > > > > To: dick@8760.com > > > > > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary > > > Crough; Beth > > > > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; > > > ietf-ediint@imc.org > > > > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > > > > > > > > > > > > Dick, > > > > > > > > > > Probably the requirements are identical, except that the > > > > > content will be > > > > > in X12 or NCPDP syntax instead of HL7 or XML. > > > > > > > > > > Kepa > > > > > > > > > > Dick Brooks wrote: > > > > > > > > > > > > Kepa, > > > > > > > > > > > > > Are you volunteering to create an interoperability > > > > > profile for digital > > > > > > > signatures of the HIPAA standard transactions ? > > > > > > > > > > > > My offer to assist in the development of an > > > > > interoperability profile was in > > > > > > response to a need identified within HL7. However, I would > > > > > be willing to > > > > > > help the HIPAA folks create an interoperability profile, > > > > > provided it's based > > > > > > on a technology that I'm familiar with (e.g. EDIINT AS2, > > > > > GISB EDM, ebXML). > > > > > > > > > > > > I would hope the investment in developing an > > > > > interoperability profile for > > > > > > HL7 could be leveraged in other areas (e.g. HIPAA, ASTM), > > > > > without any > > > > > > additional work. Do you see HIPAA's requirements being > > > significantly > > > > > > different enough from HL7 to require a separate > > > > > interoperability profile? > > > > > > > > > > > > Thanks, > > > > > > > > > > > > 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: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com] > > > > > > > Sent: Monday, November 20, 2000 6:13 PM > > > > > > > To: Dick Brooks > > > > > > > Cc: Rishel,Wes; Gunther Schadow; Rik Drummond; CLEM; Gary > > > > > Crough; Beth > > > > > > > Morrow; David@Drummondgroup. Com; GISB1@aol.com; > > > > > ietf-ediint@imc.org > > > > > > > Subject: Re: HL7 Standards Process (was RE: > EDIINT and HIPAA) > > > > > > > > > > > > > > > > > > > > > Dick, > > > > > > > > > > > > > > Are you volunteering to create an interoperability > > > > > profile for digital > > > > > > > signatures of the HIPAA standard transactions ? X12, > > > > > NCPDP, and X12+HL7 > > > > > > > (in which the signature could be on the HL7 or on the X12 > > > > > components) > > > > > > > are the immediate needs. However, keep in mind that > > > > > NCPDP could also be > > > > > > > in EDIFACT syntax (e.g. prescriptions) and HL7 could be > > > > > in different > > > > > > > syntaxes. But, for HIPAA purposes, at this time we need > > > > > something for > > > > > > > the 275 attachment only. Other HL7 messages could come > > > > > later through > > > > > > > other interoperability profiles. > > > > > > > > > > > > > > If we have a very narrow scope (HIPAA transactions as > > > > > they were released > > > > > > > in the Final Rule, plus attachments as we know them) then > > > > > it is possible > > > > > > > to get an agreement, even if there is not yet an > > > > > agreement on other > > > > > > > issues or on PKI issues. > > > > > > > > > > > > > > Other volunteers ? > > > > > > > > > > > > > > Kepa > > > > > > > > > > > > > > Dick Brooks wrote: > > > > > > > > > > > > > > > > Thanks Wes. > > > > > > > > > > > > > > > > Based on your description I would anticipate > the EDIINT AS2 > > > > > > > spec taking the > > > > > > > > "Recommendation" route, IF the group decides to go > > > forward. Do > > > > > > > you see it > > > > > > > > the same way? > > > > > > > > > > > > > > > > FYI - other groups that have adopted AS2 have found it > > > > > > > necessary to define > > > > > > > > "interoperability profiles". These profiles identify > > > > > the exact set of > > > > > > > > "options" from AS2 that everyone in the "trading > > > > > community" agrees to > > > > > > > > follow, in order to ensure interoperability. For > > > example, GISB > > > > > > > has already > > > > > > > > defined an AS2 interoperability profile and the New York > > > > > > > Collaborative, in > > > > > > > > accordance with the Public Service Commission > > > regulations, is > > > > > > > in the process > > > > > > > > of defining their interoperability profile. I'm > > > > > familiar with both these > > > > > > > > groups and the process used to develop their profiles. > > > > > I could help HL7 > > > > > > > > develop an AS2 interoperability profile, if the > > > group decides > > > > > > > to pursue this > > > > > > > > approach. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > 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: Rishel,Wes [mailto:wes.rishel@gartner.com] > > > > > > > > > Sent: Friday, November 17, 2000 8:32 PM > > > > > > > > > To: 'dick@8760.com'; Gunther Schadow > > > > > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; > > > > > Beth Morrow; > > > > > > > > > David@Drummondgroup. Com; GISB1@aol.com; > > > ietf-ediint@imc.org > > > > > > > > > Subject: HL7 Standards Process (was RE: > EDIINT and HIPAA) > > > > > > > > > > > > > > > > > > > > > > > > > > > As the chair-elect of HL7 I would like to > respond to DB's > > > > > > > > > question about HL7 > > > > > > > > > process. > > > > > > > > > > > > > > > > > > HL7 has two kinds of specifications that are > > > > > published using slighly > > > > > > > > > different processes: a Standard is submitted > to ANSI for > > > > > > > > > certification once > > > > > > > > > it has passed ballot; a Recommendation is published > > > > > by HL7 but is not > > > > > > > > > submitted to ANSI and does not become an ANSI > > > standard. Some > > > > > > > > > Recommendations > > > > > > > > > have had substantial acceptance among the HL7 > community, > > > > > > > including it's > > > > > > > > > "lower level protocols" which define ways to > reliably pass > > > > > > > > > discrete messages > > > > > > > > > over RS-232 and TCP, and were published sometime in > > > > > the early 1990s. > > > > > > > > > > > > > > > > > > A Standard originates under the sponsorship > of a Technical > > > > > > > > > Committee. If HL7 > > > > > > > > > were to create a Standard for EDIINT it would be the > > > > > Control/Query > > > > > > > > > committee. It is balloted at the committee level. > > > > > (Actually anyone can > > > > > > > > > participate in the committee ballot, but in > > > practice those who > > > > > > > > > choose to do > > > > > > > > > so are usually those who participate in, or follow > > > > > the work of, the > > > > > > > > > Technical Committee.) When it passes a committee > > > > > level ballot it is > > > > > > > > > submitted for ballot by the full HL7 Working > > > Group (which is > > > > > > > the entire > > > > > > > > > organization). If it passes at this level it is > > > automatically > > > > > > > submitted to > > > > > > > > > ANSI for certification. The ANSI review allows > > > time for public > > > > > > > > > comment, but > > > > > > > > > it is primarily a certification that the process > > > was fair and > > > > > > > consistent > > > > > > > > > with our bylaws. To date, have never had an issue > > > arise that > > > > > > > prevented or > > > > > > > > > delayed the certification process. > > > > > > > > > > > > > > > > > > In addition to Technical Committees HL7 has > > > Special Interest > > > > > > > > > Groups. Gunther > > > > > > > > > is co-chair of our SIG on security. Strictly > > > speaking, a SIG > > > > > > > > > cannot initiate > > > > > > > > > the balloting of a standard; but SIGs can prepare > > > > > such a document, and > > > > > > > > > obtain the consent of a Technical Committee which > > > > > sponsors the ballot. > > > > > > > > > > > > > > > > > > The other kind of document, the Recommendation, > > > is easier to > > > > > > > get out the > > > > > > > > > door. It can be originated by a SIG, and it has only > > > > > one level of > > > > > > > > > balloting. > > > > > > > > > The majority that is required to pass a > Recommendation is > > > > > > > less severe than > > > > > > > > > the majority required to pass a Standard (67% > vs. 90%). > > > > > > > > > > > > > > > > > > Ballots are conducted using the Web. Assuming > that both > > > > > > > ballots pass an > > > > > > > > > energetic committee can easily complete the > > > entire process in > > > > > > > two of our > > > > > > > > > three-per-year Working Group meetings > (roughly 8 months > > > > > > > elapsed time). (Of > > > > > > > > > course most committees have substantial time invested > > > > > in debating the > > > > > > > > > document before it begins the process.) > > > > > > > > > > > > > > > > > > Most of the meetings required at certain points in > > > > > the process can be > > > > > > > > > handled using conference calls; in theory a > > > REALLY motivated > > > > > > > > > committee could > > > > > > > > > accomplish the two-level ballot in five months > > > and then wait > > > > > > > about three > > > > > > > > > months for ANSI certication. (That is a > theoretical figure > > > > > > > that has never > > > > > > > > > been realized in practise.) > > > > > > > > > > > > > > > > > > Recommendations can be passed in roughly four months. > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > > > Wes Rishel > > > > > > > > > Research Director > > > > > > > > > Healthcare Industry Research & Advisory Services > > > > > > > > > GartnerGroup > > > > > > > > > Alameda, CA > > > > > > > > > Client inquiries: call +1-203-316-1288 or email to > > > > > indapps@gartner.com > > > > > > > > > wes.rishel@gartner.com > > > > > > > > > 510 522 8135 > > > > > > > > > 510 521 2423 (fax) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Dick Brooks [mailto:dick@8760.com] > > > > > > > > > > Sent: Thursday, November 02, 2000 10:27 AM > > > > > > > > > > To: Gunther Schadow > > > > > > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; > > > > > Beth Morrow; > > > > > > > > > > David@Drummondgroup. Com; GISB1@aol.com; > > > > > ietf-ediint@imc.org; Dick > > > > > > > > > > Brooks > > > > > > > > > > Subject: RE: EDIINT and HIPAA > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not familiar with the HL7 standards > > > process, all of > > > > > > > > > > my experience > > > > > > > > > > has been with IETF, DISA, GISB and recently ebXML. > > > > > Each of these > > > > > > > > > > organizations has a different process for developing > > > > > > > standards. If we > > > > > > > > > > brought AS2 to HL7 today, how long would it take to > > > > > become an > > > > > > > > > > ANSI standard? > > > > > > > > > > I would like to read HL7's operational process > > > document, can > > > > > > > > > > you provide a > > > > > > > > > > pointer? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > _/ _/ Kit C. J. Lueder > > > _/ _/ _/ The MITRE Corp. Tel: 703-883-5205 > > > _/_/_/ _/ _/_/_/ 1820 Dolley Madison Bl Cell: 703-577-2463 > > > _/ _/ _/ _/ Mailstop W658 FAX: 703-883-3383 > > > _/ _/ _/ _/ McLean, VA 22102 Mail: kit@mitre.org > > > Worse than an unanswered question is an unquestioned answer. > > > > > -- > _/ _/ Kit C. J. Lueder > _/ _/ _/ The MITRE Corp. Tel: 703-883-5205 > _/_/_/ _/ _/_/_/ 1820 Dolley Madison Bl Cell: 703-577-2463 > _/ _/ _/ _/ Mailstop W658 FAX: 703-883-3383 > _/ _/ _/ _/ McLean, VA 22102 Mail: kit@mitre.org > Worse than an unanswered question is an unquestioned answer. > From owner-ietf-ediint@mail.imc.org Wed Nov 22 18:52:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21159 for ; Wed, 22 Nov 2000 18:52:43 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA05953 for ietf-ediint-bks; Wed, 22 Nov 2000 15:23:11 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA05949 for ; Wed, 22 Nov 2000 15:23:10 -0800 (PST) Received: by spyglass.cyclonecommerce.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 16:24:10 -0700 Received: from THARDINGLAPTOP (cx66967-a.phnx3.az.home.com [24.1.196.29]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XJT4D1K6; Wed, 22 Nov 2000 16:24:05 -0700 From: Terry Harding To: dick@8760.com, Kepa Zubeldia Cc: "Rishel,Wes" , Gunther Schadow , Rik Drummond , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Message-ID: <00ae01c054db$30da7c90$1dc40118@THARDINGLAPTOP> References: Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Wed, 22 Nov 2000 16:23:15 -0700 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.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > That's encouraging because both EDIINT AS2 and GISB EDM are capable of > signing and encrypting any type of content (a.k.a. payload), as will ebXML > when we're finished. AS1 and AS2 can both send any type of payload. It is the individual vendors implementation which determines if the other payload types are properly processed. Terry Harding Cyclone Commerce Inc. From owner-ietf-ediint@mail.imc.org Wed Nov 22 19:02:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24262 for ; Wed, 22 Nov 2000 19:02:22 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA06155 for ietf-ediint-bks; Wed, 22 Nov 2000 15:30:56 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06151 for ; Wed, 22 Nov 2000 15:30:51 -0800 (PST) Received: by spyglass.cyclonecommerce.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 16:31:52 -0700 Received: from THARDINGLAPTOP (cx66967-a.phnx3.az.home.com [24.1.196.29]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XJT4D1L4; Wed, 22 Nov 2000 16:31:51 -0700 From: Terry Harding To: "Rishel,Wes" , "'Gunther Schadow'" Cc: dick@8760.com, Rik Drummond , Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Message-ID: <00b801c054dc$46549320$1dc40118@THARDINGLAPTOP> References: <69A38F8986F3D211A6B00008C79121060969A312@mammoth.gartner.com> Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Wed, 22 Nov 2000 16:31:00 -0700 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.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Whatever happens to electronic signatures I would be delighted if AS2 > somehow got launched for the simple purpose of providing authentic, > encrypted B2B messages built on top of ubiquitous Internet protocols. I > would like to offer my enthusiastic support to enabling that by whatever > means works best. If that means that HL7 adopts it, so be it. (I just hope > we don't adapt it.) Many vendors are already supplying that capability. Several vendors are AS1 and AS2 compliant and create a transport independant signed, secured message which is transferred using SMTP or HTTP. The packaging remains the same for either transport and returned MDNs also follow the same format, transport independant. Terry Harding Cyclone Commerce From owner-ietf-ediint@mail.imc.org Wed Nov 22 19:32:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03203 for ; Wed, 22 Nov 2000 19:32:11 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA06934 for ietf-ediint-bks; Wed, 22 Nov 2000 16:02:11 -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 QAA06929 for ; Wed, 22 Nov 2000 16:02:09 -0800 (PST) Received: by mailman.8760.com from localhost (router,SLMail V3.2); Wed, 22 Nov 2000 18:02:48 -0600 Received: from gamma [192.168.21.133] by mailman.8760.com [192.168.21.90] (SLmail 3.2.3113) with SMTP id 6C8B3315B97F11D4BB0C0060974E38DD for plus 10 more; Wed, 22 Nov 2000 18:02:48 -0600 Reply-To: From: "Dick Brooks" To: "Rishel,Wes" , "'Kit \(Christopher\) Lueder'" Cc: "'Kepa Zubeldia'" , "Gunther Schadow" , "Rik Drummond" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) Date: Wed, 22 Nov 2000 17:59:00 -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: <69A38F8986F3D211A6B00008C79121060969A338@mammoth.gartner.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-SLUIDL: 5DCE1F1E-BFEC11D4-BB0C0060-974E38DD Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Wes, I expect that HL7 will define "Transaction-set" identifiers when constructing the Interoperability Profile. That's how it happened with GISB. Perhaps a "namespace" qualified Transaction-Set identifier would be useful, e.g. HL7:XXXyyyy 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: Rishel,Wes [mailto:wes.rishel@gartner.com] > Sent: Wednesday, November 22, 2000 3:15 PM > To: 'dick@8760.com'; 'Kit (Christopher) Lueder' > Cc: 'Kepa Zubeldia'; Gunther Schadow; Rik Drummond; CLEM; Gary Crough; > Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; > ietf-ediint@imc.org > Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) > > > Is the transaction identifier qualified by another field or is > there a need > to set up a registry of transaction set identifiers? I suspect that HL7 > would prefer to maintain its own identifiers without worrying about > collision with another standard or having to sit through length debates > about whether to use a hyphen or an underbar. > > > > -----Original Message----- > > From: Dick Brooks [mailto:dick@8760.com] > > Sent: Wednesday, November 22, 2000 9:57 AM > > To: Rishel,Wes; 'Kit (Christopher) Lueder' > > Cc: 'Kepa Zubeldia'; Gunther Schadow; Rik Drummond; CLEM; Gary Crough; > > Beth Morrow; David@Drummondgroup. Com; GISB1@aol.com; > > ietf-ediint@imc.org > > Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) > > > > > > Wes, > > > > > Furthermore, if all you know about a message is that it is > > encoded in the > > > XML syntax you really don't know enough to do an EDI function on the > > > message. The EDI standards specify a lot more than syntax and these > > > specifications are very much a part of the interface > > contract. [snip] > > > > You are right on, that's why AS2 has a header field called > > "Transaction-Set". The sender uses this header to identify > > exactly what type of data is contained in the payload > > (regardless of the > > encoding syntax X12, XML. et al). For example, GISB uses the > > same ANSI X12 > > 850 transaction set for different purposes so they created > > transaction set > > identifiers (e.g. G850NMST or G850RQCF) to provide more precision when > > identifying a payload. A sender would insert either "G850NMST" or > > "G850RQCF" in the "transaction-set" header, this way the > > receiving party can > > "dispatch" processing to different "process flows" based on > > the "transaction > > set" identifier. > > > > > > 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 Nov 22 19:44:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06248 for ; Wed, 22 Nov 2000 19:44:59 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA07350 for ietf-ediint-bks; Wed, 22 Nov 2000 16:18:46 -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 QAA07346 for ; Wed, 22 Nov 2000 16:18:44 -0800 (PST) Received: by mailman.8760.com from localhost (router,SLMail V3.2); Wed, 22 Nov 2000 18:18:47 -0600 Received: from gamma [192.168.21.133] by mailman.8760.com [192.168.21.90] (SLmail 3.2.3113) with SMTP id 6C8B331DB97F11D4BB0C0060974E38DD for plus 10 more; Wed, 22 Nov 2000 18:18:46 -0600 Reply-To: From: "Dick Brooks" To: "Terry Harding" , "Rishel,Wes" , "'Gunther Schadow'" Cc: "Rik Drummond" , "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Wed, 22 Nov 2000 18:14:58 -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: <00b801c054dc$46549320$1dc40118@THARDINGLAPTOP> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-SLUIDL: 5DCE1F25-BFEC11D4-BB0C0060-974E38DD Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Terry, regarding the following: > Many vendors are already supplying that capability. Several vendors are > AS1 and AS2 compliant and create a transport independent signed, secured > message which is transferred using SMTP or HTTP. > The packaging remains the same for either transport and returned MDNs > also follow the same format, transport independant. I don't mean to nit-pick but I don't believe this is accurate. Didn't the AS2 testers discover a problem with the To and From headers that are used in AS1, that resulted in a "packaging change" to use AS2-To and AS2-From within AS2. IMO, this means that AS1 and AS2 use DIFFERENT packaging, not hugely different, but different. Would you agree? 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: Terry Harding [mailto:tharding@cyclonecommerce.com] > Sent: Wednesday, November 22, 2000 5:31 PM > To: Rishel,Wes; 'Gunther Schadow' > Cc: Dick Brooks; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > Whatever happens to electronic signatures I would be delighted if AS2 > > somehow got launched for the simple purpose of providing authentic, > > encrypted B2B messages built on top of ubiquitous Internet protocols. I > > would like to offer my enthusiastic support to enabling that by whatever > > means works best. If that means that HL7 adopts it, so be it. > (I just hope > > we don't adapt it.) > Many vendors are already supplying that capability. Several vendors are > AS1 and AS2 compliant and create a transport independant signed, secured > message which is transferred using SMTP or HTTP. > The packaging remains the same for either transport and returned MDNs > also follow the same format, transport independant. > > Terry Harding > Cyclone Commerce From owner-ietf-ediint@mail.imc.org Thu Nov 23 15:12:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03033 for ; Thu, 23 Nov 2000 15:12:02 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA27965 for ietf-ediint-bks; Thu, 23 Nov 2000 09:43:37 -0800 (PST) Received: from gateway.reims.net (firewall-user@gateway.reims.net [194.75.234.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27952 for ; Thu, 23 Nov 2000 09:43:32 -0800 (PST) Received: (from uucp@localhost) by gateway.reims.net (8.9.3/8.9.3) id RAA13083 for ; Thu, 23 Nov 2000 17:50:50 GMT Received: from smtpgate.saa-cons.co.uk(10.10.10.182) by gateway.reims.net via smap (3.2) id xma013046; Thu, 23 Nov 00 17:50:25 GMT Received: from olympus.saa-cons.co.uk (olympus.saa-cons.co.uk [10.1.11.12]) by smtpgate.saa-cons.co.uk (8.8.8/8.8.8) with ESMTP id RAA25761 for ; Thu, 23 Nov 2000 17:57:39 GMT (envelope-from djr@saa-cons.co.uk) Received: from localhost (djr@localhost) by olympus.saa-cons.co.uk (AIX4.3/8.9.3/8.7) with SMTP id RAA37202 for ; Thu, 23 Nov 2000 17:41:58 GMT Date: Thu, 23 Nov 2000 17:41:58 +0000 (GMT) From: Dave Roberts To: ietf-ediint@imc.org Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) In-Reply-To: Message-ID: 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: On Wed, 22 Nov 2000, Dick Brooks wrote: > The original EDIINT AS1 draft was restricted to supporting RFC1767 payload > types only. I'll try to be careful about how I phrase this response: the original draft of AS1 may have only referred to a payload of EDI, but that's not a strict requirement, and not the case now. The later (and current) drafts do not specify that the payload MUST be EDI, and I believe that since Terry took over authorship, generic EC payloads are now mentioned, although they may not be highlighted by example. During the rounds of AS1 testing, a Word Document was sent as one of the tests to prove that non EDI data could be handled by both parties. - Dave. PS Can people please trim their posts? -- Dave Roberts Servicing the Online Organisation Principal Technical Consultant http://www.saaconsultants.com/ SAA Consultants Ltd Tel: +44 1752 606000 Fax: +44 1752 606838 From owner-ietf-ediint@mail.imc.org Thu Nov 23 15:32:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11167 for ; Thu, 23 Nov 2000 15:32:07 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA29574 for ietf-ediint-bks; Thu, 23 Nov 2000 10:19:42 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29570 for ; Thu, 23 Nov 2000 10:19:41 -0800 (PST) Received: by spyglass.cyclonecommerce.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 11:20:43 -0700 Received: from THARDINGLAPTOP (cx66967-a.phnx3.az.home.com [24.1.196.29]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XJT4D1VM; Thu, 23 Nov 2000 11:20:36 -0700 From: Terry Harding To: dick@8760.com, "Rishel,Wes" , "'Gunther Schadow'" Cc: Rik Drummond , Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Message-ID: <00f701c05579$f43917c0$1dc40118@THARDINGLAPTOP> References: Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Thu, 23 Nov 2000 11:19:43 -0700 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.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Terry, > > > The packaging remains the same for either transport and returned MDNs > > also follow the same format, transport independant. > > I don't mean to nit-pick but I don't believe this is accurate. Didn't the > AS2 testers discover a problem with the To and From headers that are used in > AS1, that resulted in a "packaging change" to use AS2-To and AS2-From within > AS2. IMO, this means that AS1 and AS2 use DIFFERENT packaging, not hugely > different, but different. Would you agree? Dick, you are not nit-picking.... Yes, you are correct with the header issue. But lets look at the creation of a multipart/signed message. Step 1: Place payload inside a MIME body part Step 2: Place bodypart inside a S/MIME multipart/signed construct Step 3: Add transport dependant headers So during the creation of a message, I perform steps 1 and 2 the same way for either AS1 or AS2. Next i add the top level transport headers for SMTP or HTTP and send the message. The headers you referred to are actually top level transport specific headers. When i made the statement about the packaging being the same regardless of transport, i am referring to the actual MIME construct of the message. Transport specfic headers will vary from transport to transport. AS2 added AS2-To and AS2-From to the top level headers, but i still packaged the payload the same way. Terry Harding Cyclone Commerce From owner-ietf-ediint@mail.imc.org Thu Nov 23 15:37:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13364 for ; Thu, 23 Nov 2000 15:37:27 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA03403 for ietf-ediint-bks; Thu, 23 Nov 2000 11:41:40 -0800 (PST) Received: from puma.gartner.com (overlord.gartner.com [207.140.148.33]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA03384 for ; Thu, 23 Nov 2000 11:41:35 -0800 (PST) Received: by puma.gartner.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 14:41:41 -0500 Message-ID: <69A38F8986F3D211A6B00008C79121060969A348@mammoth.gartner.com> From: "Rishel,Wes" To: "'Terry Harding'" , "Rishel,Wes" , "'Gunther Schadow'" Cc: dick@8760.com, Rik Drummond , Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Thu, 23 Nov 2000 14:41:39 -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: Comment below. > -----Original Message----- > From: Terry Harding [mailto:tharding@cyclonecommerce.com] > Sent: Wednesday, November 22, 2000 3:31 PM > To: Rishel,Wes; 'Gunther Schadow' > Cc: dick@8760.com; Rik Drummond; Kepa Zubeldia; CLEM; Gary > Crough; Beth > Morrow; David@Drummondgroup. Com; GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) > > > > Whatever happens to electronic signatures I would be > delighted if AS2 > > somehow got launched for the simple purpose of providing authentic, > > encrypted B2B messages built on top of ubiquitous Internet > protocols. I > > would like to offer my enthusiastic support to enabling > that by whatever > > means works best. If that means that HL7 adopts it, so be > it. (I just hope > > we don't adapt it.) > Many vendors are already supplying that capability. Several > vendors are > AS1 and AS2 compliant and create a transport independant > signed, secured > message which is transferred using SMTP or HTTP. > The packaging remains the same for either transport and returned MDNs > also follow the same format, transport independant. > > Terry Harding > Cyclone Commerce Why do vendors frequently say the industry doesn't need a standard because the vendor already has the function? Speaking as someone who spent most of his career as a vendor I would suppose it is because we secretly harbor the fantasy that we will someday entirely control the space. I recognize and laud that Cyclone has been involved in interoperability testing with other vendors and don't mean to focus on Cyclone or Terry for criticism. But I do think that vendors, as a community, tend give deference to standards up to a point, and then want to "embrace and extend" to attempt to corner part of the market. Standards help to promote interoperability across vendors and limit the effectiveness of "embrace and extend". This is an area that is sadly lacking for authentication and security in general and for B2B transactions specifically. In healthcare we have an intersting relationship between the government and consensus standards becasue of the HIPAA of 1996. Rather than create its own standards, as has been the typical Government approach, that law mandated Secretary HHS to find and use consensus standards if any were available, with a strong bias towards ANSI-certificed SDOs. Part of the thrust of HIPAA is to enable wide spread interoperability for certain healthcare transactions. Currently the government cannot find a standard to mandate that would permit free exchange of these transactions over the Internet because there is nothing like AS2 standardized. Wouldn't it be great if some group standardized AS2 and specific profiles to meet specific business needs, such as batch and interactive transactions, and Sec HHS recognized and mandated that standard and those profiles? Ideally, IETF would have done so. Even though it is not ANSI-certified it carries the weight that would allow the Secretary to mandate it. However healthcare cannot wait for the standard to come out given the deliberate pace of the IETF. My company has been describing the Internet as "digital dial tone" for B2B transactions -- that is to say, a way to communicate business transactions that (a) permits structured data, and (b) is as ubiquitous and interoperable as voice and fax. The concept is great, but it is not a reality until a specification such as AS2 is standardized and widely adopted in its standard form. Wes Rishel Research Director Healthcare Industry Research & Advisory Services GartnerGroup Alameda, CA Client inquiries: call +1-203-316-1288 or email to indapps@gartner.com wes.rishel@gartner.com 510 522 8135 510 521 2423 (fax) From owner-ietf-ediint@mail.imc.org Thu Nov 23 22:02:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01742 for ; Thu, 23 Nov 2000 22:02:47 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA19589 for ietf-ediint-bks; Thu, 23 Nov 2000 18:34:32 -0800 (PST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19584 for ; Thu, 23 Nov 2000 18:34:30 -0800 (PST) Received: from gamma (user-33qt44c.dialup.mindspring.com [199.174.144.140]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with SMTP id VAA23353; Thu, 23 Nov 2000 21:35:22 -0500 (EST) Reply-To: From: "Dick Brooks" To: "Dave Roberts" , Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) Date: Thu, 23 Nov 2000 20:31:46 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dave, see responses inline. > I'll try to be careful about how I phrase this response: the original > draft of AS1 may have only referred to a payload of EDI, but that's not a > strict requirement, and not the case now. > > The later (and current) drafts do not specify that the payload MUST be > EDI, and I believe that since Terry took over authorship, generic EC > payloads are now mentioned, although they may not be highlighted by > example. Dave, the AS1 draft (ref: http://www.ietf.org/internet-drafts/draft-ietf-ediint-as1-11.txt) does state in section 2.1: "This standard is also NOT limited to strict EDI use, but applies to any electronic commerce application where business data needs to be exchanged over the Internet in a secure manner." However, there is no definitive text describing how non-rfc1767 types are supported in AS1. The AS1 specification is tightly intertwined with references to RFC 1767 and all examples are based on RFC 1767 payloads. As both you and Terry have pointed out, many AS1 vendors have added support for non-RFC1767 payloads in their products. I'm concerned the lack of definitive language in AS1 describing support for non-RFC1767 types leaves it to up to the individual AS1 vendors to decide how non-RFC1767 payloads are supported in their products and this opens the door to interoperability issues. AS2 contains definitive text describing support for ANY MIME media type. I believe the AS1 authors should consider adding language similar to what is contained in AS2. I also believe it would be beneficial to include some non-RFC1767 payloads in their interoperability testing. Rik, does the AS2 interoperability test currently underway include a test case using a non-rfc1767 payload? If not I would suggest adding a test case exchanging XML payloads. 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 Thu Nov 23 23:13:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21406 for ; Thu, 23 Nov 2000 23:13:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA25048 for ietf-ediint-bks; Thu, 23 Nov 2000 19:35:57 -0800 (PST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25043 for ; Thu, 23 Nov 2000 19:35:55 -0800 (PST) Received: from gamma (user-33qt44c.dialup.mindspring.com [199.174.144.140]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with SMTP id WAA03025; Thu, 23 Nov 2000 22:36:35 -0500 (EST) Reply-To: From: "Dick Brooks" To: "Terry Harding" , "Rishel,Wes" , "'Gunther Schadow'" Cc: "Rik Drummond" , "Kepa Zubeldia" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Thu, 23 Nov 2000 21:32: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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <00f701c05579$f43917c0$1dc40118@THARDINGLAPTOP> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Terry, Thanks for the excellent explanation - I understand what you meant by packaging now... However I still think there is some room for differences between AS1 and AS2 packaging of the SAME document. Suppose I want to send a JPEG image of a medical X-Ray. Based on the IANA registration for the image/jpeg media type, ref: http://www.isi.edu/in-notes/iana/assignments/media-types/image/jpeg It states: "Encoding considerations : Image/jpeg objects consist of binary data. A content-transfer-encoding of "Binary" is strongly encouraged for messaging environments which support binary transport. A content-transfer-encoding of Base64 (and the associated transformation) is strongly encouraged for messaging environments that do not support binary transfer." Because HTTP (and AS2) contain direct support for binary data the JPEG CAD drawing can be packaged as pure binary. However, this same JPEG data, when sent over SMTP (AS1) would most likely be base64 encoded and a content-transfer-encoding header would be required. Example of the same JPEG data packaged for AS2 and AS1: AS2 PACKAGING AS1 PACKAGING ------------------------------- ---------------------------------- Content-type: image/jpeg Content-type: image/jpeg Content-transfer-encoding: base64 [binary jpeg data here] [base64 encoded jpeg data here] 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 Fri Nov 24 00:57:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20152 for ; Fri, 24 Nov 2000 00:57:49 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA27366 for ietf-ediint-bks; Thu, 23 Nov 2000 21:18:27 -0800 (PST) Received: from aurora.regenstrief.org (aurora.regenstrief.org [134.68.31.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA27362 for ; Thu, 23 Nov 2000 21:18:25 -0800 (PST) Received: from aurora.regenstrief.org (ip209-183-121-244.ts.indy.net [209.183.121.244]) by aurora.regenstrief.org (8.11.1/8.9.3) with ESMTP id eAO5I8Z68136; Fri, 24 Nov 2000 00:18:08 -0500 (EST) (envelope-from gunther@aurora.regenstrief.org) Message-ID: <3A1DFA2B.1FEF41A5@aurora.regenstrief.org> Date: Fri, 24 Nov 2000 00:18:35 -0500 From: Gunther Schadow Organization: Regenstrief Institute X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rishel,Wes" CC: "'dick@8760.com'" , "'Kit (Christopher) Lueder'" , "'Kepa Zubeldia'" , Rik Drummond , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: Re: AS2 XML requirements (was Re: HL7 Standards Process) References: <69A38F8986F3D211A6B00008C79121060969A338@mammoth.gartner.com> Content-Type: multipart/mixed; boundary="------------9C5A15777950E812DE512F4B" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------9C5A15777950E812DE512F4B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Wes, Dick, Kepa, and all ... wow, you've had quite an e-mail day today (I mean yesterday), we can be really lucky that I see all this only after the fact that way I didn't get involved and didn't write my usual e-mail bombs :-) So, I can summarize a few key issues: 1) AS1 vs. AS2 / email vs. HTTP 2) XML as payload and how to process payload 3) digital e-signatures, the law, and whatnot 4) what else? 1) AS1 vs. AS2 / email vs. HTTP Kepa, I agree with you. Dick and Wes, I see a good place for email routes especially to smaller participants. However, we had been engaged in endless hard debates on this issue before and it's like everything had been said. All I ask is that we will continue to offer AS1 for email and AS2 for HTTP and whatever else we need. I didn't see you object against continuing to offer AS1, and that is enough for me. I don't need to change your mind to thing less negative about email. 2) XML as payload and how to process payload I agree with Wes. XML don't mean s... (I spent my day with car mechanics, so I picked up some of their jargon :-). HL7 v3 has fully embarked XML, and I agree, but it's not XML that's important but HL7, NCPDP, X12 or what have you. EbXML might provide a common message "header", but that's going to be about all, and ebXML is out of the question at this time. I have long ago tried to convince people at IETF EDIINT to revise the RFC 1767 spec to add additional EDI-* MIME types, to add parameters to the EDI-* MIME type, and to devise a way to use EDI-consent more robustly. I talked high and low, long and short, but I didn't get my point accross. Might it be that now is the time to get some agreement about this? At least some of this is a precondition to do any of the HL7/NCPDP profiles in that ANSI/HHS process. 3) digital e-signatures, the law, and whatnot I have heard a lot of very cautious statements about e-signatures in healthcare and have read 3 articles now that caution more or less bluntly that "digital signatures" are no signatures. I am also aware of ths issue of requiring to see exactly what is signed and to freeze that representation as part of the signed document. XSL stylesheets or screenshots are then discussed, and I believe that if we'd take that serious we could only allow screenshots to be signed and that wouldn't even be enough. All these worries are worth thinking about to some extent, but then there is the sheer pragmatic fact that the world won't stop spinning and e-signatures are here to stay in some form. In fact, the ESIGN act -- according to my reading -- is quite loose in what it requires of a signature. I see no demand for screenshots or XSL in it. I see simply the statmement that no for of a signature can be denied a legal status merely on the basis that it is not "in written form". Much of the rest is left open to hopefully close investigation of each individual case that goes to the courts. 4) what else? Ah, to reiterate Kepa: limit the scope. With the transaction standards in the HIPAA scope, we do not need very elaborate signature and countersignature attribution mechanics, since those transaction standards don't have much of that elaborate notion. So, the EDIINT route with one signature per transaction is probably all that's needed for now. Down the road, of course, we have HL7 v3 and XML digital signatures and we are ready for fine grained multi-signature and countersignature control with attributions along the lines of ASTM E1762 requirements, etc. But that isn't what the HHS would consider adopting anytime soon because it is simply too new and too advanced. regards -Gunther PS: thanks to Peggy Leiby and the HL7 headquarter, we now have a room for our Monday 1/8 meeting. So we can send out invitations rather soon. We will have people from ASTM, IETF, NCPDP, ABA, NCVHS, and HL7 present. This is great stuff! --------------9C5A15777950E812DE512F4B Content-Type: text/x-vcard; charset=us-ascii; name="gunther.vcf" Content-Description: Card for Gunther Schadow Content-Disposition: attachment; filename="gunther.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Schadow;Gunther tel;fax:+1 317 630 6962 tel;home:+1 317 816 0516 tel;work:+1 317 630 7960 x-mozilla-html:FALSE url:http://aurora.rg.iupui.edu org:Regenstrief Institute for Health Care adr:;;1050 Wishard Blvd;Indianapolis;Indiana;46202;USA version:2.1 email;internet:gschadow@regenstrief.org title:M.D., Medical Information Scientist note;quoted-printable:Al oppinions expressed in this message are my own and do =0D=0Anot necessarily represent those of the Regenstrief Institute. fn:Gunther Schadow end:vcard --------------9C5A15777950E812DE512F4B-- From owner-ietf-ediint@mail.imc.org Fri Nov 24 03:27:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02236 for ; Fri, 24 Nov 2000 03:27:42 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA13838 for ietf-ediint-bks; Thu, 23 Nov 2000 23:53:09 -0800 (PST) Received: from puma.gartner.com (overlord.gartner.com [207.140.148.33]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA13831 for ; Thu, 23 Nov 2000 23:53:07 -0800 (PST) Received: by puma.gartner.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Nov 2000 02:51:53 -0500 Message-ID: <69A38F8986F3D211A6B00008C79121060969A349@mammoth.gartner.com> From: "Rishel,Wes" To: "'Gunther Schadow'" Cc: "'dick@8760.com'" , "'Kit (Christopher) Lueder'" , "'Kepa Zubeldia'" , Rik Drummond , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) Date: Fri, 24 Nov 2000 02:51:51 -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: response follow > -----Original Message----- > From: Gunther Schadow [mailto:gunther@aurora.regenstrief.org] > Sent: Thursday, November 23, 2000 9:19 PM > To: Rishel,Wes > Cc: 'dick@8760.com'; 'Kit (Christopher) Lueder'; 'Kepa Zubeldia'; Rik > Drummond; CLEM; Gary Crough; Beth Morrow; David@Drummondgroup. Com; > GISB1@aol.com; ietf-ediint@imc.org > Subject: Re: AS2 XML requirements (was Re: HL7 Standards Process) > > > All these worries are worth thinking about to some extent, but then > there is the sheer pragmatic fact that the world won't stop spinning > and e-signatures are here to stay in some form. In fact, the ESIGN > act -- according to my reading -- is quite loose in what it requires > of a signature. I see no demand for screenshots or XSL in it. I > see simply the statmement that no for of a signature can be denied > a legal status merely on the basis that it is not "in written form". > Much of the rest is left open to hopefully close investigation of > each individual case that goes to the courts. If the ESIGN act is the one that passed last summer it is primarily about the law, not about technology. As I recall it says three things" 1) No law shall make an electronic signature invalid, solely because it is an electronic signature; this clears the legal pathway and overrides state laws to the contrary, but it doesn't actually say what does constitute a legal e-sig 2) a valid contract can be formed by an electronic signature as long as both parties agree to what constitutes an e-signature; so if Amazon.com wants to accept my entering a credit care number and pressing a button that says SEND as a signature, and if I understand that I am signing something and what I am signing, that is cool. If Ford decides that it wants something more tangible when it sells me a car on credit over the Web that is cool, too. 3) the Secretary of Commerce shall promulgate further standards about esignature to facilitate commerce. I am wondering if these regulations are out. I have not seen them. My primary concern is not about what constitutes an electronic signature. It is that EDIINT has a clear purpose and that purpose is different than that of being a digital implementation of an electronic signature. If HL7 or ASTM tries to pass EDIINT with the intention of making into a legal electronic signature we will spend endless hours debating all the issues that Gunther and I discussed and EDIINT STILL won't become a standard. From owner-ietf-ediint@mail.imc.org Fri Nov 24 05:22:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08834 for ; Fri, 24 Nov 2000 05:22:17 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA29202 for ietf-ediint-bks; Fri, 24 Nov 2000 01:41:36 -0800 (PST) Received: from gateway.reims.net (firewall-user@gateway.reims.net [194.75.234.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA29193 for ; Fri, 24 Nov 2000 01:41:34 -0800 (PST) From: Dave.Derry@saaconsultants.com Received: (from uucp@localhost) by gateway.reims.net (8.9.3/8.9.3) id JAA23892 for ; Fri, 24 Nov 2000 09:49:02 GMT Received: from smtpgate.saa-cons.co.uk(10.10.10.182) by gateway.reims.net via smap (3.2) id xma023868; Fri, 24 Nov 00 09:48:39 GMT Received: from domino-mail.saa-cons.co.uk (domino-mail.saa-cons.co.uk [10.10.10.4]) by smtpgate.saa-cons.co.uk (8.8.8/8.8.8) with ESMTP id JAA27797 for ; Fri, 24 Nov 2000 09:55:55 GMT (envelope-from Dave.Derry@SAAConsultants.com) To: ietf-ediint@imc.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 24 Nov 2000 09:44:55 +0000 X-MIMETrack: S/MIME Sign by Notes Client on Dave Derry/Saa(Release 5.0.5 |September 22, 2000) at 24/11/2000 09:43:32, Serialize by Notes Client on Dave Derry/Saa(Release 5.0.5 |September 22, 2000) at 24/11/2000 09:43:32, Serialize complete at 24/11/2000 09:43:32, Itemize by Notes Client on Dave Derry/Saa(Release 5.0.5 |September 22, 2000) at 24/11/2000 09:43:33, S/MIME Sign complete at 24/11/2000 09:43:33, Serialize by Router on domino-mail/Saa(Release 5.0.3 (Intl)|21 March 2000) at 24/11/2000 09:44:57, Serialize complete at 24/11/2000 09:44:57 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z1755_boundary_sign Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is an S/MIME signed message. ---------z1755_boundary_sign Content-Type: text/plain; charset="us-ascii" unsubscribe ---------z1755_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggKUMIIB/aADAgECAgMDknUwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMDEx MDgxMjEzMDBaFw0wMTExMDgxMjEzMDBaME8xHzAdBgNVBAMTFlRoYXd0ZSBGcmVl bWFpbCBNZW1iZXIxLDAqBgkqhkiG9w0BCQEWHWRhdmUuZGVycnlAc2FhY29uc3Vs dGFudHMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHP+pGNENgu4ct D6sy//w9/sfOmY5sKVTiy1+l0zIZl920c7nRJsa1cmY7rrKFzRXVJAQEmaYZ22fP 6RSeV3i4dAo2N16f2YAGOYHmGnsUkKGqUvT1IEJfj2pL7f01F8yJ3Axk9w109W/v +S2YnhAHv6C3nejHTjYUrRIjg3zdvQIDAQABozowODAoBgNVHREEITAfgR1kYXZl LmRlcnJ5QHNhYWNvbnN1bHRhbnRzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBAFgBBDuk53aYPpOWlqAuFrR2h6UsEK34GkMVuZdtH7meE9EwXw2q +jEm4HbsRkjHuSvbA31l2JfOlFzVeYwnuqd/kyGAA63dab9J4NyNQVMqj3NV90QO 1l1U+m4mg454Wr3Rb0zg+jE4TUE2jiRKP6pAYC8t6lZ9IarhDwHfb5reMIIDKTCC ApKgAwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFU aGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNl cyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UE ChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8 +tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy +boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkC AwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEt Mjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB BAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlOR S+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBXtewc1+8X ttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMIIDLTCCApag AwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBE aXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2 MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYD VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRe fS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3Ef QDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Ha o5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0B AQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JC I4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjc XyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigQAAMYAwggHr AgEBMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIw EAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJT QSAyMDAwLjguMzACAwOSdTAJBgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMTEyNDA5NDMzMlowIwYJKoZIhvcN AQkEMRYEFLJDQ8RpeQL0Jw/NkYf4OL7FhE6RMEwGCSqGSIb3DQEJDzE/MD0wBwYF Kw4DAh0wDgYIKoZIhvcNAwICAgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAB2/BUlViTy8EwacGZ07qHd69J4AH StjjHRS4NDnGN+8kII6TUYShHJxmP9Lq33ME6pzdjLLnhDnacAJzKuiLy+a18XCw WpWrQp2LWFFnXRLuYNxwMg6+uRJGERMLFLStg/rTysMqgKMG6jOkGyvLnGiUE1EP 7XeoWkPrvSGcuEUAAAAAAAAAAA== ---------z1755_boundary_sign-- From owner-ietf-ediint@mail.imc.org Fri Nov 24 11:59:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29502 for ; Fri, 24 Nov 2000 11:59:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA03342 for ietf-ediint-bks; Fri, 24 Nov 2000 08:12:30 -0800 (PST) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA03337 for ; Fri, 24 Nov 2000 08:12:28 -0800 (PST) Received: from gamma (user-2injr6e.dialup.mindspring.com [165.121.236.206]) by granger.mail.mindspring.net (8.9.3/8.8.5) with SMTP id LAA07578; Fri, 24 Nov 2000 11:13:09 -0500 (EST) Reply-To: From: "Dick Brooks" To: "Gunther Schadow" , "Rishel,Wes" Cc: "'Kit \(Christopher\) Lueder'" , "'Kepa Zubeldia'" , "Rik Drummond" , "CLEM" , "Gary Crough" , "Beth Morrow" , "David@Drummondgroup. Com" , , Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) Date: Fri, 24 Nov 2000 10:09:34 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3A1DFA2B.1FEF41A5@aurora.regenstrief.org> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Gunther, see responses inline. > 1) AS1 vs. AS2 / email vs. HTTP > > Kepa, I agree with you. Dick and Wes, I see a good place for email routes > especially to smaller participants. However, we had been engaged > in endless > hard debates on this issue before and it's like everything had been said. > All I ask is that we will continue to offer AS1 for email and AS2 for > HTTP and whatever else we need. I didn't see you object against continuing > to offer AS1, and that is enough for me. I don't need to change your mind > to thing less negative about email. No argument here. I think it was Kepa who suggested that a provider may need HTTP when sending to a Payer and a Payer may need SMTP when sending to a provider. Both parties should be free to implement the "inbound" delivery approach that meets their security, performance, reliability and business requirements. The HL7 interoperability profile needs to specify these details. 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 Mon Nov 27 12:12:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13746 for ; Mon, 27 Nov 2000 12:12:09 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA13300 for ietf-ediint-bks; Mon, 27 Nov 2000 08:39:18 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13296 for ; Mon, 27 Nov 2000 08:39:17 -0800 (PST) Received: by spyglass.cyclonecommerce.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 09:40:15 -0700 Received: from THARDINGLAPTOP (cx66967-a.phnx3.az.home.com [24.1.196.29]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XSXGF1XH; Mon, 27 Nov 2000 09:40:02 -0700 From: Terry Harding To: Dave Roberts , ietf-ediint@imc.org Message-ID: <007501c05890$88de5160$1dc40118@THARDINGLAPTOP> References: Subject: Re: AS2 XML requirements (was Re: HL7 Standards Process) Date: Mon, 27 Nov 2000 09:38:55 -0700 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.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > The later (and current) drafts do not specify that the payload MUST be > EDI, and I believe that since Terry took over authorship, generic EC > payloads are now mentioned, although they may not be highlighted by > example. Currently AS1 is under review by the IETF Area Directors. I will be forwarding the requested changes to the list for feedback. After we receive approval from the Area Directors the specification will be passed onto the IETF RFC Editors for their review and feedback.. ....Lets move EDIINT(AS1) into RFC status.... Terry Harding Cyclone Commerce From owner-ietf-ediint@mail.imc.org Mon Nov 27 12:13:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14100 for ; Mon, 27 Nov 2000 12:13:39 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA13363 for ietf-ediint-bks; Mon, 27 Nov 2000 08:41:08 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13359 for ; Mon, 27 Nov 2000 08:41:07 -0800 (PST) Received: by spyglass.cyclonecommerce.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 09:42:05 -0700 Received: from THARDINGLAPTOP (cx66967-a.phnx3.az.home.com [24.1.196.29]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XSXGF1X3; Mon, 27 Nov 2000 09:41:51 -0700 From: Terry Harding To: dick@8760.com, Dave Roberts , ietf-ediint@imc.org Message-ID: <007d01c05890$c9772ee0$1dc40118@THARDINGLAPTOP> References: Subject: Re: AS2 XML requirements (was Re: HL7 Standards Process) Date: Mon, 27 Nov 2000 09:40:43 -0700 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.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > However, there is no definitive text describing how non-rfc1767 types are > supported in AS1. The AS1 specification is tightly intertwined with > references to RFC 1767 and all examples are based on RFC 1767 payloads. Now is the time to add this definitive text to AS1. Terry Harding Cyclone Commerce From owner-ietf-ediint@mail.imc.org Mon Nov 27 12:14:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14316 for ; Mon, 27 Nov 2000 12:14:17 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA12959 for ietf-ediint-bks; Mon, 27 Nov 2000 08:32:24 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12942 for ; Mon, 27 Nov 2000 08:32:12 -0800 (PST) Received: by spyglass.cyclonecommerce.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 09:33:05 -0700 Received: from THARDINGLAPTOP (cx66967-a.phnx3.az.home.com [24.1.196.29]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XSXGF1WL; Mon, 27 Nov 2000 09:32:56 -0700 From: Terry Harding To: "Rishel,Wes" , "'Gunther Schadow'" Cc: dick@8760.com, Rik Drummond , Kepa Zubeldia , CLEM , Gary Crough , Beth Morrow , "David@Drummondgroup. Com" , GISB1@aol.com, ietf-ediint@imc.org Message-ID: <006901c0588f$8aa71ff0$1dc40118@THARDINGLAPTOP> References: <69A38F8986F3D211A6B00008C79121060969A348@mammoth.gartner.com> Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA) Date: Mon, 27 Nov 2000 09:31:47 -0700 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.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit See inline comments.. > > > Whatever happens to electronic signatures I would be > > delighted if AS2 > > > somehow got launched for the simple purpose of providing authentic, > > > encrypted B2B messages built on top of ubiquitous Internet > > protocols. I > > > would like to offer my enthusiastic support to enabling > > that by whatever > > > means works best. If that means that HL7 adopts it, so be > > it. (I just hope > > > we don't adapt it.) > > Many vendors are already supplying that capability. Several > > vendors are > > AS1 and AS2 compliant and create a transport independant > > signed, secured > > message which is transferred using SMTP or HTTP. > > The packaging remains the same for either transport and returned MDNs > > also follow the same format, transport independant. > > > > Terry Harding > > Cyclone Commerce > > Why do vendors frequently say the industry doesn't need a standard because > the vendor already has the function? I am not saying that we don't need standards, i was simple indicating that AS1 and AS2 already provide "simple purpose of providing authentic, encrypted B2B messages built on top of ubiquitous Internet protocols." quote, unquote... Many people already have false assumptions about EDIINT packaging only x12 or edifact data and was only trying to mention that EDIINT whether AS1 or AS2 provides authentic, encrypted B2B exchanges.. Terry Harding Cyclone Commerce From owner-ietf-ediint@mail.imc.org Mon Nov 27 12:51:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01636 for ; Mon, 27 Nov 2000 12:51:23 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA15362 for ietf-ediint-bks; Mon, 27 Nov 2000 09:01:19 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15355 for ; Mon, 27 Nov 2000 09:01:18 -0800 (PST) Received: by spyglass.cyclonecommerce.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 10:02:15 -0700 Received: from THARDINGLAPTOP (cx66967-a.phnx3.az.home.com [24.1.196.29]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XSXGF15A; Mon, 27 Nov 2000 10:02:11 -0700 From: Terry Harding Cc: ietf-ediint@imc.org Message-ID: <00fa01c05893$a0a99900$1dc40118@THARDINGLAPTOP> References: <39FEE816.AE3E1EAB@aurora.regenstrief.org> <01JW318160SM00004Q@mauve.mrochek.com> Subject: Review of EDIINT AS1 documents Date: Mon, 27 Nov 2000 10:01:03 -0700 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.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The following suggestions for changes to the EDIINT documents are as follows: Feedback is welcome and encouraged while changes are being made to the EDIINT documents. AD review of draft-ietf-ediint-req-08.txt: Comments from Area Director: I started to write a bunch of comments on this document, but then decided against it. The basic problem is that due to the substantial amount of time that has passed since this text was written (through no fault of the authors or the WG, I hasten to add), quite a bit of it seems dated. For example, a discussion of the use of VPNs in contrast to VANs would seem appropriate. Some of the symmetric cipher discussion is likely dated as well. But given that it is informational I see little harm in publishing it as-is. Note that it may end up with an IESG note pointing out the timing issue, however. AD review of draft-ietf-ediint-as1-11.txt: Comments from Area Director: Security considerations section. The word "Technologies" is capitalized when it should not be. The security considerations section is normally at the end of the document. It also should cover actual considerations rather than restating what the document is about. 1.0 Introduction, first paragraph. The impression is given here that this is purely an Applicability Statement. However, the very next paragraph then indicates otherwise. I suggest that this be clarified by referring to "the bulk of this document is an Applicability Statement", or something similar. 1.0 Introduction, second paragraph. There's a reference to section 3.1.8, which does not exist in the current document. I believe this is supposed to be 5.3.1. 1.0 Introduction, third paragraph. "Used" -> "used". 2.1. Reference to "standard" is premature. I suggest saying "document" instead. 2.2.2, first paragraph. "The functional requirements document, [9] "Requirements for Inter-operable Internet EDI" (can be found at www.ietf.org)," needs to be rewritten as a reference to an RFC-to-be. 2.2.2, first paragraph, "Provides" -> "provides". 2.2.2, second paragraph. Use of the term "transport" here is confusing. I suggest "environment" or something similar instead. 2.2.2, last paragraph. "Satisfy" -> "satisfy". 2.2.3, first bullet item. This section doesn't identify RFC 2298 as the mechanism being used to request EDI receipts. Suggest making it clear here rather than having to get further into the document to find out. 2.3.2, fourth bullet item. Now that PGP itself is an IETF standard, should reference RFC 2440 as well as RFC 2015 here and elsewhere in the document. 2.3.2, fourth bullet item. REQUIRES is not a keyword on the 2119 list; suggest rewording to use REQUIRED instead. 5.4.1, first paragraph. The phrase Using message, "partial", should be Using message/partial 5.4.1, second paragraph. The phrase "so that if fragmentation does occur," isn't right in this context. I suggest "so that if fragmentation is needed" instead. 5.4.1. Recommending that partial be used but saying that support for it is optional could lead to interoperability issues. I suggest that you add that in the absence of knowledge that the recipient supports partial it SHOULD NOT be used. 5.4.1, last paragraph. This is the biggie. Saying it is OK to use content-encoding in email even as an option just isn't acceptable. The problem is one of interoperability: An unextended agent that receives a message with, say, a content-encoding of gzip won't recognize the field for what it is and will cheerfully decode the base64 expecting to find text or whatever. Instead it will find garbage. Unfortunately, the only way to add compression to email in a backwards compatible way is to define new content-transfer-encodings. If this is a real issue this is the mechanism that needs to be pursued. Note that it is fine to recommend use of content-encoding if the transport is HTTP. Content-encoding is well-defined there and agents are required to check for it and handle it. Finally, this document defines new disposition-notification-options and a new MDN field received-content-mic. Both of these things require IANA registration. It is customary in standards track documents to do this with an appendix containing the appropriate registration forms. This needs to be done per sections 10.2 and 10.3 of RFC 2298. Terry Harding Cyclone Commerce From owner-ietf-ediint@mail.imc.org Mon Nov 27 14:24:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07396 for ; Mon, 27 Nov 2000 14:24:46 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA20322 for ietf-ediint-bks; Mon, 27 Nov 2000 10:37:39 -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 KAA20317 for ; Mon, 27 Nov 2000 10:37:37 -0800 (PST) Received: by mailman.8760.com from localhost (router,SLMail V3.2); Mon, 27 Nov 2000 12:37:03 -0600 Received: from gamma [192.168.21.133] by mailman.8760.com [192.168.21.90] (SLmail 3.2.3113) with SMTP id 6C8B375CB97F11D4BB0C0060974E38DD for plus 2 more; Mon, 27 Nov 2000 12:37:03 -0600 Reply-To: From: "Dick Brooks" To: "Terry Harding" , "Dave Roberts" , Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) Date: Mon, 27 Nov 2000 12:33:13 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <007d01c05890$c9772ee0$1dc40118@THARDINGLAPTOP> Importance: Normal X-SLUIDL: 5DCE232B-BFEC11D4-BB0C0060-974E38DD Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > supported in AS1. The AS1 specification is tightly intertwined with > > references to RFC 1767 and all examples are based on RFC 1767 payloads. > Now is the time to add this definitive text to AS1. I totally agree. For consistency I suggest using similar text as what appears in section 2 on page 6 of AS2. 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 Mon Nov 27 14:49:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16218 for ; Mon, 27 Nov 2000 14:49:45 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA23427 for ietf-ediint-bks; Mon, 27 Nov 2000 11:04:22 -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 LAA23423 for ; Mon, 27 Nov 2000 11:04:20 -0800 (PST) Received: by mailman.8760.com from localhost (router,SLMail V3.2); Mon, 27 Nov 2000 13:05:45 -0600 Received: from gamma [192.168.21.133] by mailman.8760.com [192.168.21.90] (SLmail 3.2.3113) with SMTP id 6C8B3778B97F11D4BB0C0060974E38DD for plus 2 more; Mon, 27 Nov 2000 13:05:45 -0600 Reply-To: From: "Dick Brooks" To: "Terry Harding" , "Dave Roberts" , Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) Date: Mon, 27 Nov 2000 13:01:54 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <013a01c058a4$173a6e40$1dc40118@THARDINGLAPTOP> Importance: Normal X-SLUIDL: 5DCE2350-BFEC11D4-BB0C0060-974E38DD Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I will be placing similar text inside of AS1. > > Terry Harding > Cyclone Commerce Thanks Terry. 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 Mon Nov 27 14:50:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16637 for ; Mon, 27 Nov 2000 14:50:38 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA23043 for ietf-ediint-bks; Mon, 27 Nov 2000 10:59:12 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23036 for ; Mon, 27 Nov 2000 10:59:10 -0800 (PST) Received: by spyglass.cyclonecommerce.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 12:00:07 -0700 Received: from THARDINGLAPTOP (cx66967-a.phnx3.az.home.com [24.1.196.29]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XSXGFFG4; Mon, 27 Nov 2000 12:00:02 -0700 From: Terry Harding To: dick@8760.com, Dave Roberts , ietf-ediint@imc.org Message-ID: <013a01c058a4$173a6e40$1dc40118@THARDINGLAPTOP> References: Subject: Re: AS2 XML requirements (was Re: HL7 Standards Process) Date: Mon, 27 Nov 2000 11:58:54 -0700 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.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > > supported in AS1. The AS1 specification is tightly intertwined with > > > references to RFC 1767 and all examples are based on RFC 1767 payloads. > > Now is the time to add this definitive text to AS1. > > I totally agree. For consistency I suggest using similar text as what > appears in section 2 on page 6 of AS2. > Dick, I will be placing similar text inside of AS1. Terry Harding Cyclone Commerce From owner-ietf-ediint@mail.imc.org Tue Nov 28 06:34:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20333 for ; Tue, 28 Nov 2000 06:34:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA14793 for ietf-ediint-bks; Tue, 28 Nov 2000 03:00:51 -0800 (PST) Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA14775 for ; Tue, 28 Nov 2000 03:00:46 -0800 (PST) Received: from dcsnet.demon.co.uk ([194.222.162.207]) by anchor-post-31.mail.demon.net with smtp (Exim 2.12 #1) id 140iWJ-000IME-0V; Tue, 28 Nov 2000 11:01:58 +0000 Received: from Delta by Delta with NETFAM id 001127; Tue, 28 Nov 2000 10:48:16 +0100 (BST) From: chris@dcsnet.demon.co.uk (Chris Davenport) Reply-To: chris@dcsnet.demon.co.uk Date: Tue, 28 Nov 2000 10:48:03 +0000 (GMT) Message-Id: <20001128.104803.001@dcsnet.demon.co.uk> To: ietf-ediint@imc.org, dick@8760.com Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) X-Mailer: DVMAIL Version 2.3 (144) 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 >> > supported in AS1. The AS1 specification is tightly intertwined with >> > references to RFC 1767 and all examples are based on RFC 1767 payloads. >> Now is the time to add this definitive text to AS1. > >I totally agree. For consistency I suggest using similar text as what >appears in section 2 on page 6 of AS2. This is not a simple change to AS1. I believe the text you are referring to is: (section 2, page 6 of AS2-07): In addition to the enveloping and MIME media type options defined in sections 4.2.x and 4.3.x of "MIME-based Secure EDI" [AS1], this specification enables the transport of payload objects containing other MIME media types. Implementors are to follow the appropriate specifications identified under "References" in [MIME-TYPES], for the type of object being transmitted. Putting this into AS1 would contradict RFC1767 which says that if the payload is not X12 or EDIFACT then it must be transported as application/EDI-consent. In effect RFC1767 would need to be rendered obsolete and I think this would involve more that the simple addition of a few paragraphs to AS1. Is this what you had in mind? I'm quite happy to see the EDI-consent sub-type disappear. As Gunther was at pains to point out a couple of years ago, it raises important interoperability issues. How does an AS1 application know what to do with a payload that arrives as EDI-consent? It doesn't know whether to pass it to an XML parser, an HL7 application or whatever. The answer given at the time was that it would be decided by a trading partner agreement but this has always seemed unsatisfactory to me. The text quoted above also seems to imply that AS1 is restricted in the types of payloads that it can transport. As I understand it the only "restriction" over and above AS2 is that binary types must have a mail-safe content transfer encoding applied (eg. base64). Am I reading this wrong? Regards, Chris. -- Chris Davenport chris@dcsnet.demon.co.uk Davros Computer Systems From owner-ietf-ediint@mail.imc.org Tue Nov 28 07:53:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18769 for ; Tue, 28 Nov 2000 07:53:21 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA22840 for ietf-ediint-bks; Tue, 28 Nov 2000 04:19:14 -0800 (PST) Received: from gateway.reims.net (firewall-user@gateway.reims.net [194.75.234.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA22833 for ; Tue, 28 Nov 2000 04:19:11 -0800 (PST) Received: (from uucp@localhost) by gateway.reims.net (8.9.3/8.9.3) id MAA23649 for ; Tue, 28 Nov 2000 12:27:04 GMT Received: from smtpgate.saa-cons.co.uk(10.10.10.182) by gateway.reims.net via smap (3.2) id xma023617; Tue, 28 Nov 00 12:26:37 GMT Received: from olympus.saa-cons.co.uk (olympus.saa-cons.co.uk [10.1.11.12]) by smtpgate.saa-cons.co.uk (8.8.8/8.8.8) with ESMTP id MAA12037 for ; Tue, 28 Nov 2000 12:34:11 GMT (envelope-from djr@saa-cons.co.uk) Received: from localhost (djr@localhost) by olympus.saa-cons.co.uk (AIX4.3/8.9.3/8.7) with SMTP id MAA28866 for ; Tue, 28 Nov 2000 12:18:04 GMT Date: Tue, 28 Nov 2000 12:18:04 +0000 (GMT) From: Dave Roberts Reply-To: Dave Roberts To: ietf-ediint@imc.org Subject: AS1 ties to EDI (was RE: AS2 XML requirements) In-Reply-To: Message-ID: 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: On Thu, 23 Nov 2000, Dick Brooks wrote: > However, there is no definitive text describing how non-rfc1767 types are > supported in AS1. The AS1 specification is tightly intertwined with > references to RFC 1767 and all examples are based on RFC 1767 payloads. Right. Terry, is it possible to change the text within the Security Considerations paragraph and the Introduction? I don't know if that's ok at this late stage. Changing most of the EDI references to "EC or EDI" should set the tone for the remainder of the document. > it to up to the individual AS1 vendors to decide how non-RFC1767 payloads > are supported in their products and this opens the door to interoperability > issues. I see your point. There is no clear guidance on what MIME type is to be used for non-EDI data. Whilst some may use the IANA MIME type, others may not. > AS2 contains definitive text describing support for ANY MIME media type. I > believe the AS1 authors should consider adding language similar to what is > contained in AS2. Right, so an EDI payload uses the MIME types laid down in RFC 1767. Non-EDI payloads should use the MIME types as laid down by the IANA. Perhaps also a statement on the MIME types that MUST be supported (i.e. those specified by RFC1767), and a statement that any other MIME type is up to the vendor to handle. Or would that be too liberal? - Dave. -- Dave Roberts Servicing the Online Organisation Principal Technical Consultant http://www.saaconsultants.com/ SAA Consultants Ltd Tel: +44 1752 606000 Plymouth, UK. Fax: +44 1752 606838 From owner-ietf-ediint@mail.imc.org Tue Nov 28 09:20:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22289 for ; Tue, 28 Nov 2000 09:20:38 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA26405 for ietf-ediint-bks; Tue, 28 Nov 2000 05:40:46 -0800 (PST) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA26397 for ; Tue, 28 Nov 2000 05:40:44 -0800 (PST) Received: from apollo (user-33qt1uo.dialup.mindspring.com [199.174.135.216]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with SMTP id IAA27116; Tue, 28 Nov 2000 08:42:05 -0500 (EST) From: "Dick Brooks" To: , Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) Date: Tue, 28 Nov 2000 07:45:20 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <20001128.104803.001@dcsnet.demon.co.uk> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Chris, see comments inline. >Putting this into AS1 would contradict RFC1767 which says that if the >payload is not X12 or EDIFACT then it must be transported as >application/EDI-consent. In effect RFC1767 would need to be rendered >obsolete and I think this would involve more that the simple addition >of a few paragraphs to AS1. Is this what you had in mind? I worked on the development of RFC 1767 and was at the IETF meeting in Seattle when Mike Odell suggested EDI-consent. The intent behind EDI-consent was to provide a means to identify proprietary EDI formats/syntax (e.g. flat files). I don't believe the suggested inclusion of wording from AS2 will render RFC 1767 obsolete. The RFC1767 defined media type of EDI-consent would still be "available" to those parties interested in classifying their payloads as "EDI" as opposed to "text/plain; charset=us-ascii", in the case of an ascii flat file. AS1 needs to be "reworked" to be become a "generic" secure transport standard which supports all MIME media types as payloads. Contradictory statements, such as the one you cited would be eliminated and some non-RFC1767 examples should be included (perhaps an XML example would help). >I'm quite happy to see the EDI-consent sub-type disappear. As Gunther >was at pains to point out a couple of years ago, it raises important >interoperability issues. How does an AS1 application know what to do >with a payload that arrives as EDI-consent? It doesn't know whether >to pass it to an XML parser, an HL7 application or whatever. The answer >given at the time was that it would be decided by a trading partner >agreement but this has always seemed unsatisfactory to me. The answer is implied in the name; two parties agree beforehand and have a mutual understanding of the semantics. The "message processing engine" within their message handling products must process EDI-consent, text/xml, image/jpeg, etc. data properly for each trading partner relationship. >The text quoted above also seems to imply that AS1 is restricted in the >types of payloads that it can transport. As I understand it the only >"restriction" over and above AS2 is that binary types must have a >mail-safe content transfer encoding applied (eg. base64). >Am I reading this wrong? At the time AS2 was originally created the "then current" AS1 draft (draft-ietf-ediint-as1-09.txt) did not contain explicit support for non-RFC1767 MIME types. There is a generic statement in section 2.1 of AS1 indicating support for all electronic commerce, but this could be interpreted to indicate AS1's support for the EDI-consent type as opposed to other, non-RFC1767 media types. By adding explicit support for non-RFC1767 types AS1 will take on a broader context, that of a secure transport loop for any type of payload. AS2 already defines a secure transport loop for all MIME media types, this inclusion will align the two specs. Dick Brooks http://www.8760.com/ From owner-ietf-ediint@mail.imc.org Tue Nov 28 10:11:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14669 for ; Tue, 28 Nov 2000 10:11:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA03041 for ietf-ediint-bks; Tue, 28 Nov 2000 06:36:12 -0800 (PST) Received: from smtpproxy1.mitre.org (mb-20-100.mitre.org [129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA03034 for ; Tue, 28 Nov 2000 06:36:08 -0800 (PST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id JAA00043 for ; Tue, 28 Nov 2000 09:36:58 -0500 (EST) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id JAA19851 for ; Tue, 28 Nov 2000 09:36:57 -0500 (EST) Received: from dhcp-145-238.mitre.org (128.29.145.238) by mailhub1.mitre.org with SMTP id 4960358; Tue, 28 Nov 2000 09:36:05 -0500 Message-ID: <3A23C350.4B57CB42@mitre.org> Date: Tue, 28 Nov 2000 09:38:08 -0500 From: "Kit (Christopher) Lueder" Organization: The MITRE Corporation X-Mailer: Mozilla 4.75 [en]C-20000818M (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 CC: ietf-ediint@imc.org Subject: Re: AS2 XML requirements (was Re: HL7 Standards Process) References: 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 I don't get it. Why should we change AS1 by saying that "all examples are based on RFC 1767 payloads"? Are we trying to squash extensibility? Kit. Dick Brooks wrote: > > > > supported in AS1. The AS1 specification is tightly intertwined with > > > references to RFC 1767 and all examples are based on RFC 1767 payloads. > > Now is the time to add this definitive text to AS1. > > I totally agree. For consistency I suggest using similar text as what > appears in section 2 on page 6 of AS2. Chris Davenport wrote: > I'm quite happy to see the EDI-consent sub-type disappear. As Gunther > was at pains to point out a couple of years ago, it raises important > interoperability issues. Ouch. That would make edi-int gradually become useless and irrelevant, I think, as XML and other internet technologies evolve. The problem that needs to be solved is that there is no good extensibility mechanism in edi-int. Kit. -- _/ _/ Kit C. J. Lueder _/ _/ _/ The MITRE Corp. Tel: 703-883-5205 _/_/_/ _/ _/_/_/ 1820 Dolley Madison Bl Cell: 703-577-2463 _/ _/ _/ _/ Mailstop W658 FAX: 703-883-3383 _/ _/ _/ _/ McLean, VA 22102 Mail: kit@mitre.org Worse than an unanswered question is an unquestioned answer. From owner-ietf-ediint@mail.imc.org Tue Nov 28 11:40:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23786 for ; Tue, 28 Nov 2000 11:40:49 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA11047 for ietf-ediint-bks; Tue, 28 Nov 2000 08:01:44 -0800 (PST) Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11041 for ; Tue, 28 Nov 2000 08:01:43 -0800 (PST) Received: from dcsnet.demon.co.uk ([194.222.162.207]) by anchor-post-32.mail.demon.net with smtp (Exim 2.12 #1) id 140nDh-000IR1-0W; Tue, 28 Nov 2000 16:03:04 +0000 Received: from Delta by Delta with NETFAM id 001130; Tue, 28 Nov 2000 15:48:06 +0100 (BST) From: chris@dcsnet.demon.co.uk (Chris Davenport) Reply-To: chris@dcsnet.demon.co.uk Date: Tue, 28 Nov 2000 15:47:55 +0000 (GMT) Message-Id: <20001128.154755.001@dcsnet.demon.co.uk> To: dick@8760.com, ietf-ediint@imc.org Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) X-Mailer: DVMAIL Version 2.3 (144) 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 >AS1 needs to be "reworked" to be become a "generic" secure >transport >standard which supports all MIME media types as payloads. Contradictory >statements, >such as the one you cited would be eliminated and some non-RFC1767 examples >should >be included (perhaps an XML example would help). > Dick, Thanks for the explanation. I look forward to reading the revised AS1/AS2 drafts in due course. Regards, Chris. -- Chris Davenport chris@dcsnet.demon.co.uk Davros Computer Systems From owner-ietf-ediint@mail.imc.org Tue Nov 28 11:57:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00228 for ; Tue, 28 Nov 2000 11:57:49 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA13748 for ietf-ediint-bks; Tue, 28 Nov 2000 08:21:22 -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 IAA13739 for ; Tue, 28 Nov 2000 08:21:19 -0800 (PST) Received: by mailman.8760.com from localhost (router,SLMail V3.2); Tue, 28 Nov 2000 10:22:51 -0600 Received: from gamma [192.168.21.133] by mailman.8760.com [192.168.21.90] (SLmail 3.2.3113) with SMTP id 6C8B3999B97F11D4BB0C0060974E38DD for plus 2 more; Tue, 28 Nov 2000 10:22:51 -0600 Reply-To: From: "Dick Brooks" To: "Kit \(Christopher\) Lueder" , "Dick Brooks" Cc: Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process) Date: Tue, 28 Nov 2000 10:18: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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3A23C350.4B57CB42@mitre.org> X-SLUIDL: 5DCE25EF-BFEC11D4-BB0C0060-974E38DD Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kit, Nobody is suggesting that AS1 be changed to say that all examples be based on RFC1767. The problem is that all AS1 examples ARE based on RFC 1767. I, and others (yourself included, I presume), are advocating the expansion of AS1 to explicitly include support for other MIME types. 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 Kit (Christopher) > Lueder > Sent: Tuesday, November 28, 2000 8:38 AM > To: dick > Cc: ietf-ediint@imc.org > Subject: Re: AS2 XML requirements (was Re: HL7 Standards Process) > > > I don't get it. Why should we change AS1 by saying that "all examples > are based on RFC 1767 payloads"? Are we trying to squash extensibility? > Kit. > > Dick Brooks wrote: > > > > > > supported in AS1. The AS1 specification is tightly intertwined with > > > > references to RFC 1767 and all examples are based on RFC > 1767 payloads. > > > Now is the time to add this definitive text to AS1. > > > > I totally agree. For consistency I suggest using similar text as what > > appears in section 2 on page 6 of AS2. > > > Chris Davenport wrote: > > I'm quite happy to see the EDI-consent sub-type disappear. As Gunther > > was at pains to point out a couple of years ago, it raises important > > interoperability issues. > > Ouch. That would make edi-int gradually become useless and irrelevant, I > think, as XML and other internet technologies evolve. The problem that > needs to be solved is that there is no good extensibility mechanism in > edi-int. > Kit. > > -- > _/ _/ Kit C. J. Lueder > _/ _/ _/ The MITRE Corp. Tel: 703-883-5205 > _/_/_/ _/ _/_/_/ 1820 Dolley Madison Bl Cell: 703-577-2463 > _/ _/ _/ _/ Mailstop W658 FAX: 703-883-3383 > _/ _/ _/ _/ McLean, VA 22102 Mail: kit@mitre.org > Worse than an unanswered question is an unquestioned answer. > From owner-ietf-ediint@mail.imc.org Tue Nov 28 12:24:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07736 for ; Tue, 28 Nov 2000 12:24:26 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA20065 for ietf-ediint-bks; Tue, 28 Nov 2000 08:48:36 -0800 (PST) Received: from smtpproxy1.mitre.org (mb-20-100.mitre.org [129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20060 for ; Tue, 28 Nov 2000 08:48:33 -0800 (PST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id LAA28124 for ; Tue, 28 Nov 2000 11:49:28 -0500 (EST) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id LAA16038 for ; Tue, 28 Nov 2000 11:49:27 -0500 (EST) Received: from dhcp-145-238.mitre.org (128.29.145.238) by mailhub1.mitre.org with SMTP id 4963089; Tue, 28 Nov 2000 11:48:33 -0500 Message-ID: <3A23E25C.24C3BA27@mitre.org> Date: Tue, 28 Nov 2000 11:50:36 -0500 From: "Kit (Christopher) Lueder" Organization: The MITRE Corporation X-Mailer: Mozilla 4.75 [en]C-20000818M (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-ediint@imc.org Subject: Re: AS2 XML requirements References: 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 Sorry, I guess I read that as the opposite of the authors' intention. Yes, I advocate expanding the types. I think something like an "XML-consent" MIME type (or "edi-XMLconsent" if you prefer) would provide a general mechanism of carrying XML content that the recipient knows needs to be handed to the XML parser. I consider XML to be a type of EDI in the general sense (not the X12/Edifact sense), since it is structured data, computer processable. Yes, I know that HL7 can be encoded in XML, but if you are happy using the edi-hl7 tag for HL7 XML, that is fine too. It seems like a burden on you to figure out which encoding you are using for HL7, but if you aren't worried about it, I'm not either. Personally, I would have a tag of "edi-hl7XML"... Kit. Dick Brooks wrote: > > Kit, > > Nobody is suggesting that AS1 be changed to say that all examples be based > on RFC1767. The problem is that all AS1 examples ARE based on RFC 1767. I, > and others (yourself included, I presume), are advocating the expansion of > AS1 to explicitly include support for other MIME types. > > 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----- > > I don't get it. Why should we change AS1 by saying that "all examples > > are based on RFC 1767 payloads"? Are we trying to squash extensibility? > > Kit. > > > > Dick Brooks wrote: > > > > > > > > supported in AS1. The AS1 specification is tightly intertwined with > > > > > references to RFC 1767 and all examples are based on RFC > > 1767 payloads. > > > > Now is the time to add this definitive text to AS1. > > > > > > I totally agree. For consistency I suggest using similar text as what > > > appears in section 2 on page 6 of AS2. > > > > > > Chris Davenport wrote: > > > I'm quite happy to see the EDI-consent sub-type disappear. As Gunther > > > was at pains to point out a couple of years ago, it raises important > > > interoperability issues. > > > > Ouch. That would make edi-int gradually become useless and irrelevant, I > > think, as XML and other internet technologies evolve. The problem that > > needs to be solved is that there is no good extensibility mechanism in > > edi-int. > > Kit. > > > > -- > > _/ _/ Kit C. J. Lueder > > _/ _/ _/ The MITRE Corp. Tel: 703-883-5205 > > _/_/_/ _/ _/_/_/ 1820 Dolley Madison Bl Cell: 703-577-2463 > > _/ _/ _/ _/ Mailstop W658 FAX: 703-883-3383 > > _/ _/ _/ _/ McLean, VA 22102 Mail: kit@mitre.org > > Worse than an unanswered question is an unquestioned answer. > > -- _/ _/ Kit C. J. Lueder _/ _/ _/ The MITRE Corp. Tel: 703-883-5205 _/_/_/ _/ _/_/_/ 1820 Dolley Madison Bl Cell: 703-577-2463 _/ _/ _/ _/ Mailstop W658 FAX: 703-883-3383 _/ _/ _/ _/ McLean, VA 22102 Mail: kit@mitre.org Worse than an unanswered question is an unquestioned answer. From owner-ietf-ediint@mail.imc.org Tue Nov 28 12:35:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10947 for ; Tue, 28 Nov 2000 12:35:06 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA20820 for ietf-ediint-bks; Tue, 28 Nov 2000 09:01:19 -0800 (PST) Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20809 for ; Tue, 28 Nov 2000 09:01:18 -0800 (PST) Received: from dcsnet.demon.co.uk ([194.222.162.207]) by anchor-post-34.mail.demon.net with smtp (Exim 2.12 #1) id 140o9M-000Cbb-0Y for ietf-ediint@imc.org; Tue, 28 Nov 2000 17:02:39 +0000 Received: from Delta by Delta with NETFAM id 001131; Tue, 28 Nov 2000 16:43:26 +0100 (BST) From: chris@dcsnet.demon.co.uk (Chris Davenport) Reply-To: chris@dcsnet.demon.co.uk Date: Tue, 28 Nov 2000 16:43:15 +0000 (GMT) Message-Id: <20001128.164315.001@dcsnet.demon.co.uk> To: ietf-ediint@imc.org Subject: [AS2] minor typographical errors X-Mailer: DVMAIL Version 2.3 (144) 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 Here are some (trivial) typographical errors (features :-)) of AS2-07, noticed during a recent reading: 1. The string "AS 2" is often used where "AS2" would be more consistent. 2. Bottom of page 4 "For MDNS, ..." should read "For MDNs, ..." 3. Page 5, para 2: "referred to as "generalized receipts." (there is a missing close quote). 4. Page 7, para 2: "The term "Receipts" is here used". "Receipts" should not be capitalised. 5. Page 19, para 3: What is a "P.A.I.N. requirement"? I think this needs some kind of reference or at least an expansion of the acronym. 6. Example C.1 uses the rsa-md5 signature algorithm. This is correct, but according to AS1 SHA1 is RECOMMENDED (though AS2 seems silent on this point). Also the value "rsa-md5" appears to be historical and should be just "md5" anyway (from AS1 page 14). Deep joy, Chris. -- Chris Davenport chris@dcsnet.demon.co.uk Davros Computer Systems From owner-ietf-ediint@mail.imc.org Tue Nov 28 13:43:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03623 for ; Tue, 28 Nov 2000 13:43:51 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA25978 for ietf-ediint-bks; Tue, 28 Nov 2000 09:44:35 -0800 (PST) Received: from smtpproxy1.mitre.org (mb-20-100.mitre.org [129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25971 for ; Tue, 28 Nov 2000 09:44:31 -0800 (PST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id MAA09548; Tue, 28 Nov 2000 12:45:13 -0500 (EST) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id MAA26649; Tue, 28 Nov 2000 12:45:12 -0500 (EST) Received: from dhcp-145-238.mitre.org (128.29.145.238) by mailhub1.mitre.org with SMTP id 4964056; Tue, 28 Nov 2000 12:44:19 -0500 Message-ID: <3A23EF6F.51BC6E4D@mitre.org> Date: Tue, 28 Nov 2000 12:46:23 -0500 From: "Kit (Christopher) Lueder" Organization: The MITRE Corporation X-Mailer: Mozilla 4.75 [en]C-20000818M (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: chris@dcsnet.demon.co.uk CC: ietf-ediint@imc.org Subject: Re: [AS2] minor typographical errors References: <20001128.164315.001@dcsnet.demon.co.uk> 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 PAIN is Privacy, Authentication, Integrity, Non-repudiaton Chris Davenport wrote: > > Here are some (trivial) typographical errors (features :-)) of AS2-07, > noticed during a recent reading: > > 1. The string "AS 2" is often used where "AS2" would be more consistent. > > 2. Bottom of page 4 "For MDNS, ..." should read "For MDNs, ..." > > 3. Page 5, para 2: "referred to as "generalized receipts." > (there is a missing close quote). > > 4. Page 7, para 2: "The term "Receipts" is here used". "Receipts" > should not be capitalised. > > 5. Page 19, para 3: What is a "P.A.I.N. requirement"? I think this > needs some kind of reference or at least an expansion of the > acronym. > > 6. Example C.1 uses the rsa-md5 signature algorithm. This is correct, > but according to AS1 SHA1 is RECOMMENDED (though AS2 seems silent on > this point). Also the value "rsa-md5" appears to be historical and > should be just "md5" anyway (from AS1 page 14). > > Deep joy, > > Chris. > > -- > Chris Davenport chris@dcsnet.demon.co.uk > Davros Computer Systems -- _/ _/ Kit C. J. Lueder _/ _/ _/ The MITRE Corp. Tel: 703-883-5205 _/_/_/ _/ _/_/_/ 1820 Dolley Madison Bl Cell: 703-577-2463 _/ _/ _/ _/ Mailstop W658 FAX: 703-883-3383 _/ _/ _/ _/ McLean, VA 22102 Mail: kit@mitre.org Worse than an unanswered question is an unquestioned answer. From owner-ietf-ediint@mail.imc.org Tue Nov 28 14:13:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12099 for ; Tue, 28 Nov 2000 14:13:23 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA29142 for ietf-ediint-bks; Tue, 28 Nov 2000 10:35:16 -0800 (PST) Received: from gateway.reims.net (firewall-user@gateway.reims.net [194.75.234.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29136 for ; Tue, 28 Nov 2000 10:35:12 -0800 (PST) Received: (from uucp@localhost) by gateway.reims.net (8.9.3/8.9.3) id SAA25542 for ; Tue, 28 Nov 2000 18:43:05 GMT Received: from smtpgate.saa-cons.co.uk(10.10.10.182) by gateway.reims.net via smap (3.2) id xma025540; Tue, 28 Nov 00 18:42:54 GMT Received: from olympus.saa-cons.co.uk (olympus.saa-cons.co.uk [10.1.11.12]) by smtpgate.saa-cons.co.uk (8.8.8/8.8.8) with ESMTP id SAA14166 for ; Tue, 28 Nov 2000 18:50:29 GMT (envelope-from djr@saa-cons.co.uk) Received: from localhost (djr@localhost) by olympus.saa-cons.co.uk (AIX4.3/8.9.3/8.7) with SMTP id SAA17660 for ; Tue, 28 Nov 2000 18:34:26 GMT Date: Tue, 28 Nov 2000 18:34:26 +0000 (GMT) From: Dave Roberts To: ietf-ediint@imc.org Subject: [AS2] some more minor typographical errors In-Reply-To: <20001128.164315.001@dcsnet.demon.co.uk> Message-ID: 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: Oh, that reminds me:- General: DUNS number is sometimes typed as D-U-N-S or DUNS P19, Example of a GISB data exchange... last line of paragraph says: "the contents of this post appear as folloows:": folloows -> follows. P20, the bottom of the GISB example, missing dashes to indicate final MIME boundary. ----87453838942833 -> ----87453838942833-- General: some of the formatting of the document held at IETF seems to be inconsistent. Some paragraphs have line widths of about 70 chars, and others only 50. Sometimes it is different within the same paragraph. I don't know if formatting is an issue as far as standards submission in concerned, but it makes it a little harder to read. IMHO. - Dave. -- Dave Roberts Servicing the Online Organisation Principal Technical Consultant http://www.saaconsultants.com/ SAA Consultants Ltd Tel: +44 1752 606000 Plymouth, UK. Fax: +44 1752 606838 From owner-ietf-ediint@mail.imc.org Tue Nov 28 14:42:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20085 for ; Tue, 28 Nov 2000 14:42:21 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA28658 for ietf-ediint-bks; Tue, 28 Nov 2000 10:24:45 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA28654 for ; Tue, 28 Nov 2000 10:24:43 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id eASIHjD27802 for ; Tue, 28 Nov 2000 10:17:45 -0800 (PST) Received: from iplanet.com ([192.18.113.4]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id G4QZ6R00.PO6 for ; Tue, 28 Nov 2000 10:25:39 -0800 Message-ID: <3A23F92D.4583ADD2@iplanet.com> Date: Tue, 28 Nov 2000 10:27:57 -0800 From: Stacy Thurston Reply-To: stacyt@iplanet.com Organization: The Internet X-Mailer: Mozilla 4.75 [en]C-AOLNSCP (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ediint@imc.org Subject: AS2 = Email & HTTP References: Content-Type: multipart/alternative; boundary="------------3AE2813E39B2072F4A2529C0" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------3AE2813E39B2072F4A2529C0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, ---------------------------------------------------- Question: Could AS2 be restated as: Email messages sent/received using HTTP protocol? AS2 = Email + Security + Web server + Web browser Example, To Send: 1. Use all the normal email standards to create the email message file, 2. then use the an HTTP "POST" to send the file. 3. Then once recieved, use all the normal email standards to "decode" the email message file. 4. To know what kind of file you have received, check the MIME type (e.g. EDIX12-850 means you have received an X12-850 purchase order document), then process appropriately. ** If this is the case, GREAT! This allows us to use all our current programs (technologies) to securely and confidentially: send, receive and process documents through firewalls that have an HTTP opening. Use: 1. Our email (SMTP) client to create "email file messages" 2. Our batch oreinted "Browser" client to send the "email file messages" using HTTP POST. 3. Our web server (HTTP) to receive documents 4. * Here we need to write a plugin or cgi to pass the file to the email client. 5. Our email (POP) client would decode the "email file messages" as it would any email message. 6. We already have the programs to process the files based on sender, receiver and MIME type. 7. Our email client can create an "MDN file message". 8. * Here we need to write a program to pass the "MDN file message" to the batch oreinted "Browser" client that would send the "MDN file message" using HTTP POST. 9. Repeat steps 3, 4, 5 and 6 *** And all of our current security programs remain the same (e.g. SMIME, digital signatures and encryption). File - Email client - Batch web browser - Internet - Web server - Email client - File This will be easy for us to create an AS2 peer to peer system :) Thanks for the conversations, Stacy Thurston, iPlanet (SUN|Netscape) Product Manager http://www.iplanet.com/products/ecommerce/ecxpert/ecxpert.html [Image] ---------------------------------------------------- Background: I work with a product dedicated to sending & receiving documents. We add communication "agents" (programs/connectors) to do the sending and receiving. Example: * "Browser" client to send documents * HTTP server to receive documents * POP client to get documents * FTP client to get and put documents We have found that: 1. Email messaging standards are adequate to send/receive/process documents: * SMTP/POP, multipart, SMIME, digital signatures & RSA encryption * Note, mulitpart is rich enough to allow us to tell what kind of file is being sent to us, i.e. MIME type is the document type. 2. And the HTTP protocol is adequate for file transport. ---------------------------------------------------- eom --------------3AE2813E39B2072F4A2529C0 Content-Type: multipart/related; boundary="------------72F2D468D1CE1EB1F05D5DEE" --------------72F2D468D1CE1EB1F05D5DEE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all,

----------------------------------------------------
Question:

Could AS2 be restated as: Email messages sent/received using HTTP protocol?

AS2  =  Email + Security + Web server + Web browser

Example, To Send:
1. Use all the normal email standards to create the email message file,
2. then use the an HTTP "POST" to send the file.
3. Then once recieved, use all the normal email standards to "decode" the email message file.
4. To know what kind of file you have received, check the MIME type (e.g. EDIX12-850 means you have received an X12-850 purchase order document), then process appropriately.

** If this is the case, GREAT!
This allows us to use all our current programs (technologies) to securely and confidentially: send, receive and process documents through firewalls that have an HTTP opening.

Use:
1. Our email (SMTP) client to create "email file messages"
2. Our batch oreinted "Browser" client to send the "email file messages" using HTTP POST.
3. Our web server (HTTP) to receive documents
4. * Here we need to write a plugin or cgi to pass the file to the email client.
5. Our email (POP) client would decode the "email file messages" as it would any email message.
6. We already have the programs to process the files based on sender, receiver and MIME type.
7. Our email client can create an "MDN file message".
8. * Here we need to write a program to pass the "MDN file message" to the batch oreinted "Browser" client that would send the "MDN file message" using HTTP POST.
9. Repeat steps 3, 4, 5 and 6

*** And all of our current security programs remain the same (e.g. SMIME, digital signatures and encryption).

File - Email client - Batch web browser - Internet - Web server - Email client - File

This will be easy for us to create an AS2 peer to peer system :)

Thanks for the conversations,
Stacy Thurston, iPlanet (SUN|Netscape) Product Manager
http://www.iplanet.com/products/ecommerce/ecxpert/ecxpert.html

----------------------------------------------------
Background:

I work with a product dedicated to sending & receiving documents.  We add communication "agents" (programs/connectors) to do the sending and receiving.

Example:
* "Browser" client to send documents
* HTTP server to receive documents
* POP client to get documents
* FTP client to get and put documents

We have found that:
1. Email messaging standards are adequate to send/receive/process documents:
* SMTP/POP, multipart, SMIME, digital signatures & RSA encryption
* Note, mulitpart is rich enough to allow us to tell what kind of file is being sent to us, i.e. MIME type is the document type.
2. And the HTTP protocol is adequate for file transport.

----------------------------------------------------
eom --------------72F2D468D1CE1EB1F05D5DEE Content-Type: image/jpeg Content-ID: Content-Disposition: inline; filename="C:\TEMP\nsmailUM.jpeg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR CAHNAakDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiuT8V+INQ0rWdLsLKWOFLq3uJpJDpVxftmNoQAE hZSoPmnLHI4A71Je+K/7G1iLSryKe9u5IrdUSxtMb5pFuWyMyHCn7MwweEyCzlSSgB1FFce3 xI0T+2LzS4Vnubq389Ujt2ikknlhVmeJIg/mhvkcAsiqSvDHcu6TVPiN4c0m3v7ia5klgs7c T+ZAnmLNkRHbGQcE4uLc5OFPnLgnD7QDrKK8/ufiQl3p15eaMsDrbaVqN1IkrLLsntxAyLvi dkZSs2TtY9QMghhXoFABRRRQAUUUUAFFFef+HfF+rajoNprF9dQeXcfYlaFNDuINr3EsaALJ LLtlUbmG5M4yG5GFYA9Aori774maNYFlmtrtD9ont0MzwW6ytDIY5SjzSIrBTs6HneMZKyBL kvj/AEKKwa9aSfyP3bxnyiDLC8Bn85VPPliNZTkgEmGRQCwAIB1FFcnN8QtGt/Eo0WYSI7XC 2yXBmg2SSMQoCJ5nmuBITGWVCFZXBI2MRJ4F8SXnifR5Ly9jgjkX7PgQqQP3lpBO3Un+KZgP YDvyQDqKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKAKcmmwy6zbaozSefb281uigjaVkaNmJ4znMS4 57nr2p3HhuzufEcGuPJOLqHy9qBhsOxLhBkYz0upM89l9DnYooAx7Pw+ljqLXEOoXwtTLJOl hvUQpLIWZ2yFDtlnc7WZlBbIA2rtz5vAWjyWdtbxGe2a2u2u4poCiurE5RD8uDHGVh2oQV/0 eEEEJiuP0C/vJP2lfFVm93O1qmlRbYTISi4EBGF6cGSQj/fb1NesUAcn/wAK/wBNYakZr7Up pNRt7mC4llmVmPnxwJIw+XAOLdCABtXJAAXaq9ZRRQAUUUUAFFFFABWOnhuzj8OadoYkn+y6 f9l8pyw3t9ndHTccY5Ma5wB1OMVsUUAc+3hOBFiay1G+sbqKW6kW5h8pn23EvnSpiRGXaX24 +XcNgGeTmxN4Y0u4vLa4uIPtHkWjWmy4/fCVCMAyF8s7BTIoJJ4mlznea2K8n+FF/eXfj74l RXN3PNHFqo8tJJCwT55k4B6fKiL9EUdAKAOsh+H+m26QxRX2pLClxBeSxiZQLm6iZD58p25d 28tdwJ2k5baH+atTw54bs/DFg9nZSTyRt5WTMwJ/dwRwL0A/hhUn3J7cDYooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKAOT0258VazFc3dvqejW0C3t1bxxSaXLKwWKeSIEsLhQSQme g61c+x+MP+g7of8A4Jpv/kqs/StT/sTwFrmreT532G71e58rdt37Lq4bbnBxnGM4Nc38PfFv ijVtD8RWlxNHq2tWVlbXtnLJGkKyNc2olSEqu0YVhjdnnd/DigDtPsfjD/oO6H/4Jpv/AJKo +x+MP+g7of8A4Jpv/kquH8EeML3WdTt9LuvE99a+IUtHW70jXNKjQtL5aMJIvLEZ2gknazFm TPC43VueFNR1yTxrqGlPrEmu6TZWSR3d/JbxRCLUA3zRJ5aqCNhyy/OVOAWB4IBufY/GH/Qd 0P8A8E03/wAlUfY/GH/Qd0P/AME03/yVXn99421bTvFuoad4j12+8NyPqBGlSy6dFLps9urR hQz48wswYliJFC7uSpG2tj/hbln/AMJR/ZX2ODyf7b/sX/j9H2vzMY83yNv+p3/Lu3574zxQ B1H2Pxh/0HdD/wDBNN/8lUfY/GH/AEHdD/8ABNN/8lVy+h/FC81Kz8N6nfaDBZaRrt29lFcp fmV4ZgXVFaPyh99kIBBIHUkd8uT44QsbhoNJtEgW3ub21nvNTEC3tvHIY0MQ8st5rssmI2AI 29TngA7z7H4w/wCg7of/AIJpv/kqj7H4w/6Duh/+Cab/AOSqy/DHjubxZ4ivLKw0qOPT7S3t Lh7me6IlK3EHmoBEEIyOh+f3Gelcf4o8banpviLx3FJ4h1Kwg0i3t206O10+OWLzZIMhZXML 7Q0m0Dcy/eIB44APRPsfjD/oO6H/AOCab/5Ko+x+MP8AoO6H/wCCab/5Krl9e+J1x4Y+x2Gp adYpq40T+1L1Li/FtHvHBhhO2TfIWD4X0A5Pa5YfES716/uYvD3h2S+gtLeyuLgS3aQTlblP MAjQgoxVDk7pE5yB2JANz7H4w/6Duh/+Cab/AOSqPsfjD/oO6H/4Jpv/AJKrg/EvxrttKGrx pZxhLS9m0xfLv0F75qxn96IWjZRFvG3eSfUqfu1oQ/FaHT9GupdWspIpLfQrXVrVpJw7Xyyq FOfLjCxkTMsecDO7cFCigDrPsfjD/oO6H/4Jpv8A5Ko+x+MP+g7of/gmm/8AkquPsPjClxrF tYXmkwWkkmqppE1t/aKyXcU5UBn8oLhoRJlN4fnGcZ+WvUKAOf8AsfjD/oO6H/4Jpv8A5Ko+ x+MP+g7of/gmm/8AkqugooA5/wCx+MP+g7of/gmm/wDkqj7H4w/6Duh/+Cab/wCSq6CigDn/ ALH4w/6Duh/+Cab/AOSqPsfjD/oO6H/4Jpv/AJKroKKAOf8AsfjD/oO6H/4Jpv8A5Ko+x+MP +g7of/gmm/8AkqugooA5/wCx+MP+g7of/gmm/wDkqqepXPirRora7uNT0a5ga9tbeSKPS5Ym KyzxxEhjcMAQHz0PSusrn/GX/IDtv+wrpv8A6Ww0Aef+Hv8Ak6HxZ/2Co/8A0G1r2CvH/D3/ ACdD4s/7BUf/AKDa17BQAUVh+NJ5rXwL4huLeWSGeLTLl45I2KsjCJiCCOQQec1He65qg8Qz 6NpWkQXMkFpDdPPc3nkRgSPKu3hHbd+6yMKQRuyVIAYA6CiuPj8SapqXiHw2+lW0B0jVNKkv nW5n8uQDfb84EbfMqy8KGAYu2SNoJuXHiiaFLrUo7CN9BsnlS6vDcFZV8pisrJFsO5EZWByy sdj7Vb5N4B0lFcnqPi6+sz4jmh0aOSz0FJGmnkvNhmItlnCooRjnLhW3YABBBY5VdCw1q+k1 mPTtS0yOye5t5Lm12XPmtsjaNWEo2gI/71OFZx975uAWANyiubt/FE0yWupSWEaaDevElreC 4LSt5rBYmeLYNqOzKBhmYb03Kvz7DwbqWtapp13NrEFohS9uoYnguDISEuJU2keWgAUKqg8l gMkKeKAOkrx/4Qf8lD+J3/YVH/o24r2CvH/hB/yUP4nf9hUf+jbigD2CuT0258VazFc3dvqe jW0C3t1bxxSaXLKwWKeSIEsLhQSQmeg611lc/wCDf+QHc/8AYV1L/wBLZqAD7H4w/wCg7of/ AIJpv/kqj7H4w/6Duh/+Cab/AOSq6Cs/XdT/ALE8Panq3k+d9htJbnyt23fsQttzg4zjGcGg DP8AsfjD/oO6H/4Jpv8A5Ko+x+MP+g7of/gmm/8AkquL+Hvi3xRq2h+IrS4mj1bWrKytr2zl kjSFZGubUSpCVXaMKwxuzzu/hxUfgjxhe6zqdvpd14nvrXxClo63eka5pUaFpfLRhJF5YjO0 Ek7WYsyZ4XG6gDuPsfjD/oO6H/4Jpv8A5Ko+x+MP+g7of/gmm/8AkqsPwpqOuSeNdQ0p9Yk1 3SbKySO7v5LeKIRagG+aJPLVQRsOWX5ypwCwPBj0jUPEXjDUfEFzY65/ZEOlaq2m29oLSOeO TySpkeUsA7bw2AEZNoA5J5oA6D7H4w/6Duh/+Cab/wCSqPsfjD/oO6H/AOCab/5Krh9S8c6t YfEfU9JkuZ3sU1vSLG3ih8pPLW4hdpNxaNiykqCRkN6MvfQ/4W5Z/wDCUf2V9jg8n+2/7F/4 /R9r8zGPN8jb/qd/y7t+e+M8UAdR9j8Yf9B3Q/8AwTTf/JVH2Pxh/wBB3Q//AATTf/JVcGfj JfT+GrPUoPDkdvJqVlfT2RnvN6b7UFn3BVB2bQcdCWUrhVIkr0Dwbf32q+CtE1DUzGby5sop pWRshyyg7vuqASCCQBgEkAkDJAI/sfjD/oO6H/4Jpv8A5Ko+x+MP+g7of/gmm/8AkqugooAy /DWpTaz4V0jVLhY1nvbKG4kWMEKGdAxAyScZPqa1K5/wJ/yTzw1/2CrX/wBFLXQUAcPbeG7P xd4A1TQ7+SeO1utVv97wMA426hK4wSCOqjtWha/D/wAP6f4hn1nTrX7BJPp7ae8FiFt4yjPu LjywGEnAG4MMADuM1Y8G/wDIDuf+wrqX/pbNXQUAcefh9BNPaXF94g1y9uLG0mtbKeaaJZLb zUCNIrpGrNJtHDOW55681oeGPCq+FbOGxtdWvp7CCLyobSaO3VE5zuzHErFuuSSc7iTk810F FAHJ6v4CttcS9tb7WtZk0u9uFuJ9NadHiYhlbarMhlRCUB2q4AycYqS18D2djrE97Z6pqtvb z6g2pTWENwEhkuGXDMxC+YVJAYoX2E9scV1FFAHHp8ONHj8CWvhKO5vktbSUT214roLmGQSm QOj7cK2SRkDOCRUa/DTSrVLL+yr/AFLSZ7XTDpf2ixeNXlgLBju3IQH3ZbegVssTnpjtKKAM PR/Ctjoet6rqtrNdvPqaW6TLPL5gUQpsTBPzEkdSzMSeajXwdpf9p+I72Xz5v+EhijhvYXfC bEjMeF2gMMqxzyfbFdBRQBxa/DeyhSya01vWbS7tNMOki8gkiEr2u4FUJMZClccMgVvUk81Y l8AWJ1S6vrTVdZsTepbJepbXeDciDhN0rAyg7flJR1LDryST1lFAHF3nw1026GqwJq2s2lhq lxNdXVla3CxxvNLHsdi23eQfvbCxTIGVI4ov/hhoOpJoKTyXezR7eK1CqUxeQxsjLHcZT94m 6MHbwMknvXaUUAcva+B7Ox1ie9s9U1W3t59QbUprCG4CQyXDLhmYhfMKkgMUL7Ce2OK6iiig AorDn8Tw/aJbbTtO1LVZ4nKyC0gCxjBw2JpSkTFW+UqrlgcjHytiP7d4sk+eLQNKSNuVW41d 1kUdg4S3ZQ3qFZhnoSOaAOgorn/tnjD/AKAWh/8Ag5m/+RaPtnjD/oBaH/4OZv8A5FoA6Ciu f+2eMP8AoBaH/wCDmb/5Fo+2eMP+gFof/g5m/wDkWgDoKK5/7Z4w/wCgFof/AIOZv/kWj/hI NRs+NW8OX0Sp/rLmwZbyEZ6bVXE7dQDiHg5/hG6gDoK5/wAZf8gO2/7Cum/+lsNamm6rY6vb tPYXMc6I5jkC8NE4AJR1PKOMjKsAR3ArL8Zf8gO2/wCwrpv/AKWw0Aef+Hv+TofFn/YKj/8A QbWvYK8f8Pf8nQ+LP+wVH/6Da17BQBl+JdNm1nwrq+l27RrPe2U1vG0hIUM6FQTgE4yfQ0Qa bNF4q1DVGaPyLiytrdFBO4NG87MTxjGJVxz2PTvqUUAcfpnh7WNI/wCER8pLGf8AszSjpt7u uHTG77Pl4/3Z348luDtzkciqdz8PrZ726iXRPD88F5cS3D6ndWySXcJkcu6hGjKyEEkKzMAo Kgo+w7+8ooA5fUPDd5d6P4zs45IBJrfmfZizHCbrSKAb+OPmQnjPGO/Fak+mzS+KtP1RWj8i 3srm3dSTuLSPAykcYxiJs89x17alFAHB6T8PrbTLixto9E8Px29g8bxaolsjXswjIKhlMeEc 4G6QMxOGKqhYFOg8NWGpaZFfWl7FaCA3tzcW0sM7OzrNPJLh1KKEIDgcFs89O+5RQAV4/wDC D/kofxO/7Co/9G3FewV4/wDCD/kofxO/7Co/9G3FAHsFc/4N/wCQHc/9hXUv/S2augrn/Bv/ ACA7n/sK6l/6WzUAdBWP4p8N2fi7w5d6HfyTx2t1s3vAwDja6uMEgjqo7VsUUAcva/D/AMP6 f4hn1nTrX7BJPp7ae8FiFt4yjPuLjywGEnAG4MMADuM1XPw+gmntLi+8Qa5e3FjaTWtlPNNE slt5qBGkV0jVmk2jhnLc89ea7CuX+Ith/anw/wBYsf7Yg0jz4gn2y4l8uNfmX5XbIwr/AHD1 4boehALHhjwqvhWzhsbXVr6ewgi8qG0mjt1ROc7sxxKxbrkknO4k5PNV7jwPZvqN5c2Wqarp kN/Kk97aafcCKOeRTkvnbvRmAAYxshYDnnmvK73xJfeBrPxJEfC2m6D4pg0yOWO40x/9CuYD dCIS+QDgOPMypcFuucD5Tqah4t8aafqa6aNQ8jf4g060ha/FnPcrFPG5kSeO3baq7kVlxsYg nDegB3F98ONH1DxHNrktzfLdS6hZ6gyI6BBJbIyRgDbnaQxyM5PYirFr4Hs7HWJ72z1TVbe3 n1BtSmsIbgJDJcMuGZiF8wqSAxQvsJ7Y4rz+z8eeIpdetNDn1mC3hi1vVrWXUZ4I9zQ2kSyJ 5v3U25f5yoQlVGGU5J6j4Jf8kh0L/t4/9KJKALFt8KvD9vp2iWDy309rpEV5DEkkqjzUugRK JCqg9GONu3HvXUaHpKaDodlpMVzPcQ2cSwxyT7d+xeFB2qo4GB07c5OTWhRQAUUUUAc/4E/5 J54a/wCwVa/+ilroK5/wJ/yTzw1/2CrX/wBFLXQUAc/4N/5Adz/2FdS/9LZq6Cuf8G/8gO5/ 7Cupf+ls1dBQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVxepX7atcLLdGT/AIRwamNMkiRl C3ByYy0oKl2T7Ttg8tdoPzMxeNsDoPEupTaN4V1fVLdY2nsrKa4jWQEqWRCwBwQcZHqKrzeG of8AhCh4atbiSJIrJbW2uXAd4WRQI5eMfOrKrAjHKgjFAEena9ZjxHN4ZtbLyI7OIpEUAVB5 aQMyhR91QtzDtx1+cYUKC0lt4p00+H7bWtSurTTLO7c/ZpLq5VFljJYxMC2MF4wH2nkZIPIN c/d+GNXufDVvPA8lnr1xcTS3MkbjzYVugyMhlDDeIFeJhg/N9kjAC/LtueJNGv4tR0e80VL6 G3sbSez8nSBarIquYSoC3A8sRgQkHGGB24GM4ANiXxFZ23iGbSbyWC22xWzQyzTBfOkmeZVj UHGW/ckgAknPTjmxrWp/2RphuhD50jSxW8UZbaGklkWNNzYOF3OuSASBkgE8Hg7zwpqFtb3e mWuhyTm68L2+iQXyzwstqwEyuHdijlPniYlI/m2525AFd5raXEmjzx21nBes20SWs4BWaIsP NQAkAsU3hdxC7iNxxmgCvp+oaw2oiz1bSYLfzImljms7p7iMbSoKuzRR7WO8FQM5Cv0282LX XdHvtOn1Gz1WxuLGDd51zDcI8ce0bm3MDgYBBOegrj38PXt/p2sadpWjT6BYXmlXNqbS7mj8 kzyACJoo4nkWJV/e79oXcXBw55A+g6vfeHvFryxarJf6jpRsYF1Oa0EjlUm2gC3AjVczfeZi SSchQoLAHaR6tpsyTPFqFo6Q3H2WVlmUhJtwXy254fcyjaeckDvRJq2mw6pDpcuoWiahMm+K 0aZRK688qmckfK3IHY+lc/N4XZPFljJaRxw6KqRzTW0aKsQlgV0iBQEAkiWNg2Pl+xxj+7tz 7zw7qsviy8JOpPp95qdrqAEEtslqvkrB/rSymbfugzhPlI2DcuWKgHQXVtbaretc6Rq8dtqk CbJJICkodA7gRzIfvIJEkHBVgRIFZcvnL1fU/wC2PBmn3rQ+RM2q6fHPBu3eTMl/Ekke7A3b XVl3Dg4yOCK1PCulNpOnXiS20cE9xqd7dPt25kD3EjI7EdSY9nXkAAcYxXN69/o2savZpzHN qGh6gxPUSPdpAQP9nbaxkDrktzggAA5/w9/ydD4s/wCwVH/6Da17BXj/AIe/5Oh8Wf8AYKj/ APQbWvYKACiiigAooooAKKKKACiiigArx/4Qf8lD+J3/AGFR/wCjbivYK8f+EH/JQ/id/wBh Uf8Ao24oA9grn/Bv/IDuf+wrqX/pbNXQVz/g3/kB3P8A2FdS/wDS2agDoKp6lqtjpFus9/cx wI7iOMNy0rkEhEUcu5wcKoJPYGq+q6lNBcW+m2CxtqV2jvEZQfLijQqHlfBBYKXQBAQWLAZU bnU03QLHTbhrwLJc6g6FJL66bzJ2UkEqGP3ELDd5aBUBJwooAp/8Jlpf/Prrn/givf8A4zUc /ivRbq3lt7iw1maCVCkkcnh+9ZXUjBBBhwQRxiukooA4uzvfB2n291b2Xhq7toLtNlzHD4Xu kWZcEYcCDDDDEYPqfWiC98HWtvFb2/hq7hgiuBdRxx+F7pVSYDAkAEGA4HG7rXaUUAcf/avh P/oAX3/H39u/5Fm7/wCPj/nt/qP9Z/tdferFj4j8P6ZZx2dhpWq2lrHnZDB4dvI0XJJOFEOB kkn8a6iigDn/APhM9IXmVNVgjHLTXGj3cUcY7s7vEFRR1LMQAOSQK3IJ4bq3iuLeWOaCVA8c kbBldSMggjggjnNSVz9/4b8n7TfeHpP7N1N98u1G221zKcn99Hgqdzbd0igS4GA46UAdBRVP S9Sh1awW7hWRAXeN45AA0ciOUdDgkZVlZcgkHGQSMGrlAHP+BP8Aknnhr/sFWv8A6KWugrn/ AAJ/yTzw1/2CrX/0UtdBQBz/AIN/5Adz/wBhXUv/AEtmo8Zl/wDhH0jjnnh87ULGF3gmaJ9j 3cSMA6kMMqxHBHWjwb/yA7n/ALCupf8ApbNR4y/5Adt/2FdN/wDS2GgA/wCEN0v/AJ+tc/8A B7e//HqP+EN0v/n61z/we3v/AMeroKKAOf8A+EN0v/n61z/we3v/AMeo/wCEN0v/AJ+tc/8A B7e//Hq6CigDn/8AhDdL/wCfrXP/AAe3v/x6j/hDdL/5+tc/8Ht7/wDHq6CigDn/APhDdL/5 +tc/8Ht7/wDHqP8AhDdL/wCfrXP/AAe3v/x6ugooA5//AIQ3S/8An61z/wAHt7/8eqvodoNM 8ZaxYQXN9Jarp9lMqXd7Nc7XaS5DEGVmIyEXp6CuorlG1CGw+IerearnfpVjjaB2lu/f3oA6 uis621m3u7hYI0lDNnBYDHAz61o0Ac/47/5J54l/7BV1/wCimroK5/x3/wAk88S/9gq6/wDR TV0FAFdb+zfy9t3A3myvBHiQHfIm7cg9WGx8jqNrehrL1nxTpuiWFxqNxdWjWdvb3Esm25Xz WaJ1QoinhjubYfmGHKrgluOf1Twxq41m/vdPeQwWzjUbC2Rwiy3DNEZIl+bEZYQSAyEYP2+T rh98es+EdRTQ49Osl+2SR+GtRsHnJWM3F1N5BDMC33pGSRiSTySScnJAOkTxTpp1k2T3VpHA 9vaS2ty1yu25a4aYIidmJEORgndu4HHOxNPDbIHnljiQuqBnYKCzMFUc9yxAA7kgVxevaDe6 v/wk97Hpe261Dw0ljaCVo/MWU/aS8W4MQOXiyc7SQOTjjQ+IMP2jwmYPs0F15moWCeRcHEcu buEbXOG+U9DweD0PSgDQfxFZyNor2EsF9a6pdvbJcQTBkXbFLIWBGQ3MJXGe/titCG/s7j7P 5F3BL9piM8GyQN5sY25dcfeX515HHzD1FcnbaRqc+tW2qyWElsk2um+eCWSMyQRDTmtgX2sV JLqMBWbhgTjkCPwvpmrWeo+H7a70qe3h0bRJdPku2liaOeTNsAYwrl9pELnLKpxjIB4oA6Sb X9N+z3rWupabLPapMXR7tVVGiA3iRhkoFLJuODt3DI5GbB1bTVv0sG1C0F47siW5mXzGZUDs AuckhWViOwYHoa8rXSb2706z0uDTYDdHwVe6bb3Uc8bfbyotlVkYHHkktlCzA/O2VTq3WXfh y7e4164isY/Pvdd025SQFA0lvCbQsSc5wpjmIU89cD5uQDtK8/8AE3/Iz6h/3L3/AKcpa9Ar z/xN/wAjPqH/AHL3/pyloA5/w9/ydD4s/wCwVH/6Da17BXj/AIe/5Oh8Wf8AYKj/APQbWvYK ACiiigAooooAKKKKACiiigArx/4Qf8lD+J3/AGFR/wCjbivYK8f+EH/JQ/id/wBhUf8Ao24o A9grn/Bv/IDuf+wrqX/pbNXQVz/g3/kB3P8A2FdS/wDS2agA8O/6dqOtay3Pn3bWUGeGWG2L RlSBx/rvtDA8kq65PAVdyOeGZ5kiljd4X2SqrAlG2hsN6HaynB7EHvWH4N/5Adz/ANhXUv8A 0tmrL0+DXpfEniptL1LTbaD+04wyXWnvOxb7HbchlmQAYxxjseeeADYm8aeFbZwk/iXRonKK 4V7+JSVZQynluhUgg9wQaj/4Tvwf/wBDXof/AIMYf/iq5/Rf+RY+Fv8A2w/9Ns9dBef8lD0b /sFX/wD6NtKALkPiXQbnVDpcGt6bLqAdkNol0jShlzuGwHORg5GOMGrGpatpujW63GqahaWM DOEWS6mWJS2CcAsQM4BOPY1x+gaPqWq2Msc+o2i6Smu3dwLdLNhPui1CSRR5pkK43oM/u/u5 HB+atTxel5JqHhZbCeCC6OqvsknhMqL/AKHc5yoZSeM/xD156UAbkOrabc6WdUg1C0l08Izm 7SZWiCrncd4OMDByc8YNEOrabc6WdUg1C0l08Izm7SZWiCrncd4OMDByc8YNcvf6VNpJs9R1 G5juIn1gX+rSpEY4EVbZoo28ssxCK6W7Elm2spkJUL8tPUZrPUX1vVrS53aM39myR3tsBJB9 qhuGZpm5AeNALfzHBHyRsu4GM7QDqP8AhLPDf9nf2j/wkGlfYfN8j7T9tj8vzMbtm7ON2Ocd cVY0zXdH1vzf7J1Wxv8AyceZ9kuEl2ZzjO0nGcHr6GsPwpqC6nrOqXIvNN1Rxb28Z1TTAywS ANMRBt8yQb0yWJDZImXIGATc8Cf8k88Nf9gq1/8ARS0AFx/xKPF9pOn/AB761m1ljHa4jjaR JMcDmNJFZjknZCBwDXQVz/iH/kOeE/8AsKyf+kV1XQUAc/4E/wCSeeGv+wVa/wDopa6Cuf8A An/JPPDX/YKtf/RS10FAHP8Ag3/kB3P/AGFdS/8AS2ajxl/yA7b/ALCum/8ApbDR4N/5Adz/ ANhXUv8A0tmo8Zf8gO2/7Cum/wDpbDQBn+PdN/teTw1Y+XYyebqrfLf2v2mE4tLk/NHuXd04 5GDg9sVj6nappl3LpcNvYwQ2/wDYDbbO0WBN7alJvIAyQpIyFLHGT3JJ7zUNTttMEL3ckcUU jsplklRFjCxvIWJZhkBUPTJHXGASMtvG/hvz9Mig1mxuf7Ru2s4Ht7qN18wIXIJDf7q8ZO6R Bj5hQBz/AIC1/XdX1EjU7+xm32nnXNnDOJZLGfK/umVYU8jGXBSV5HJTgnY5NfVNUvf+Eol8 SxWN8+kaXL5D3KSRiEQRCZLtiC4kGHfJRY23mzjIJ3KU7yz1bTdQuLq3stQtLme0fZcxwzK7 QtkjDgHKnKkYPofSo313R47y6s5NVsUurSIz3MLXCB4YwAS7rnKrgg5PHIoA8r0aeTTNcjnj 8QXd5dQJ4hSO0MUErPMl0j+WI0VGd2GJSgZScDaVUkG5p3i/VnnnsbzX4F05ZbdpdbhnimWC ORLk5WY28cO3zIIo8lGAaR13bsBPTNN1bTdZt2uNL1C0voFco0lrMsqhsA4JUkZwQce4rP8A D3iKTxDbwXaaJqVnZ3FutxDc3TQbZFYAqAElZgSDnkDoc4PFAHF6NqGowT61q1trn2y1/wCE gs7VR9kVFu1lS0hMjkj5vkdWVo9iswL/ADIyqtfSvFniWaxmuLrVLEs8ULXsUMqzSaUXmiWQ sogUQeWjzErM0hBizyEkJ9Eg8S6DdX8Vhb63ps15KgeO3jukaR1KbwQoOSCvzZ9OelF34i0q 1e/g+32kl5Y27XM9mtzGsqIFDZYMwCjBXliByMkDmgDD8BXH2qTxLML77ep1VQl35Xl+cotL YK+OhyADuUBW+8oCkCqWsf8AJQ9Q/wCwVZ/+jbqux0zUodVtXuIFkVEuJ7chwAd0UrRMeCeN yEj2x06Vx2sf8lD1D/sFWf8A6NuqANHRv+QtB/wL/wBBNdZXJ6N/yFoP+Bf+gmusoA5/x3/y TzxL/wBgq6/9FNXQVz/jv/knniX/ALBV1/6KaugoAw9O8X6DqWiXGsxanaR6fb3ElvLcSzoE VkfZktuwA3ysuTyHU962IJ4bq3iuLeWOaCVA8ckbBldSMggjggjnNcXBpmrW1nZznSp5JNN8 QX175CSxb7mGY3IRoyXC/wDLwpIcqflbjOA3QeGLG4sNFMd1H5U013dXRjLAmMTTySqrEZG4 BwDgkZBwSOSAXLLVtN1J5EsNQtLp40jd1gmVyquu5CcHgMvIPccio7O/0fxDZmWyu7HU7VJV y8MiTIsiEOvIyAwO1h3HBrz/AMH6RqN74S0NoNGsbeO38NS20a3JV7a7kuFgdWKr820+W3mB lBy5C7xlq1NJ0PWLu48SvrNtd3NvqOmQ2kMep3MCSSAG4DxubZMRj94OV3nDA5zlFAOstdd0 e+06fUbPVbG4sYN3nXMNwjxx7RubcwOBgEE56CpIdW0250s6pBqFpLp4RnN2kytEFXO47wcY GDk54wa5ODS9XvNM1N76yvpnP2Zrdrx7SO+LxSGTIaEGEqh2tGr9X3h8I2a3PC8GoQ2Vy+ox SJLNcF1a4WEXLrsRcz+T+7L5UgFf4BGDyDQBj6V4l8KwGz1ayt9N0+z1uyl1G51BjFD8ySRL tlYcF91wQctwwI5JrqLzVtN0+4tbe91C0tp7t9ltHNMqNM2QMICcscsBgeo9a5Pw1oN7H/wh kuo6X5MmkaJNaSec0btDP/o6AqVZvvLHLgg/dODgnFYbeD9dGjWViyakqXXhyz0m6hsZrVVV 41lDiZ5VYhP3uA0IY8OcH5cgHqlef+Jv+Rn1D/uXv/TlLXoFef8Aib/kZ9Q/7l7/ANOUtAHP +Hv+TofFn/YKj/8AQbWvYK8f8Pf8nQ+LP+wVH/6Da17BQAUUUUAFFFFABRRRQAUUUUAFeP8A wg/5KH8Tv+wqP/RtxXsFeP8Awg/5KH8Tv+wqP/RtxQB7BXP+Df8AkB3P/YV1L/0tmroK5/wb /wAgO5/7Cupf+ls1AB4N/wCQHc/9hXUv/S2aiLxnokusX2nrewBbDK3Vy1xEscUoUuYjl924 IrsTt2gI43ZVgDwb/wAgO5/7Cupf+ls1Zc3hy7ufEwuZ7GOW0HiNdQBcowEa6aIlkwT1EwAH cEA9OaAOoj1bTZtUm0uLULR9QhTfLaLMplReOWTOQPmXkjuPWq58S6CLe4uDrem+RbpE88n2 pNsSyAGMsc4AYEFSeueM1z9hpGpx6pp1pJYSJBYaxe6k16ZIzFKk32naiANv3j7SudyqPkfB Py7o/DXhWXTf+EM8/TIIv7K0SaGbAQ+RdSfZ9xGP4m2zZZeuWyfm5AO0nnhtbeW4uJY4YIkL ySSMFVFAySSeAAOc1HY39nqdnHeWF3Bd2smdk0EgkRsEg4YcHBBH4VzdppWp2vwy0nTFto/7 StLKzR4m8t2R4xHv8vdlPNXaShb5d4UnjNSeC9P1axTWpdXE/nXmoC4ia4kieRo/s8KDf5Sq gYFCpAGAV4LDDMAamh+IdN8Q2UVxYXMbO9vDcPbl1MsCyoHQSKCdpKnPv2zVNvG/hvz9Mig1 mxuf7Ru2s4Ht7qN18wIXIJDf7q8ZO6RBj5hXL+HvDesw6HpllJoVjZTad4fuLAxXLpLbXM83 ktyE5K5ibzMgcudpcfNUdlovib/hM7PWbyz1K5t1uLUBrua08+OMRX0bFli2IArTo2FLkq2Q ScooB3GoeIdN06y1e4a5jnfSbc3F5bwOrSxqELgFc8FlBIzjNXLW/s77z/sd3BceRK0E3kyB /LkX7yNjowyMg8iuLutC1OTwx4k0ddIje4kt9UFreGWP96bqR5Ejj7gfMocvsAZFxvHzDoNP 0prHxVfTw20cGnnTLO1txHtVQYnuCUCjoAsidsc8dDgAj8Q/8hzwn/2FZP8A0iuq6Cuf8Q/8 hzwn/wBhWT/0iuq6CgDn/An/ACTzw1/2CrX/ANFLXQVz/gT/AJJ54a/7BVr/AOilroKAOf8A Bv8AyA7n/sK6l/6WzUeMv+QHbf8AYV03/wBLYaPBv/IDuf8AsK6l/wCls1HjL/kB23/YV03/ ANLYaAK/jrw3eeJ9Hjs7KSCORftGTMxA/eWk8C9Af4plJ9ge/Bj1Tw7qU/jey121No0EL2we OWVkbaiXiORhSCcXSEDjO0gleDWx4g1dtD0n7clnJeP9ot4FgjdVZzLMkXBbAz8+eSAcYJHU c/aeO5ktb241jSo7ZLe3v7hRZ3RuC62cvlTA7kjwSxUr1yM524wQCx4c8O6lptxpK3ptBBo2 mNpts8MrO1yrGH946lVERxAPlBf75+b5fm5/X/h7rOqS3SwXNokbvfMpe6nCyfaIJ0X9wP3U RRplBZVZpPmclWLK+xB411SbS7yc+GbsXFu8YAEV0ImV93OWt1lYjbghInxvQ5wWKWLnxdfQ ppckejRyR3iBjMLzMTkthVhlVCjF+CnmtCH8yMA7iwQA2INNmi8VahqjNH5FxZW1uigncGje dmJ4xjEq457Hp35/wL4Wm8N29rBceHfD9pPBZJbyajYSlp7hlCglgYUOGK7j8x5A69RXt/iQ ZZmhfSJEedFawO+TZNvmihXfI0QTG6eIloWmXG4gn5d5dfEK9trqXTj4fk/tOK4kiaISSzIV jigdnDQQyPgm4TblBkDLFGISgCPTPAV5p2lWdnGbGPybTR4nERIUyWt0087fd/i3Eg9SxOcd ap6/8PdZ1SW6WC5tEjd75lL3U4WT7RBOi/uB+6iKNMoLKrNJ8zkqxZX6TxHreqR+ELTUNItP Iur2W0i8u+byZLcTyInI2OBIpcDBBAOSQ23a3Pw+Pry2isZjBPeNf6VpsttbspciaZbqSRna GJmPyQD7sZGQPlUEkAHaaBps2ladLbztGzve3dwChJG2W4klUcgc7XAPvnr1rifE9lcXnxDv PI1O7sdulWmfs6xHfmW56+YjdPbHWu60TUn1fR4L2Wzns5JNwaCeNkZSrFSQHVW2nGVLKpKk EgE4HJax/wAlD1D/ALBVn/6NuqAKuk6HqDanCo8VauhO75litMj5T6wV0/8Awj2qf9Dnrn/f my/+R6p6N/yFoP8AgX/oJrrKAOD8aaFqMPgXxDK/izWZ0TTLlmikiswrgRN8p2wA4PTgg+hF dhq15Np2jX17b2kl5Pb28ksdtHndMyqSEGATkkY6Hr0NZfjv/knniX/sFXX/AKKaugoAx7Xx FZsuzUZYNOumu3to7e4mCvJ+9kjiYBsE+YIiyjHPOM4zVy81bTdPuLW3vdQtLae7fZbRzTKj TNkDCAnLHLAYHqPWuH8TWF3qXirxJZWWmR3M994cgsFud6K1t5r3Q3Hdg+VkAttJb5Vwjfw6 HinSNTurjXYrOwkuU1vR001JUkjVbZwbjLy7mB2fv1PyBz8rcdMgHSJf6Pp95a6HHd2NtdGI fZrBZERzGoONkfXaAp6DA2n0qnp3i/QdS0S41mLU7SPT7e4kt5biWdAisj7Mlt2AG+VlyeQ6 nvWXf6XqQ8UM1lZT/Zbm7guZy728lnIUEYaSRWHnJMqxgII8puSJieXxnzaJrZ0e38q3vra4 0/xBe3o+yvbGaaGVrna0XmEx8i4XIk2kBXwM7cgHaPq2mx29pcPqFosF66JayNMoWdnGUCHO GLDkAZz2rLHiyzg8Aw+Lb9Ps1q2npfPEHBI3IGEak7QzEkKOmSR61hwaFeabFptzLpF3qsRt 9Qhu7N5bd52N1OkxMmfLiI+RgyqSAWAG8Zarn9iaj/wpv+wPs/8AxM/+Ef8AsXkb1/132fZt 3Z2/e4znHvQBcPiaaHTobqeHTZHleyASy1AzDbc3HlK4JjXKbSGBx8xDDjbuOxHq2mzapNpc WoWj6hCm+W0WZTKi8csmcgfMvJHcetc3ruiajea7eXNvb74ZP7G2NvUZ8i+kll4J/hRgffOB k8VT0jw7qtv4lhF2dSe0tNTvNQiJlthaDzjNt2AKZ2fE+CH2qDvIYgKGAOk0jWLzUb+9t7nS Z7KO3z5csmcTYnnj4yo/hhSTqeJV7YJ8v+JPhfVNa8a3U9l4ovtOjji0mMwxD5SZbySND8rL /q2BkG7cdzHBUYx7RXn/AIm/5GfUP+5e/wDTlLQB5JpXgTXrn4y654fi8calBqFrZLLLqyh/ NnUiE7G/eA4+derH7g49O7/4VB4w/wCis65+U3/x+jw9/wAnQ+LP+wVH/wCg2tewUAeP/wDC oPGH/RWdc/Kb/wCP0f8ACoPGH/RWdc/Kb/4/XsFFAHj/APwqDxh/0VnXPym/+P0f8Kg8Yf8A RWdc/Kb/AOP17BRQB4//AMKg8Yf9FZ1z8pv/AI/R/wAKg8Yf9FZ1z8pv/j9ewUUAeP8A/CoP GH/RWdc/Kb/4/R/wqDxh/wBFZ1z8pv8A4/XsFFAHj/8AwqDxh/0VnXPym/8Aj9cJ4E8Ca9rf irxjZWXjjUtMn069EVzcwh9162+Ub3xIpzlCeS33zz6/TdeP/CD/AJKH8Tv+wqP/AEbcUAH/ AAqDxh/0VnXPym/+P1l6B8LPFV9p0s0HxO1m1Rb27iMaCXBZLiRGfiYcsylz7seT1Pulc/4N /wCQHc/9hXUv/S2agDP+Gen3Gl+Dvsl1qM+oTRahextPMACxW5kUn1+YqXO4scsecYA3JvEO mW+qDTpJ5BPvWNnEEhijdsbUeULsRzuXCswJ3pgfMuafg3/kB3P/AGFdS/8AS2aqd54d1KbV LyOI2n9n32p2upSztKwliaDyP3ax7SHDfZ1+YuuPMPynb8wBuaNreneINOTUNKuPtNo+NkwR lVuAeMgZxnBx0YMpwykCvD4p0aezubqO8zDb7Sx8pwXDnEbRrjMiueEZAwc8KWNSeGtNm0bw rpGl3DRtPZWUNvI0ZJUsiBSRkA4yPQVh23hvWI/CFtokslj/AMSz7ELIqz/v/ssiOGkbH7vz PLUbQr7OTukzgAGpJ4v0OGyhu5ruSJJbj7KkctvKkvnbC4jMRXeHZRlVIBbcu3O5cxnxt4dW KaU6hiOGJ5ZXMMmIyil3jY7eJlVWYwn94ACSuBVO28O6k+p22qXZtIp21g6jcQRStIsa/Ymt QqOVUuSQjHKrjJHOATn614K1LUvCp0uGe0Wc3uqXG53YLtuUvFjHC5yDcpnjs2M4GQDc/wCE 28O/9BD/AGv9TJ/qv+e/3f8Aj3/6b/6r/aq5D4h0y41Q6dHPIZ97Rq5gkEUjrnciSldjuNrZ VWJGx8j5Wxl694bvNU/4SfyJIF/tXRE0+DexG2QfaclsA4X98vIyeDx0zT/4RbWZPGdjq1xe Ry29pezTktdzkyRvFKiKsH+qiMe9UyAS4BYlTlWANjTfGGgatbtc2mpRm3Fubrz5EaKNogAW dXcAMEyA+CdhOG2nijR/E9pres31haJJizt4JZGlR4pFaRpRseJ1DIQIgwz1Dg4xgnD/AOEI vJ/D2l6TPdQR+R4auNGnlQF8SSpAodQQNyjymPJB6epxsaNZax/wkOpatq1tY232i0traOK0 unn/ANW8zFiWjTGfOAwAehoAPEP/ACHPCf8A2FZP/SK6roK5/wAQ/wDIc8J/9hWT/wBIrqug oA5/wJ/yTzw1/wBgq1/9FLXQVz/gT/knnhr/ALBVr/6KWugoA5/wb/yA7n/sK6l/6WzUeMv+ QHbf9hXTf/S2Gjwb/wAgO5/7Cupf+ls1HjL/AJAdt/2FdN/9LYaANi9sbfUIFhuo/MjWWOYD cRh43WRDx6Mqn3xzxVNfDmkKSTYxuClyjLIS6stxIJJgVJIIZgDg9OgwOK1KKAMMeEdHFu8R ju3d3V/tMl9O9wpUEDbOXMigBnGFYDDuP42ySeENDlSFGtJAkabHVLiVRcKWLET4b9+CzOSJ N2S7k53tncooA5e78DaT5Ez6dbQW980XkRT3HmzLDHvR9iKJFKKpjUoEZRG3KY5zHpXgPT7O ykS6kke7muGuJLiylmtG3MiIwDLIZMMIkZ9ztvcFjzjHWUUAU5dKsZrCCwa2jW0geF4oY/kV DE6vHgLjAVkXjpxjpxWf/wAIhoYt4oUtJIhDbwW0TxXEqSRRwhxGEdWDKQJJAWBBIcgkg4rc ooAr2Njb6dZx2trH5cKZIBYsSSSWZmOSzEkksSSSSSSTXFax/wAlD1D/ALBVn/6Nuq72uC1j /koeof8AYKs//Rt1QBo6N/yFoP8AgX/oJrrK5PRv+QtB/wAC/wDQTXWUAc/47/5J54l/7BV1 /wCimq5r3iHTfDVhHe6pcxwQSXEVurO6r8zuFz8xAwASx9FVj2qn47/5J54l/wCwVdf+imqT xbbXd1oSrZWsl3PFe2dx5EbIrOsVzFIwBcqudqHqRQBce/0e31xbN7uxj1e6iG2EyIJ5Y13k YX7zKP3hHYfN71HqniHTdGv9Ksr25jin1S4NvbKzquWCFs8kHGQF4z8zoO9c/f6RqcmqajaR 2EjwX+sWWpLeiSMRRJD9m3I4Lb95+zNjarD50yR823Y1+2u5tR8O3FrayXCWmp+ZOEZAUja3 mi3/ADEZAaRSQMnGcA9KAJNG8RWervJb+bBFfJLcr9k84NIY4bh4PM28HaSnXGATjJq5Hq2m zapNpcWoWj6hCm+W0WZTKi8csmcgfMvJHcetcvp3hy7tH0pxYxxOniO/1C6ZSgJjkW7WORsH 5iVkhHcgYBxg4r6R4d1W38Swi7OpPaWmp3moREy2wtB5xm27AFM7PifBD7VB3kMQFDAHQaxr GpWus2Ol6Xp1pdz3VvPcM11eNAqLE0S4G2NySTMOw6GrEOpzWlkZvEP9m6a5dguy+MiFVQuT udI+QquSMcBSc9cYfizSFvvEOkXlz4Y/t+xgtLqJ4dtu/lyO8BRtszqOkcgyMkfjUcegW9yd BFp4Tj0i0s9YN3PavFbKBi2lVZtsTspO9owDncCoOABmgDqINW026uIre31C0mnltxdRxxzK zPCTgSAA5KE8bulFnq2m6hcXVvZahaXM9o+y5jhmV2hbJGHAOVOVIwfQ+lcvp3hy7tH0pxYx xOniO/1C6ZSgJjkW7WORsH5iVkhHcgYBxg4r+GtH8QweKrK61KCSOztdMntAga3WCKUvAdtu kahhARGdhkYvhcMFOC4B0mla5/aWovZ+XAdmn2t751vP5sb+cZRhG2jco8rIb+IN0Fcv4m/5 GfUP+5e/9OUtaHgrRNR0j7N9ut/K2eH9Msm+dWxND5/mLwT03rz0OeCeaz/E3/Iz6h/3L3/p yloA5/w9/wAnQ+LP+wVH/wCg2tewV4/4e/5Oh8Wf9gqP/wBBta9goAKKKKACiiigAooooAKK KKACvH/hB/yUP4nf9hUf+jbivYK8f+EH/JQ/id/2FR/6NuKAPYK5/wAG/wDIDuf+wrqX/pbN XQVz/g3/AJAdz/2FdS/9LZqADwb/AMgO5/7Cupf+ls1U9W127sfEN7biWT7PGmkhETYCGuLy WJzkqcgqqgj0BwVJ3C54N/5Adz/2FdS/9LZqsX3huz1C/mvJZJ1kl+x7gjAAfZp2njxx3ZiD 6jpg80AYdh4+aTRo9V1PR5LO3n0eTV4EjuFmkaKJYzIGGFAJ81dnzHcOW8s/LWh4X8WQ+Iri 9tVfTZJ7RIpHfTL8XcG2QuFG/apDgxtldvAKnJzgSJ4O0sadY2EvnzWtppUmkBHfHmQSCINu KgHdiFeRjqfbGhpmmS6f5rXGqX2ozSYHmXZQbVGcALGqIOSedu45AJICgAHP6F4n1GW6jg1G zzb3Oq31hb3XmrvZopZ2UeWBgRiOEruLbiy/dIO8mm+L9U1fTtIltNCgjvNUtGvoYLq/2IsC iLcWdI3+YtMu1ccrySrfINCw8I2dhqK3S3l9KiXc99HbTSho47iYybpF+XcPlldQudmDnaXy xB4Tgg07Sbax1G+sptLtBZQXcPlNIYcICrB0ZDkxRknaDleCASCAZbfEaxTTRfSWskSSJbXM CSN8z2ksRlaY7QQpRIro7MknyMD765k1Lxx9j3slvYxW5u5reK91K/8AsttJ5O1XBfYxWTzD IqoR8whdgcYzqL4R0VXsv9CjaCzsjYx28iiRGi2hVDbgSxVTIoJPAmlHO80L4aEGl2VlYatq Vk9qhU3MLRs8+7BdpA6MjOzDcX27slsEbmBAMef4hW1v4gXTJorSB1uLe1mtp79FvRLMIyuy BQwdB5yBmDjG2TAO0btzQNZuNaW9lk0/7LbwXc9rE5mDmYxSvGzAAfKvyDGTnO4YwAzV7Lwj Z6ZPENOvL6zsU8ovYwyjy5WiRI0LMVMnCxxggOFYJ8wO5t2ppmmw6VavbwNIyPcT3BLkE7pZ WlYcAcbnIHtjr1oAy/EP/Ic8J/8AYVk/9Irqugrn/EP/ACHPCf8A2FZP/SK6roKAOf8AAn/J PPDX/YKtf/RS10Fc/wCBP+SeeGv+wVa/+ilroKAOf8G/8gO5/wCwrqX/AKWzVoa1pKa3phsp Lme2/exTJNBt3o8ciyKRuVl+8g6g1n+Df+QHc/8AYV1L/wBLZq6CgDn/APhHtU/6HPXP+/Nl /wDI9YeoW2uWl9JBH4v1cquMFoLPPIB/5967yue1PTLy41CWWKHcjYwdwHYe9AHN/wDE/wD+ hu1b/vxZ/wDxij/if/8AQ3at/wB+LP8A+MVs/wBjah/z7/8Aj6/40f2NqH/Pv/4+v+NMZy81 74jj8QWdgPFup+VNazzMTb2e4MjxAY/cdP3jZ+gq/wD8T/8A6G7Vv+/Fn/8AGKbdaTfDxvpU Zg+Y6beEDevQSW2e/uK2/wCxtQ/59/8Ax9f8aAMb/if/APQ3at/34s//AIxR/wAT/wD6G7Vv +/Fn/wDGK2f7G1D/AJ9//H1/xo/sbUP+ff8A8fX/ABoAxv8Aif8A/Q3at/34s/8A4xTLaxnj 1G4v7zU7u/upoo4S9wsS7UQuVAEaKOsjdc1uf2NqH/Pv/wCPr/jR/Y2of8+//j6/40AGjf8A IWg/4F/6Ca6yue0zTLy31CKWWHai5ydwPY+9dDSEc/47/wCSeeJf+wVdf+imroKr39jb6np1 zYXkfmWt1E8MybiNyMCGGRyMgnpWf4Yvri80OFL+Tfqdp/ot+SoUmdOGbaMYV+JF4GUdTgZo A2KKKKACs/TtWTVF8y3tpxCJbmFpH2gK8MpiII3Z+YqxGB0XnBwDzf2O0XxnfS6lo93c6hJe wvpt3FbOTDbiKIMBcDCxoHWctGXBYFvlbzAGx30rWmguVsLa7ivGsvEaW8gzEVllvUaHDnAU sBuU5GQMjgZoA9Mqve31vp8CzXUnlxtLHCDtJy8jrGg49WZR7Z54rzO30KWfR7+K1t5Es7i9 0tRBp+jTaSilLtWlkWNnMm/YVLSAKAEXDEqdtzWNAt00PWrJ9D83TLTxBYzWlnHYmVEgH2Qz GKJVOV5uN2wc7pPU0AekUUUUAFef+Jv+Rn1D/uXv/TlLXoFef3/+n6fea8fmjvdb0uGzc9Ta xXkKoeOCrSNPIrDO5JVOcYAAOf8AD3/J0Piz/sFR/wDoNrXsFeP+Hv8Ak6HxZ/2Co/8A0G1r 2CgAooooAKKKKACiiigAooooAK8f+EH/ACUP4nf9hUf+jbivYK8f+EH/ACUP4nf9hUf+jbig D2Cuf8G/8gO5/wCwrqX/AKWzV0Fc/wCDf+QHc/8AYV1L/wBLZqAC3/4lHi+7gf8A499axdRS HtcRxrG8eeBzGkbKoyTsmJ4AroKr31hZ6nZyWd/aQXdrJjfDPGJEbBBGVPBwQD+FY/nap4f/ AHT2s+qaUn3J4pPMu4F9HQ8yqoB+dSZGyo2O2XYA6Ciuf/4TLS/+fXXP/BFe/wDxmj/hMtL/ AOfXXP8AwRXv/wAZoA6Ciuf/AOEy0v8A59dc/wDBFe//ABmox450Vrh7dYtZM6IrvGNEvdyq xIUkeVkAlWAPfafSgDpKK5//AITLS/8An11z/wAEV7/8Zo/4TLS/+fXXP/BFe/8AxmgDoKK5 /wD4TCwf5YLDXJZjwkf9jXUe9uw3SRqi5PdmVR1JA5o/s/Ude+bWR9j088f2XFIsn2hTzi4b b9AY0O3hgzSq2AAGj/8AE61Z/ER/49Vie005T1MfmZkmyOCspSMr94bI1YEeYyjoKKKAOf8A An/JPPDX/YKtf/RS10Fc/wCBP+SeeGv+wVa/+ilroKAOf8G/8gO5/wCwrqX/AKWzV0Fc/wCD f+QHc/8AYV1L/wBLZq3J54bW3luLiWOGCJC8kkjBVRQMkkngADnNAElFc3BZ6l4jt4rvUbu7 0+wnQSR6bbbrecKRkCeUHeHHynbGY9p3KTIOTJ/wgvhNuZfDelTyHlpri0SWSQ92d3BZ2PUs xJJ5JJoA6Ciuf/4QTwf/ANCpof8A4Lof/iaP+EE8H/8AQqaH/wCC6H/4mgAvP+Sh6N/2Cr// ANG2ldBXP/8ACCeD/wDoVND/APBdD/8AE0f8IJ4P/wChU0P/AMF0P/xNAHQUVz//AAgng/8A 6FTQ/wDwXQ//ABNH/CCeD/8AoVND/wDBdD/8TQB0FFc//wAI0+n/AD+H9Sn09hwLactc2hHQ KImYGNVBO1YmjA4yGCha0NH1P+1LN3kh+z3UEr29zAW3GORTg84BKkYdSQCyOrYGcUAaFFFF ABWPfaTcJeSalpFz9nu2w01u+PIvCAAPM+UsrbRtEiYPC7hIqKlbFFAHP/8ACV29j+7162n0 iRfvzTqWtMdNwuAPLVSchRIUc8ZQFgCf8J34P/6GvQ//AAYw/wDxVdBRQBz/APwnfg//AKGv Q/8AwYw//FUf8J34P/6GvQ//AAYw/wDxVdBRQBz/APwnfg//AKGvQ/8AwYw//FUf8J34P/6G vQ//AAYw/wDxVdBRQBz/APwnfg//AKGvQ/8AwYw//FUf8Jx4ak4s9Xg1GTqYdMDXsij+8UhD MF6DcRjJAzkiugooA5//AImPiP8A5/tH0wf7sdzdg/m0MZU/7MuT/wAstnzx+K4IbXw3ZW9v FHDBFqemJHHGoVUUXkAAAHAAHGK6Suf8Zf8AIDtv+wrpv/pbDQB5/wCHv+TofFn/AGCo/wD0 G1r2CvH/AA9/ydD4s/7BUf8A6Da17BQAUUUUAFFFFABRRRQAUUUUAFeP/CD/AJKH8Tv+wqP/ AEbcV7BXj/wg/wCSh/E7/sKj/wBG3FAHsFc/4N/5Adz/ANhXUv8A0tmroK5/wb/yA7n/ALCu pf8ApbNQB0FFFFABRRRQAV4f4H8e/wBsfH7xFbm9/wBAvomtrONX85JGtz8jIwHyqV8+TAIX 5z1OCfcK4vR/DWg6d8RtSex0TTbV4NMs3haC1RDGzyXauVwOCygAkdQADQB2lFFFABRRRQAU UUUAc/4E/wCSeeGv+wVa/wDopa6Cuf8AAn/JPPDX/YKtf/RS10FAHP8Ag3/kB3P/AGFdS/8A S2ai4/4mnjL+z5+bTTbSG9MJ5WaaSRxGx/65+QxAOQWkVsBo1NHg3/kB3P8A2FdS/wDS2ajQ /wB/4l8T3MnzTRXcNkjdMQpbxyquPZ55Tnr82M4AAANi+v7PTLOS8v7uC0tY8b5p5BGi5IAy x4GSQPxqvpmu6Prfm/2Tqtjf+TjzPslwkuzOcZ2k4zg9fQ1j/EGb7P4TM/2mC18vULB/PuBm OLF3CdzjK/KOp5HA6jrWPe63can4fnFr4v0q9m/tDTohPoaBHtxJdxq27MsoO4EgAjBwwIYH FAHoFRzzw2tvLcXEscMESF5JJGCqigZJJPAAHOa8/dbnT7jUZYdU1Jk0zXbCxtIpbt5FSKY2 vmh9xJlLee4BkL7ONm3Fc+/iK9+z66tnd3cYbw5qF27vqUs86XEYj2+YpRUtp08xt0URwpYZ AATIB7BHPDM8yRSxu8L7JVVgSjbQ2G9DtZTg9iD3omnhtkDzyxxIXVAzsFBZmCqOe5YgAdyQ Kw/D3/Ic8Wf9hWP/ANIrWuTtLtbvwVZSvqN3dag17o76lFM7Otvdm7h81OR+7fdw0IICYXCJ u+YA9IhnhuULwSxyoHZCyMGAZWKsOO4YEEdiCKkryvUdVvVgsRd3saae17q6yy3msy6anmJe lYU+0RgtkJ5gWPgEKT/AMSahNrA07Vr671e+F9pfhS0vlWF3gja8AuiZWjKqesYzGwCkcOh2 qFAPTIZ4blC8EscqB2QsjBgGVirDjuGBBHYgisPWP+Jf4j0XU4/kW4lOn3bnhDGyO8ZY/wB4 SqiIScDz3AGXFU/h7FaW+hX9va3Ekpi1jUElEly8zRsLmTAJZiQduxsd9245LEm545+TwNrV yvE1naPewN/cmhHmxtjvh0U4PBxggjIoA6CiiigAooooAKKKKACiiigAooooAKKKKACuf8Zf 8gO2/wCwrpv/AKWw10Fc/wCMv+QHbf8AYV03/wBLYaAPP/D3/J0Piz/sFR/+g2tewV4/4e/5 Oh8Wf9gqP/0G1r2CgAooooAKKKKACiiigAooooAK8f8AhB/yUP4nf9hUf+jbivYK8f8AhB/y UP4nf9hUf+jbigD2Cuf8G/8AIDuf+wrqX/pbNXQVz/g3/kB3P/YV1L/0tmoAp69pOm6z460S 31TT7S+gXTL51juoVlUN5toMgMCM4JGfc1c/4QTwf/0Kmh/+C6H/AOJovP8Akoejf9gq/wD/ AEbaVc1LxLoOjXC2+qa3ptjOyB1jurpImK5IyAxBxkEZ9jQBT/4QTwf/ANCpof8A4Lof/iaP +EE8H/8AQqaH/wCC6H/4mthL+zkvGs0u4GukzuhEgLrgITlevAkjJ/319RVigDn/APhBPB// AEKmh/8Aguh/+Jo/4QTwf/0Kmh/+C6H/AOJrYmv7O3+0efdwRfZohPPvkC+VGd2HbP3V+RuT x8p9DUkc8MzzJFLG7wvslVWBKNtDYb0O1lOD2IPegDD/AOEE8H/9Cpof/guh/wDiaP8AhBPB /wD0Kmh/+C6H/wCJroKjhnhuULwSxyoHZCyMGAZWKsOO4YEEdiCKAMP/AIQTwf8A9Cpof/gu h/8AiaP+EE8H/wDQqaH/AOC6H/4mugqOGeG5QvBLHKgdkLIwYBlYqw47hgQR2IIoA5/wNBDa +G5Le3ijhgi1PUEjjjUKqKLyYAADgADjFdJXE+Gtb+yadeQfZ9+3VdR+bfjObyY+ldJp+rfb 7hovI2YXdnfnuPb3oAo+BP8Aknnhr/sFWv8A6KWugrn/AAJ/yTzw1/2CrX/0UtdBQBz/AIN/ 5Adz/wBhXUv/AEtmo8Pf8hzxZ/2FY/8A0itaPBv/ACA7n/sK6l/6WzUeHv8AkOeLP+wrH/6R WtAHQVj2XijR76fWoor6Af2NL5V67SptjwgcsTnhRllJOMNG4/hrYri7zSNTmfxGqWEhD6xY 6lbN5keLlIVtS6J82Q+bdwN+0ZZecZIAOssb+z1OzjvLC7gu7WTOyaCQSI2CQcMODggj8Kpw +IdNutZTS7W5juZyk5doXV1iaFoldHwcq4MycY9c44zX8O212kusX93ayWh1G9FxHbysjSRq sEMWH2FlyTESMMeCOhyBxcXhPVrvTodKbR/slxbeFLnQ31GZ4vLuJGEKx7SjNJ5eUkYblBAb oCSKAPQLXXdHvtOn1Gz1WxuLGDd51zDcI8ce0bm3MDgYBBOegoutd0ex06DUbzVbG3sZ9vk3 M1wiRybhuXaxODkAkY6iuPTQdXu7bUL+aLVZbtpdPdU1Oa0E0iWtyZyiLbgRjIZgpZ+WODsU BjqSwaha6lpetw+H5CEt7yKWws5YfNRp5YpA7FmRCf3TF8MfnfguMtQBsa54h03w9ZS3F/cx q6W81wluHUSzrEhdxGpI3EKM+3fFWJNW02HVIdLl1C0TUJk3xWjTKJXXnlUzkj5W5A7H0rzv UvCerWnhK50j+x/7XkuvDVrpS/Z3i2RXECzYdvOZPl3SoVKgkbCSAQM6l54d1WXxZeEnUn0+ 81O11ACCW2S1XyVg/wBaWUzb90GcJ8pGwblyxUA7yuf8d/8AJPPEv/YKuv8A0U1dBXP+O/8A knniX/sFXX/opqAOgooooAKKKKACiiigAooooAKKKKACiiigArn/ABl/yA7b/sK6b/6Ww10F c/4y/wCQHbf9hXTf/S2GgDz/AMPf8nQ+LP8AsFR/+g2tewV4/wCHv+TofFn/AGCo/wD0G1r2 CgAooooAKKKKACiiigAooooAK8f+EH/JQ/id/wBhUf8Ao24r2CvH/hB/yUP4nf8AYVH/AKNu KAPYK5/wb/yA7n/sK6l/6WzV0Fc/4N/5Adz/ANhXUv8A0tmoALz/AJKHo3/YKv8A/wBG2lV2 0u9n+Id5ex319Z2qafZAiGOMx3JWW5LIzOjHgEZ2FSA/XkYsXn/JQ9G/7BV//wCjbSrF/wCI 7LSrq8jvX2x20VtIfKjklkJnleJBsVDnLIANpJJJyAACwBw/iC28SSeKNVnsVvkRfNjin8qR 1jt2GlmXywpDHKrckLGQ5ZX2HeM11ngqO9i0aZbu7u7mP7Qxt3uraWBhHtXICzSPMRv38yHP JwNgTMa+O9JfXLfTh56RvaXFzPPcW8sItvK2ErKHQbMq5bLFcDYekiE7Gma1Zav5otWnWSLB eG5tpLeRQc4bZIqttOGAbGCVYA5BwAeV+J9H8Q3mg6xrx0WRhqVvc5t7aeY3eyeOFIkNusYK upt7bzB5jDAm4YMAND7BPaR6+umjxBBBc6nbTPcTLfTMLc2abW27hM580FGEbq6/LvOxNh7R vGugpBJMbqfy02FCLOY/aAzrGrQ/J++Us6DdHuHzrzhhmS88T2kXhXVdctEknGn280slvKjw SBkTfsdXUMhIwRlejA4IIyAcXpT621tCPESeI0mjieLT1sVlVxMtzOv7zazof3YtcG4d4zyd zAyMZG03xHp2lyXWitqX9qXWp6siQuf3UcbfbJIT5bDywGlELCRhk7wN2wha6DTPHFjNYXt/ qWo+H4rS1eFHm07VftioZH2L5h8tPLG7GCcjqTgDNamj+KNJ12V4rGafzE3/ACXFpLbltjbH 2iRV3bW+VsZ2kgHBIoA4exh1WK1/fX2uXWiG7j+1+XZ31vMq+VNny/Mle6P7z7NnZhQBxkGX HWeBYLu28LKl9FdxXBvb12W7VFlO66lYFtnyZIIOV+U5yOMVIfGOkyKPs0+5mlhSMzxSxJMs kqRb4mKESrmRcMmV+ZMsoYNWhoWp/wBt+HtM1byfJ+3WkVz5W7ds3oG25wM4zjOBQBwejf6m /wD+wrqH/pXLXT+Hv+P+T/rkf5iuY0b/AFN//wBhXUP/AErlrp/D3/H/ACf9cj/MUxkvgT/k nnhr/sFWv/opa6Cuf8Cf8k88Nf8AYKtf/RS10FIRz/g3/kB3P/YV1L/0tmo8Pf8AIc8Wf9hW P/0itaPBv/IDuf8AsK6l/wCls1Hh7/kOeLP+wrH/AOkVrQB0FFFFAEc88Nrby3FxLHDBEheS SRgqooGSSTwABzmsN/GugxRK891Pbs8ohSG4s5opmdldlAjZA53CNwuB8zKVXLcVoa7pn9t+ HtT0nzvJ+3Wktt5u3ds3oV3YyM4znGRXL6Z4QvodasdUmigt5IbtXlU6pc3ztGsFzGMSTAfx XHCBQBhjuYkAAHQWPinRtRvI7W1vPMmfKgGJ1AkAJaJmIAWYAEmIkOACSoAqvJ4x0k6dqF1b T7vslpJdqZ4pYo5o0GS8blD5kf3cvGHADKedy5r2vhu8g/sndJAfset3uoSYY8xzfatoHH3h 56ZHThuTxnn5vAmv3X9pNdX8Es1zol7poklvJ5PNmm8vE21spCrFDmONcJgAFxgIAdxo2p/2 vYyXPk+Vsu7m227t2fJmeLdnA67M47Zxz1rQrL0DTZtK06W3naNne9u7gFCSNstxJKo5A52u AffPXrWpQAVz/jv/AJJ54l/7BV1/6Kaugrn/AB3/AMk88S/9gq6/9FNQB0FFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFc/wCMv+QHbf8AYV03/wBLYa6Cuf8AGX/IDtv+wrpv/pbDQB5/4e/5 Oh8Wf9gqP/0G1r2CvH/D3/J0Piz/ALBUf/oNrXsFABRRRQAUUUUAFFFFABRRRQAV4/8ACD/k ofxO/wCwqP8A0bcV7BXj/wAIP+Sh/E7/ALCo/wDRtxQB7BXP+Df+QHc/9hXUv/S2augrn/Bv /IDuf+wrqX/pbNQAXn/JQ9G/7BV//wCjbSjU/DH9o6pcXv2zy/O/s/5PKzj7LctP1z/Fu2+2 M89KLz/koejf9gq//wDRtpWf438SaxoWRpMdi2zSr7UJGu1dsfZ/KIACkZ3eYVwSMZDZO3aw AX/gX+0Na1K7k1Hba6lFdW9zCsHziOeC3iOx92AwNsGyVIO4jHGa2NJ0m8tdRu9S1K9gur65 iityba2MEaxxmRl+Vnc7syvk7sY28DBJ5++8U67aW8mnw2sF7q66qNNEsEACPm1F1vETzL0X 5MGUdN2f4KjbxZr5tbWdoNNthCjnUd7LMIisrxgy+XKTboxjPzgThDv34ERZgCO3+GKQapBf DUYBJF5as6WCrJcBLmCcPNIG3STN5BDOTgl9wVSG3dBe+GPtml+KbL7Zs/t7f8/lZ8jdbRwd M/N/q93brjtmsPVfF2tafe3GF037NLcfY7AFSwml3+XhJVkIeUNwYXWHnf8AvNsTPVfTPHOr 6g81k6aba3di9213PdELEy2627Mh8uWQQn/ScF98mzyySpJ2qAdJNo2sajYm21bVLGXbd2tz G1pYPDjyZllKkNM+d2wDIxjk89KNM8Mf2dqlve/bPM8n+0Pk8rGftVys/XP8O3b75zx0rl9F 8deItWbT7oaVB9gP2GK7kHlonmXEUMhKyPOGXHnqAgicttADZf5bnjzUNVsb8vb3ka2MGhal fNbASI0ksSIqkyRyKQP33A7YJ+9saMAjt/hikGqQXw1GASReWrOlgqyXAS5gnDzSBt0kzeQQ zk4JfcFUht3YaFpn9ieHtM0nzvO+w2kVt5u3bv2IF3YycZxnGTXn8fjDxFam/gsLL7bHp8t5 dXMs7x4Mf226REMkk0fkqqwEbsSAA/dAUBvUKAPM9G/1N/8A9hXUP/SuWun8Pf8AH/J/1yP8 xXMaN/qb/wD7Cuof+lctdP4e/wCP+T/rkf5imMl8Cf8AJPPDX/YKtf8A0UtdBXP+BP8Aknnh r/sFWv8A6KWugpCOf8G/8gO5/wCwrqX/AKWzUeHv+Q54s/7Csf8A6RWtHg3/AJAdz/2FdS/9 LZqNL/0bxp4gs05jmitNQYnqJHEkBA/2dtrGQOuS3OCAACvrniy40jUdRhj0r7Ra6bp8epXd wbgJtiJmDKq4JaTEJKjhTzlkwN1PUvHjaQ7WupWNpYXjvCYReagscCpKszL50u0iN8W8oKqH G4oAzBiV3NS8N2eqf2v58k6/2rp66fPsYDbGPNwVyDhv3zcnI4HHXMepeF7bUNUbVBd3drfh IVingKEwmPzgGUOrKSVuJVO4EYIwAQDQBjy/ECE6Jp+oQJpqJdvOhuL3URBZhoX8tgs4RtxZ gWQbRuRWb5cYq4PFsreI4dJNhBBI2wNb3V8kd425AxeKHBWWNMkMwk6xygBio3aE2hSvZ20U GuarbTw7t10kiO8u45bcsiNHycEYUbfuptUlTXXwjZxfY4Iby+j0y18gppvmh4S0O3yjllMg 2mOM4VwpK5IO5twBlxfEK2juNTivYrQPY2VxfPBY36XM8SQlQ6TIABHL84AUM4JDjd8oJkuv GtxpS6qmsaXBZzWEVo/mC+DQObiV4kPmFQVjUqNzMoI+bCkKC0n/AAgtjBbyqsl3eoumT6Zb 2V1c7IEt5AmIQUXKgeWB5nzPgncXwuK+k+EL6Y6nc6/dyNd3iWqh47rz2R7eR5I5Q3lRopDO vyCPb+7y24u1AGp4f8S/8JHpN9PZLYzXVpK1ufs1751tJJ5auu2YJkrh1BOzIIYYOMnk9I8U a5No8F1d3cn2u8TRrwqDE0UUd3dmNo4wIlYDYv8AGzkbsBiV3N6Bptg2n27RyX13eyu5d57p lLMcADAUKigAAYVQOpOSSTj2/grTba1t7dJ7spBb6fbqS65K2cpliJ+XqWOG9R0x1oAp2Hj6 zvvFC6Opsf3t3PZxxpfB7tZIRJuaSDb8kZ8p8NuJOY+BuO3Q8d/8k88S/wDYKuv/AEU1WLPw +ljqLXEOoXwtTLJOlhvUQpLIWZ2yFDtlnc7WZlBbIA2rtr+Mf9J0P+x15k1mVdP2jgmN8mcq egZYFmcE8ZUDBJCkA6CiiigAooooAKKKKACiiigAooooAKKKKACuf8Zf8gO2/wCwrpv/AKWw 10Fc/wCMv+QHbf8AYV03/wBLYaAPP/D3/J0Piz/sFR/+g2tewV4/4e/5Oh8Wf9gqP/0G1r2C gAooooAKKKKACiiigAooooAK8f8AhB/yUP4nf9hUf+jbivYK8f8AhB/yUP4nf9hUf+jbigD2 Cuf8G/8AIDuf+wrqX/pbNXQVz/g3/kB3P/YV1L/0tmoALz/koejf9gq//wDRtpWxc2Fnebvt VpBPuieA+bGGzG+N6c/wttXI6HAz0rHvP+Sh6N/2Cr//ANG2ldBQBTudJ029t7m3u9PtJ4Lp w9xHLCrLMwCgFwRhiAiAE/3R6Co5dC0eb7D5ulWMn9n4+xbrdD9mxjHl8fJjavTH3R6VoUUA Z76Fo8l5dXkmlWL3V3EYLmZrdC80ZABR2xllwAMHjgVn6l4Rsb6K0itZP7MjtZVnRLS0tiPM RVSN8SxPhkVQqlcEDjoBjoKKAMu08N6LZPYSwaXaCfT7dbW0naIPLDEqlQiyHLYwSOvc+pq5 c2FnebvtVpBPuieA+bGGzG+N6c/wttXI6HAz0qxRQBnzaFo9xLbSzaVYySWsrT27vboTFIzb 2dSR8rFvmJHJPPWtCiigDzPRv9Tf/wDYV1D/ANK5a6fw9/x/yf8AXI/zFcxo3+pv/wDsK6h/ 6Vy10/h7/j/k/wCuR/mKYyXwJ/yTzw1/2CrX/wBFLXQVz/gT/knnhr/sFWv/AKKWugpCOf8A Bv8AyA7n/sK6l/6WzVY1uxuDLbatp0fmajZZVYywAmgdkM0XOBuIQFTlcOi5YKWBr+Df+QHc /wDYV1L/ANLZq6CgCvY31vqNnHdWsnmQvkAlSpBBIZWU4KsCCCpAIIIIBFWKx77QEkvJNR0y f+zdTkx5txDErC5AACrOpH7xRgc5VwMhXXcc1/tPjCP5P7K0O428ed/ac0Pmf7Xl+Q+zPXbu bHTcetAHQUVz/wBs8Yf9ALQ//BzN/wDItH2zxh/0AtD/APBzN/8AItAHQUVycmveKotZttLb QNG8+4t5rhGGsS7QsbRqwP8Ao2c5lXHHY9O9z7Z4w/6AWh/+Dmb/AORaAOgorn/tnjD/AKAW h/8Ag5m/+RaPtnjD/oBaH/4OZv8A5FoA6Cufsf8Aifa5HrA+bS7WIpp7HpNI+RJOB3UKFSNx gkPMRlHVif2Bcav83iWeC8gPI0uKIfZFPUb9wLTMuSMnahwreWrKCOgoAKKKKACiiigAoooo AKKKKACiiigAooooAK5/xl/yA7b/ALCum/8ApbDXQVz/AIy/5Adt/wBhXTf/AEthoA8/8Pf8 nQ+LP+wVH/6Da17BXj/h7/k6HxZ/2Co//QbWvYKACiiigAooooAKKKKACiiigArx/wCEH/JQ /id/2FR/6NuK9grx/wCEH/JQ/id/2FR/6NuKAPYK5/wb/wAgO5/7Cupf+ls1dBXP+Df+QHc/ 9hXUv/S2agC5qvh/T9ZuLe4u/taz26OkUlrezWzBXKlgTE6kglEODnoKp/8ACG6X/wA/Wuf+ D29/+PV0FFAHmf8AY0f/AEEtc/8AB3ef/HaP7Gj/AOglrn/g7vP/AI7XT/8ACPXf/PSD/vo/ 4Uf8I9d/89IP++j/AIUxnMf2NH/0Etc/8Hd5/wDHaP7Gj/6CWuf+Du8/+O10/wDwj13/AM9I P++j/hVOOwll1m50tWTz7e3huHYk7SsjSKoHGc5ibPHcdewBif2NH/0Etc/8Hd5/8do/saP/ AKCWuf8Ag7vP/jtdP/wj13/z0g/76P8AhR/wj13/AM9IP++j/hQBzH9jR/8AQS1z/wAHd5/8 do/saP8A6CWuf+Du8/8AjtdP/wAI9d/89IP++j/hR/wj13/z0g/76P8AhQBg2NjBp1qLe3Eg j3u5MkrSMzOxZiWYkklmJyT3re8Pf8f8n/XI/wAxR/wj13/z0g/76P8AhV7StKnsbppZXjKl Cvyk56j29qAK3gT/AJJ54a/7BVr/AOilroK5/wACf8k88Nf9gq1/9FLXQUhHP+Df+QHc/wDY V1L/ANLZq6Cuf8G/8gO5/wCwrqX/AKWzV0FABRRRQAUUUUAeZ698SvCWj/Ea0TUNTkt3sLK8 trlXs58pI8lsyD7nIKxsQwyCADnkZ9Mrw/xx4C/tj4/eHbgWX+gX0S3N5IyeckjW5+dXUn5V K+RHkgL846nIPuFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFc/4y/wCQHbf9 hXTf/S2Gugrn/GX/ACA7b/sK6b/6Ww0Aef8Ah7/k6HxZ/wBgqP8A9Bta9grx/wAPf8nQ+LP+ wVH/AOg2tewUAFFFFABRRRQAUUUUAFFFFABXj/wg/wCSh/E7/sKj/wBG3FewV4/8IP8Akofx O/7Co/8ARtxQB7BXP+Df+QHc/wDYV1L/ANLZq6Cuf8G/8gO5/wCwrqX/AKWzUAdBWHP4iaS4 ltdI0u71OWNzFJMm2K3icHGGlcjcAwYN5QkKlWBXOAS8nm1fVJ9GtZZILe3RGvrmJiH+fJEE bD7jlQGZshlV028uHTYgghtbeK3t4o4YIkCRxxqFVFAwAAOAAOMUAYf2zxh/0AtD/wDBzN/8 i0fbPGH/AEAtD/8ABzN/8i10FFAHP/bPGH/QC0P/AMHM3/yLWfDb+MIvEN7q39kaGftNpBbe V/a83y+U8zbs/Zuc+djGONvfPHYUUAc/9s8Yf9ALQ/8Awczf/ItH2zxh/wBALQ//AAczf/It dBRQBz/27xZH88ugaU8a8stvq7tIw7hA9uqlvQMyjPUgc1YsfElndXkdhdRz6bqUmdlnfKEe TAJPlsCUlwvJ8tm25G7B4rYqnqumw6vpdxYTtIiTJgSREB4m6q6Eg7XVgGU9iAe1AFyisvSt SmnuLjTb9Y11K0RHlMQPlyxuWCSpkkqGKOChJKlSMsNrtqUAc/4E/wCSeeGv+wVa/wDopa6C uf8AAn/JPPDX/YKtf/RS10FAHP8Ag3/kB3P/AGFdS/8AS2ajxmX/AOEfSOOeeHztQsYXeCZo n2PdxIwDqQwyrEcEdaPBv/IDuf8AsK6l/wCls1HjL/kB23/YV03/ANLYaAD/AIQ3S/8An61z /wAHt7/8eo/4Q3S/+frXP/B7e/8Ax6ugooA5/wD4Q3S/+frXP/B7e/8Ax6j/AIQ3S/8An61z /wAHt7/8eroKKAObPgbRWuEuGl1kzojIkh1u93KrEFgD5uQCVUkd9o9Kk/4Q3S/+frXP/B7e /wDx6ugooA5//hDdL/5+tc/8Ht7/APHqP+EN0v8A5+tc/wDB7e//AB6ugooA5/8A4Q3S/wDn 61z/AMHt7/8AHqr6HaDTPGWsWEFzfSWq6fZTKl3ezXO12kuQxBlZiMhF6egrqK5RtQhsPiHq 3mq536VY42gdpbv396AOrorOttZt7u4WCNJQzZwWAxwM+taNABRRRQAUUUUAFFFFABRRRQAU UUUAFc/4y/5Adt/2FdN/9LYa6Cuf8Zf8gO2/7Cum/wDpbDQB5/4e/wCTofFn/YKj/wDQbWvY K8f8Pf8AJ0Piz/sFR/8AoNrXsFABRRRQAUUUUAFFFFABRRRQAV4/8IP+Sh/E7/sKj/0bcV7B Xj/wg/5KH8Tv+wqP/RtxQB7BXP8Ag3/kB3P/AGFdS/8AS2augrn/AAb/AMgO5/7Cupf+ls1A B4R/e2OpXr83Fzqt55r/AN7ypmgTjoMRwxrx125OSSTT8V+JJtG1nS7JdZ0bSILq3uJXudUj LKWjaEKi/vYxkiRj1P3elXPBv/IDuf8AsK6l/wCls1Saxo+pXWs2OqaXqNpaT2tvPbst1ZtO rrK0TZG2RCCDCO56mgCuPFENno2l3MlxHrcmoXDW0E2jQgxzSBZHAAMjBRiMqWLkA8sVXJUt /GljO6BrLUoo2eWDzWt9w+0RK7SQKqks7qI5PmQMhKlVctxVx9JvLttFnv72CS6067e5doLY xpLmKWIKFLsVwJQc5OdvbPGfN4O8/Trez/tOeHytQvb3zrddkg+0C5GEbJ2sv2nIbnlOgzwA SSeKgIpEmsrvTryK4s0e3ukjkby7icRIw8uQrgkOPvZXaSVIwGk07xJv8DaVr9/Hma8tLaQw 26/fmmCBUTceMu4UbjgZ5IGTWPp/w7Sxe8kS5sYGu5bCV4rDTVtoUNrcGX5UDE/OCASzMQcn OMIuwnhjy/BenaALz95p8VqIrkxcNJblGRmTP3S0a5UMDgkBgeaAKfiXxbNpGh2epR28luJX uFnjurctJF5VrcSnCh1DENCBw21hna2CGrQuPFFtbao9obS7eCG4itJ71QnlQzybPLjYFg5J 82LlVKjeMkYbbT8Q+E7jxHoEGn3eq/6Qn2gyXAtxhjLbzQ4VARhV8/IBJOEAJJJao7jwPbT+ LH1sLprGa4iuZHn01JbpXjVFURTMcImI142EglyGUkFQCxB4ytrm4aGHTdSb/SLizhkaNFWe 4hMm6JCzjJKxOwY4TjBYMCoueFNWuNe8JaTq13bfZ7i8tI5pIxjGWUHK4ZvlPUZOcEZwciq9 v4Y+z/2b/pm77Fqt3qX+qxv8/wC0fJ142/aOvOdnQZ4ueG9Km0Pw1pukz3Md09lbpbiZIjEH VBtU7SzYO0DPPJyeOgAKes/6N4q8NXicyTS3GnsD0EbwtOSP9rdaxgHpgtxkgjoK5/xD/wAh zwn/ANhWT/0iuq6CgDn/AAJ/yTzw1/2CrX/0UtdBXP8AgT/knnhr/sFWv/opa6CgDn/Bv/ID uf8AsK6l/wCls1HjL/kB23/YV03/ANLYaPBv/IDuf+wrqX/pbNR4y/5Adt/2FdN/9LYaAK/x BtvtnhM2u2BvO1CwjxcRebGc3cI+dMjcvPK5GRxkVy/jnTE8PeAEsoLXSoWn+3mf7Bp628bH +z7shlQlijYVQWDZIBGcEivUKKAPP9G1/XbvxzJaXN/YiH7Xcwyab54aaKBC4jl8lYQ8e4LG 295ShEnABdAM/wAWLKvjPVEi1bZdTRaG9vbTIjIuNRK7toCuyq2Cfm/5akE/c2+gQ67o9xLc xQ6rYySWsqwXCJcITFIzbFRgD8rFvlAPJPHWga7o7SwxDVbEyTRJPEguEzJG7BEdRnlWZlUE cEkAcmgDg9X1/XLKW50qPWJFNpevAt7MIopLj9xbyrHuEEitKTO4WJIdzhOCCjCS58MNRl1U a5fXWoedeXktpeS2w2AQ+bZQOCoA3BTkoNxPEQ5Lbi3UWHinRNQntrWLVLEX9xEkq2X2uJ5g GQSD5UY5+U5ypII5BI5on8UaPGs3k30F3Jb3cFncRWsqSPDJLKIlDgH5fmPOeflPBIxQBxeo eKvFek2V1N5Md0dJQWFwTEGNzdskvlvsT5su32EhU4UXTqclcx5+meK9fbS9QtLzxNpryW6W kg1dJl8hzJ5wcLcfZhFGm6EAExyDcWj372Gz0iy8Q6be2t3cfaY4Es3mFwJ3VTEsUskRdueE LQyEE9lPTBA1KAMvw5eNqHh+zunuJLjzEJEskSozrk4J2koxxj50+R/vJ8rCuW1j/koeof8A YKs//Rt1Xe1wWsf8lD1D/sFWf/o26oA0dG/5C0H/AAL/ANBNdZXJ6N/yFoP+Bf8AoJrrKACi iigAooooAKKKKACiiigAooooAK5/xl/yA7b/ALCum/8ApbDXQVz/AIy/5Adt/wBhXTf/AEth oA8/8Pf8nQ+LP+wVH/6Da17BXj/h7/k6HxZ/2Co//QbWvYKACiiigAooooAKKKKACiiigArx /wCEH/JQ/id/2FR/6NuK9grx/wCEH/JQ/id/2FR/6NuKAPYK5/wb/wAgO5/7Cupf+ls1dBXP +Df+QHc/9hXUv/S2agA8G/8AIDuf+wrqX/pbNWXqOsalo3iXxXqEs8dzp+naFBeRWQVkO4G4 P39xAJ8tgSE5BT+582p4N/5Adz/2FdS/9LZq0JtE0641G4vp7fzZrm0FlOruzRywgsQrRk7G 5duSM4YjOCRQBT0e/wBS/tm+0jVJbS4ntreC6W4tYGgUrK0q7CjO5yDCTu3c7gMDGTl3HiTW I/DniHXo47E2tlFf/ZomV96SWzug3nOJFcxluNhXhfnzuHQaZotlpHmm1WdpJcB5rm5kuJGA zhd8jM20ZYhc4BZiBknNeTwto039oCSz3LfxSQzr5r7dkn+sCDOI95+Ztm3cwDHJANAHN614 t1zSb17IWsc15bWSX0lvaabc3YuC7yhYFkTiIgRbfNcEMW3bFClauaz4qutM8Qx26PBLa/a7 a0eCKynlbMzom57kfuoWHmBvLYElQvI8wbdzUvD2matcLPeQSM4QRuEnkjWZASQkqqwEqct8 rhh8zcfMcx3vhbRtQ1Fb+6s/MnWWOcfvXCCWMqUl2A7fMG1V343FRtJ28UAcXY+Jtc0+zt7G 4vo5ru5vdUcXSaTc3mxILry/L8mOQuAS+Q27CKqpgnDV3EGqzSeFYtXuLaOxnayF1Jb3kpiW Btm4pI5XKhTwW28YJx2qu/hHR2R1WO7iLXEtz5kF9PE6vK26QK6uGVGYBigIUkA4yM1qfYLP +zv7O+yQfYfK8j7N5Y8vy8bdm3ptxxjpigDg4PGeuXGrW+jW4tJrua4iQ3N1plzYqqSQ3T8Q yMXYqbbOdwD7ivyEFx2Hh/UptV0nz7hYxPHcXFrIYwQrtDM8RcAklQxTdtycZxk4ya9n4Q0O wv0v4LSQ3iurm4luJZZHZUlRS7OxLkLNIoLZ4IHRVxqWdjb6fA0NrH5cbSyTEbicvI7SOefV mY+2eOKAMfxD/wAhzwn/ANhWT/0iuq6Cuf8AEP8AyHPCf/YVk/8ASK6roKAOf8Cf8k88Nf8A YKtf/RS10Fc/4E/5J54a/wCwVa/+ilroKAOf8G/8gO5/7Cupf+ls1HjL/kB23/YV03/0tho8 G/8AIDuf+wrqX/pbNR4y/wCQHbf9hXTf/S2GgDoKKKKAPO38Cale6dpOm366a9ppFvBYoDI0 gvYVuLWR2kQoBGSlrjZlwTJgsAMmPXbG6uPFEmn2tn9oWbW7HVTNLYz/ALoxCBXVJCgiGI4m bzPMyctGEyc1nr8RtRvzKukX+lXklxd2strGtwoKW7XvklWCq5TdG1qSHAcGeUjlPLXYtPGe t2uio95pkF3qEuoX0SRwzSyBYoZ2TpFA0h2nCg+XtwAWZWdVIBJovgrUtN8KjS5p7Rpxe6Xc bkdiu22SzWQcrnJNs+OO65xk4z4Ph7rMeoafM9zaeVZpDFj7VO4k8u7tZjIkbfu4AywOBDGo VDtG5gRs6TR/Flx4haO60rSvM0z9wJpJbgJOhlijmBWPBVlVJkLHzAeHwGwu7D034gX1p4T0 m81nTJHub3TIbi3eN973DloImZ0jQ7A0lxGyhA5Kk/KGAQgFiTwpMl3YWriRhd3t62oeRnyp LNrh7lFkJGGO5o49hzlJ7gAEFmHeVx9l4zv77yLeLw9Ot+3nSPDK0kCvFF5W5ojNGjOx89AA 6xqWDgsAoZtjwnfXGp+DdDv7yTzLq60+3mmfaBudo1LHA4GST0oA2K4LWP8Akoeof9gqz/8A Rt1Xe1wWsf8AJQ9Q/wCwVZ/+jbqgDR0b/kLQf8C/9BNdZXJ6N/yFoP8AgX/oJrrKACiiigAo oooAKKKKACiiigAooooAK5/xl/yA7b/sK6b/AOlsNdBXP+Mv+QHbf9hXTf8A0thoA8/8Pf8A J0Piz/sFR/8AoNrXsFeP+Hv+TofFn/YKj/8AQbWvYKACiiigAooooAKKKKACiiigArx/4Qf8 lD+J3/YVH/o24r2CvH/hB/yUP4nf9hUf+jbigD2Cuf8ABv8AyA7n/sK6l/6WzV0Fc/4N/wCQ Hc/9hXUv/S2agA8G/wDIDuf+wrqX/pbNXQVz/g3/AJAdz/2FdS/9LZq6CgArm/GGpahYw6Xb 6ct2Zb+9+zsbIQ+eFEMsuY/OPl5zGAd2flLY5wR0lV76ws9Ts5LO/tILu1kxvhnjEiNggjKn g4IB/CgDi7K/8Q6td6Lp76nJpxmt9Ra5aNLeWc+RcRRx5Yb4llw3z4BXJcBVO0pTt/E2sjTN IvLzU/n13ShdiO3tExbymS2RI4Ax+8/2nbulZlD7WIVAyn0CGws7f7P5FpBF9miMEGyML5UZ 25RcfdX5F4HHyj0FRnSdNa3S3bT7QwJbtapGYV2rCwAaMDGAhCqCvQ7R6UAcPo2v3mpX2nW9 w0khtPEctiXu1t3nwNPkkYM0OY1cOzLlMHaNp53Z6TwJ/wAk88Nf9gq1/wDRS1qQaTptqIhb 6faQiJw8YjhVdjCPygRgcER/Jn+7x04qT/Q9L07/AJYWdjaxe0ccMaj8AqgD6ACgCxRWXbeI NPuhbFftcJurg20K3VlNAzyCNpCAsiKcbUY7unBGc8VqUAc/4h/5DnhP/sKyf+kV1XQVz/iH /kOeE/8AsKyf+kV1XQUAc/4E/wCSeeGv+wVa/wDopa6Cuf8AAn/JPPDX/YKtf/RS10FAHP8A g3/kB3P/AGFdS/8AS2ajxl/yA7b/ALCum/8ApbDR4N/5Adz/ANhXUv8A0tmo8Zf8gO2/7Cum /wDpbDQB0FV7+xt9T065sLyPzLW6ieGZNxG5GBDDI5GQT0qxRQBl654e0zxHb20GqQSSpbXC 3UJjnkiaOVQQrhkYEEbj3qu/hDQ5EdHtJGR7iW4ZTcSkMZW3Sofm5idhlov9Wx5KmtyigDDt /CGh2j2rQWkkaWqRLHCLiXyj5ahY2ePdsd1Cph2BYbE5+UYkbwtozWdnamz/AHNlafY7YCVw YosxkbWzkMDDGQ+dwKAgg1sUUAYZ8IaG9ukMlpJIFdmZ5LiV5JtwAZZXLbpUYKgKOWUhEBBC qBqWFjb6Zp1tYWcfl2trEkMKbidqKAFGTycADrViigArgtY/5KHqH/YKs/8A0bdV3tcFrH/J Q9Q/7BVn/wCjbqgDR0b/AJC0H/Av/QTXWVyejf8AIWg/4F/6Ca6ygAooooAKKKKACiiigAoo ooAKKKKACuf8Zf8AIDtv+wrpv/pbDXQVz/jL/kB23/YV03/0thoA8/8AD3/J0Piz/sFR/wDo NrXsFeP+Hv8Ak6HxZ/2Co/8A0G1r2CgAooooAKKKKACiiigAooooAK8f+EH/ACUP4nf9hUf+ jbivYK8f+EH/ACUP4nf9hUf+jbigD2Cuf8G/8gO5/wCwrqX/AKWzV0Fc/wCDf+QHc/8AYV1L /wBLZqADwb/yA7n/ALCupf8ApbNXL23hWKSXT5Z9MnMl34g1EXzsHBe0LXbpG5/592YRNs/1 bFgSCWOeo0X/AIluuato7/JHJKdQsl7GOTBlAJ5ZhP5jsOQomjGQCFHQUAeV6hpV79j0uO6s o20u2uNUi+z3mjS6jEn+lD7Ntt4yGAEKuEfG1UO0Y3jNi00m5stb0k3Nnd6hqSJZq899YObg BUjWRkvY5GSFBh3aFiS7eaMsJVJ9MooA83ewnt/EeoyWejT314/2pmZreWyuSrI5QG/V/Llj JKIkY+aMNGxw0Jxn6fp1+LbXIYdL8rSW/s2UQ2ejyWENxEty5usW7MzMxiXawIDOoUbWBQt6 xVe+sLPU7OSzv7SC7tZMb4Z4xIjYIIyp4OCAfwoA8f8A7OE2q6g0Gl+XoUeoTD7JqGjzaiiO 1rYmE/ZkbdH8gl2kgeWp2EIWCjuNc0m4uPhBe6XdQz6hfDRGjKzxiSaWdYflJAL5k3gHhm+b oT1rqLGws9Ms47OwtILS1jzshgjEaLkknCjgZJJ/GrFAHl+u6HqirqdvodhPBINVlNj9nTyl jH9imKNkbgIokwgbIAbjINbngSwNpcalNDHHBZyJCqQW+iyaXAJFMhdhFI5YuQyBn2gEKgBY qQvaUUAc/wCIf+Q54T/7Csn/AKRXVdBXPr/xO/FEc6/Np2kb/LkH3Zbxg0bYPH+qTep6qWmY cNEcdBQBz/gT/knnhr/sFWv/AKKWugrn/An/ACTzw1/2CrX/ANFLXQUAc/4N/wCQHc/9hXUv /S2atDWtJTW9MNlJcz2372KZJoNu9HjkWRSNysv3kHUGs/wb/wAgO5/7Cupf+ls1dBQBz/8A wj2qf9Dnrn/fmy/+R6w9QttctL6SCPxfq5VcYLQWeeQD/wA+9d5XPanpl5cahLLFDuRsYO4D sPegDm/+J/8A9Ddq3/fiz/8AjFH/ABP/APobtW/78Wf/AMYrZ/sbUP8An3/8fX/Gj+xtQ/59 /wDx9f8AGmM5ea98Rx+ILOwHi3U/KmtZ5mJt7PcGR4gMfuOn7xs/QVf/AOJ//wBDdq3/AH4s /wD4xTbrSb4eN9KjMHzHTbwgb16CS2z39xW3/Y2of8+//j6/40AY3/E//wChu1b/AL8Wf/xi j/if/wDQ3at/34s//jFbP9jah/z7/wDj6/40f2NqH/Pv/wCPr/jQBjf8T/8A6G7Vv+/Fn/8A GKZbWM8eo3F/eand391NFHCXuFiXaiFyoAjRR1kbrmtz+xtQ/wCff/x9f8aP7G1D/n3/APH1 /wAaADRv+QtB/wAC/wDQTXWVz2maZeW+oRSyw7UXOTuB7H3roaQgooooAKKKKACiiigAoooo AKKKKACuf8Zf8gO2/wCwrpv/AKWw10Fc/wCMv+QHbf8AYV03/wBLYaAPP/D3/J0Piz/sFR/+ g2tewV4/4e/5Oh8Wf9gqP/0G1r2CgAooooAKKKKACiiigAooooAK8f8AhB/yUP4nf9hUf+jb ivYK8f8AhB/yUP4nf9hUf+jbigD2Cuf8G/8AIDuf+wrqX/pbNXQVz/g3/kB3P/YV1L/0tmoA 0NT0lNS8qVLmezvIciG7ttvmRhsbl+ZWVlbAyrAjIU43KpFODX1tLiLTtdaO0vncRxTFWS3u 2JwvlueA7c/uixcENjcoDtuVHPBDdW8tvcRRzQSoUkjkUMrqRggg8EEcYoAkorn/APhBPB// AEKmh/8Aguh/+Jo/4QTwf/0Kmh/+C6H/AOJoA6Ciuf8A+EE8H/8AQqaH/wCC6H/4mvN/DI8J 638ZvE/h+PwtoctjaWiLC4sEUI8LbZQUK8sXmILDHES9etAHtFFc/wD8IJ4P/wChU0P/AMF0 P/xNH/CCeD/+hU0P/wAF0P8A8TQBuTzw2tvLcXEscMESF5JJGCqigZJJPAAHOaw/7VvNe/d6 EPKsW+WTVJVK8HnNujLibI6SH938ykebhlqSDwX4VtbiK4t/DWjQzxOHjkjsIlZGByCCFyCD zmtygCvY2Nvp1nHa2sflwpkgFixJJJZmY5LMSSSxJJJJJJNWKKKAOf8AAn/JPPDX/YKtf/RS 10Fc/wCBP+SeeGv+wVa/+ilroKAMOfwX4VuriW4uPDWjTTyuXkkksImZ2JySSVySTzmo/wDh BPB//QqaH/4Lof8A4mugooA5/wD4QTwf/wBCpof/AILof/iaP+EE8H/9Cpof/guh/wDia6Ci gDn/APhBPB//AEKmh/8Aguh/+Jo/4QTwf/0Kmh/+C6H/AOJroKKAODuvBfhVfHWk26+GtGED 6Zeu8YsItrMstqFJG3BIDMAe24+tbn/CCeD/APoVND/8F0P/AMTXhHxG8CpqPx+sdKth+51z ybqZIFWIxJlhMwJ4LYieTOOS3Qnr9L0Ac/8A8IJ4P/6FTQ//AAXQ/wDxNH/CCeD/APoVND/8 F0P/AMTXQUUAc/8A8IJ4P/6FTQ//AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTXQUUAc/8A8IJ4 P/6FTQ//AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTXQUUAc/8A8IJ4P/6FTQ//AAXQ/wDxNH/C CeD/APoVND/8F0P/AMTXQUUAc/8A8IJ4P/6FTQ//AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTX QUUAc/8A8IJ4P/6FTQ//AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTXQUUAc/8A8IJ4P/6FTQ// AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTXQUUAc/8A8IJ4P/6FTQ//AAXQ/wDxNH/CCeD/APoV ND/8F0P/AMTXQUUAc/8A8IJ4P/6FTQ//AAXQ/wDxNSQeC/CtrcRXFv4a0aGeJw8ckdhErIwO QQQuQQec1uUUAeP+Hv8Ak6HxZ/2Co/8A0G1r2CvH/D3/ACdD4s/7BUf/AKDa17BQAUUUUAFF FFABRRRQAUUUUAFeP/CD/kofxO/7Co/9G3FewV4/8IP+Sh/E7/sKj/0bcUAewVz/AIN/5Adz /wBhXUv/AEtmroKw5/BfhW6uJbi48NaNNPK5eSSSwiZnYnJJJXJJPOaANyiuf/4QTwf/ANCp of8A4Lof/iaP+EE8H/8AQqaH/wCC6H/4mgDoKK5//hBPB/8A0Kmh/wDguh/+Jo/4QTwf/wBC pof/AILof/iaAOgryfwt8LdH0H4q3Woxahqt1dWVpFeLJdzI5lkuDcxyFzsBPCAjock5JruP +EE8H/8AQqaH/wCC6H/4msO18F+FW8datbt4a0YwJplk6Rmwi2qzS3QYgbcAkKoJ77R6UAd5 RXP/APCCeD/+hU0P/wAF0P8A8TR/wgng/wD6FTQ//BdD/wDE0AdBRXP/APCCeD/+hU0P/wAF 0P8A8TR/wgng/wD6FTQ//BdD/wDE0AdBRXP/APCCeD/+hU0P/wAF0P8A8TR/wgng/wD6FTQ/ /BdD/wDE0AHgT/knnhr/ALBVr/6KWugqOCCG1t4re3ijhgiQJHHGoVUUDAAA4AA4xUlABRRW Prd9cCW20nTpPL1G9yyyFQRDAjIJpecjcA4CjDZd1ypUMQAF9r6R3kmnaZB/aWpx4823hlVR bAgFWnYn92pyOMM5GSqNtOK/2bxhJ8/9q6Hb7ufJ/syaby/9nzPPTfjpu2rnrtHSqfiLUF8I 6bo9tYXmm6Xb3F6beS61INJHGDFNKWYmRCzs6DLM2SXJOSajsfGmywje5T+1Gm1A2Fnc6TDm K9byDMGQF2CqCHiJ3lQyEsVG7aAaH2Pxh/0HdD/8E03/AMlUfY/GH/Qd0P8A8E03/wAlVJb+ KLa51RLQWl2kE1xLaQXrBPKmnj3+ZGoDFwR5UvLKFOw4Jyu6ODxdZz6O+pizvlt28k2paID7 YszBYTGd20b2IGHKsuQXCAg0AZ9z4a8SXeuWGrzazob3VhFNFb50WQhPN2bmGbnIbCYBBHDM Oc1ofY/GH/Qd0P8A8E03/wAlUf8ACWQfZc/2dff2h9r+xf2b+687zvK87bu3+V/qv3md+McZ 3fLQ/itBKsUej6rLMkQmu4khXfaIWdQWUsC/McmPKEm7ZlchkLAB9j8Yf9B3Q/8AwTTf/JVH 2Pxh/wBB3Q//AATTf/JVSa7rV3pereH7S3sJLiPUb1reaRSn7pRDI+eXU5ym7oflRx94qDl6 B48t77w9aahq1vPYs+lf2k8rQkRyoiIZ2jXJfajOo+YDcCCm8c0AaH9v3GkfL4lggs4BwNUi lH2Rj0G/cQ0LNgnB3IMqvmMzAHoKy9K1oalcXFpNYXen3luiSPbXRjLeW5YI4MbuuCUcYzn5 TkAEE07H/iQ65Ho4+XS7qIvp6npDImTJAD2UqVeNBkgJMBhEVQAdBRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQB4/4e/5Oh8Wf9gqP/0G1r2CvH/D3/J0Piz/ALBUf/oNrXsFABRRRQAU UUUAFFFFABRRRQAV4/8ACD/kofxO/wCwqP8A0bcV7BXj/wAIP+Sh/E7/ALCo/wDRtxQB7BRR RQBz+s3usf8ACQ6bpOk3NjbfaLS5uZJbu1ef/VvCoUBZExnzicknoKPsfjD/AKDuh/8Agmm/ +SqLz/koejf9gq//APRtpXQUAc/9j8Yf9B3Q/wDwTTf/ACVR9j8Yf9B3Q/8AwTTf/JVdBRQB z/2Pxh/0HdD/APBNN/8AJVU49B8VRazc6ouv6N59xbw27qdHl2hY2kZSP9JznMrZ57Dp36yi gDn/ALH4w/6Duh/+Cab/AOSqPsfjD/oO6H/4Jpv/AJKroKKAOf8AsfjD/oO6H/4Jpv8A5Ko+ x+MP+g7of/gmm/8AkqugooAx/DGoXmp6KZ78wNdR3d1bO0EZjRvKnkiDBSzEZCA4yetbFc14 QurePRrpJJ4lYarqOQzgEf6bNXQR3MEzbYpo3YDOFYE0AS0UUUAFc/pf+k+NPEF4nEcMVpp7 A9TIgknJH+ztuowD1yG4wAT0Fc/4e/5Dniz/ALCsf/pFa0AaGo6Z9vvtJufO8v8As+7a527c +ZmGWLbnPH+tznn7uO+Qajpn2++0m587y/7Pu2udu3PmZhli25zx/rc55+7jvkeZzajrMGk6 9d3epSS382ma6wngknhWL7LMkMflxeayIRkncAG+7yTuZ+ouvFuoJ4suNPtbWSWC1vbezkgT TbiUyCRYmaX7Sv7qIIJslGBJEZ5G8YANC18LzW+qW8jX8b6faXtxqFtALciUTTebv3ybyGT9 /LgBFI+TLHB3Vx4LaTwm3h671CO5s4Ut4rOOS1UoiQMrRiVScyliqh+VDAYVUJJMmuTawfGW j2mk3MEPm6fevIbkO8a7ZLbDeWpXew3FRllwHY5ONrY+q+Prq38PWWuW6QRxvpUeqS2S2k93 IwZC+xnjAW3X5SBK4YMdx2gRnIBqR+DBD4am0qL+xk8648+WBdHjFk/AG1oN2SPlVsmTdvAO do2VXuvAbXNhY2ZvrQpbo6iSXT1aS1LOWLWb7gbcrkKmTIEEcWB8pLXL3XdTtfFC2kggtrEy xxxie0mZbhXCjeLpf3cTbmKLE6lmZAMjzFIw9M+IOoT6NdaxNp8k1oNHl1VVGn3FqsBRVZYD NICkxYOcOgA/dk7SGGADsNX0qbUbrSLiC5jgfT737UQ8RkEimKSJk4ZdpKykhucEDg9Kx18D wvo2naXcX0jwWuhTaLI0cYVpFkWFTIMkhSBD0wfve3MmhzawPGWsWmrXME3lafZPGbYOkbbp LnLeWxbYx2hThmyEU5Gdqx2fiLUptUs5JRaf2ffandabFAsTCWJoPP8A3jSbiHDfZ2+UIuPM HzHb8wBc8MeGU8PfanEelRyXGwMumaatnHhc4JAZmZvmPJbGAMAHcWPGP+jaH/bC8SaNKuob hyRGmROFHQs0DTIAeMsDkEBhl+GvEWvaqmiG/GmxPq+mDUUEETkQqjQb1JLfMXWbI6eWRg+b 1Op47/5J54l/7BV1/wCimoA6CiiigAooooAKKKKACiiigAooooAKKKKACiiigDx/w9/ydD4s /wCwVH/6Da17BXj/AIe/5Oh8Wf8AYKj/APQbWvYKACiiigAooooAKKKKACiiigArx/4Qf8lD +J3/AGFR/wCjbivYK8f+EH/JQ/id/wBhUf8Ao24oA9gooooA5+8/5KHo3/YKv/8A0baV0Fc/ ef8AJQ9G/wCwVf8A/o20roKAOHv9T1a0k8W60uqztb6FKTHppii8mWNLSGZlLbPMDEu+G34B 2nawBU6l14omt9UuI1sI30+0vbfT7mc3BEomm8rZsj2EMn7+LJLqR8+FOBuj1W18I6PrA1TW NQgsri7lE4S81N4oZpI1RQ/ks4jZlCx87cgqp6gGrDWnhq+1i3vRcwS3Vx5U8ccd63l3B2s0 UpiDbJG2xEq5UnEQIPyDABT0/wAXX15LoMsmjRx6frj5tLhLzeyIYJJl81Cg2uVQDapcfey3 C78+f4g3xubmCx0COYwXEcDSTX3loC99NZrnCM2S0QfhSMFsnKqH3P8AhCtB6i1nVl4gZbyY NajutuQ+YFI+UrHtBUBSMACjTvC3hqK2ddNs4Ft/NQFYJW2K8Fy8yqADhdkzSHaMY+6RgYAB l33jyW3tbAW2kST39y90jwjzpEjNtKIZcNDDI5G8jaSigjk7ThSDxrqUoubmHQY47OG4trTF 3dtFcCa4jhaNXiETBQGuEVjvJADEBiAp2Lvw/oZS3t5fMtne4maBoL2W3laSVmmlVXR1chiG coDj5AcfKMWE8OaRFbyW8VjHFBJcQXJjjJVRJCIxEQAcKFEMQ2jA+XpycgFfwbf32q+CtE1D UzGby5soppWRshyyg7vuqASCCQBgEkAkDJ3Kp6Vpdpoul2+m2CSJaWybIkeV5Cq9huck4HQD PAwBwBVygDzPRv8AU3//AGFdQ/8ASuWun8Pf8f8AJ/1yP8xXMaN/qb//ALCuof8ApXLXT+Hv +P8Ak/65H+YpjOlooopCCuf8Pf8AIc8Wf9hWP/0ita6Cuf8AD3/Ic8Wf9hWP/wBIrWgCxL4W 0aeCWGSz3RyxXcLjzXGUuXEk46/xMAfbtgVJN4e0y41QajJBIZ96yMgnkEUjrja7xBtjuNq4 ZlJGxMH5VxqUUAZeq+HtM1q4t7m9gka4tkdIJ4p5IpIQ5UtsdGBUnYASDnGR0Yg19S8H6Bq1 uttd6bGbcW4tfIjdoo2iAIVGRCAwTJKZB2E5Xaea5fVvEusaKNV1KW7kdI0vRaIY4JbCV4Y5 XSNSjCdZQIjvL/LuSVRjKED6x4mtLO/tzPd2863Gmrby6stpLOPPuvKk3R2zBfK2gAZ2sSZM NwNoB2E3h7TLjVBqMkEhn3rIyCeQRSOuNrvEG2O42rhmUkbEwflXEdr4W0az88R2e+OaJoDD PK80aRN96KNHJWOM4AKIApCqMYUY5/8AtPVvtf8AYP8Aas+7+2/7P/tDyovtHl/YftecbPL3 bvkzsxs7bvmrHsdQ1uC0sNJtTfSTT3es3FxLpEdskhaK+28C5YosZMrEjJbO3BwGyAd5pXh/ T9GuLi4tPtbT3CIksl1ezXLFULFQDK7EAF3OBjqaIfD2mW+qHUY4JBPvaRUM8hijds7nSIts RzubLKoJ3vk/M2cPwRqms63JfXup3sBjj+zxpa2qIY1d7S3lciQFt67nbbg9GbJcFdvYUAZc Ph7TLdNOSGCSIadbi1tdk8imOING2zIbLAmGPOc5AIOQSDT8d/8AJPPEv/YKuv8A0U1dBXP+ O/8AknniX/sFXX/opqAOgooooAKKKKACiiigAooooAKKKKACiiigAooooA8f8Pf8nQ+LP+wV H/6Da17BXj/h7/k6HxZ/2Co//QbWvYKACiiigAooooAKKKKACiiigArx/wCEH/JQ/id/2FR/ 6NuK9grx/wCEH/JQ/id/2FR/6NuKAPYKKKKAOfvP+Sh6N/2Cr/8A9G2ldBXP3n/JQ9G/7BV/ /wCjbSugoA5fXNLvdQ8ZaPJa319YRxafeh7q0jjbBaS2whMiOoztY9ATsODgGqeqQalN8StL cRXb6fC9u4YKxiRvI1FXPoD80IJ90B6iu0ooA8/8BQ6+mol9Xvr6WY2n+nwzWc8caXOV+7JL KyNg+aB9nVYyOTgeWKz9NsTp1streR+I49ITUNUNwIGvmmMxuQbdg0eZWjMRkO5SYyxyxLkV 2k/i/Q7W4lhmu5EKOYw5t5fLllBwYo327ZZcgjy0LPlWGMqQI38aaInkrvvnml8zFvFpty8y bNm7fEsZdOJIz8wGQ6kZBFAGHrcGrzeHvBr6pFqT3sNxG+qtpygyp/ocyyn5Og3MQTH83OI/ nK1h3kPiuV7f/TtVtYRE/wDZe2zubiRm+0TeX5myVFDeT9l/4+8qSTuwRLnvPD/ie08RXWrR WaSGKwuEiSfY+ydWiSQOjFQCPmOME5AVs4dc7lABRRRQB5no3+pv/wDsK6h/6Vy10/h7/j/k /wCuR/mK5jRv9Tf/APYV1D/0rlrp/D3/AB/yf9cj/MUxnS0UUUhBXP8Ah7/kOeLP+wrH/wCk VrXQVz/h7/kOeLP+wrH/AOkVrQB0FFFed6xoNzKPF97b2kn2ubU7UK8kLyq9osdmZwsQI8xG VJA6JzJs2HJCgAHcR6TpsOqTapFp9omoTJslu1hUSuvHDPjJHyrwT2HpUdnoWj6fZmzstKsb a1MqzmGG3REMikFX2gY3AqpB6jaPSuDttKMWh2xu7KS50P8AtgzXFlFo0kEIt/srIFSyJeQp 9o2OQVzvJk27QHMfivR7+81GMLbzxRvpUEOnmfTZNSuba5Bl3mOZZQtvMN0OZXfDFVO/CEgA 9Al0/S9Siv7S506CeGWVTdRz2uUncKhDHcMSYAQbucbcZyuBHJ4a0GbS4dLl0TTX0+F98Vo1 qhiRueVTGAfmbkDufWuHvvD2pT+LtfMFtItnrl7HY3xZGxLbrb2zZzj5U8tb2LcpB8yVBnIB STUdJv5viBPM6bZG1C1ls510mSaZbZVh8xUu96xwxkrOGjPJDPgMZFBAO4v9Gs7+BomTyt93 BeSPCArSSQvG6ljjn/VIp77RjI4wf23p39sf2V9o/wBL6bdjbN23f5e/G3zNnz7M7tvzY281 l+DtKXT7PULh7aSK7utTvXkaXduZPtUxjxu6JtbcAMD5yw5Yk82v2+x8UXGoNp99cXTahLNd Q/YZHhtYQFiS4gb5Vkka3jjVlVnkBlYooxJE4B6RXP8Ajv8A5J54l/7BV1/6Kaugrn/Hf/JP PEv/AGCrr/0U1AHQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeP+Hv8Ak6HxZ/2Co/8A 0G1r2CvH/D3/ACdD4s/7BUf/AKDa17BQAUUUUAFFFFABRRRQAUUUUAFeP/CD/kofxO/7Co/9 G3FewV4/8IP+Sh/E7/sKj/0bcUAewUUUUAc/ef8AJQ9G/wCwVf8A/o20roK5+8/5KHo3/YKv /wD0baV0FABRRRQBxer+A21i9vZJ760EFw6yMn9nrvuGR1eNLk7ts0SlAANivtG3zBly9zQf B6aLqNteo9jG0cVzG8Fhp62sJMpg5VQSRgW4zuLEljyAAo6iigDm/B/hebwraT2jX8d3A6Ww TFuY2VoreKBiTvIIYQqwGBjJGW7dJRRQAUUUUAeZ6N/qb/8A7Cuof+lctdP4e/4/5P8Arkf5 iuY0b/U3/wD2FdQ/9K5a6fw9/wAf8n/XI/zFMZ0tFFFIQVz+h/uPEvie2k+WaW7hvUXrmF7e OJWz7vBKMdflzjBBPQVz9x/xK/GX9oT8WmpWkNkZjwsM0cjmNT/1089gCcANGq5LSKKAOgrl 7jx/oVt4c1rXJZJxa6Ndy2V0giJcTI4Tao6HcWTBzj5hkjBx1FeT6r4D1m7g1N44MyXEWpui b05cvfCBM7v+Wi35bP8AD5WDy3ygHcar4x0vRdO1e/vvPjtdKu4rW6cJuwZBEQwAOSoE6578 NgHjNw6/YjxUnhwNIdQaya+KhflWIOEBJ9SxOAM/dOccZw7zRNRl/tvZb5+0+INPvYvnX5oY vse9uvGPJk4PJ28A5Gc/wb4R1HQNYspbhd0MVpc2zvlRjYtlBE2Ax/1iWhlx/Du2nkZIB0Gh +J5teisrmLw7qtvY3kSzR3c722zYy7lJCzM/Ix/D35xzVgeKNH/4SG70Nr6BL61ihlkR5UH+ tcoqgZzuzs4x/wAtY+u4Vy/gbR7jSrXRbW80LxHbXVtaJFNPPrAltFdYtrYiFyw2k5CgR8ZH Axxoa5pUt1q3iFrk/Y7C60SBI9Vdk2Wk0Mk7byCwYMnmJIG4A2Z3AgUAdJPq2m2olNxqFpCI nKSGSZV2MI/NIOTwRH8+P7vPTmo5dd0eH7D5uq2Mf9oY+xbrhB9pzjHl8/PncvTP3h61w9xb XC6X4QvZ9K+1X97rb6nNZ3GEkV3trmRYyXHMkS7EQtt5iQZQfdpz+D9dcagpTUkg1q3mhlgs prVRGJLm6l23DSqxUBblQTDvIIkwGwmQD1Suf8c/P4G1q2Xma8tHsoF/vzTDyo1z2y7qMngZ ySBk10Fc/rH/ABMPEei6ZH8628p1C7Q8oI1R0jDD+8ZWR0BGD5DkHKCgDoKKKKACiiigAooo oAKKKKACiiigAooooAKKKKAPH/D3/J0Piz/sFR/+g2tewV4/4e/5Oh8Wf9gqP/0G1r2CgAoo ooAKKKKACiiigAooooAK8f8AhB/yUP4nf9hUf+jbivYK8f8AhB/yUP4nf9hUf+jbigD2Ciii gDn9ZstY/wCEh03VtJtrG5+z2lzbSRXd08H+seFgwKxvnHkkYIHUUfbPGH/QC0P/AMHM3/yL XQUUAcT/AMJb4l/6F7Sf/BvJ/wDI1H/CW+Jf+he0n/wbyf8AyNUVFMZL/wAJb4l/6F7Sf/Bv J/8AI1H/AAlviX/oXtJ/8G8n/wAjVFRQBL/wlviX/oXtJ/8ABvJ/8jUf8Jb4l/6F7Sf/AAby f/I1RUUAS/8ACW+Jf+he0n/wbyf/ACNR/wAJb4l/6F7Sf/BvJ/8AI1RUUAUNIt7m3s5ftixJ PNd3NyyQyF1XzZnkChiqk4DgZwOldL4e/wCP+T/rkf5ismtbw9/x/wAn/XI/zFAHS0UUUhBU c8EN1by29xFHNBKhSSORQyupGCCDwQRxipKKAObgvNS8OW8VpqNpd6hYQII49Stt1xOVAwDP EBvLn5RujEm47mIjHAk/4TrwmvEviTSoJBw0NxdpFJGe6ujkMjDoVYAg8EA10FFAHP8A/Cd+ D/8Aoa9D/wDBjD/8VR/wnfg//oa9D/8ABjD/APFV0FFAHP8A/Cd+D/8Aoa9D/wDBjD/8VR/w nfg//oa9D/8ABjD/APFV0FFAHP8A/Cd+D/8Aoa9D/wDBjD/8VR/wnfg//oa9D/8ABjD/APFV 0FFAHP8A/CSvqHyeH9Nn1BjyLmcNbWgHUMJWUmRWAO1olkB4yVDBq0NH0z+y7N0km+0XU8r3 FzOV2mSRjk8ZJCgYRQSSqIq5OM1oUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHj/h 7/k6HxZ/2Co//QbWvYKjEEK3D3CxRid0VHkCjcyqSVBPUgFmIHbcfWpKACiiigAooooAKKKK ACiiigArx/4Qf8lD+J3/AGFR/wCjbivYKjjghheZ4oo0eZ98rKoBdtoXLep2qoyewA7UASUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//Z --------------72F2D468D1CE1EB1F05D5DEE-- --------------3AE2813E39B2072F4A2529C0-- From owner-ietf-ediint@mail.imc.org Tue Nov 28 17:08:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12093 for ; Tue, 28 Nov 2000 17:08:04 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12454 for ietf-ediint-bks; Tue, 28 Nov 2000 13:29:16 -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 NAA12449 for ; Tue, 28 Nov 2000 13:29:10 -0800 (PST) Received: by mailman.8760.com from localhost (router,SLMail V3.2); Tue, 28 Nov 2000 15:30:46 -0600 Received: from gamma [192.168.21.133] by mailman.8760.com [192.168.21.90] (SLmail 3.2.3113) with SMTP id 6C8B3A6EB97F11D4BB0C0060974E38DD for plus 1 more; Tue, 28 Nov 2000 15:30:46 -0600 Reply-To: From: "Dick Brooks" To: "Dave Roberts" , Subject: RE: [AS2] some more minor typographical errors Date: Tue, 28 Nov 2000 15:26:51 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal X-SLUIDL: B4EA5525-C56D11D4-BB0C0060-974E38DD Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks Dave, I'll work with Dale on the GISB related changes within AS2. 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 Tue Nov 28 17:44:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25873 for ; Tue, 28 Nov 2000 17:44:29 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA12895 for ietf-ediint-bks; Tue, 28 Nov 2000 13:42:22 -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 NAA12890 for ; Tue, 28 Nov 2000 13:42:17 -0800 (PST) Received: by mailman.8760.com from localhost (router,SLMail V3.2); Tue, 28 Nov 2000 15:42:20 -0600 Received: from gamma [192.168.21.133] by mailman.8760.com [192.168.21.90] (SLmail 3.2.3113) with SMTP id 6C8B3A75B97F11D4BB0C0060974E38DD for plus 1 more; Tue, 28 Nov 2000 15:42:19 -0600 Reply-To: From: "Dick Brooks" To: , Subject: RE: AS2 = Email & HTTP Date: Tue, 28 Nov 2000 15:38:24 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_001F_01C05951.3EC513E0" 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 In-Reply-To: <3A23F92D.4583ADD2@iplanet.com> Importance: Normal X-SLUIDL: B4EA5542-C56D11D4-BB0C0060-974E38DD 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_001F_01C05951.3EC513E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0020_01C05951.3EC513E0" ------=_NextPart_001_0020_01C05951.3EC513E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Stacy, regarding: >Question: >Could AS2 be restated as: Email messages sent/received using HTTP protocol? >AS2 = Email + Security + Web server + Web browser >Example, To Send: >1. Use all the normal email standards to create the email message file, >2. then use the an HTTP "POST" to send the file. >3. Then once received, use all the normal email standards to "decode" the email message file. >4. To know what kind of file you have received, check the MIME type (e.g. EDIX12-850 means you have received an X12-850 purchase order document), then process appropriately. No, this doesn't work. The HTTP standard defines headers that "collide" with e-mail headers (e.g. From). The next version of the AS2 spec will contain two new headers, AS2-To and AS2-From which will replace the To and From headers used in e-mail. There are also some encoding differences between SMTP and HTTP. 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 Stacy Thurston Sent: Tuesday, November 28, 2000 12:28 PM To: ietf-ediint@imc.org Subject: AS2 = Email & HTTP Hi all, ---------------------------------------------------- Question: Could AS2 be restated as: Email messages sent/received using HTTP protocol? AS2 = Email + Security + Web server + Web browser Example, To Send: 1. Use all the normal email standards to create the email message file, 2. then use the an HTTP "POST" to send the file. 3. Then once recieved, use all the normal email standards to "decode" the email message file. 4. To know what kind of file you have received, check the MIME type (e.g. EDIX12-850 means you have received an X12-850 purchase order document), then process appropriately. ** If this is the case, GREAT! This allows us to use all our current programs (technologies) to securely and confidentially: send, receive and process documents through firewalls that have an HTTP opening. Use: 1. Our email (SMTP) client to create "email file messages" 2. Our batch oreinted "Browser" client to send the "email file messages" using HTTP POST. 3. Our web server (HTTP) to receive documents 4. * Here we need to write a plugin or cgi to pass the file to the email client. 5. Our email (POP) client would decode the "email file messages" as it would any email message. 6. We already have the programs to process the files based on sender, receiver and MIME type. 7. Our email client can create an "MDN file message". 8. * Here we need to write a program to pass the "MDN file message" to the batch oreinted "Browser" client that would send the "MDN file message" using HTTP POST. 9. Repeat steps 3, 4, 5 and 6 *** And all of our current security programs remain the same (e.g. SMIME, digital signatures and encryption). File - Email client - Batch web browser - Internet - Web server - Email client - File This will be easy for us to create an AS2 peer to peer system :) Thanks for the conversations, Stacy Thurston, iPlanet (SUN|Netscape) Product Manager http://www.iplanet.com/products/ecommerce/ecxpert/ecxpert.html ---------------------------------------------------- Background: I work with a product dedicated to sending & receiving documents. We add communication "agents" (programs/connectors) to do the sending and receiving. Example: * "Browser" client to send documents * HTTP server to receive documents * POP client to get documents * FTP client to get and put documents We have found that: 1. Email messaging standards are adequate to send/receive/process documents: * SMTP/POP, multipart, SMIME, digital signatures & RSA encryption * Note, mulitpart is rich enough to allow us to tell what kind of file is being sent to us, i.e. MIME type is the document type. 2. And the HTTP protocol is adequate for file transport. ---------------------------------------------------- eom ------=_NextPart_001_0020_01C05951.3EC513E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Stacy,=20 regarding:
 
>Question:

>Could AS2 be=20 restated as: Email messages sent/received using HTTP protocol?

>AS2 =20 =3D  Email + Security + Web server + Web browser

>Example, To=20 Send: 
>1. Use all = the normal=20 email standards to create the email message file, 
>2. then use the an HTTP "POST" to = send the=20 file. 
>3. Then once = received,=20 use all the normal email standards to "decode" the email message=20 file. 
>4. To know = what kind of=20 file you have received, check the MIME type (e.g. EDIX12-850 means you=20 have received an X12-850 purchase = order=20 document), then process appropriately.

No,=20 this doesn't work. The HTTP standard defines headers that "collide" with = e-mail=20 headers (e.g. From). The next version of the AS2 spec will contain two = new=20 headers, AS2-To and AS2-From which will replace the To and From headers = used in=20 e-mail. There are also some encoding differences between SMTP and=20 HTTP.
 
 

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 Stacy Thurston
Sent: Tuesday, November 28, = 2000 12:28=20 PM
To: ietf-ediint@imc.org
Subject: AS2 =3D Email = &=20 HTTP

Hi all,=20

----------------------------------------------------
Question:=20

Could AS2 be restated as: Email messages sent/received using HTTP = protocol?=20

AS2  =3D  Email + Security + Web server + Web browser=20

Example, To Send:
1. Use all the normal email standards to = create the=20 email message file,
2. then use the an HTTP "POST" to send the = file.=20
3. Then once recieved, use all the normal email standards to = "decode" the=20 email message file.
4. To know what kind of file you have = received, check=20 the MIME type (e.g. EDIX12-850 means you have received an X12-850 = purchase=20 order document), then process appropriately.=20

** If this is the case, GREAT!
This allows us to use all our = current=20 programs (technologies) to securely and confidentially: send, receive = and=20 process documents through firewalls that have an HTTP opening.=20

Use:
1. Our email (SMTP) client to create "email file messages" =
2.=20 Our batch oreinted "Browser" client to send the "email file messages" = using=20 HTTP POST.
3. Our web server (HTTP) to receive documents
4. * = Here we=20 need to write a plugin or cgi to pass the file to the email client. =
5. Our=20 email (POP) client would decode the "email file messages" as it would = any=20 email message.
6. We already have the programs to process the = files based=20 on sender, receiver and MIME type.
7. Our email client can create = an "MDN=20 file message".
8. * Here we need to write a program to pass the = "MDN file=20 message" to the batch oreinted "Browser" client that would send the = "MDN file=20 message" using HTTP POST.
9. Repeat steps 3, 4, 5 and 6=20

*** And all of our current security programs remain the same (e.g. = SMIME,=20 digital signatures and encryption).=20

File - Email client - Batch web browser - Internet - Web server - = Email=20 client - File=20

This will be easy for us to create an AS2 peer to peer system :)=20

Thanks for the conversations,
Stacy Thurston, iPlanet = (SUN|Netscape)=20 Product Manager
h= ttp://www.iplanet.com/products/ecommerce/ecxpert/ecxpert.html=20

=20

---------------------------------------------------- =
Background:=20

I work with a product dedicated to sending & receiving = documents. =20 We add communication "agents" (programs/connectors) to do the sending = and=20 receiving.=20

Example:
* "Browser" client to send documents
* HTTP server = to=20 receive documents
* POP client to get documents
* FTP client = to get=20 and put documents=20

We have found that:
1. Email messaging standards are adequate = to=20 send/receive/process documents:
* SMTP/POP, multipart, SMIME, = digital=20 signatures & RSA encryption
* Note, mulitpart is rich enough = to allow=20 us to tell what kind of file is being sent to us, i.e. MIME type is = the=20 document type.
2. And the HTTP protocol is adequate for file = transport.=20

----------------------------------------------------
eom=20

------=_NextPart_001_0020_01C05951.3EC513E0-- ------=_NextPart_000_001F_01C05951.3EC513E0 Content-Type: image/jpeg; name="CTEMPnsmailUM.jpeg" Content-Transfer-Encoding: base64 Content-ID: <680542921@28112000-2c9d> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAHNAakDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiuT8V+INQ0rWdLs LKWOFLq3uJpJDpVxftmNoQAEhZSoPmnLHI4A71Je+K/7G1iLSryKe9u5IrdUSxtMb5pFuWyMyHCn 7MwweEyCzlSSgB1FFce3xI0T+2LzS4Vnubq389Ujt2ikknlhVmeJIg/mhvkcAsiqSvDHcu6TVPiN 4c0m3v7ia5klgs7cT+ZAnmLNkRHbGQcE4uLc5OFPnLgnD7QDrKK8/ufiQl3p15eaMsDrbaVqN1Ik rLLsntxAyLvidkZSs2TtY9QMghhXoFABRRRQAUUUUAFFFef+HfF+rajoNprF9dQeXcfYlaFNDuIN r3EsaALJLLtlUbmG5M4yG5GFYA9Aori774maNYFlmtrtD9ont0MzwW6ytDIY5SjzSIrBTs6HneMZ KyBLkvj/AEKKwa9aSfyP3bxnyiDLC8Bn85VPPliNZTkgEmGRQCwAIB1FFcnN8QtGt/Eo0WYSI7XC 2yXBmg2SSMQoCJ5nmuBITGWVCFZXBI2MRJ4F8SXnifR5Ly9jgjkX7PgQqQP3lpBO3Un+KZgPYDvy QDqKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKAKcmmwy6zbaozSefb281uigjaVkaNmJ4znMS457nr2p3Hhuzu fEcGuPJOLqHy9qBhsOxLhBkYz0upM89l9DnYooAx7Pw+ljqLXEOoXwtTLJOlhvUQpLIWZ2yFDtln c7WZlBbIA2rtz5vAWjyWdtbxGe2a2u2u4poCiurE5RD8uDHGVh2oQV/0eEEEJiuP0C/vJP2lfFVm 93O1qmlRbYTISi4EBGF6cGSQj/fb1NesUAcn/wAK/wBNYakZr7UppNRt7mC4llmVmPnxwJIw+XAO LdCABtXJAAXaq9ZRRQAUUUUAFFFFABWOnhuzj8OadoYkn+y6f9l8pyw3t9ndHTccY5Ma5wB1OMVs UUAc+3hOBFiay1G+sbqKW6kW5h8pn23EvnSpiRGXaX24+XcNgGeTmxN4Y0u4vLa4uIPtHkWjWmy4 /fCVCMAyF8s7BTIoJJ4mlznea2K8n+FF/eXfj74lRXN3PNHFqo8tJJCwT55k4B6fKiL9EUdAKAOs h+H+m26QxRX2pLClxBeSxiZQLm6iZD58p25d28tdwJ2k5baH+atTw54bs/DFg9nZSTyRt5WTMwJ/ dwRwL0A/hhUn3J7cDYooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAOT0258VazFc3dvqejW 0C3t1bxxSaXLKwWKeSIEsLhQSQmeg61c+x+MP+g7of8A4Jpv/kqs/StT/sTwFrmreT532G71e58r dt37Lq4bbnBxnGM4Nc38PfFvijVtD8RWlxNHq2tWVlbXtnLJGkKyNc2olSEqu0YVhjdnnd/DigDt PsfjD/oO6H/4Jpv/AJKo+x+MP+g7of8A4Jpv/kquH8EeML3WdTt9LuvE99a+IUtHW70jXNKjQtL5 aMJIvLEZ2gknazFmTPC43VueFNR1yTxrqGlPrEmu6TZWSR3d/JbxRCLUA3zRJ5aqCNhyy/OVOAWB 4IBufY/GH/Qd0P8A8E03/wAlUfY/GH/Qd0P/AME03/yVXn99421bTvFuoad4j12+8NyPqBGlSy6d FLps9urRhQz48wswYliJFC7uSpG2tj/hbln/AMJR/ZX2ODyf7b/sX/j9H2vzMY83yNv+p3/Lu357 4zxQB1H2Pxh/0HdD/wDBNN/8lUfY/GH/AEHdD/8ABNN/8lVy+h/FC81Kz8N6nfaDBZaRrt29lFcp fmV4ZgXVFaPyh99kIBBIHUkd8uT44QsbhoNJtEgW3ub21nvNTEC3tvHIY0MQ8st5rssmI2AI29Tn gA7z7H4w/wCg7of/AIJpv/kqj7H4w/6Duh/+Cab/AOSqy/DHjubxZ4ivLKw0qOPT7S3tLh7me6Il K3EHmoBEEIyOh+f3Gelcf4o8banpviLx3FJ4h1Kwg0i3t206O10+OWLzZIMhZXML7Q0m0Dcy/eIB 44APRPsfjD/oO6H/AOCab/5Ko+x+MP8AoO6H/wCCab/5Krl9e+J1x4Y+x2GpadYpq40T+1L1Li/F tHvHBhhO2TfIWD4X0A5Pa5YfES716/uYvD3h2S+gtLeyuLgS3aQTlblPMAjQgoxVDk7pE5yB2JAN z7H4w/6Duh/+Cab/AOSqPsfjD/oO6H/4Jpv/AJKrg/EvxrttKGrxpZxhLS9m0xfLv0F75qxn96IW jZRFvG3eSfUqfu1oQ/FaHT9GupdWspIpLfQrXVrVpJw7XyyqFOfLjCxkTMsecDO7cFCigDrPsfjD /oO6H/4Jpv8A5Ko+x+MP+g7of/gmm/8AkquPsPjClxrFtYXmkwWkkmqppE1t/aKyXcU5UBn8oLho RJlN4fnGcZ+WvUKAOf8AsfjD/oO6H/4Jpv8A5Ko+x+MP+g7of/gmm/8AkqugooA5/wCx+MP+g7of /gmm/wDkqj7H4w/6Duh/+Cab/wCSq6CigDn/ALH4w/6Duh/+Cab/AOSqPsfjD/oO6H/4Jpv/AJKr oKKAOf8AsfjD/oO6H/4Jpv8A5Ko+x+MP+g7of/gmm/8AkqugooA5/wCx+MP+g7of/gmm/wDkqqep XPirRora7uNT0a5ga9tbeSKPS5YmKyzxxEhjcMAQHz0PSusrn/GX/IDtv+wrpv8A6Ww0Aef+Hv8A k6HxZ/2Co/8A0G1r2CvH/D3/ACdD4s/7BUf/AKDa17BQAUVh+NJ5rXwL4huLeWSGeLTLl45I2Ksj CJiCCOQQec1He65qg8Qz6NpWkQXMkFpDdPPc3nkRgSPKu3hHbd+6yMKQRuyVIAYA6CiuPj8SapqX iHw2+lW0B0jVNKkvnW5n8uQDfb84EbfMqy8KGAYu2SNoJuXHiiaFLrUo7CN9BsnlS6vDcFZV8pis rJFsO5EZWByysdj7Vb5N4B0lFcnqPi6+sz4jmh0aOSz0FJGmnkvNhmItlnCooRjnLhW3YABBBY5V dCw1q+k1mPTtS0yOye5t5Lm12XPmtsjaNWEo2gI/71OFZx975uAWANyiubt/FE0yWupSWEaaDevE lreC4LSt5rBYmeLYNqOzKBhmYb03Kvz7DwbqWtapp13NrEFohS9uoYnguDISEuJU2keWgAUKqg8l gMkKeKAOkrx/4Qf8lD+J3/YVH/o24r2CvH/hB/yUP4nf9hUf+jbigD2CuT0258VazFc3dvqejW0C 3t1bxxSaXLKwWKeSIEsLhQSQmeg611lc/wCDf+QHc/8AYV1L/wBLZqAD7H4w/wCg7of/AIJpv/kq j7H4w/6Duh/+Cab/AOSq6Cs/XdT/ALE8Panq3k+d9htJbnyt23fsQttzg4zjGcGgDP8AsfjD/oO6 H/4Jpv8A5Ko+x+MP+g7of/gmm/8AkquL+Hvi3xRq2h+IrS4mj1bWrKytr2zlkjSFZGubUSpCVXaM Kwxuzzu/hxUfgjxhe6zqdvpd14nvrXxClo63eka5pUaFpfLRhJF5YjO0Ek7WYsyZ4XG6gDuPsfjD /oO6H/4Jpv8A5Ko+x+MP+g7of/gmm/8AkqsPwpqOuSeNdQ0p9Yk13SbKySO7v5LeKIRagG+aJPLV QRsOWX5ypwCwPBj0jUPEXjDUfEFzY65/ZEOlaq2m29oLSOeOTySpkeUsA7bw2AEZNoA5J5oA6D7H 4w/6Duh/+Cab/wCSqPsfjD/oO6H/AOCab/5Krh9S8c6tYfEfU9JkuZ3sU1vSLG3ih8pPLW4hdpNx aNiykqCRkN6MvfQ/4W5Z/wDCUf2V9jg8n+2/7F/4/R9r8zGPN8jb/qd/y7t+e+M8UAdR9j8Yf9B3 Q/8AwTTf/JVH2Pxh/wBB3Q//AATTf/JVcGfjJfT+GrPUoPDkdvJqVlfT2RnvN6b7UFn3BVB2bQcd CWUrhVIkr0Dwbf32q+CtE1DUzGby5soppWRshyyg7vuqASCCQBgEkAkDJAI/sfjD/oO6H/4Jpv8A 5Ko+x+MP+g7of/gmm/8AkqugooAy/DWpTaz4V0jVLhY1nvbKG4kWMEKGdAxAyScZPqa1K5/wJ/yT zw1/2CrX/wBFLXQUAcPbeG7Pxd4A1TQ7+SeO1utVv97wMA426hK4wSCOqjtWha/D/wAP6f4hn1nT rX7BJPp7ae8FiFt4yjPuLjywGEnAG4MMADuM1Y8G/wDIDuf+wrqX/pbNXQUAcefh9BNPaXF94g1y 9uLG0mtbKeaaJZLbzUCNIrpGrNJtHDOW55681oeGPCq+FbOGxtdWvp7CCLyobSaO3VE5zuzHErFu uSSc7iTk810FFAHJ6v4CttcS9tb7WtZk0u9uFuJ9NadHiYhlbarMhlRCUB2q4AycYqS18D2djrE9 7Z6pqtvbz6g2pTWENwEhkuGXDMxC+YVJAYoX2E9scV1FFAHHp8ONHj8CWvhKO5vktbSUT214roLm GQSmQOj7cK2SRkDOCRUa/DTSrVLL+yr/AFLSZ7XTDpf2ixeNXlgLBju3IQH3ZbegVssTnpjtKKAM PR/Ctjoet6rqtrNdvPqaW6TLPL5gUQpsTBPzEkdSzMSeajXwdpf9p+I72Xz5v+EhijhvYXfCbEjM eF2gMMqxzyfbFdBRQBxa/DeyhSya01vWbS7tNMOki8gkiEr2u4FUJMZClccMgVvUk81Yl8AWJ1S6 vrTVdZsTepbJepbXeDciDhN0rAyg7flJR1LDryST1lFAHF3nw1026GqwJq2s2lhqlxNdXVla3Cxx vNLHsdi23eQfvbCxTIGVI4ov/hhoOpJoKTyXezR7eK1CqUxeQxsjLHcZT94m6MHbwMknvXaUUAcv a+B7Ox1ie9s9U1W3t59QbUprCG4CQyXDLhmYhfMKkgMUL7Ce2OK6iiigAorDn8Tw/aJbbTtO1LVZ 4nKyC0gCxjBw2JpSkTFW+UqrlgcjHytiP7d4sk+eLQNKSNuVW41d1kUdg4S3ZQ3qFZhnoSOaAOgo rn/tnjD/AKAWh/8Ag5m/+RaPtnjD/oBaH/4OZv8A5FoA6Ciuf+2eMP8AoBaH/wCDmb/5Fo+2eMP+ gFof/g5m/wDkWgDoKK5/7Z4w/wCgFof/AIOZv/kWj/hINRs+NW8OX0Sp/rLmwZbyEZ6bVXE7dQDi Hg5/hG6gDoK5/wAZf8gO2/7Cum/+lsNamm6rY6vbtPYXMc6I5jkC8NE4AJR1PKOMjKsAR3ArL8Zf 8gO2/wCwrpv/AKWw0Aef+Hv+TofFn/YKj/8AQbWvYK8f8Pf8nQ+LP+wVH/6Da17BQBl+JdNm1nwr q+l27RrPe2U1vG0hIUM6FQTgE4yfQ0QabNF4q1DVGaPyLiytrdFBO4NG87MTxjGJVxz2PTvqUUAc fpnh7WNI/wCER8pLGf8AszSjpt7uuHTG77Pl4/3Z348luDtzkciqdz8PrZ726iXRPD88F5cS3D6n dWySXcJkcu6hGjKyEEkKzMAoKgo+w7+8ooA5fUPDd5d6P4zs45IBJrfmfZizHCbrSKAb+OPmQnjP GO/Fak+mzS+KtP1RWj8i3srm3dSTuLSPAykcYxiJs89x17alFAHB6T8PrbTLixto9E8Px29g8bxa olsjXswjIKhlMeEc4G6QMxOGKqhYFOg8NWGpaZFfWl7FaCA3tzcW0sM7OzrNPJLh1KKEIDgcFs89 O+5RQAV4/wDCD/kofxO/7Co/9G3FewV4/wDCD/kofxO/7Co/9G3FAHsFc/4N/wCQHc/9hXUv/S2a ugrn/Bv/ACA7n/sK6l/6WzUAdBWP4p8N2fi7w5d6HfyTx2t1s3vAwDja6uMEgjqo7VsUUAcva/D/ AMP6f4hn1nTrX7BJPp7ae8FiFt4yjPuLjywGEnAG4MMADuM1XPw+gmntLi+8Qa5e3FjaTWtlPNNE slt5qBGkV0jVmk2jhnLc89ea7CuX+Ith/anw/wBYsf7Yg0jz4gn2y4l8uNfmX5XbIwr/AHD14boe hALHhjwqvhWzhsbXVr6ewgi8qG0mjt1ROc7sxxKxbrkknO4k5PNV7jwPZvqN5c2WqarpkN/Kk97a afcCKOeRTkvnbvRmAAYxshYDnnmvK73xJfeBrPxJEfC2m6D4pg0yOWO40x/9CuYDdCIS+QDgOPMy pcFuucD5Tqah4t8aafqa6aNQ8jf4g060ha/FnPcrFPG5kSeO3baq7kVlxsYgnDegB3F98ONH1DxH NrktzfLdS6hZ6gyI6BBJbIyRgDbnaQxyM5PYirFr4Hs7HWJ72z1TVbe3n1BtSmsIbgJDJcMuGZiF 8wqSAxQvsJ7Y4rz+z8eeIpdetNDn1mC3hi1vVrWXUZ4I9zQ2kSyJ5v3U25f5yoQlVGGU5J6j4Jf8 kh0L/t4/9KJKALFt8KvD9vp2iWDy309rpEV5DEkkqjzUugRKJCqg9GONu3HvXUaHpKaDodlpMVzP cQ2cSwxyT7d+xeFB2qo4GB07c5OTWhRQAUUUUAc/4E/5J54a/wCwVa/+ilroK5/wJ/yTzw1/2CrX /wBFLXQUAc/4N/5Adz/2FdS/9LZq6Cuf8G/8gO5/7Cupf+ls1dBQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAVxepX7atcLLdGT/AIRwamNMkiRlC3ByYy0oKl2T7Ttg8tdoPzMxeNsDoPEupTaN4V1f VLdY2nsrKa4jWQEqWRCwBwQcZHqKrzeGof8AhCh4atbiSJIrJbW2uXAd4WRQI5eMfOrKrAjHKgjF AEena9ZjxHN4ZtbLyI7OIpEUAVB5aQMyhR91QtzDtx1+cYUKC0lt4p00+H7bWtSurTTLO7c/ZpLq 5VFljJYxMC2MF4wH2nkZIPINc/d+GNXufDVvPA8lnr1xcTS3MkbjzYVugyMhlDDeIFeJhg/N9kjA C/LtueJNGv4tR0e80VL6G3sbSez8nSBarIquYSoC3A8sRgQkHGGB24GM4ANiXxFZ23iGbSbyWC22 xWzQyzTBfOkmeZVjUHGW/ckgAknPTjmxrWp/2RphuhD50jSxW8UZbaGklkWNNzYOF3OuSASBkgE8 Hg7zwpqFtb3emWuhyTm68L2+iQXyzwstqwEyuHdijlPniYlI/m2525AFd5raXEmjzx21nBes20SW s4BWaIsPNQAkAsU3hdxC7iNxxmgCvp+oaw2oiz1bSYLfzImljms7p7iMbSoKuzRR7WO8FQM5Cv02 82LXXdHvtOn1Gz1WxuLGDd51zDcI8ce0bm3MDgYBBOegrj38PXt/p2sadpWjT6BYXmlXNqbS7mj8 kzyACJoo4nkWJV/e79oXcXBw55A+g6vfeHvFryxarJf6jpRsYF1Oa0EjlUm2gC3AjVczfeZiSSch QoLAHaR6tpsyTPFqFo6Q3H2WVlmUhJtwXy254fcyjaeckDvRJq2mw6pDpcuoWiahMm+K0aZRK688 qmckfK3IHY+lc/N4XZPFljJaRxw6KqRzTW0aKsQlgV0iBQEAkiWNg2Pl+xxj+7tz7zw7qsviy8JO pPp95qdrqAEEtslqvkrB/rSymbfugzhPlI2DcuWKgHQXVtbaretc6Rq8dtqkCbJJICkodA7gRzIf vIJEkHBVgRIFZcvnL1fU/wC2PBmn3rQ+RM2q6fHPBu3eTMl/Ekke7A3bXVl3Dg4yOCK1PCulNpOn XiS20cE9xqd7dPt25kD3EjI7EdSY9nXkAAcYxXN69/o2savZpzHNqGh6gxPUSPdpAQP9nbaxkDrk tzggAA5/w9/ydD4s/wCwVH/6Da17BXj/AIe/5Oh8Wf8AYKj/APQbWvYKACiiigAooooAKKKKACii igArx/4Qf8lD+J3/AGFR/wCjbivYK8f+EH/JQ/id/wBhUf8Ao24oA9grn/Bv/IDuf+wrqX/pbNXQ Vz/g3/kB3P8A2FdS/wDS2agDoKp6lqtjpFus9/cxwI7iOMNy0rkEhEUcu5wcKoJPYGq+q6lNBcW+ m2CxtqV2jvEZQfLijQqHlfBBYKXQBAQWLAZUbnU03QLHTbhrwLJc6g6FJL66bzJ2UkEqGP3ELDd5 aBUBJwooAp/8Jlpf/Prrn/givf8A4zUc/ivRbq3lt7iw1maCVCkkcnh+9ZXUjBBBhwQRxiukooA4 uzvfB2n291b2Xhq7toLtNlzHD4XukWZcEYcCDDDDEYPqfWiC98HWtvFb2/hq7hgiuBdRxx+F7pVS YDAkAEGA4HG7rXaUUAcf/avhP/oAX3/H39u/5Fm7/wCPj/nt/qP9Z/tdferFj4j8P6ZZx2dhpWq2 lrHnZDB4dvI0XJJOFEOBkkn8a6iigDn/APhM9IXmVNVgjHLTXGj3cUcY7s7vEFRR1LMQAOSQK3IJ 4bq3iuLeWOaCVA8ckbBldSMggjggjnNSVz9/4b8n7TfeHpP7N1N98u1G221zKcn99Hgqdzbd0igS 4GA46UAdBRVPS9Sh1awW7hWRAXeN45AA0ciOUdDgkZVlZcgkHGQSMGrlAHP+BP8Aknnhr/sFWv8A 6KWugrn/AAJ/yTzw1/2CrX/0UtdBQBz/AIN/5Adz/wBhXUv/AEtmo8Zl/wDhH0jjnnh87ULGF3gm aJ9j3cSMA6kMMqxHBHWjwb/yA7n/ALCupf8ApbNR4y/5Adt/2FdN/wDS2GgA/wCEN0v/AJ+tc/8A B7e//HqP+EN0v/n61z/we3v/AMeroKKAOf8A+EN0v/n61z/we3v/AMeo/wCEN0v/AJ+tc/8AB7e/ /Hq6CigDn/8AhDdL/wCfrXP/AAe3v/x6j/hDdL/5+tc/8Ht7/wDHq6CigDn/APhDdL/5+tc/8Ht7 /wDHqP8AhDdL/wCfrXP/AAe3v/x6ugooA5//AIQ3S/8An61z/wAHt7/8eqvodoNM8ZaxYQXN9Jar p9lMqXd7Nc7XaS5DEGVmIyEXp6CuorlG1CGw+IerearnfpVjjaB2lu/f3oA6uis621m3u7hYI0lD NnBYDHAz61o0Ac/47/5J54l/7BV1/wCimroK5/x3/wAk88S/9gq6/wDRTV0FAFdb+zfy9t3A3myv BHiQHfIm7cg9WGx8jqNrehrL1nxTpuiWFxqNxdWjWdvb3Esm25XzWaJ1QoinhjubYfmGHKrgluOf 1Twxq41m/vdPeQwWzjUbC2Rwiy3DNEZIl+bEZYQSAyEYP2+Trh98es+EdRTQ49Osl+2SR+GtRsHn JWM3F1N5BDMC33pGSRiSTySScnJAOkTxTpp1k2T3VpHA9vaS2ty1yu25a4aYIidmJEORgndu4HHO xNPDbIHnljiQuqBnYKCzMFUc9yxAA7kgVxevaDe6v/wk97Hpe261Dw0ljaCVo/MWU/aS8W4MQOXi yc7SQOTjjQ+IMP2jwmYPs0F15moWCeRcHEcubuEbXOG+U9DweD0PSgDQfxFZyNor2EsF9a6pdvbJ cQTBkXbFLIWBGQ3MJXGe/titCG/s7j7P5F3BL9piM8GyQN5sY25dcfeX515HHzD1FcnbaRqc+tW2 qyWElsk2um+eCWSMyQRDTmtgX2sVJLqMBWbhgTjkCPwvpmrWeo+H7a70qe3h0bRJdPku2liaOeTN sAYwrl9pELnLKpxjIB4oA6SbX9N+z3rWupabLPapMXR7tVVGiA3iRhkoFLJuODt3DI5GbB1bTVv0 sG1C0F47siW5mXzGZUDsAuckhWViOwYHoa8rXSb2706z0uDTYDdHwVe6bb3Uc8bfbyotlVkYHHkk tlCzA/O2VTq3WXfhy7e4164isY/Pvdd025SQFA0lvCbQsSc5wpjmIU89cD5uQDtK8/8AE3/Iz6h/ 3L3/AKcpa9Arz/xN/wAjPqH/AHL3/pyloA5/w9/ydD4s/wCwVH/6Da17BXj/AIe/5Oh8Wf8AYKj/ APQbWvYKACiiigAooooAKKKKACiiigArx/4Qf8lD+J3/AGFR/wCjbivYK8f+EH/JQ/id/wBhUf8A o24oA9grn/Bv/IDuf+wrqX/pbNXQVz/g3/kB3P8A2FdS/wDS2agA8O/6dqOtay3Pn3bWUGeGWG2L RlSBx/rvtDA8kq65PAVdyOeGZ5kiljd4X2SqrAlG2hsN6HaynB7EHvWH4N/5Adz/ANhXUv8A0tmr L0+DXpfEniptL1LTbaD+04wyXWnvOxb7HbchlmQAYxxjseeeADYm8aeFbZwk/iXRonKK4V7+JSVZ QynluhUgg9wQaj/4Tvwf/wBDXof/AIMYf/iq5/Rf+RY+Fv8A2w/9Ns9dBef8lD0b/sFX/wD6NtKA LkPiXQbnVDpcGt6bLqAdkNol0jShlzuGwHORg5GOMGrGpatpujW63GqahaWMDOEWS6mWJS2CcAsQ M4BOPY1x+gaPqWq2Msc+o2i6Smu3dwLdLNhPui1CSRR5pkK43oM/u/u5HB+atTxel5JqHhZbCeCC 6OqvsknhMqL/AKHc5yoZSeM/xD156UAbkOrabc6WdUg1C0l08Izm7SZWiCrncd4OMDByc8YNEOra bc6WdUg1C0l08Izm7SZWiCrncd4OMDByc8YNcvf6VNpJs9R1G5juIn1gX+rSpEY4EVbZoo28ssxC K6W7Elm2spkJUL8tPUZrPUX1vVrS53aM39myR3tsBJB9qhuGZpm5AeNALfzHBHyRsu4GM7QDqP8A hLPDf9nf2j/wkGlfYfN8j7T9tj8vzMbtm7ON2OcdcVY0zXdH1vzf7J1Wxv8AyceZ9kuEl2ZzjO0n GcHr6GsPwpqC6nrOqXIvNN1Rxb28Z1TTAywSANMRBt8yQb0yWJDZImXIGATc8Cf8k88Nf9gq1/8A RS0AFx/xKPF9pOn/AB761m1ljHa4jjaRJMcDmNJFZjknZCBwDXQVz/iH/kOeE/8AsKyf+kV1XQUA c/4E/wCSeeGv+wVa/wDopa6Cuf8AAn/JPPDX/YKtf/RS10FAHP8Ag3/kB3P/AGFdS/8AS2ajxl/y A7b/ALCum/8ApbDR4N/5Adz/ANhXUv8A0tmo8Zf8gO2/7Cum/wDpbDQBn+PdN/teTw1Y+XYyebqr fLf2v2mE4tLk/NHuXd045GDg9sVj6nappl3LpcNvYwQ2/wDYDbbO0WBN7alJvIAyQpIyFLHGT3JJ 7zUNTttMEL3ckcUUjsplklRFjCxvIWJZhkBUPTJHXGASMtvG/hvz9Mig1mxuf7Ru2s4Ht7qN18wI XIJDf7q8ZO6RBj5hQBz/AIC1/XdX1EjU7+xm32nnXNnDOJZLGfK/umVYU8jGXBSV5HJTgnY5NfVN Uvf+Eol8SxWN8+kaXL5D3KSRiEQRCZLtiC4kGHfJRY23mzjIJ3KU7yz1bTdQuLq3stQtLme0fZcx wzK7QtkjDgHKnKkYPofSo313R47y6s5NVsUurSIz3MLXCB4YwAS7rnKrgg5PHIoA8r0aeTTNcjnj 8QXd5dQJ4hSO0MUErPMl0j+WI0VGd2GJSgZScDaVUkG5p3i/VnnnsbzX4F05ZbdpdbhnimWCORLk 5WY28cO3zIIo8lGAaR13bsBPTNN1bTdZt2uNL1C0voFco0lrMsqhsA4JUkZwQce4rP8AD3iKTxDb wXaaJqVnZ3FutxDc3TQbZFYAqAElZgSDnkDoc4PFAHF6NqGowT61q1trn2y1/wCEgs7VR9kVFu1l S0hMjkj5vkdWVo9iswL/ADIyqtfSvFniWaxmuLrVLEs8ULXsUMqzSaUXmiWQsogUQeWjzErM0hBi zyEkJ9Eg8S6DdX8Vhb63ps15KgeO3jukaR1KbwQoOSCvzZ9OelF34i0q1e/g+32kl5Y27XM9mtzG sqIFDZYMwCjBXliByMkDmgDD8BXH2qTxLML77ep1VQl35Xl+cotLYK+OhyADuUBW+8oCkCqWsf8A JQ9Q/wCwVZ/+jbqux0zUodVtXuIFkVEuJ7chwAd0UrRMeCeNyEj2x06Vx2sf8lD1D/sFWf8A6Nuq ANHRv+QtB/wL/wBBNdZXJ6N/yFoP+Bf+gmusoA5/x3/yTzxL/wBgq6/9FNXQVz/jv/knniX/ALBV 1/6KaugoAw9O8X6DqWiXGsxanaR6fb3ElvLcSzoEVkfZktuwA3ysuTyHU962IJ4bq3iuLeWOaCVA 8ckbBldSMggjggjnNcXBpmrW1nZznSp5JNN8QX175CSxb7mGY3IRoyXC/wDLwpIcqflbjOA3QeGL G4sNFMd1H5U013dXRjLAmMTTySqrEZG4BwDgkZBwSOSAXLLVtN1J5EsNQtLp40jd1gmVyquu5CcH gMvIPccio7O/0fxDZmWyu7HU7VJVy8MiTIsiEOvIyAwO1h3HBrz/AMH6RqN74S0NoNGsbeO38NS2 0a3JV7a7kuFgdWKr820+W3mBlBy5C7xlq1NJ0PWLu48SvrNtd3NvqOmQ2kMep3MCSSAG4DxubZMR j94OV3nDA5zlFAOstdd0e+06fUbPVbG4sYN3nXMNwjxx7RubcwOBgEE56CpIdW0250s6pBqFpLp4 RnN2kytEFXO47wcYGDk54wa5ODS9XvNM1N76yvpnP2Zrdrx7SO+LxSGTIaEGEqh2tGr9X3h8I2a3 PC8GoQ2Vy+oxSJLNcF1a4WEXLrsRcz+T+7L5UgFf4BGDyDQBj6V4l8KwGz1ayt9N0+z1uyl1G51B jFD8ySRLtlYcF91wQctwwI5JrqLzVtN0+4tbe91C0tp7t9ltHNMqNM2QMICcscsBgeo9a5Pw1oN7 H/whkuo6X5MmkaJNaSec0btDP/o6AqVZvvLHLgg/dODgnFYbeD9dGjWViyakqXXhyz0m6hsZrVVV 41lDiZ5VYhP3uA0IY8OcH5cgHqlef+Jv+Rn1D/uXv/TlLXoFef8Aib/kZ9Q/7l7/ANOUtAHP+Hv+ TofFn/YKj/8AQbWvYK8f8Pf8nQ+LP+wVH/6Da17BQAUUUUAFFFFABRRRQAUUUUAFeP8Awg/5KH8T v+wqP/RtxXsFeP8Awg/5KH8Tv+wqP/RtxQB7BXP+Df8AkB3P/YV1L/0tmroK5/wb/wAgO5/7Cupf +ls1AB4N/wCQHc/9hXUv/S2aiLxnokusX2nrewBbDK3Vy1xEscUoUuYjl924IrsTt2gI43ZVgDwb /wAgO5/7Cupf+ls1Zc3hy7ufEwuZ7GOW0HiNdQBcowEa6aIlkwT1EwAHcEA9OaAOoj1bTZtUm0uL ULR9QhTfLaLMplReOWTOQPmXkjuPWq58S6CLe4uDrem+RbpE88n2pNsSyAGMsc4AYEFSeueM1z9h pGpx6pp1pJYSJBYaxe6k16ZIzFKk32naiANv3j7SudyqPkfBPy7o/DXhWXTf+EM8/TIIv7K0SaGb AQ+RdSfZ9xGP4m2zZZeuWyfm5AO0nnhtbeW4uJY4YIkLySSMFVFAySSeAAOc1HY39nqdnHeWF3Bd 2smdk0EgkRsEg4YcHBBH4VzdppWp2vwy0nTFto/7StLKzR4m8t2R4xHv8vdlPNXaShb5d4UnjNSe C9P1axTWpdXE/nXmoC4ia4kieRo/s8KDf5SqgYFCpAGAV4LDDMAamh+IdN8Q2UVxYXMbO9vDcPbl 1MsCyoHQSKCdpKnPv2zVNvG/hvz9Mig1mxuf7Ru2s4Ht7qN18wIXIJDf7q8ZO6RBj5hXL+HvDesw 6HpllJoVjZTad4fuLAxXLpLbXM83ktyE5K5ibzMgcudpcfNUdlovib/hM7PWbyz1K5t1uLUBrua0 8+OMRX0bFli2IArTo2FLkq2QScooB3GoeIdN06y1e4a5jnfSbc3F5bwOrSxqELgFc8FlBIzjNXLW /s77z/sd3BceRK0E3kyB/LkX7yNjowyMg8iuLutC1OTwx4k0ddIje4kt9UFreGWP96bqR5Ejj7gf MocvsAZFxvHzDoNP0prHxVfTw20cGnnTLO1txHtVQYnuCUCjoAsidsc8dDgAj8Q/8hzwn/2FZP8A 0iuq6Cuf8Q/8hzwn/wBhWT/0iuq6CgDn/An/ACTzw1/2CrX/ANFLXQVz/gT/AJJ54a/7BVr/AOil roKAOf8ABv8AyA7n/sK6l/6WzUeMv+QHbf8AYV03/wBLYaPBv/IDuf8AsK6l/wCls1HjL/kB23/Y V03/ANLYaAK/jrw3eeJ9Hjs7KSCORftGTMxA/eWk8C9Af4plJ9ge/Bj1Tw7qU/jey121No0EL2we OWVkbaiXiORhSCcXSEDjO0gleDWx4g1dtD0n7clnJeP9ot4FgjdVZzLMkXBbAz8+eSAcYJHUc/ae O5ktb241jSo7ZLe3v7hRZ3RuC62cvlTA7kjwSxUr1yM524wQCx4c8O6lptxpK3ptBBo2mNpts8Mr O1yrGH946lVERxAPlBf75+b5fm5/X/h7rOqS3SwXNokbvfMpe6nCyfaIJ0X9wP3URRplBZVZpPmc lWLK+xB411SbS7yc+GbsXFu8YAEV0ImV93OWt1lYjbghInxvQ5wWKWLnxdfQppckejRyR3iBjMLz MTkthVhlVCjF+CnmtCH8yMA7iwQA2INNmi8VahqjNH5FxZW1uigncGjedmJ4xjEq457Hp35/wL4W m8N29rBceHfD9pPBZJbyajYSlp7hlCglgYUOGK7j8x5A69RXt/iQZZmhfSJEedFawO+TZNvmihXf I0QTG6eIloWmXG4gn5d5dfEK9trqXTj4fk/tOK4kiaISSzIVjigdnDQQyPgm4TblBkDLFGISgCPT PAV5p2lWdnGbGPybTR4nERIUyWt0087fd/i3Eg9SxOcdap6/8PdZ1SW6WC5tEjd75lL3U4WT7RBO i/uB+6iKNMoLKrNJ8zkqxZX6TxHreqR+ELTUNItPIur2W0i8u+byZLcTyInI2OBIpcDBBAOSQ23a 3Pw+Pry2isZjBPeNf6VpsttbspciaZbqSRnaGJmPyQD7sZGQPlUEkAHaaBps2ladLbztGzve3dwC hJG2W4klUcgc7XAPvnr1rifE9lcXnxDvPI1O7sdulWmfs6xHfmW56+YjdPbHWu60TUn1fR4L2Wzn s5JNwaCeNkZSrFSQHVW2nGVLKpKkEgE4HJax/wAlD1D/ALBVn/6NuqAKuk6HqDanCo8VauhO75li tMj5T6wV0/8Awj2qf9Dnrn/fmy/+R6p6N/yFoP8AgX/oJrrKAOD8aaFqMPgXxDK/izWZ0TTLlmik iswrgRN8p2wA4PTgg+hFdhq15Np2jX17b2kl5Pb28ksdtHndMyqSEGATkkY6Hr0NZfjv/knniX/s FXX/AKKaugoAx7XxFZsuzUZYNOumu3to7e4mCvJ+9kjiYBsE+YIiyjHPOM4zVy81bTdPuLW3vdQt Lae7fZbRzTKjTNkDCAnLHLAYHqPWuH8TWF3qXirxJZWWmR3M994cgsFud6K1t5r3Q3Hdg+VkAttJ b5Vwjfw6HinSNTurjXYrOwkuU1vR001JUkjVbZwbjLy7mB2fv1PyBz8rcdMgHSJf6Pp95a6HHd2N tdGIfZrBZERzGoONkfXaAp6DA2n0qnp3i/QdS0S41mLU7SPT7e4kt5biWdAisj7Mlt2AG+VlyeQ6 nvWXf6XqQ8UM1lZT/Zbm7guZy728lnIUEYaSRWHnJMqxgII8puSJieXxnzaJrZ0e38q3vra40/xB e3o+yvbGaaGVrna0XmEx8i4XIk2kBXwM7cgHaPq2mx29pcPqFosF66JayNMoWdnGUCHOGLDkAZz2 rLHiyzg8Aw+Lb9Ps1q2npfPEHBI3IGEak7QzEkKOmSR61hwaFeabFptzLpF3qsRt9Qhu7N5bd52N 1OkxMmfLiI+RgyqSAWAG8Zarn9iaj/wpv+wPs/8AxM/+Ef8AsXkb1/132fZt3Z2/e4znHvQBcPia aHTobqeHTZHleyASy1AzDbc3HlK4JjXKbSGBx8xDDjbuOxHq2mzapNpcWoWj6hCm+W0WZTKi8csm cgfMvJHcetc3ruiajea7eXNvb74ZP7G2NvUZ8i+kll4J/hRgffOBk8VT0jw7qtv4lhF2dSe0tNTv NQiJlthaDzjNt2AKZ2fE+CH2qDvIYgKGAOk0jWLzUb+9t7nSZ7KO3z5csmcTYnnj4yo/hhSTqeJV 7YJ8v+JPhfVNa8a3U9l4ovtOjji0mMwxD5SZbySND8rL/q2BkG7cdzHBUYx7RXn/AIm/5GfUP+5e /wDTlLQB5JpXgTXrn4y654fi8calBqFrZLLLqyh/NnUiE7G/eA4+derH7g49O7/4VB4w/wCis65+ U3/x+jw9/wAnQ+LP+wVH/wCg2tewUAeP/wDCoPGH/RWdc/Kb/wCP0f8ACoPGH/RWdc/Kb/4/XsFF AHj/APwqDxh/0VnXPym/+P0f8Kg8Yf8ARWdc/Kb/AOP17BRQB4//AMKg8Yf9FZ1z8pv/AI/R/wAK g8Yf9FZ1z8pv/j9ewUUAeP8A/CoPGH/RWdc/Kb/4/R/wqDxh/wBFZ1z8pv8A4/XsFFAHj/8AwqDx h/0VnXPym/8Aj9cJ4E8Ca9rfirxjZWXjjUtMn069EVzcwh9162+Ub3xIpzlCeS33zz6/TdeP/CD/ AJKH8Tv+wqP/AEbcUAH/AAqDxh/0VnXPym/+P1l6B8LPFV9p0s0HxO1m1Rb27iMaCXBZLiRGfiYc sylz7seT1Pulc/4N/wCQHc/9hXUv/S2agDP+Gen3Gl+Dvsl1qM+oTRahextPMACxW5kUn1+YqXO4 scsecYA3JvEOmW+qDTpJ5BPvWNnEEhijdsbUeULsRzuXCswJ3pgfMuafg3/kB3P/AGFdS/8AS2aq d54d1KbVLyOI2n9n32p2upSztKwliaDyP3ax7SHDfZ1+YuuPMPynb8wBuaNreneINOTUNKuPtNo+ NkwRlVuAeMgZxnBx0YMpwykCvD4p0aezubqO8zDb7Sx8pwXDnEbRrjMiueEZAwc8KWNSeGtNm0bw rpGl3DRtPZWUNvI0ZJUsiBSRkA4yPQVh23hvWI/CFtokslj/AMSz7ELIqz/v/ssiOGkbH7vzPLUb Qr7OTukzgAGpJ4v0OGyhu5ruSJJbj7KkctvKkvnbC4jMRXeHZRlVIBbcu3O5cxnxt4dWKaU6hiOG J5ZXMMmIyil3jY7eJlVWYwn94ACSuBVO28O6k+p22qXZtIp21g6jcQRStIsa/YmtQqOVUuSQjHKr jJHOATn614K1LUvCp0uGe0Wc3uqXG53YLtuUvFjHC5yDcpnjs2M4GQDc/wCE28O/9BD/AGv9TJ/q v+e/3f8Aj3/6b/6r/aq5D4h0y41Q6dHPIZ97Rq5gkEUjrnciSldjuNrZVWJGx8j5Wxl694bvNU/4 SfyJIF/tXRE0+DexG2QfaclsA4X98vIyeDx0zT/4RbWZPGdjq1xeRy29pezTktdzkyRvFKiKsH+q iMe9UyAS4BYlTlWANjTfGGgatbtc2mpRm3Fubrz5EaKNogAWdXcAMEyA+CdhOG2nijR/E9pres31 haJJizt4JZGlR4pFaRpRseJ1DIQIgwz1Dg4xgnD/AOEIvJ/D2l6TPdQR+R4auNGnlQF8SSpAodQQ NyjymPJB6epxsaNZax/wkOpatq1tY232i0traOK0unn/ANW8zFiWjTGfOAwAehoAPEP/ACHPCf8A 2FZP/SK6roK5/wAQ/wDIc8J/9hWT/wBIrqugoA5/wJ/yTzw1/wBgq1/9FLXQVz/gT/knnhr/ALBV r/6KWugoA5/wb/yA7n/sK6l/6WzUeMv+QHbf9hXTf/S2Gjwb/wAgO5/7Cupf+ls1HjL/AJAdt/2F dN/9LYaANi9sbfUIFhuo/MjWWOYDcRh43WRDx6Mqn3xzxVNfDmkKSTYxuClyjLIS6stxIJJgVJII ZgDg9OgwOK1KKAMMeEdHFu8Rju3d3V/tMl9O9wpUEDbOXMigBnGFYDDuP42ySeENDlSFGtJAkabH VLiVRcKWLET4b9+CzOSJN2S7k53tncooA5e78DaT5Ez6dbQW980XkRT3HmzLDHvR9iKJFKKpjUoE ZRG3KY5zHpXgPT7OykS6kke7muGuJLiylmtG3MiIwDLIZMMIkZ9ztvcFjzjHWUUAU5dKsZrCCwa2 jW0geF4oY/kVDE6vHgLjAVkXjpxjpxWf/wAIhoYt4oUtJIhDbwW0TxXEqSRRwhxGEdWDKQJJAWBB Icgkg4rcooAr2Njb6dZx2trH5cKZIBYsSSSWZmOSzEkksSSSSSSTXFax/wAlD1D/ALBVn/6Nuq72 uC1j/koeof8AYKs//Rt1QBo6N/yFoP8AgX/oJrrK5PRv+QtB/wAC/wDQTXWUAc/47/5J54l/7BV1 /wCimq5r3iHTfDVhHe6pcxwQSXEVurO6r8zuFz8xAwASx9FVj2qn47/5J54l/wCwVdf+imqTxbbX d1oSrZWsl3PFe2dx5EbIrOsVzFIwBcqudqHqRQBce/0e31xbN7uxj1e6iG2EyIJ5Y13kYX7zKP3h HYfN71HqniHTdGv9Ksr25jin1S4NvbKzquWCFs8kHGQF4z8zoO9c/f6RqcmqajaR2EjwX+sWWpLe iSMRRJD9m3I4Lb95+zNjarD50yR823Y1+2u5tR8O3FrayXCWmp+ZOEZAUja3mi3/ADEZAaRSQMnG cA9KAJNG8RWervJb+bBFfJLcr9k84NIY4bh4PM28HaSnXGATjJq5Hq2mzapNpcWoWj6hCm+W0WZT Ki8csmcgfMvJHcetcvp3hy7tH0pxYxxOniO/1C6ZSgJjkW7WORsH5iVkhHcgYBxg4r6R4d1W38Sw i7OpPaWmp3moREy2wtB5xm27AFM7PifBD7VB3kMQFDAHQaxrGpWus2Ol6Xp1pdz3VvPcM11eNAqL E0S4G2NySTMOw6GrEOpzWlkZvEP9m6a5dguy+MiFVQuTudI+QquSMcBSc9cYfizSFvvEOkXlz4Y/ t+xgtLqJ4dtu/lyO8BRtszqOkcgyMkfjUcegW9ydBFp4Tj0i0s9YN3PavFbKBi2lVZtsTspO9owD ncCoOABmgDqINW026uIre31C0mnltxdRxxzKzPCTgSAA5KE8bulFnq2m6hcXVvZahaXM9o+y5jhm V2hbJGHAOVOVIwfQ+lcvp3hy7tH0pxYxxOniO/1C6ZSgJjkW7WORsH5iVkhHcgYBxg4r+GtH8Qwe KrK61KCSOztdMntAga3WCKUvAdtukahhARGdhkYvhcMFOC4B0mla5/aWovZ+XAdmn2t751vP5sb+ cZRhG2jco8rIb+IN0Fcv4m/5GfUP+5e/9OUtaHgrRNR0j7N9ut/K2eH9Msm+dWxND5/mLwT03rz0 OeCeaz/E3/Iz6h/3L3/pyloA5/w9/wAnQ+LP+wVH/wCg2tewV4/4e/5Oh8Wf9gqP/wBBta9goAKK KKACiiigAooooAKKKKACvH/hB/yUP4nf9hUf+jbivYK8f+EH/JQ/id/2FR/6NuKAPYK5/wAG/wDI Duf+wrqX/pbNXQVz/g3/AJAdz/2FdS/9LZqADwb/AMgO5/7Cupf+ls1U9W127sfEN7biWT7PGmkh ETYCGuLyWJzkqcgqqgj0BwVJ3C54N/5Adz/2FdS/9LZqsX3huz1C/mvJZJ1kl+x7gjAAfZp2njxx 3ZiD6jpg80AYdh4+aTRo9V1PR5LO3n0eTV4EjuFmkaKJYzIGGFAJ81dnzHcOW8s/LWh4X8WQ+Iri 9tVfTZJ7RIpHfTL8XcG2QuFG/apDgxtldvAKnJzgSJ4O0sadY2EvnzWtppUmkBHfHmQSCINuKgHd iFeRjqfbGhpmmS6f5rXGqX2ozSYHmXZQbVGcALGqIOSedu45AJICgAHP6F4n1GW6jg1Gzzb3Oq31 hb3XmrvZopZ2UeWBgRiOEruLbiy/dIO8mm+L9U1fTtIltNCgjvNUtGvoYLq/2IsCiLcWdI3+YtMu 1ccrySrfINCw8I2dhqK3S3l9KiXc99HbTSho47iYybpF+XcPlldQudmDnaXyxB4Tgg07Sbax1G+s ptLtBZQXcPlNIYcICrB0ZDkxRknaDleCASCAZbfEaxTTRfSWskSSJbXMCSN8z2ksRlaY7QQpRIro 7MknyMD765k1Lxx9j3slvYxW5u5reK91K/8AsttJ5O1XBfYxWTzDIqoR8whdgcYzqL4R0VXsv9Cj aCzsjYx28iiRGi2hVDbgSxVTIoJPAmlHO80L4aEGl2VlYatqVk9qhU3MLRs8+7BdpA6MjOzDcX27 slsEbmBAMef4hW1v4gXTJorSB1uLe1mtp79FvRLMIyuyBQwdB5yBmDjG2TAO0btzQNZuNaW9lk0/ 7LbwXc9rE5mDmYxSvGzAAfKvyDGTnO4YwAzV7LwjZ6ZPENOvL6zsU8ovYwyjy5WiRI0LMVMnCxxg gOFYJ8wO5t2ppmmw6VavbwNIyPcT3BLkE7pZWlYcAcbnIHtjr1oAy/EP/Ic8J/8AYVk/9Irqugrn /EP/ACHPCf8A2FZP/SK6roKAOf8AAn/JPPDX/YKtf/RS10Fc/wCBP+SeeGv+wVa/+ilroKAOf8G/ 8gO5/wCwrqX/AKWzVoa1pKa3phspLme2/exTJNBt3o8ciyKRuVl+8g6g1n+Df+QHc/8AYV1L/wBL Zq6CgDn/APhHtU/6HPXP+/Nl/wDI9YeoW2uWl9JBH4v1cquMFoLPPIB/5967yue1PTLy41CWWKHc jYwdwHYe9AHN/wDE/wD+hu1b/vxZ/wDxij/if/8AQ3at/wB+LP8A+MVs/wBjah/z7/8Aj6/40f2N qH/Pv/4+v+NMZy8174jj8QWdgPFup+VNazzMTb2e4MjxAY/cdP3jZ+gq/wD8T/8A6G7Vv+/Fn/8A GKbdaTfDxvpUZg+Y6beEDevQSW2e/uK2/wCxtQ/59/8Ax9f8aAMb/if/APQ3at/34s//AIxR/wAT /wD6G7Vv+/Fn/wDGK2f7G1D/AJ9//H1/xo/sbUP+ff8A8fX/ABoAxv8Aif8A/Q3at/34s/8A4xTL axnj1G4v7zU7u/upoo4S9wsS7UQuVAEaKOsjdc1uf2NqH/Pv/wCPr/jR/Y2of8+//j6/40AGjf8A IWg/4F/6Ca6yue0zTLy31CKWWHai5ydwPY+9dDSEc/47/wCSeeJf+wVdf+imroKr39jb6np1zYXk fmWt1E8MybiNyMCGGRyMgnpWf4Yvri80OFL+Tfqdp/ot+SoUmdOGbaMYV+JF4GUdTgZoA2KKKKAC s/TtWTVF8y3tpxCJbmFpH2gK8MpiII3Z+YqxGB0XnBwDzf2O0XxnfS6lo93c6hJewvpt3FbOTDbi KIMBcDCxoHWctGXBYFvlbzAGx30rWmguVsLa7ivGsvEaW8gzEVllvUaHDnAUsBuU5GQMjgZoA9Mq ve31vp8CzXUnlxtLHCDtJy8jrGg49WZR7Z54rzO30KWfR7+K1t5Es7i90tRBp+jTaSilLtWlkWNn Mm/YVLSAKAEXDEqdtzWNAt00PWrJ9D83TLTxBYzWlnHYmVEgH2QzGKJVOV5uN2wc7pPU0AekUUUU AFef+Jv+Rn1D/uXv/TlLXoFef3/+n6fea8fmjvdb0uGzc9TaxXkKoeOCrSNPIrDO5JVOcYAAOf8A D3/J0Piz/sFR/wDoNrXsFeP+Hv8Ak6HxZ/2Co/8A0G1r2CgAooooAKKKKACiiigAooooAK8f+EH/ ACUP4nf9hUf+jbivYK8f+EH/ACUP4nf9hUf+jbigD2Cuf8G/8gO5/wCwrqX/AKWzV0Fc/wCDf+QH c/8AYV1L/wBLZqAC3/4lHi+7gf8A499axdRSHtcRxrG8eeBzGkbKoyTsmJ4AroKr31hZ6nZyWd/a QXdrJjfDPGJEbBBGVPBwQD+FY/nap4f/AHT2s+qaUn3J4pPMu4F9HQ8yqoB+dSZGyo2O2XYA6Ciu f/4TLS/+fXXP/BFe/wDxmj/hMtL/AOfXXP8AwRXv/wAZoA6Ciuf/AOEy0v8A59dc/wDBFe//ABmo x450Vrh7dYtZM6IrvGNEvdyqxIUkeVkAlWAPfafSgDpKK5//AITLS/8An11z/wAEV7/8Zo/4TLS/ +fXXP/BFe/8AxmgDoKK5/wD4TCwf5YLDXJZjwkf9jXUe9uw3SRqi5PdmVR1JA5o/s/Ude+bWR9j0 88f2XFIsn2hTzi4bb9AY0O3hgzSq2AAGj/8AE61Z/ER/49Vie005T1MfmZkmyOCspSMr94bI1YEe YyjoKKKAOf8AAn/JPPDX/YKtf/RS10Fc/wCBP+SeeGv+wVa/+ilroKAOf8G/8gO5/wCwrqX/AKWz V0Fc/wCDf+QHc/8AYV1L/wBLZq3J54bW3luLiWOGCJC8kkjBVRQMkkngADnNAElFc3BZ6l4jt4rv Ubu70+wnQSR6bbbrecKRkCeUHeHHynbGY9p3KTIOTJ/wgvhNuZfDelTyHlpri0SWSQ92d3BZ2PUs xJJ5JJoA6Ciuf/4QTwf/ANCpof8A4Lof/iaP+EE8H/8AQqaH/wCC6H/4mgAvP+Sh6N/2Cr//ANG2 ldBXP/8ACCeD/wDoVND/APBdD/8AE0f8IJ4P/wChU0P/AMF0P/xNAHQUVz//AAgng/8A6FTQ/wDw XQ//ABNH/CCeD/8AoVND/wDBdD/8TQB0FFc//wAI0+n/AD+H9Sn09hwLactc2hHQKImYGNVBO1Ym jA4yGCha0NH1P+1LN3kh+z3UEr29zAW3GORTg84BKkYdSQCyOrYGcUAaFFFFABWPfaTcJeSalpFz 9nu2w01u+PIvCAAPM+UsrbRtEiYPC7hIqKlbFFAHP/8ACV29j+7162n0iRfvzTqWtMdNwuAPLVSc hRIUc8ZQFgCf8J34P/6GvQ//AAYw/wDxVdBRQBz/APwnfg//AKGvQ/8AwYw//FUf8J34P/6GvQ// AAYw/wDxVdBRQBz/APwnfg//AKGvQ/8AwYw//FUf8J34P/6GvQ//AAYw/wDxVdBRQBz/APwnfg// AKGvQ/8AwYw//FUf8Jx4ak4s9Xg1GTqYdMDXsij+8UhDMF6DcRjJAzkiugooA5//AImPiP8A5/tH 0wf7sdzdg/m0MZU/7MuT/wAstnzx+K4IbXw3ZW9vFHDBFqemJHHGoVUUXkAAAHAAHGK6Suf8Zf8A IDtv+wrpv/pbDQB5/wCHv+TofFn/AGCo/wD0G1r2CvH/AA9/ydD4s/7BUf8A6Da17BQAUUUUAFFF FABRRRQAUUUUAFeP/CD/AJKH8Tv+wqP/AEbcV7BXj/wg/wCSh/E7/sKj/wBG3FAHsFc/4N/5Adz/ ANhXUv8A0tmroK5/wb/yA7n/ALCupf8ApbNQB0FFFFABRRRQAV4f4H8e/wBsfH7xFbm9/wBAvomt rONX85JGtz8jIwHyqV8+TAIX5z1OCfcK4vR/DWg6d8RtSex0TTbV4NMs3haC1RDGzyXauVwOCygA kdQADQB2lFFFABRRRQAUUUUAc/4E/wCSeeGv+wVa/wDopa6Cuf8AAn/JPPDX/YKtf/RS10FAHP8A g3/kB3P/AGFdS/8AS2ai4/4mnjL+z5+bTTbSG9MJ5WaaSRxGx/65+QxAOQWkVsBo1NHg3/kB3P8A 2FdS/wDS2ajQ/wB/4l8T3MnzTRXcNkjdMQpbxyquPZ55Tnr82M4AAANi+v7PTLOS8v7uC0tY8b5p 5BGi5IAyx4GSQPxqvpmu6Prfm/2Tqtjf+TjzPslwkuzOcZ2k4zg9fQ1j/EGb7P4TM/2mC18vULB/ PuBmOLF3CdzjK/KOp5HA6jrWPe63can4fnFr4v0q9m/tDTohPoaBHtxJdxq27MsoO4EgAjBwwIYH FAHoFRzzw2tvLcXEscMESF5JJGCqigZJJPAAHOa8/dbnT7jUZYdU1Jk0zXbCxtIpbt5FSKY2vmh9 xJlLee4BkL7ONm3Fc+/iK9+z66tnd3cYbw5qF27vqUs86XEYj2+YpRUtp08xt0URwpYZAATIB7BH PDM8yRSxu8L7JVVgSjbQ2G9DtZTg9iD3omnhtkDzyxxIXVAzsFBZmCqOe5YgAdyQKw/D3/Ic8Wf9 hWP/ANIrWuTtLtbvwVZSvqN3dag17o76lFM7Otvdm7h81OR+7fdw0IICYXCJu+YA9IhnhuULwSxy oHZCyMGAZWKsOO4YEEdiCKkryvUdVvVgsRd3saae17q6yy3msy6anmJelYU+0RgtkJ5gWPgEKT/A MSahNrA07Vr671e+F9pfhS0vlWF3gja8AuiZWjKqesYzGwCkcOh2qFAPTIZ4blC8EscqB2QsjBgG VirDjuGBBHYgisPWP+Jf4j0XU4/kW4lOn3bnhDGyO8ZY/wB4SqiIScDz3AGXFU/h7FaW+hX9va3E kpi1jUElEly8zRsLmTAJZiQduxsd9245LEm545+TwNrVyvE1naPewN/cmhHmxtjvh0U4PBxggjIo A6CiiigAooooAKKKKACiiigAooooAKKKKACuf8Zf8gO2/wCwrpv/AKWw10Fc/wCMv+QHbf8AYV03 /wBLYaAPP/D3/J0Piz/sFR/+g2tewV4/4e/5Oh8Wf9gqP/0G1r2CgAooooAKKKKACiiigAooooAK 8f8AhB/yUP4nf9hUf+jbivYK8f8AhB/yUP4nf9hUf+jbigD2Cuf8G/8AIDuf+wrqX/pbNXQVz/g3 /kB3P/YV1L/0tmoAp69pOm6z460S31TT7S+gXTL51juoVlUN5toMgMCM4JGfc1c/4QTwf/0Kmh/+ C6H/AOJovP8Akoejf9gq/wD/AEbaVc1LxLoOjXC2+qa3ptjOyB1jurpImK5IyAxBxkEZ9jQBT/4Q Twf/ANCpof8A4Lof/iaP+EE8H/8AQqaH/wCC6H/4mthL+zkvGs0u4GukzuhEgLrgITlevAkjJ/31 9RVigDn/APhBPB//AEKmh/8Aguh/+Jo/4QTwf/0Kmh/+C6H/AOJrYmv7O3+0efdwRfZohPPvkC+V Gd2HbP3V+RuTx8p9DUkc8MzzJFLG7wvslVWBKNtDYb0O1lOD2IPegDD/AOEE8H/9Cpof/guh/wDi aP8AhBPB/wD0Kmh/+C6H/wCJroKjhnhuULwSxyoHZCyMGAZWKsOO4YEEdiCKAMP/AIQTwf8A9Cpo f/guh/8AiaP+EE8H/wDQqaH/AOC6H/4mugqOGeG5QvBLHKgdkLIwYBlYqw47hgQR2IIoA5/wNBDa +G5Le3ijhgi1PUEjjjUKqKLyYAADgADjFdJXE+Gtb+yadeQfZ9+3VdR+bfjObyY+ldJp+rfb7hov I2YXdnfnuPb3oAo+BP8Aknnhr/sFWv8A6KWugrn/AAJ/yTzw1/2CrX/0UtdBQBz/AIN/5Adz/wBh XUv/AEtmo8Pf8hzxZ/2FY/8A0itaPBv/ACA7n/sK6l/6WzUeHv8AkOeLP+wrH/6RWtAHQVj2XijR 76fWoor6Af2NL5V67SptjwgcsTnhRllJOMNG4/hrYri7zSNTmfxGqWEhD6xY6lbN5keLlIVtS6J8 2Q+bdwN+0ZZecZIAOssb+z1OzjvLC7gu7WTOyaCQSI2CQcMODggj8Kpw+IdNutZTS7W5juZyk5do XV1iaFoldHwcq4MycY9c44zX8O212kusX93ayWh1G9FxHbysjSRqsEMWH2FlyTESMMeCOhyBxcXh PVrvTodKbR/slxbeFLnQ31GZ4vLuJGEKx7SjNJ5eUkYblBAboCSKAPQLXXdHvtOn1Gz1WxuLGDd5 1zDcI8ce0bm3MDgYBBOegoutd0ex06DUbzVbG3sZ9vk3M1wiRybhuXaxODkAkY6iuPTQdXu7bUL+ aLVZbtpdPdU1Oa0E0iWtyZyiLbgRjIZgpZ+WODsUBjqSwaha6lpetw+H5CEt7yKWws5YfNRp5YpA 7FmRCf3TF8MfnfguMtQBsa54h03w9ZS3F/cxq6W81wluHUSzrEhdxGpI3EKM+3fFWJNW02HVIdLl 1C0TUJk3xWjTKJXXnlUzkj5W5A7H0rzvUvCerWnhK50j+x/7XkuvDVrpS/Z3i2RXECzYdvOZPl3S oVKgkbCSAQM6l54d1WXxZeEnUn0+81O11ACCW2S1XyVg/wBaWUzb90GcJ8pGwblyxUA7yuf8d/8A JPPEv/YKuv8A0U1dBXP+O/8AknniX/sFXX/opqAOgooooAKKKKACiiigAooooAKKKKACiiigArn/ ABl/yA7b/sK6b/6Ww10Fc/4y/wCQHbf9hXTf/S2GgDz/AMPf8nQ+LP8AsFR/+g2tewV4/wCHv+To fFn/AGCo/wD0G1r2CgAooooAKKKKACiiigAooooAK8f+EH/JQ/id/wBhUf8Ao24r2CvH/hB/yUP4 nf8AYVH/AKNuKAPYK5/wb/yA7n/sK6l/6WzV0Fc/4N/5Adz/ANhXUv8A0tmoALz/AJKHo3/YKv8A /wBG2lV20u9n+Id5ex319Z2qafZAiGOMx3JWW5LIzOjHgEZ2FSA/XkYsXn/JQ9G/7BV//wCjbSrF /wCI7LSrq8jvX2x20VtIfKjklkJnleJBsVDnLIANpJJJyAACwBw/iC28SSeKNVnsVvkRfNjin8qR 1jt2GlmXywpDHKrckLGQ5ZX2HeM11ngqO9i0aZbu7u7mP7Qxt3uraWBhHtXICzSPMRv38yHPJwNg TMa+O9JfXLfTh56RvaXFzPPcW8sItvK2ErKHQbMq5bLFcDYekiE7Gma1Zav5otWnWSLBeG5tpLeR Qc4bZIqttOGAbGCVYA5BwAeV+J9H8Q3mg6xrx0WRhqVvc5t7aeY3eyeOFIkNusYKupt7bzB5jDAm 4YMAND7BPaR6+umjxBBBc6nbTPcTLfTMLc2abW27hM580FGEbq6/LvOxNh7RvGugpBJMbqfy02FC LOY/aAzrGrQ/J++Us6DdHuHzrzhhmS88T2kXhXVdctEknGn280slvKjwSBkTfsdXUMhIwRlejA4I IyAcXpT621tCPESeI0mjieLT1sVlVxMtzOv7zazof3YtcG4d4zydzAyMZG03xHp2lyXWitqX9qXW p6siQuf3UcbfbJIT5bDywGlELCRhk7wN2wha6DTPHFjNYXt/qWo+H4rS1eFHm07VftioZH2L5h8t PLG7GCcjqTgDNamj+KNJ12V4rGafzE3/ACXFpLbltjbH2iRV3bW+VsZ2kgHBIoA4exh1WK1/fX2u XWiG7j+1+XZ31vMq+VNny/Mle6P7z7NnZhQBxkGXHWeBYLu28LKl9FdxXBvb12W7VFlO66lYFtny ZIIOV+U5yOMVIfGOkyKPs0+5mlhSMzxSxJMskqRb4mKESrmRcMmV+ZMsoYNWhoWp/wBt+HtM1byf J+3WkVz5W7ds3oG25wM4zjOBQBwejf6m/wD+wrqH/pXLXT+Hv+P+T/rkf5iuY0b/AFN//wBhXUP/ AErlrp/D3/H/ACf9cj/MUxkvgT/knnhr/sFWv/opa6Cuf8Cf8k88Nf8AYKtf/RS10FIRz/g3/kB3 P/YV1L/0tmo8Pf8AIc8Wf9hWP/0itaPBv/IDuf8AsK6l/wCls1Hh7/kOeLP+wrH/AOkVrQB0FFFF AEc88Nrby3FxLHDBEheSSRgqooGSSTwABzmsN/GugxRK891Pbs8ohSG4s5opmdldlAjZA53CNwuB 8zKVXLcVoa7pn9t+HtT0nzvJ+3Wktt5u3ds3oV3YyM4znGRXL6Z4QvodasdUmigt5IbtXlU6pc3z tGsFzGMSTAfxXHCBQBhjuYkAAHQWPinRtRvI7W1vPMmfKgGJ1AkAJaJmIAWYAEmIkOACSoAqvJ4x 0k6dqF1bT7vslpJdqZ4pYo5o0GS8blD5kf3cvGHADKedy5r2vhu8g/sndJAfset3uoSYY8xzfato HH3h56ZHThuTxnn5vAmv3X9pNdX8Es1zol7poklvJ5PNmm8vE21spCrFDmONcJgAFxgIAdxo2p/2 vYyXPk+Vsu7m227t2fJmeLdnA67M47Zxz1rQrL0DTZtK06W3naNne9u7gFCSNstxJKo5A52uAffP XrWpQAVz/jv/AJJ54l/7BV1/6Kaugrn/AB3/AMk88S/9gq6/9FNQB0FFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFc/wCMv+QHbf8AYV03/wBLYa6Cuf8AGX/IDtv+wrpv/pbDQB5/4e/5Oh8Wf9gqP/0G 1r2CvH/D3/J0Piz/ALBUf/oNrXsFABRRRQAUUUUAFFFFABRRRQAV4/8ACD/kofxO/wCwqP8A0bcV 7BXj/wAIP+Sh/E7/ALCo/wDRtxQB7BXP+Df+QHc/9hXUv/S2augrn/Bv/IDuf+wrqX/pbNQAXn/J Q9G/7BV//wCjbSjU/DH9o6pcXv2zy/O/s/5PKzj7LctP1z/Fu2+2M89KLz/koejf9gq//wDRtpWf 438SaxoWRpMdi2zSr7UJGu1dsfZ/KIACkZ3eYVwSMZDZO3awAX/gX+0Na1K7k1Hba6lFdW9zCsHz iOeC3iOx92AwNsGyVIO4jHGa2NJ0m8tdRu9S1K9gur65iityba2MEaxxmRl+Vnc7syvk7sY28DBJ 5++8U67aW8mnw2sF7q66qNNEsEACPm1F1vETzL0X5MGUdN2f4KjbxZr5tbWdoNNthCjnUd7LMIis rxgy+XKTboxjPzgThDv34ERZgCO3+GKQapBfDUYBJF5as6WCrJcBLmCcPNIG3STN5BDOTgl9wVSG 3dBe+GPtml+KbL7Zs/t7f8/lZ8jdbRwdM/N/q93brjtmsPVfF2tafe3GF037NLcfY7AFSwml3+Xh JVkIeUNwYXWHnf8AvNsTPVfTPHOr6g81k6aba3di9213PdELEy2627Mh8uWQQn/ScF98mzyySpJ2 qAdJNo2sajYm21bVLGXbd2tzG1pYPDjyZllKkNM+d2wDIxjk89KNM8Mf2dqlve/bPM8n+0Pk8rGf tVys/XP8O3b75zx0rl9F8deItWbT7oaVB9gP2GK7kHlonmXEUMhKyPOGXHnqAgicttADZf5bnjzU NVsb8vb3ka2MGhalfNbASI0ksSIqkyRyKQP33A7YJ+9saMAjt/hikGqQXw1GASReWrOlgqyXAS5g nDzSBt0kzeQQzk4JfcFUht3YaFpn9ieHtM0nzvO+w2kVt5u3bv2IF3YycZxnGTXn8fjDxFam/gsL L7bHp8t5dXMs7x4Mf226REMkk0fkqqwEbsSAA/dAUBvUKAPM9G/1N/8A9hXUP/SuWun8Pf8AH/J/ 1yP8xXMaN/qb/wD7Cuof+lctdP4e/wCP+T/rkf5imMl8Cf8AJPPDX/YKtf8A0UtdBXP+BP8Aknnh r/sFWv8A6KWugpCOf8G/8gO5/wCwrqX/AKWzUeHv+Q54s/7Csf8A6RWtHg3/AJAdz/2FdS/9LZqN L/0bxp4gs05jmitNQYnqJHEkBA/2dtrGQOuS3OCAACvrniy40jUdRhj0r7Ra6bp8epXdwbgJtiJm DKq4JaTEJKjhTzlkwN1PUvHjaQ7WupWNpYXjvCYReagscCpKszL50u0iN8W8oKqHG4oAzBiV3NS8 N2eqf2v58k6/2rp66fPsYDbGPNwVyDhv3zcnI4HHXMepeF7bUNUbVBd3drfhIVingKEwmPzgGUOr KSVuJVO4EYIwAQDQBjy/ECE6Jp+oQJpqJdvOhuL3URBZhoX8tgs4RtxZgWQbRuRWb5cYq4PFsreI 4dJNhBBI2wNb3V8kd425AxeKHBWWNMkMwk6xygBio3aE2hSvZ20UGuarbTw7t10kiO8u45bcsiNH ycEYUbfuptUlTXXwjZxfY4Iby+j0y18gppvmh4S0O3yjllMg2mOM4VwpK5IO5twBlxfEK2juNTiv YrQPY2VxfPBY36XM8SQlQ6TIABHL84AUM4JDjd8oJkuvGtxpS6qmsaXBZzWEVo/mC+DQObiV4kPm FQVjUqNzMoI+bCkKC0n/AAgtjBbyqsl3eoumT6Zb2V1c7IEt5AmIQUXKgeWB5nzPgncXwuK+k+EL 6Y6nc6/dyNd3iWqh47rz2R7eR5I5Q3lRopDOvyCPb+7y24u1AGp4f8S/8JHpN9PZLYzXVpK1ufs1 751tJJ5auu2YJkrh1BOzIIYYOMnk9I8Ua5No8F1d3cn2u8TRrwqDE0UUd3dmNo4wIlYDYv8AGzkb sBiV3N6Bptg2n27RyX13eyu5d57plLMcADAUKigAAYVQOpOSSTj2/grTba1t7dJ7spBb6fbqS65K 2cpliJ+XqWOG9R0x1oAp2Hj6zvvFC6Opsf3t3PZxxpfB7tZIRJuaSDb8kZ8p8NuJOY+BuO3Q8d/8 k88S/wDYKuv/AEU1WLPw+ljqLXEOoXwtTLJOlhvUQpLIWZ2yFDtlnc7WZlBbIA2rtr+Mf9J0P+x1 5k1mVdP2jgmN8mcqegZYFmcE8ZUDBJCkA6CiiigAooooAKKKKACiiigAooooAKKKKACuf8Zf8gO2 /wCwrpv/AKWw10Fc/wCMv+QHbf8AYV03/wBLYaAPP/D3/J0Piz/sFR/+g2tewV4/4e/5Oh8Wf9gq P/0G1r2CgAooooAKKKKACiiigAooooAK8f8AhB/yUP4nf9hUf+jbivYK8f8AhB/yUP4nf9hUf+jb igD2Cuf8G/8AIDuf+wrqX/pbNXQVz/g3/kB3P/YV1L/0tmoALz/koejf9gq//wDRtpWxc2Fnebvt VpBPuieA+bGGzG+N6c/wttXI6HAz0rHvP+Sh6N/2Cr//ANG2ldBQBTudJ029t7m3u9PtJ4Lpw9xH LCrLMwCgFwRhiAiAE/3R6Co5dC0eb7D5ulWMn9n4+xbrdD9mxjHl8fJjavTH3R6VoUUAZ76Fo8l5 dXkmlWL3V3EYLmZrdC80ZABR2xllwAMHjgVn6l4Rsb6K0itZP7MjtZVnRLS0tiPMRVSN8SxPhkVQ qlcEDjoBjoKKAMu08N6LZPYSwaXaCfT7dbW0naIPLDEqlQiyHLYwSOvc+pq5c2FnebvtVpBPuieA +bGGzG+N6c/wttXI6HAz0qxRQBnzaFo9xLbSzaVYySWsrT27vboTFIzb2dSR8rFvmJHJPPWtCiig DzPRv9Tf/wDYV1D/ANK5a6fw9/x/yf8AXI/zFcxo3+pv/wDsK6h/6Vy10/h7/j/k/wCuR/mKYyXw J/yTzw1/2CrX/wBFLXQVz/gT/knnhr/sFWv/AKKWugpCOf8ABv8AyA7n/sK6l/6WzVY1uxuDLbat p0fmajZZVYywAmgdkM0XOBuIQFTlcOi5YKWBr+Df+QHc/wDYV1L/ANLZq6CgCvY31vqNnHdWsnmQ vkAlSpBBIZWU4KsCCCpAIIIIBFWKx77QEkvJNR0yf+zdTkx5txDErC5AACrOpH7xRgc5VwMhXXcc 1/tPjCP5P7K0O428ed/ac0Pmf7Xl+Q+zPXbubHTcetAHQUVz/wBs8Yf9ALQ//BzN/wDItH2zxh/0 AtD/APBzN/8AItAHQUVycmveKotZttLbQNG8+4t5rhGGsS7QsbRqwP8Ao2c5lXHHY9O9z7Z4w/6A Wh/+Dmb/AORaAOgorn/tnjD/AKAWh/8Ag5m/+RaPtnjD/oBaH/4OZv8A5FoA6Cufsf8Aifa5HrA+ bS7WIpp7HpNI+RJOB3UKFSNxgkPMRlHVif2Bcav83iWeC8gPI0uKIfZFPUb9wLTMuSMnahwreWrK COgoAKKKKACiiigAooooAKKKKACiiigAooooAK5/xl/yA7b/ALCum/8ApbDXQVz/AIy/5Adt/wBh XTf/AEthoA8/8Pf8nQ+LP+wVH/6Da17BXj/h7/k6HxZ/2Co//QbWvYKACiiigAooooAKKKKACiii gArx/wCEH/JQ/id/2FR/6NuK9grx/wCEH/JQ/id/2FR/6NuKAPYK5/wb/wAgO5/7Cupf+ls1dBXP +Df+QHc/9hXUv/S2agC5qvh/T9ZuLe4u/taz26OkUlrezWzBXKlgTE6kglEODnoKp/8ACG6X/wA/ Wuf+D29/+PV0FFAHmf8AY0f/AEEtc/8AB3ef/HaP7Gj/AOglrn/g7vP/AI7XT/8ACPXf/PSD/vo/ 4Uf8I9d/89IP++j/AIUxnMf2NH/0Etc/8Hd5/wDHaP7Gj/6CWuf+Du8/+O10/wDwj13/AM9IP++j /hVOOwll1m50tWTz7e3huHYk7SsjSKoHGc5ibPHcdewBif2NH/0Etc/8Hd5/8do/saP/AKCWuf8A g7vP/jtdP/wj13/z0g/76P8AhR/wj13/AM9IP++j/hQBzH9jR/8AQS1z/wAHd5/8do/saP8A6CWu f+Du8/8AjtdP/wAI9d/89IP++j/hR/wj13/z0g/76P8AhQBg2NjBp1qLe3Egj3u5MkrSMzOxZiWY kklmJyT3re8Pf8f8n/XI/wAxR/wj13/z0g/76P8AhV7StKnsbppZXjKlCvyk56j29qAK3gT/AJJ5 4a/7BVr/AOilroK5/wACf8k88Nf9gq1/9FLXQUhHP+Df+QHc/wDYV1L/ANLZq6Cuf8G/8gO5/wCw rqX/AKWzV0FABRRRQAUUUUAeZ698SvCWj/Ea0TUNTkt3sLK8trlXs58pI8lsyD7nIKxsQwyCADnk Z9Mrw/xx4C/tj4/eHbgWX+gX0S3N5IyeckjW5+dXUn5VK+RHkgL846nIPuFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFc/4y/wCQHbf9hXTf/S2Gugrn/GX/ACA7b/sK6b/6Ww0Aef8A h7/k6HxZ/wBgqP8A9Bta9grx/wAPf8nQ+LP+wVH/AOg2tewUAFFFFABRRRQAUUUUAFFFFABXj/wg /wCSh/E7/sKj/wBG3FewV4/8IP8AkofxO/7Co/8ARtxQB7BXP+Df+QHc/wDYV1L/ANLZq6Cuf8G/ 8gO5/wCwrqX/AKWzUAdBWHP4iaS4ltdI0u71OWNzFJMm2K3icHGGlcjcAwYN5QkKlWBXOAS8nm1f VJ9GtZZILe3RGvrmJiH+fJEEbD7jlQGZshlV028uHTYgghtbeK3t4o4YIkCRxxqFVFAwAAOAAOMU AYf2zxh/0AtD/wDBzN/8i0fbPGH/AEAtD/8ABzN/8i10FFAHP/bPGH/QC0P/AMHM3/yLWfDb+MIv EN7q39kaGftNpBbeV/a83y+U8zbs/Zuc+djGONvfPHYUUAc/9s8Yf9ALQ/8Awczf/ItH2zxh/wBA LQ//AAczf/ItdBRQBz/27xZH88ugaU8a8stvq7tIw7hA9uqlvQMyjPUgc1YsfElndXkdhdRz6bqU mdlnfKEeTAJPlsCUlwvJ8tm25G7B4rYqnqumw6vpdxYTtIiTJgSREB4m6q6Eg7XVgGU9iAe1AFyi svStSmnuLjTb9Y11K0RHlMQPlyxuWCSpkkqGKOChJKlSMsNrtqUAc/4E/wCSeeGv+wVa/wDopa6C uf8AAn/JPPDX/YKtf/RS10FAHP8Ag3/kB3P/AGFdS/8AS2ajxmX/AOEfSOOeeHztQsYXeCZon2Pd xIwDqQwyrEcEdaPBv/IDuf8AsK6l/wCls1HjL/kB23/YV03/ANLYaAD/AIQ3S/8An61z/wAHt7/8 eo/4Q3S/+frXP/B7e/8Ax6ugooA5/wD4Q3S/+frXP/B7e/8Ax6j/AIQ3S/8An61z/wAHt7/8eroK KAObPgbRWuEuGl1kzojIkh1u93KrEFgD5uQCVUkd9o9Kk/4Q3S/+frXP/B7e/wDx6ugooA5//hDd L/5+tc/8Ht7/APHqP+EN0v8A5+tc/wDB7e//AB6ugooA5/8A4Q3S/wDn61z/AMHt7/8AHqr6HaDT PGWsWEFzfSWq6fZTKl3ezXO12kuQxBlZiMhF6egrqK5RtQhsPiHq3mq536VY42gdpbv396AOrorO ttZt7u4WCNJQzZwWAxwM+taNABRRRQAUUUUAFFFFABRRRQAUUUUAFc/4y/5Adt/2FdN/9LYa6Cuf 8Zf8gO2/7Cum/wDpbDQB5/4e/wCTofFn/YKj/wDQbWvYK8f8Pf8AJ0Piz/sFR/8AoNrXsFABRRRQ AUUUUAFFFFABRRRQAV4/8IP+Sh/E7/sKj/0bcV7BXj/wg/5KH8Tv+wqP/RtxQB7BXP8Ag3/kB3P/ AGFdS/8AS2augrn/AAb/AMgO5/7Cupf+ls1AB4R/e2OpXr83Fzqt55r/AN7ypmgTjoMRwxrx125O SSTT8V+JJtG1nS7JdZ0bSILq3uJXudUjLKWjaEKi/vYxkiRj1P3elXPBv/IDuf8AsK6l/wCls1Sa xo+pXWs2OqaXqNpaT2tvPbst1ZtOrrK0TZG2RCCDCO56mgCuPFENno2l3MlxHrcmoXDW0E2jQgxz SBZHAAMjBRiMqWLkA8sVXJUt/GljO6BrLUoo2eWDzWt9w+0RK7SQKqks7qI5PmQMhKlVctxVx9Jv LttFnv72CS6067e5doLYxpLmKWIKFLsVwJQc5OdvbPGfN4O8/Trez/tOeHytQvb3zrddkg+0C5GE bJ2sv2nIbnlOgzwASSeKgIpEmsrvTryK4s0e3ukjkby7icRIw8uQrgkOPvZXaSVIwGk07xJv8DaV r9/Hma8tLaQw26/fmmCBUTceMu4UbjgZ5IGTWPp/w7Sxe8kS5sYGu5bCV4rDTVtoUNrcGX5UDE/O CASzMQcnOMIuwnhjy/BenaALz95p8VqIrkxcNJblGRmTP3S0a5UMDgkBgeaAKfiXxbNpGh2epR28 luJXuFnjurctJF5VrcSnCh1DENCBw21hna2CGrQuPFFtbao9obS7eCG4itJ71QnlQzybPLjYFg5J 82LlVKjeMkYbbT8Q+E7jxHoEGn3eq/6Qn2gyXAtxhjLbzQ4VARhV8/IBJOEAJJJao7jwPbT+LH1s LprGa4iuZHn01JbpXjVFURTMcImI142EglyGUkFQCxB4ytrm4aGHTdSb/SLizhkaNFWe4hMm6JCz jJKxOwY4TjBYMCoueFNWuNe8JaTq13bfZ7i8tI5pIxjGWUHK4ZvlPUZOcEZwciq9v4Y+z/2b/pm7 7Fqt3qX+qxv8/wC0fJ142/aOvOdnQZ4ueG9Km0Pw1pukz3Md09lbpbiZIjEHVBtU7SzYO0DPPJye OgAKes/6N4q8NXicyTS3GnsD0EbwtOSP9rdaxgHpgtxkgjoK5/xD/wAhzwn/ANhWT/0iuq6CgDn/ AAJ/yTzw1/2CrX/0UtdBXP8AgT/knnhr/sFWv/opa6CgDn/Bv/IDuf8AsK6l/wCls1HjL/kB23/Y V03/ANLYaPBv/IDuf+wrqX/pbNR4y/5Adt/2FdN/9LYaAK/xBtvtnhM2u2BvO1CwjxcRebGc3cI+ dMjcvPK5GRxkVy/jnTE8PeAEsoLXSoWn+3mf7Bp628bH+z7shlQlijYVQWDZIBGcEivUKKAPP9G1 /XbvxzJaXN/YiH7Xcwyab54aaKBC4jl8lYQ8e4LG295ShEnABdAM/wAWLKvjPVEi1bZdTRaG9vbT IjIuNRK7toCuyq2Cfm/5akE/c2+gQ67o9xLcxQ6rYySWsqwXCJcITFIzbFRgD8rFvlAPJPHWga7o 7SwxDVbEyTRJPEguEzJG7BEdRnlWZlUEcEkAcmgDg9X1/XLKW50qPWJFNpevAt7MIopLj9xbyrHu EEitKTO4WJIdzhOCCjCS58MNRl1Ua5fXWoedeXktpeS2w2AQ+bZQOCoA3BTkoNxPEQ5Lbi3UWHin RNQntrWLVLEX9xEkq2X2uJ5gGQSD5UY5+U5ypII5BI5on8UaPGs3k30F3Jb3cFncRWsqSPDJLKIl DgH5fmPOeflPBIxQBxeoeKvFek2V1N5Md0dJQWFwTEGNzdskvlvsT5su32EhU4UXTqclcx5+meK9 fbS9QtLzxNpryW6Wkg1dJl8hzJ5wcLcfZhFGm6EAExyDcWj372Gz0iy8Q6be2t3cfaY4Es3mFwJ3 VTEsUskRdueELQyEE9lPTBA1KAMvw5eNqHh+zunuJLjzEJEskSozrk4J2koxxj50+R/vJ8rCuW1j /koeof8AYKs//Rt1Xe1wWsf8lD1D/sFWf/o26oA0dG/5C0H/AAL/ANBNdZXJ6N/yFoP+Bf8AoJrr KACiiigAooooAKKKKACiiigAooooAK5/xl/yA7b/ALCum/8ApbDXQVz/AIy/5Adt/wBhXTf/AEth oA8/8Pf8nQ+LP+wVH/6Da17BXj/h7/k6HxZ/2Co//QbWvYKACiiigAooooAKKKKACiiigArx/wCE H/JQ/id/2FR/6NuK9grx/wCEH/JQ/id/2FR/6NuKAPYK5/wb/wAgO5/7Cupf+ls1dBXP+Df+QHc/ 9hXUv/S2agA8G/8AIDuf+wrqX/pbNWXqOsalo3iXxXqEs8dzp+naFBeRWQVkO4G4P39xAJ8tgSE5 BT+582p4N/5Adz/2FdS/9LZq0JtE0641G4vp7fzZrm0FlOruzRywgsQrRk7G5duSM4YjOCRQBT0e /wBS/tm+0jVJbS4ntreC6W4tYGgUrK0q7CjO5yDCTu3c7gMDGTl3HiTWI/DniHXo47E2tlFf/Zom V96SWzug3nOJFcxluNhXhfnzuHQaZotlpHmm1WdpJcB5rm5kuJGAzhd8jM20ZYhc4BZiBknNeTwt o039oCSz3LfxSQzr5r7dkn+sCDOI95+Ztm3cwDHJANAHN614t1zSb17IWsc15bWSX0lvaabc3YuC 7yhYFkTiIgRbfNcEMW3bFClauaz4qutM8Qx26PBLa/a7a0eCKynlbMzom57kfuoWHmBvLYElQvI8 wbdzUvD2matcLPeQSM4QRuEnkjWZASQkqqwEqct8rhh8zcfMcx3vhbRtQ1Fb+6s/MnWWOcfvXCCW MqUl2A7fMG1V343FRtJ28UAcXY+Jtc0+zt7G4vo5ru5vdUcXSaTc3mxILry/L8mOQuAS+Q27CKqp gnDV3EGqzSeFYtXuLaOxnayF1Jb3kpiWBtm4pI5XKhTwW28YJx2qu/hHR2R1WO7iLXEtz5kF9PE6 vK26QK6uGVGYBigIUkA4yM1qfYLP+zv7O+yQfYfK8j7N5Y8vy8bdm3ptxxjpigDg4PGeuXGrW+jW 4tJrua4iQ3N1plzYqqSQ3T8QyMXYqbbOdwD7ivyEFx2Hh/UptV0nz7hYxPHcXFrIYwQrtDM8RcAk lQxTdtycZxk4ya9n4Q0Owv0v4LSQ3iurm4luJZZHZUlRS7OxLkLNIoLZ4IHRVxqWdjb6fA0NrH5c bSyTEbicvI7SOefVmY+2eOKAMfxD/wAhzwn/ANhWT/0iuq6Cuf8AEP8AyHPCf/YVk/8ASK6roKAO f8Cf8k88Nf8AYKtf/RS10Fc/4E/5J54a/wCwVa/+ilroKAOf8G/8gO5/7Cupf+ls1HjL/kB23/YV 03/0tho8G/8AIDuf+wrqX/pbNR4y/wCQHbf9hXTf/S2GgDoKKKKAPO38Cale6dpOm366a9ppFvBY oDI0gvYVuLWR2kQoBGSlrjZlwTJgsAMmPXbG6uPFEmn2tn9oWbW7HVTNLYz/ALoxCBXVJCgiGI4m bzPMyctGEyc1nr8RtRvzKukX+lXklxd2strGtwoKW7XvklWCq5TdG1qSHAcGeUjlPLXYtPGet2ui o95pkF3qEuoX0SRwzSyBYoZ2TpFA0h2nCg+XtwAWZWdVIBJovgrUtN8KjS5p7Rpxe6Xcbkdiu22S zWQcrnJNs+OO65xk4z4Ph7rMeoafM9zaeVZpDFj7VO4k8u7tZjIkbfu4AywOBDGoVDtG5gRs6TR/ Flx4haO60rSvM0z9wJpJbgJOhlijmBWPBVlVJkLHzAeHwGwu7D034gX1p4T0m81nTJHub3TIbi3e N973DloImZ0jQ7A0lxGyhA5Kk/KGAQgFiTwpMl3YWriRhd3t62oeRnypLNrh7lFkJGGO5o49hzlJ 7gAEFmHeVx9l4zv77yLeLw9Ot+3nSPDK0kCvFF5W5ojNGjOx89AA6xqWDgsAoZtjwnfXGp+DdDv7 yTzLq60+3mmfaBudo1LHA4GST0oA2K4LWP8Akoeof9gqz/8ARt1Xe1wWsf8AJQ9Q/wCwVZ/+jbqg DR0b/kLQf8C/9BNdZXJ6N/yFoP8AgX/oJrrKACiiigAooooAKKKKACiiigAooooAK5/xl/yA7b/s K6b/AOlsNdBXP+Mv+QHbf9hXTf8A0thoA8/8Pf8AJ0Piz/sFR/8AoNrXsFeP+Hv+TofFn/YKj/8A QbWvYKACiiigAooooAKKKKACiiigArx/4Qf8lD+J3/YVH/o24r2CvH/hB/yUP4nf9hUf+jbigD2C uf8ABv8AyA7n/sK6l/6WzV0Fc/4N/wCQHc/9hXUv/S2agA8G/wDIDuf+wrqX/pbNXQVz/g3/AJAd z/2FdS/9LZq6CgArm/GGpahYw6Xb6ct2Zb+9+zsbIQ+eFEMsuY/OPl5zGAd2flLY5wR0lV76ws9T s5LO/tILu1kxvhnjEiNggjKng4IB/CgDi7K/8Q6td6Lp76nJpxmt9Ra5aNLeWc+RcRRx5Yb4llw3 z4BXJcBVO0pTt/E2sjTNIvLzU/n13ShdiO3tExbymS2RI4Ax+8/2nbulZlD7WIVAyn0CGws7f7P5 FpBF9miMEGyML5UZ25RcfdX5F4HHyj0FRnSdNa3S3bT7QwJbtapGYV2rCwAaMDGAhCqCvQ7R6UAc Po2v3mpX2nW9w0khtPEctiXu1t3nwNPkkYM0OY1cOzLlMHaNp53Z6TwJ/wAk88Nf9gq1/wDRS1qQ aTptqIhb6faQiJw8YjhVdjCPygRgcER/Jn+7x04qT/Q9L07/AJYWdjaxe0ccMaj8AqgD6ACgCxRW XbeINPuhbFftcJurg20K3VlNAzyCNpCAsiKcbUY7unBGc8VqUAc/4h/5DnhP/sKyf+kV1XQVz/iH /kOeE/8AsKyf+kV1XQUAc/4E/wCSeeGv+wVa/wDopa6Cuf8AAn/JPPDX/YKtf/RS10FAHP8Ag3/k B3P/AGFdS/8AS2ajxl/yA7b/ALCum/8ApbDR4N/5Adz/ANhXUv8A0tmo8Zf8gO2/7Cum/wDpbDQB 0FV7+xt9T065sLyPzLW6ieGZNxG5GBDDI5GQT0qxRQBl654e0zxHb20GqQSSpbXC3UJjnkiaOVQQ rhkYEEbj3qu/hDQ5EdHtJGR7iW4ZTcSkMZW3Sofm5idhlov9Wx5KmtyigDDt/CGh2j2rQWkkaWqR LHCLiXyj5ahY2ePdsd1Cph2BYbE5+UYkbwtozWdnamz/AHNlafY7YCVwYosxkbWzkMDDGQ+dwKAg g1sUUAYZ8IaG9ukMlpJIFdmZ5LiV5JtwAZZXLbpUYKgKOWUhEBBCqBqWFjb6Zp1tYWcfl2trEkMK bidqKAFGTycADrViigArgtY/5KHqH/YKs/8A0bdV3tcFrH/JQ9Q/7BVn/wCjbqgDR0b/AJC0H/Av /QTXWVyejf8AIWg/4F/6Ca6ygAooooAKKKKACiiigAooooAKKKKACuf8Zf8AIDtv+wrpv/pbDXQV z/jL/kB23/YV03/0thoA8/8AD3/J0Piz/sFR/wDoNrXsFeP+Hv8Ak6HxZ/2Co/8A0G1r2CgAoooo AKKKKACiiigAooooAK8f+EH/ACUP4nf9hUf+jbivYK8f+EH/ACUP4nf9hUf+jbigD2Cuf8G/8gO5 /wCwrqX/AKWzV0Fc/wCDf+QHc/8AYV1L/wBLZqADwb/yA7n/ALCupf8ApbNXL23hWKSXT5Z9MnMl 34g1EXzsHBe0LXbpG5/592YRNs/1bFgSCWOeo0X/AIluuato7/JHJKdQsl7GOTBlAJ5ZhP5jsOQo mjGQCFHQUAeV6hpV79j0uO6so20u2uNUi+z3mjS6jEn+lD7Ntt4yGAEKuEfG1UO0Y3jNi00m5stb 0k3Nnd6hqSJZq899YObgBUjWRkvY5GSFBh3aFiS7eaMsJVJ9MooA83ewnt/EeoyWejT314/2pmZr eWyuSrI5QG/V/LljJKIkY+aMNGxw0Jxn6fp1+LbXIYdL8rSW/s2UQ2ejyWENxEty5usW7MzMxiXa wIDOoUbWBQt6xVe+sLPU7OSzv7SC7tZMb4Z4xIjYIIyp4OCAfwoA8f8A7OE2q6g0Gl+XoUeoTD7J qGjzaiiO1rYmE/ZkbdH8gl2kgeWp2EIWCjuNc0m4uPhBe6XdQz6hfDRGjKzxiSaWdYflJAL5k3gH hm+boT1rqLGws9Ms47OwtILS1jzshgjEaLkknCjgZJJ/GrFAHl+u6HqirqdvodhPBINVlNj9nTyl jH9imKNkbgIokwgbIAbjINbngSwNpcalNDHHBZyJCqQW+iyaXAJFMhdhFI5YuQyBn2gEKgBYqQva UUAc/wCIf+Q54T/7Csn/AKRXVdBXPr/xO/FEc6/Np2kb/LkH3Zbxg0bYPH+qTep6qWmYcNEcdBQB z/gT/knnhr/sFWv/AKKWugrn/An/ACTzw1/2CrX/ANFLXQUAc/4N/wCQHc/9hXUv/S2atDWtJTW9 MNlJcz2372KZJoNu9HjkWRSNysv3kHUGs/wb/wAgO5/7Cupf+ls1dBQBz/8Awj2qf9Dnrn/fmy/+ R6w9QttctL6SCPxfq5VcYLQWeeQD/wA+9d5XPanpl5cahLLFDuRsYO4DsPegDm/+J/8A9Ddq3/fi z/8AjFH/ABP/APobtW/78Wf/AMYrZ/sbUP8An3/8fX/Gj+xtQ/59/wDx9f8AGmM5ea98Rx+ILOwH i3U/KmtZ5mJt7PcGR4gMfuOn7xs/QVf/AOJ//wBDdq3/AH4s/wD4xTbrSb4eN9KjMHzHTbwgb16C S2z39xW3/Y2of8+//j6/40AY3/E//wChu1b/AL8Wf/xij/if/wDQ3at/34s//jFbP9jah/z7/wDj 6/40f2NqH/Pv/wCPr/jQBjf8T/8A6G7Vv+/Fn/8AGKZbWM8eo3F/eand391NFHCXuFiXaiFyoAjR R1kbrmtz+xtQ/wCff/x9f8aP7G1D/n3/APH1/wAaADRv+QtB/wAC/wDQTXWVz2maZeW+oRSyw7UX OTuB7H3roaQgooooAKKKKACiiigAooooAKKKKACuf8Zf8gO2/wCwrpv/AKWw10Fc/wCMv+QHbf8A YV03/wBLYaAPP/D3/J0Piz/sFR/+g2tewV4/4e/5Oh8Wf9gqP/0G1r2CgAooooAKKKKACiiigAoo ooAK8f8AhB/yUP4nf9hUf+jbivYK8f8AhB/yUP4nf9hUf+jbigD2Cuf8G/8AIDuf+wrqX/pbNXQV z/g3/kB3P/YV1L/0tmoA0NT0lNS8qVLmezvIciG7ttvmRhsbl+ZWVlbAyrAjIU43KpFODX1tLiLT tdaO0vncRxTFWS3u2JwvlueA7c/uixcENjcoDtuVHPBDdW8tvcRRzQSoUkjkUMrqRggg8EEcYoAk orn/APhBPB//AEKmh/8Aguh/+Jo/4QTwf/0Kmh/+C6H/AOJoA6Ciuf8A+EE8H/8AQqaH/wCC6H/4 mvN/DI8J638ZvE/h+PwtoctjaWiLC4sEUI8LbZQUK8sXmILDHES9etAHtFFc/wD8IJ4P/wChU0P/ AMF0P/xNH/CCeD/+hU0P/wAF0P8A8TQBuTzw2tvLcXEscMESF5JJGCqigZJJPAAHOaw/7VvNe/d6 EPKsW+WTVJVK8HnNujLibI6SH938ykebhlqSDwX4VtbiK4t/DWjQzxOHjkjsIlZGByCCFyCDzmty gCvY2Nvp1nHa2sflwpkgFixJJJZmY5LMSSSxJJJJJJNWKKKAOf8AAn/JPPDX/YKtf/RS10Fc/wCB P+SeeGv+wVa/+ilroKAMOfwX4VuriW4uPDWjTTyuXkkksImZ2JySSVySTzmo/wDhBPB//QqaH/4L of8A4mugooA5/wD4QTwf/wBCpof/AILof/iaP+EE8H/9Cpof/guh/wDia6CigDn/APhBPB//AEKm h/8Aguh/+Jo/4QTwf/0Kmh/+C6H/AOJroKKAODuvBfhVfHWk26+GtGED6Zeu8YsItrMstqFJG3BI DMAe24+tbn/CCeD/APoVND/8F0P/AMTXhHxG8CpqPx+sdKth+51zybqZIFWIxJlhMwJ4LYieTOOS 3Qnr9L0Ac/8A8IJ4P/6FTQ//AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTXQUUAc/8A8IJ4P/6FTQ// AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTXQUUAc/8A8IJ4P/6FTQ//AAXQ/wDxNH/CCeD/APoVND/8 F0P/AMTXQUUAc/8A8IJ4P/6FTQ//AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTXQUUAc/8A8IJ4P/6F TQ//AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTXQUUAc/8A8IJ4P/6FTQ//AAXQ/wDxNH/CCeD/APoV ND/8F0P/AMTXQUUAc/8A8IJ4P/6FTQ//AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTXQUUAc/8A8IJ4 P/6FTQ//AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTXQUUAc/8A8IJ4P/6FTQ//AAXQ/wDxNSQeC/Ct rcRXFv4a0aGeJw8ckdhErIwOQQQuQQec1uUUAeP+Hv8Ak6HxZ/2Co/8A0G1r2CvH/D3/ACdD4s/7 BUf/AKDa17BQAUUUUAFFFFABRRRQAUUUUAFeP/CD/kofxO/7Co/9G3FewV4/8IP+Sh/E7/sKj/0b cUAewVz/AIN/5Adz/wBhXUv/AEtmroKw5/BfhW6uJbi48NaNNPK5eSSSwiZnYnJJJXJJPOaANyiu f/4QTwf/ANCpof8A4Lof/iaP+EE8H/8AQqaH/wCC6H/4mgDoKK5//hBPB/8A0Kmh/wDguh/+Jo/4 QTwf/wBCpof/AILof/iaAOgryfwt8LdH0H4q3Woxahqt1dWVpFeLJdzI5lkuDcxyFzsBPCAjock5 JruP+EE8H/8AQqaH/wCC6H/4msO18F+FW8datbt4a0YwJplk6Rmwi2qzS3QYgbcAkKoJ77R6UAd5 RXP/APCCeD/+hU0P/wAF0P8A8TR/wgng/wD6FTQ//BdD/wDE0AdBRXP/APCCeD/+hU0P/wAF0P8A 8TR/wgng/wD6FTQ//BdD/wDE0AdBRXP/APCCeD/+hU0P/wAF0P8A8TR/wgng/wD6FTQ//BdD/wDE 0AHgT/knnhr/ALBVr/6KWugqOCCG1t4re3ijhgiQJHHGoVUUDAAA4AA4xUlABRRWPrd9cCW20nTp PL1G9yyyFQRDAjIJpecjcA4CjDZd1ypUMQAF9r6R3kmnaZB/aWpx4823hlVRbAgFWnYn92pyOMM5 GSqNtOK/2bxhJ8/9q6Hb7ufJ/syaby/9nzPPTfjpu2rnrtHSqfiLUF8I6bo9tYXmm6Xb3F6beS61 INJHGDFNKWYmRCzs6DLM2SXJOSajsfGmywje5T+1Gm1A2Fnc6TDmK9byDMGQF2CqCHiJ3lQyEsVG 7aAaH2Pxh/0HdD/8E03/AMlUfY/GH/Qd0P8A8E03/wAlVJb+KLa51RLQWl2kE1xLaQXrBPKmnj3+ ZGoDFwR5UvLKFOw4Jyu6ODxdZz6O+pizvlt28k2paID7YszBYTGd20b2IGHKsuQXCAg0AZ9z4a8S XeuWGrzazob3VhFNFb50WQhPN2bmGbnIbCYBBHDMOc1ofY/GH/Qd0P8A8E03/wAlUf8ACWQfZc/2 dff2h9r+xf2b+687zvK87bu3+V/qv3md+McZ3fLQ/itBKsUej6rLMkQmu4khXfaIWdQWUsC/McmP KEm7ZlchkLAB9j8Yf9B3Q/8AwTTf/JVH2Pxh/wBB3Q//AATTf/JVSa7rV3pereH7S3sJLiPUb1re aRSn7pRDI+eXU5ym7oflRx94qDl6B48t77w9aahq1vPYs+lf2k8rQkRyoiIZ2jXJfajOo+YDcCCm 8c0AaH9v3GkfL4lggs4BwNUilH2Rj0G/cQ0LNgnB3IMqvmMzAHoKy9K1oalcXFpNYXen3luiSPbX RjLeW5YI4MbuuCUcYzn5TkAEE07H/iQ65Ho4+XS7qIvp6npDImTJAD2UqVeNBkgJMBhEVQAdBRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB4/4e/5Oh8Wf9gqP/0G1r2CvH/D3/J0Piz/ALBUf/oN rXsFABRRRQAUUUUAFFFFABRRRQAV4/8ACD/kofxO/wCwqP8A0bcV7BXj/wAIP+Sh/E7/ALCo/wDR txQB7BRRRQBz+s3usf8ACQ6bpOk3NjbfaLS5uZJbu1ef/VvCoUBZExnzicknoKPsfjD/AKDuh/8A gmm/+SqLz/koejf9gq//APRtpXQUAc/9j8Yf9B3Q/wDwTTf/ACVR9j8Yf9B3Q/8AwTTf/JVdBRQB z/2Pxh/0HdD/APBNN/8AJVU49B8VRazc6ouv6N59xbw27qdHl2hY2kZSP9JznMrZ57Dp36yigDn/ ALH4w/6Duh/+Cab/AOSqPsfjD/oO6H/4Jpv/AJKroKKAOf8AsfjD/oO6H/4Jpv8A5Ko+x+MP+g7o f/gmm/8AkqugooAx/DGoXmp6KZ78wNdR3d1bO0EZjRvKnkiDBSzEZCA4yetbFc14QurePRrpJJ4l YarqOQzgEf6bNXQR3MEzbYpo3YDOFYE0AS0UUUAFc/pf+k+NPEF4nEcMVpp7A9TIgknJH+ztuowD 1yG4wAT0Fc/4e/5Dniz/ALCsf/pFa0AaGo6Z9vvtJufO8v8As+7a527c+ZmGWLbnPH+tznn7uO+Q ajpn2++0m587y/7Pu2udu3PmZhli25zx/rc55+7jvkeZzajrMGk69d3epSS382ma6wngknhWL7LM kMflxeayIRkncAG+7yTuZ+ouvFuoJ4suNPtbWSWC1vbezkgTTbiUyCRYmaX7Sv7qIIJslGBJEZ5G 8YANC18LzW+qW8jX8b6faXtxqFtALciUTTebv3ybyGT9/LgBFI+TLHB3Vx4LaTwm3h671CO5s4Ut 4rOOS1UoiQMrRiVScyliqh+VDAYVUJJMmuTawfGWj2mk3MEPm6fevIbkO8a7ZLbDeWpXew3FRllw HY5ONrY+q+Prq38PWWuW6QRxvpUeqS2S2k93IwZC+xnjAW3X5SBK4YMdx2gRnIBqR+DBD4am0qL+ xk8648+WBdHjFk/AG1oN2SPlVsmTdvAOdo2VXuvAbXNhY2ZvrQpbo6iSXT1aS1LOWLWb7gbcrkKm TIEEcWB8pLXL3XdTtfFC2kggtrEyxxxie0mZbhXCjeLpf3cTbmKLE6lmZAMjzFIw9M+IOoT6Ndax Np8k1oNHl1VVGn3FqsBRVZYDNICkxYOcOgA/dk7SGGADsNX0qbUbrSLiC5jgfT737UQ8RkEimKSJ k4ZdpKykhucEDg9Kx18Dwvo2naXcX0jwWuhTaLI0cYVpFkWFTIMkhSBD0wfve3MmhzawPGWsWmrX ME3lafZPGbYOkbbpLnLeWxbYx2hThmyEU5Gdqx2fiLUptUs5JRaf2ffandabFAsTCWJoPP8A3jSb iHDfZ2+UIuPMHzHb8wBc8MeGU8PfanEelRyXGwMumaatnHhc4JAZmZvmPJbGAMAHcWPGP+jaH/bC 8SaNKuobhyRGmROFHQs0DTIAeMsDkEBhl+GvEWvaqmiG/GmxPq+mDUUEETkQqjQb1JLfMXWbI6eW Rg+b1Op47/5J54l/7BV1/wCimoA6CiiigAooooAKKKKACiiigAooooAKKKKACiiigDx/w9/ydD4s /wCwVH/6Da17BXj/AIe/5Oh8Wf8AYKj/APQbWvYKACiiigAooooAKKKKACiiigArx/4Qf8lD+J3/ AGFR/wCjbivYK8f+EH/JQ/id/wBhUf8Ao24oA9gooooA5+8/5KHo3/YKv/8A0baV0Fc/ef8AJQ9G /wCwVf8A/o20roKAOHv9T1a0k8W60uqztb6FKTHppii8mWNLSGZlLbPMDEu+G34B2nawBU6l14om t9UuI1sI30+0vbfT7mc3BEomm8rZsj2EMn7+LJLqR8+FOBuj1W18I6PrA1TWNQgsri7lE4S81N4o ZpI1RQ/ks4jZlCx87cgqp6gGrDWnhq+1i3vRcwS3Vx5U8ccd63l3B2s0UpiDbJG2xEq5UnEQIPyD ABT0/wAXX15LoMsmjRx6frj5tLhLzeyIYJJl81Cg2uVQDapcfey3C78+f4g3xubmCx0COYwXEcDS TX3loC99NZrnCM2S0QfhSMFsnKqH3P8AhCtB6i1nVl4gZbyYNajutuQ+YFI+UrHtBUBSMACjTvC3 hqK2ddNs4Ft/NQFYJW2K8Fy8yqADhdkzSHaMY+6RgYABl33jyW3tbAW2kST39y90jwjzpEjNtKIZ cNDDI5G8jaSigjk7ThSDxrqUoubmHQY47OG4trTF3dtFcCa4jhaNXiETBQGuEVjvJADEBiAp2Lvw /oZS3t5fMtne4maBoL2W3laSVmmlVXR1chiGcoDj5AcfKMWE8OaRFbyW8VjHFBJcQXJjjJVRJCIx EQAcKFEMQ2jA+XpycgFfwbf32q+CtE1DUzGby5soppWRshyyg7vuqASCCQBgEkAkDJ3Kp6Vpdpou l2+m2CSJaWybIkeV5Cq9huck4HQDPAwBwBVygDzPRv8AU3//AGFdQ/8ASuWun8Pf8f8AJ/1yP8xX MaN/qb//ALCuof8ApXLXT+Hv+P8Ak/65H+YpjOlooopCCuf8Pf8AIc8Wf9hWP/0ita6Cuf8AD3/I c8Wf9hWP/wBIrWgCxL4W0aeCWGSz3RyxXcLjzXGUuXEk46/xMAfbtgVJN4e0y41QajJBIZ96yMgn kEUjrja7xBtjuNq4ZlJGxMH5VxqUUAZeq+HtM1q4t7m9gka4tkdIJ4p5IpIQ5UtsdGBUnYASDnGR 0Yg19S8H6Bq1uttd6bGbcW4tfIjdoo2iAIVGRCAwTJKZB2E5Xaea5fVvEusaKNV1KW7kdI0vRaIY 4JbCV4Y5XSNSjCdZQIjvL/LuSVRjKED6x4mtLO/tzPd2863Gmrby6stpLOPPuvKk3R2zBfK2gAZ2 sSZMNwNoB2E3h7TLjVBqMkEhn3rIyCeQRSOuNrvEG2O42rhmUkbEwflXEdr4W0az88R2e+OaJoDD PK80aRN96KNHJWOM4AKIApCqMYUY5/8AtPVvtf8AYP8Aas+7+2/7P/tDyovtHl/YftecbPL3bvkz sxs7bvmrHsdQ1uC0sNJtTfSTT3es3FxLpEdskhaK+28C5YosZMrEjJbO3BwGyAd5pXh/T9GuLi4t PtbT3CIksl1ezXLFULFQDK7EAF3OBjqaIfD2mW+qHUY4JBPvaRUM8hijds7nSItsRzubLKoJ3vk/ M2cPwRqms63JfXup3sBjj+zxpa2qIY1d7S3lciQFt67nbbg9GbJcFdvYUAZcPh7TLdNOSGCSIadb i1tdk8imOING2zIbLAmGPOc5AIOQSDT8d/8AJPPEv/YKuv8A0U1dBXP+O/8AknniX/sFXX/opqAO gooooAKKKKACiiigAooooAKKKKACiiigAooooA8f8Pf8nQ+LP+wVH/6Da17BXj/h7/k6HxZ/2Co/ /QbWvYKACiiigAooooAKKKKACiiigArx/wCEH/JQ/id/2FR/6NuK9grx/wCEH/JQ/id/2FR/6NuK APYKKKKAOfvP+Sh6N/2Cr/8A9G2ldBXP3n/JQ9G/7BV//wCjbSugoA5fXNLvdQ8ZaPJa319YRxaf eh7q0jjbBaS2whMiOoztY9ATsODgGqeqQalN8StLcRXb6fC9u4YKxiRvI1FXPoD80IJ90B6iu0oo A8/8BQ6+mol9Xvr6WY2n+nwzWc8caXOV+7JLKyNg+aB9nVYyOTgeWKz9NsTp1streR+I49ITUNUN wIGvmmMxuQbdg0eZWjMRkO5SYyxyxLkV2k/i/Q7W4lhmu5EKOYw5t5fLllBwYo327ZZcgjy0LPlW GMqQI38aaInkrvvnml8zFvFpty8ybNm7fEsZdOJIz8wGQ6kZBFAGHrcGrzeHvBr6pFqT3sNxG+qt pygyp/ocyyn5Og3MQTH83OI/nK1h3kPiuV7f/TtVtYRE/wDZe2zubiRm+0TeX5myVFDeT9l/4+8q STuwRLnvPD/ie08RXWrRWaSGKwuEiSfY+ydWiSQOjFQCPmOME5AVs4dc7lABRRRQB5no3+pv/wDs K6h/6Vy10/h7/j/k/wCuR/mK5jRv9Tf/APYV1D/0rlrp/D3/AB/yf9cj/MUxnS0UUUhBXP8Ah7/k OeLP+wrH/wCkVrXQVz/h7/kOeLP+wrH/AOkVrQB0FFFed6xoNzKPF97b2kn2ubU7UK8kLyq9osdm ZwsQI8xGVJA6JzJs2HJCgAHcR6TpsOqTapFp9omoTJslu1hUSuvHDPjJHyrwT2HpUdnoWj6fZmzs tKsba1MqzmGG3REMikFX2gY3AqpB6jaPSuDttKMWh2xu7KS50P8AtgzXFlFo0kEIt/srIFSyJeQp 9o2OQVzvJk27QHMfivR7+81GMLbzxRvpUEOnmfTZNSuba5Bl3mOZZQtvMN0OZXfDFVO/CEgA9Al0 /S9Siv7S506CeGWVTdRz2uUncKhDHcMSYAQbucbcZyuBHJ4a0GbS4dLl0TTX0+F98Vo1qhiRueVT GAfmbkDufWuHvvD2pT+LtfMFtItnrl7HY3xZGxLbrb2zZzj5U8tb2LcpB8yVBnIBSTUdJv5viBPM 6bZG1C1ls510mSaZbZVh8xUu96xwxkrOGjPJDPgMZFBAO4v9Gs7+BomTyt93BeSPCArSSQvG6ljj n/VIp77RjI4wf23p39sf2V9o/wBL6bdjbN23f5e/G3zNnz7M7tvzY281l+DtKXT7PULh7aSK7utT vXkaXduZPtUxjxu6JtbcAMD5yw5Yk82v2+x8UXGoNp99cXTahLNdQ/YZHhtYQFiS4gb5Vkka3jjV lVnkBlYooxJE4B6RXP8Ajv8A5J54l/7BV1/6Kaugrn/Hf/JPPEv/AGCrr/0U1AHQUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAeP+Hv8Ak6HxZ/2Co/8A0G1r2CvH/D3/ACdD4s/7BUf/AKDa17BQ AUUUUAFFFFABRRRQAUUUUAFeP/CD/kofxO/7Co/9G3FewV4/8IP+Sh/E7/sKj/0bcUAewUUUUAc/ ef8AJQ9G/wCwVf8A/o20roK5+8/5KHo3/YKv/wD0baV0FABRRRQBxer+A21i9vZJ760EFw6yMn9n rvuGR1eNLk7ts0SlAANivtG3zBly9zQfB6aLqNteo9jG0cVzG8Fhp62sJMpg5VQSRgW4zuLEljyA Ao6iigDm/B/hebwraT2jX8d3A6WwTFuY2VoreKBiTvIIYQqwGBjJGW7dJRRQAUUUUAeZ6N/qb/8A 7Cuof+lctdP4e/4/5P8Arkf5iuY0b/U3/wD2FdQ/9K5a6fw9/wAf8n/XI/zFMZ0tFFFIQVz+h/uP Evie2k+WaW7hvUXrmF7eOJWz7vBKMdflzjBBPQVz9x/xK/GX9oT8WmpWkNkZjwsM0cjmNT/1089g CcANGq5LSKKAOgrl7jx/oVt4c1rXJZJxa6Ndy2V0giJcTI4Tao6HcWTBzj5hkjBx1FeT6r4D1m7g 1N44MyXEWpuib05cvfCBM7v+Wi35bP8AD5WDy3ygHcar4x0vRdO1e/vvPjtdKu4rW6cJuwZBEQwA OSoE6578NgHjNw6/YjxUnhwNIdQaya+KhflWIOEBJ9SxOAM/dOccZw7zRNRl/tvZb5+0+INPvYvn X5oYvse9uvGPJk4PJ28A5Gc/wb4R1HQNYspbhd0MVpc2zvlRjYtlBE2Ax/1iWhlx/Du2nkZIB0Gh +J5teisrmLw7qtvY3kSzR3c722zYy7lJCzM/Ix/D35xzVgeKNH/4SG70Nr6BL61ihlkR5UH+tcoq gZzuzs4x/wAtY+u4Vy/gbR7jSrXRbW80LxHbXVtaJFNPPrAltFdYtrYiFyw2k5CgR8ZHAxxoa5pU t1q3iFrk/Y7C60SBI9Vdk2Wk0Mk7byCwYMnmJIG4A2Z3AgUAdJPq2m2olNxqFpCInKSGSZV2MI/N IOTwRH8+P7vPTmo5dd0eH7D5uq2Mf9oY+xbrhB9pzjHl8/PncvTP3h61w9xbXC6X4QvZ9K+1X97r b6nNZ3GEkV3trmRYyXHMkS7EQtt5iQZQfdpz+D9dcagpTUkg1q3mhlgsprVRGJLm6l23DSqxUBbl QTDvIIkwGwmQD1Suf8c/P4G1q2Xma8tHsoF/vzTDyo1z2y7qMngZySBk10Fc/rH/ABMPEei6ZH86 28p1C7Q8oI1R0jDD+8ZWR0BGD5DkHKCgDoKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPH/D3 /J0Piz/sFR/+g2tewV4/4e/5Oh8Wf9gqP/0G1r2CgAooooAKKKKACiiigAooooAK8f8AhB/yUP4n f9hUf+jbivYK8f8AhB/yUP4nf9hUf+jbigD2CiiigDn9ZstY/wCEh03VtJtrG5+z2lzbSRXd08H+ seFgwKxvnHkkYIHUUfbPGH/QC0P/AMHM3/yLXQUUAcT/AMJb4l/6F7Sf/BvJ/wDI1H/CW+Jf+he0 n/wbyf8AyNUVFMZL/wAJb4l/6F7Sf/BvJ/8AI1H/AAlviX/oXtJ/8G8n/wAjVFRQBL/wlviX/oXt J/8ABvJ/8jUf8Jb4l/6F7Sf/AAbyf/I1RUUAS/8ACW+Jf+he0n/wbyf/ACNR/wAJb4l/6F7Sf/Bv J/8AI1RUUAUNIt7m3s5ftixJPNd3NyyQyF1XzZnkChiqk4DgZwOldL4e/wCP+T/rkf5ismtbw9/x /wAn/XI/zFAHS0UUUhBUc8EN1by29xFHNBKhSSORQyupGCCDwQRxipKKAObgvNS8OW8VpqNpd6hY QII49Stt1xOVAwDPEBvLn5RujEm47mIjHAk/4TrwmvEviTSoJBw0NxdpFJGe6ujkMjDoVYAg8EA1 0FFAHP8A/Cd+D/8Aoa9D/wDBjD/8VR/wnfg//oa9D/8ABjD/APFV0FFAHP8A/Cd+D/8Aoa9D/wDB jD/8VR/wnfg//oa9D/8ABjD/APFV0FFAHP8A/Cd+D/8Aoa9D/wDBjD/8VR/wnfg//oa9D/8ABjD/ APFV0FFAHP8A/CSvqHyeH9Nn1BjyLmcNbWgHUMJWUmRWAO1olkB4yVDBq0NH0z+y7N0km+0XU8r3 FzOV2mSRjk8ZJCgYRQSSqIq5OM1oUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHj/h7/k6 HxZ/2Co//QbWvYKjEEK3D3CxRid0VHkCjcyqSVBPUgFmIHbcfWpKACiiigAooooAKKKKACiiigAr x/4Qf8lD+J3/AGFR/wCjbivYKjjghheZ4oo0eZ98rKoBdtoXLep2qoyewA7UASUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFAH//Z ------=_NextPart_000_001F_01C05951.3EC513E0-- From owner-ietf-ediint@mail.imc.org Tue Nov 28 18:11:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05617 for ; Tue, 28 Nov 2000 18:11:05 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA13936 for ietf-ediint-bks; Tue, 28 Nov 2000 14:14:51 -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 OAA13932 for ; Tue, 28 Nov 2000 14:14:48 -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 RAA20565; Tue, 28 Nov 2000 17:16:15 -0500 (EST) Received: from don ([206.191.40.98]) by mail6.magma.ca (8.9.3/8.9.3) with SMTP id RAA00436; Tue, 28 Nov 2000 17:16:13 -0500 (EST) From: "Don Gribble" To: , , Subject: RE: AS2 = Email & HTTP Date: Tue, 28 Nov 2000 17:15:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0012_01C0595F.1F358420" 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_0012_01C0595F.1F358420 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0013_01C0595F.1F358420" ------=_NextPart_001_0013_01C0595F.1F358420 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id OAA13936 Content-Transfer-Encoding: quoted-printable Please unsubscribe me! -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Dick Brooks Sent: November 28, 2000 4:38 PM To: stacyt@iplanet.com; ietf-ediint@imc.org Subject: RE: AS2 =3D Email & HTTP Stacy, regarding: =A0 >Question: >Could AS2 be restated as: Email messages sent/received using HTTP protoc= ol? >AS2=A0 =3D=A0 Email + Security + Web server + Web browser >Example, To Send:=A0 >1. Use all the normal email standards to create the email message file,=A0 >2. then use the an HTTP "POST" to send the file.=A0 >3. Then once received, use all the normal email standards to "decode" th= e email message file.=A0 >4. To know what kind of file you have received, check the MIME type (e.g. EDIX12-850 means you have=A0received an X12-850 purchase order document),= then process appropriately. No, this doesn't work. The HTTP standard defines headers that "collide" w= ith e-mail headers (e.g. From). The next version of the AS2 spec will contain two new headers, AS2-To and AS2-From which will replace the To and From headers used in e-mail. There are also some encoding differences between SMTP and HTTP. =A0 =A0 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 Stacy Thurston Sent: Tuesday, November 28, 2000 12:28 PM To: ietf-ediint@imc.org Subject: AS2 =3D Email & HTTP Hi all, ---------------------------------------------------- Question: Could AS2 be restated as: Email messages sent/received using HTTP protoco= l? AS2=A0 =3D=A0 Email + Security + Web server + Web browser Example, To Send: 1. Use all the normal email standards to create the email message file, 2. then use the an HTTP "POST" to send the file. 3. Then once recieved, use all the normal email standards to "decode" the email message file. 4. To know what kind of file you have received, check the MIME type (e.g. EDIX12-850 means you have received an X12-850 purchase order document), t= hen process appropriately. ** If this is the case, GREAT! This allows us to use all our current programs (technologies) to securely and confidentially: send, receive and process documents through firewalls that have an HTTP opening. Use: 1. Our email (SMTP) client to create "email file messages" 2. Our batch oreinted "Browser" client to send the "email file messages" using HTTP POST. 3. Our web server (HTTP) to receive documents 4. * Here we need to write a plugin or cgi to pass the file to the email client. 5. Our email (POP) client would decode the "email file messages" as it wo= uld any email message. 6. We already have the programs to process the files based on sender, receiver and MIME type. 7. Our email client can create an "MDN file message". 8. * Here we need to write a program to pass the "MDN file message" to th= e batch oreinted "Browser" client that would send the "MDN file message" us= ing HTTP POST. 9. Repeat steps 3, 4, 5 and 6 *** And all of our current security programs remain the same (e.g. SMIME, digital signatures and encryption). File - Email client - Batch web browser - Internet - Web server - Email client - File This will be easy for us to create an AS2 peer to peer system :) Thanks for the conversations, Stacy Thurston, iPlanet (SUN|Netscape) Product Manager http://www.iplanet.com/products/ecommerce/ecxpert/ecxpert.html ---------------------------------------------------- Background: I work with a product dedicated to sending & receiving documents.=A0 We a= dd communication "agents" (programs/connectors) to do the sending and receiving. Example: * "Browser" client to send documents * HTTP server to receive documents * POP client to get documents * FTP client to get and put documents We have found that: 1. Email messaging standards are adequate to send/receive/process documen= ts: * SMTP/POP, multipart, SMIME, digital signatures & RSA encryption * Note, mulitpart is rich enough to allow us to tell what kind of file is being sent to us, i.e. MIME type is the document type. 2. And the HTTP protocol is adequate for file transport. ---------------------------------------------------- eom ------=_NextPart_001_0013_01C0595F.1F358420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Please=20 unsubscribe me!
-----Original Message-----
From:=20 owner-ietf-ediint@mail.imc.org = [mailto:owner-ietf-ediint@mail.imc.org]On=20 Behalf Of Dick Brooks
Sent: November 28, 2000 4:38=20 PM
To: stacyt@iplanet.com; = ietf-ediint@imc.org
Subject:=20 RE: AS2 =3D Email & HTTP

Stacy, regarding:
 
>Question:

>Could AS2 be=20 restated as: Email messages sent/received using HTTP protocol?

>AS2 =20 =3D  Email + Security + Web server + Web browser

>Example, To=20 Send: 
>1. Use all = the normal=20 email standards to create the email message file, 
>2. then use the an HTTP "POST" = to send the=20 file. 
>3. Then = once=20 received, use all the normal email standards to "decode" the email = message=20 file. 
>4. To know = what kind=20 of file you have received, check the MIME type (e.g. EDIX12-850 means = you=20 have received an X12-850 purchase = order=20 document), then process appropriately.

No,=20 this doesn't work. The HTTP standard defines headers that "collide" = with=20 e-mail headers (e.g. From). The next version of the AS2 spec will = contain two=20 new headers, AS2-To and AS2-From which will replace the To and From = headers=20 used in e-mail. There are also some encoding differences between SMTP = and=20 HTTP.
 
 

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 - = Empowering=20 e-commerce solutions

-----Original Message-----
From:=20 owner-ietf-ediint@mail.imc.org = [mailto:owner-ietf-ediint@mail.imc.org]On=20 Behalf Of Stacy Thurston
Sent: Tuesday, November 28, = 2000=20 12:28 PM
To: ietf-ediint@imc.org
Subject: AS2 = =3D Email=20 & HTTP

Hi all,=20

---------------------------------------------------- =
Question:=20

Could AS2 be restated as: Email messages sent/received using HTTP = protocol?=20

AS2  =3D  Email + Security + Web server + Web browser=20

Example, To Send:
1. Use all the normal email standards to = create the=20 email message file,
2. then use the an HTTP "POST" to send the = file.=20
3. Then once recieved, use all the normal email standards to = "decode"=20 the email message file.
4. To know what kind of file you have = received,=20 check the MIME type (e.g. EDIX12-850 means you have received an = X12-850=20 purchase order document), then process appropriately.=20

** If this is the case, GREAT!
This allows us to use all our = current=20 programs (technologies) to securely and confidentially: send, = receive and=20 process documents through firewalls that have an HTTP opening.=20

Use:
1. Our email (SMTP) client to create "email file = messages"=20
2. Our batch oreinted "Browser" client to send the "email file = messages"=20 using HTTP POST.
3. Our web server (HTTP) to receive documents =
4. *=20 Here we need to write a plugin or cgi to pass the file to the email = client.=20
5. Our email (POP) client would decode the "email file messages" = as it=20 would any email message.
6. We already have the programs to = process the=20 files based on sender, receiver and MIME type.
7. Our email = client can=20 create an "MDN file message".
8. * Here we need to write a = program to=20 pass the "MDN file message" to the batch oreinted "Browser" client = that=20 would send the "MDN file message" using HTTP POST.
9. Repeat = steps 3, 4,=20 5 and 6=20

*** And all of our current security programs remain the same = (e.g. SMIME,=20 digital signatures and encryption).=20

File - Email client - Batch web browser - Internet - Web server - = Email=20 client - File=20

This will be easy for us to create an AS2 peer to peer system :)=20

Thanks for the conversations,
Stacy Thurston, iPlanet = (SUN|Netscape)=20 Product Manager
h= ttp://www.iplanet.com/products/ecommerce/ecxpert/ecxpert.html=20

=20

---------------------------------------------------- =
Background:=20

I work with a product dedicated to sending & receiving=20 documents.  We add communication "agents" (programs/connectors) = to do=20 the sending and receiving.=20

Example:
* "Browser" client to send documents
* HTTP = server to=20 receive documents
* POP client to get documents
* FTP client = to get=20 and put documents=20

We have found that:
1. Email messaging standards are adequate = to=20 send/receive/process documents:
* SMTP/POP, multipart, SMIME, = digital=20 signatures & RSA encryption
* Note, mulitpart is rich enough = to=20 allow us to tell what kind of file is being sent to us, i.e. MIME = type is=20 the document type.
2. And the HTTP protocol is adequate for file = transport.=20

----------------------------------------------------
eom=20

------=_NextPart_001_0013_01C0595F.1F358420-- ------=_NextPart_000_0012_01C0595F.1F358420 Content-Type: image/jpeg; name="CTEMPnsmailUM.jpeg" Content-ID: <884091722@28112000-183d> /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAHNAakDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiuT8V+INQ0rWdLs LKWOFLq3uJpJDpVxftmNoQAEhZSoPmnLHI4A71Je+K/7G1iLSryKe9u5IrdUSxtMb5pFuWyMyHCn 7MwweEyCzlSSgB1FFce3xI0T+2LzS4Vnubq389Ujt2ikknlhVmeJIg/mhvkcAsiqSvDHcu6TVPiN 4c0m3v7ia5klgs7cT+ZAnmLNkRHbGQcE4uLc5OFPnLgnD7QDrKK8/ufiQl3p15eaMsDrbaVqN1Ik rLLsntxAyLvidkZSs2TtY9QMghhXoFABRRRQAUUUUAFFFef+HfF+rajoNprF9dQeXcfYlaFNDuIN r3EsaALJLLtlUbmG5M4yG5GFYA9Aori774maNYFlmtrtD9ont0MzwW6ytDIY5SjzSIrBTs6HneMZ KyBLkvj/AEKKwa9aSfyP3bxnyiDLC8Bn85VPPliNZTkgEmGRQCwAIB1FFcnN8QtGt/Eo0WYSI7XC 2yXBmg2SSMQoCJ5nmuBITGWVCFZXBI2MRJ4F8SXnifR5Ly9jgjkX7PgQqQP3lpBO3Un+KZgPYDvy QDqKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKAKcmmwy6zbaozSefb281uigjaVkaNmJ4znMS457nr2p3Hhuzu fEcGuPJOLqHy9qBhsOxLhBkYz0upM89l9DnYooAx7Pw+ljqLXEOoXwtTLJOlhvUQpLIWZ2yFDtln c7WZlBbIA2rtz5vAWjyWdtbxGe2a2u2u4poCiurE5RD8uDHGVh2oQV/0eEEEJiuP0C/vJP2lfFVm 93O1qmlRbYTISi4EBGF6cGSQj/fb1NesUAcn/wAK/wBNYakZr7UppNRt7mC4llmVmPnxwJIw+XAO LdCABtXJAAXaq9ZRRQAUUUUAFFFFABWOnhuzj8OadoYkn+y6f9l8pyw3t9ndHTccY5Ma5wB1OMVs UUAc+3hOBFiay1G+sbqKW6kW5h8pn23EvnSpiRGXaX24+XcNgGeTmxN4Y0u4vLa4uIPtHkWjWmy4 /fCVCMAyF8s7BTIoJJ4mlznea2K8n+FF/eXfj74lRXN3PNHFqo8tJJCwT55k4B6fKiL9EUdAKAOs h+H+m26QxRX2pLClxBeSxiZQLm6iZD58p25d28tdwJ2k5baH+atTw54bs/DFg9nZSTyRt5WTMwJ/ dwRwL0A/hhUn3J7cDYooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAOT0258VazFc3dvqejW 0C3t1bxxSaXLKwWKeSIEsLhQSQmeg61c+x+MP+g7of8A4Jpv/kqs/StT/sTwFrmreT532G71e58r dt37Lq4bbnBxnGM4Nc38PfFvijVtD8RWlxNHq2tWVlbXtnLJGkKyNc2olSEqu0YVhjdnnd/DigDt PsfjD/oO6H/4Jpv/AJKo+x+MP+g7of8A4Jpv/kquH8EeML3WdTt9LuvE99a+IUtHW70jXNKjQtL5 aMJIvLEZ2gknazFmTPC43VueFNR1yTxrqGlPrEmu6TZWSR3d/JbxRCLUA3zRJ5aqCNhyy/OVOAWB 4IBufY/GH/Qd0P8A8E03/wAlUfY/GH/Qd0P/AME03/yVXn99421bTvFuoad4j12+8NyPqBGlSy6d FLps9urRhQz48wswYliJFC7uSpG2tj/hbln/AMJR/ZX2ODyf7b/sX/j9H2vzMY83yNv+p3/Lu357 4zxQB1H2Pxh/0HdD/wDBNN/8lUfY/GH/AEHdD/8ABNN/8lVy+h/FC81Kz8N6nfaDBZaRrt29lFcp fmV4ZgXVFaPyh99kIBBIHUkd8uT44QsbhoNJtEgW3ub21nvNTEC3tvHIY0MQ8st5rssmI2AI29Tn gA7z7H4w/wCg7of/AIJpv/kqj7H4w/6Duh/+Cab/AOSqy/DHjubxZ4ivLKw0qOPT7S3tLh7me6Il K3EHmoBEEIyOh+f3Gelcf4o8banpviLx3FJ4h1Kwg0i3t206O10+OWLzZIMhZXML7Q0m0Dcy/eIB 44APRPsfjD/oO6H/AOCab/5Ko+x+MP8AoO6H/wCCab/5Krl9e+J1x4Y+x2GpadYpq40T+1L1Li/F tHvHBhhO2TfIWD4X0A5Pa5YfES716/uYvD3h2S+gtLeyuLgS3aQTlblPMAjQgoxVDk7pE5yB2JAN z7H4w/6Duh/+Cab/AOSqPsfjD/oO6H/4Jpv/AJKrg/EvxrttKGrxpZxhLS9m0xfLv0F75qxn96IW jZRFvG3eSfUqfu1oQ/FaHT9GupdWspIpLfQrXVrVpJw7XyyqFOfLjCxkTMsecDO7cFCigDrPsfjD /oO6H/4Jpv8A5Ko+x+MP+g7of/gmm/8AkquPsPjClxrFtYXmkwWkkmqppE1t/aKyXcU5UBn8oLho RJlN4fnGcZ+WvUKAOf8AsfjD/oO6H/4Jpv8A5Ko+x+MP+g7of/gmm/8AkqugooA5/wCx+MP+g7of /gmm/wDkqj7H4w/6Duh/+Cab/wCSq6CigDn/ALH4w/6Duh/+Cab/AOSqPsfjD/oO6H/4Jpv/AJKr oKKAOf8AsfjD/oO6H/4Jpv8A5Ko+x+MP+g7of/gmm/8AkqugooA5/wCx+MP+g7of/gmm/wDkqqep XPirRora7uNT0a5ga9tbeSKPS5YmKyzxxEhjcMAQHz0PSusrn/GX/IDtv+wrpv8A6Ww0Aef+Hv8A k6HxZ/2Co/8A0G1r2CvH/D3/ACdD4s/7BUf/AKDa17BQAUVh+NJ5rXwL4huLeWSGeLTLl45I2Ksj CJiCCOQQec1He65qg8Qz6NpWkQXMkFpDdPPc3nkRgSPKu3hHbd+6yMKQRuyVIAYA6CiuPj8SapqX iHw2+lW0B0jVNKkvnW5n8uQDfb84EbfMqy8KGAYu2SNoJuXHiiaFLrUo7CN9BsnlS6vDcFZV8pis rJFsO5EZWByysdj7Vb5N4B0lFcnqPi6+sz4jmh0aOSz0FJGmnkvNhmItlnCooRjnLhW3YABBBY5V dCw1q+k1mPTtS0yOye5t5Lm12XPmtsjaNWEo2gI/71OFZx975uAWANyiubt/FE0yWupSWEaaDevE lreC4LSt5rBYmeLYNqOzKBhmYb03Kvz7DwbqWtapp13NrEFohS9uoYnguDISEuJU2keWgAUKqg8l gMkKeKAOkrx/4Qf8lD+J3/YVH/o24r2CvH/hB/yUP4nf9hUf+jbigD2CuT0258VazFc3dvqejW0C 3t1bxxSaXLKwWKeSIEsLhQSQmeg611lc/wCDf+QHc/8AYV1L/wBLZqAD7H4w/wCg7of/AIJpv/kq j7H4w/6Duh/+Cab/AOSq6Cs/XdT/ALE8Panq3k+d9htJbnyt23fsQttzg4zjGcGgDP8AsfjD/oO6 H/4Jpv8A5Ko+x+MP+g7of/gmm/8AkquL+Hvi3xRq2h+IrS4mj1bWrKytr2zlkjSFZGubUSpCVXaM Kwxuzzu/hxUfgjxhe6zqdvpd14nvrXxClo63eka5pUaFpfLRhJF5YjO0Ek7WYsyZ4XG6gDuPsfjD /oO6H/4Jpv8A5Ko+x+MP+g7of/gmm/8AkqsPwpqOuSeNdQ0p9Yk13SbKySO7v5LeKIRagG+aJPLV QRsOWX5ypwCwPBj0jUPEXjDUfEFzY65/ZEOlaq2m29oLSOeOTySpkeUsA7bw2AEZNoA5J5oA6D7H 4w/6Duh/+Cab/wCSqPsfjD/oO6H/AOCab/5Krh9S8c6tYfEfU9JkuZ3sU1vSLG3ih8pPLW4hdpNx aNiykqCRkN6MvfQ/4W5Z/wDCUf2V9jg8n+2/7F/4/R9r8zGPN8jb/qd/y7t+e+M8UAdR9j8Yf9B3 Q/8AwTTf/JVH2Pxh/wBB3Q//AATTf/JVcGfjJfT+GrPUoPDkdvJqVlfT2RnvN6b7UFn3BVB2bQcd CWUrhVIkr0Dwbf32q+CtE1DUzGby5soppWRshyyg7vuqASCCQBgEkAkDJAI/sfjD/oO6H/4Jpv8A 5Ko+x+MP+g7of/gmm/8AkqugooAy/DWpTaz4V0jVLhY1nvbKG4kWMEKGdAxAyScZPqa1K5/wJ/yT zw1/2CrX/wBFLXQUAcPbeG7Pxd4A1TQ7+SeO1utVv97wMA426hK4wSCOqjtWha/D/wAP6f4hn1nT rX7BJPp7ae8FiFt4yjPuLjywGEnAG4MMADuM1Y8G/wDIDuf+wrqX/pbNXQUAcefh9BNPaXF94g1y 9uLG0mtbKeaaJZLbzUCNIrpGrNJtHDOW55681oeGPCq+FbOGxtdWvp7CCLyobSaO3VE5zuzHErFu uSSc7iTk810FFAHJ6v4CttcS9tb7WtZk0u9uFuJ9NadHiYhlbarMhlRCUB2q4AycYqS18D2djrE9 7Z6pqtvbz6g2pTWENwEhkuGXDMxC+YVJAYoX2E9scV1FFAHHp8ONHj8CWvhKO5vktbSUT214roLm GQSmQOj7cK2SRkDOCRUa/DTSrVLL+yr/AFLSZ7XTDpf2ixeNXlgLBju3IQH3ZbegVssTnpjtKKAM PR/Ctjoet6rqtrNdvPqaW6TLPL5gUQpsTBPzEkdSzMSeajXwdpf9p+I72Xz5v+EhijhvYXfCbEjM eF2gMMqxzyfbFdBRQBxa/DeyhSya01vWbS7tNMOki8gkiEr2u4FUJMZClccMgVvUk81Yl8AWJ1S6 vrTVdZsTepbJepbXeDciDhN0rAyg7flJR1LDryST1lFAHF3nw1026GqwJq2s2lhqlxNdXVla3Cxx vNLHsdi23eQfvbCxTIGVI4ov/hhoOpJoKTyXezR7eK1CqUxeQxsjLHcZT94m6MHbwMknvXaUUAcv a+B7Ox1ie9s9U1W3t59QbUprCG4CQyXDLhmYhfMKkgMUL7Ce2OK6iiigAorDn8Tw/aJbbTtO1LVZ 4nKyC0gCxjBw2JpSkTFW+UqrlgcjHytiP7d4sk+eLQNKSNuVW41d1kUdg4S3ZQ3qFZhnoSOaAOgo rn/tnjD/AKAWh/8Ag5m/+RaPtnjD/oBaH/4OZv8A5FoA6Ciuf+2eMP8AoBaH/wCDmb/5Fo+2eMP+ gFof/g5m/wDkWgDoKK5/7Z4w/wCgFof/AIOZv/kWj/hINRs+NW8OX0Sp/rLmwZbyEZ6bVXE7dQDi Hg5/hG6gDoK5/wAZf8gO2/7Cum/+lsNamm6rY6vbtPYXMc6I5jkC8NE4AJR1PKOMjKsAR3ArL8Zf 8gO2/wCwrpv/AKWw0Aef+Hv+TofFn/YKj/8AQbWvYK8f8Pf8nQ+LP+wVH/6Da17BQBl+JdNm1nwr q+l27RrPe2U1vG0hIUM6FQTgE4yfQ0QabNF4q1DVGaPyLiytrdFBO4NG87MTxjGJVxz2PTvqUUAc fpnh7WNI/wCER8pLGf8AszSjpt7uuHTG77Pl4/3Z348luDtzkciqdz8PrZ726iXRPD88F5cS3D6n dWySXcJkcu6hGjKyEEkKzMAoKgo+w7+8ooA5fUPDd5d6P4zs45IBJrfmfZizHCbrSKAb+OPmQnjP GO/Fak+mzS+KtP1RWj8i3srm3dSTuLSPAykcYxiJs89x17alFAHB6T8PrbTLixto9E8Px29g8bxa olsjXswjIKhlMeEc4G6QMxOGKqhYFOg8NWGpaZFfWl7FaCA3tzcW0sM7OzrNPJLh1KKEIDgcFs89 O+5RQAV4/wDCD/kofxO/7Co/9G3FewV4/wDCD/kofxO/7Co/9G3FAHsFc/4N/wCQHc/9hXUv/S2a ugrn/Bv/ACA7n/sK6l/6WzUAdBWP4p8N2fi7w5d6HfyTx2t1s3vAwDja6uMEgjqo7VsUUAcva/D/ AMP6f4hn1nTrX7BJPp7ae8FiFt4yjPuLjywGEnAG4MMADuM1XPw+gmntLi+8Qa5e3FjaTWtlPNNE slt5qBGkV0jVmk2jhnLc89ea7CuX+Ith/anw/wBYsf7Yg0jz4gn2y4l8uNfmX5XbIwr/AHD14boe hALHhjwqvhWzhsbXVr6ewgi8qG0mjt1ROc7sxxKxbrkknO4k5PNV7jwPZvqN5c2WqarpkN/Kk97a afcCKOeRTkvnbvRmAAYxshYDnnmvK73xJfeBrPxJEfC2m6D4pg0yOWO40x/9CuYDdCIS+QDgOPMy pcFuucD5Tqah4t8aafqa6aNQ8jf4g060ha/FnPcrFPG5kSeO3baq7kVlxsYgnDegB3F98ONH1DxH NrktzfLdS6hZ6gyI6BBJbIyRgDbnaQxyM5PYirFr4Hs7HWJ72z1TVbe3n1BtSmsIbgJDJcMuGZiF 8wqSAxQvsJ7Y4rz+z8eeIpdetNDn1mC3hi1vVrWXUZ4I9zQ2kSyJ5v3U25f5yoQlVGGU5J6j4Jf8 kh0L/t4/9KJKALFt8KvD9vp2iWDy309rpEV5DEkkqjzUugRKJCqg9GONu3HvXUaHpKaDodlpMVzP cQ2cSwxyT7d+xeFB2qo4GB07c5OTWhRQAUUUUAc/4E/5J54a/wCwVa/+ilroK5/wJ/yTzw1/2CrX /wBFLXQUAc/4N/5Adz/2FdS/9LZq6Cuf8G/8gO5/7Cupf+ls1dBQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAVxepX7atcLLdGT/AIRwamNMkiRlC3ByYy0oKl2T7Ttg8tdoPzMxeNsDoPEupTaN4V1f VLdY2nsrKa4jWQEqWRCwBwQcZHqKrzeGof8AhCh4atbiSJIrJbW2uXAd4WRQI5eMfOrKrAjHKgjF AEena9ZjxHN4ZtbLyI7OIpEUAVB5aQMyhR91QtzDtx1+cYUKC0lt4p00+H7bWtSurTTLO7c/ZpLq 5VFljJYxMC2MF4wH2nkZIPINc/d+GNXufDVvPA8lnr1xcTS3MkbjzYVugyMhlDDeIFeJhg/N9kjA C/LtueJNGv4tR0e80VL6G3sbSez8nSBarIquYSoC3A8sRgQkHGGB24GM4ANiXxFZ23iGbSbyWC22 xWzQyzTBfOkmeZVjUHGW/ckgAknPTjmxrWp/2RphuhD50jSxW8UZbaGklkWNNzYOF3OuSASBkgE8 Hg7zwpqFtb3emWuhyTm68L2+iQXyzwstqwEyuHdijlPniYlI/m2525AFd5raXEmjzx21nBes20SW s4BWaIsPNQAkAsU3hdxC7iNxxmgCvp+oaw2oiz1bSYLfzImljms7p7iMbSoKuzRR7WO8FQM5Cv02 82LXXdHvtOn1Gz1WxuLGDd51zDcI8ce0bm3MDgYBBOegrj38PXt/p2sadpWjT6BYXmlXNqbS7mj8 kzyACJoo4nkWJV/e79oXcXBw55A+g6vfeHvFryxarJf6jpRsYF1Oa0EjlUm2gC3AjVczfeZiSSch QoLAHaR6tpsyTPFqFo6Q3H2WVlmUhJtwXy254fcyjaeckDvRJq2mw6pDpcuoWiahMm+K0aZRK688 qmckfK3IHY+lc/N4XZPFljJaRxw6KqRzTW0aKsQlgV0iBQEAkiWNg2Pl+xxj+7tz7zw7qsviy8JO pPp95qdrqAEEtslqvkrB/rSymbfugzhPlI2DcuWKgHQXVtbaretc6Rq8dtqkCbJJICkodA7gRzIf vIJEkHBVgRIFZcvnL1fU/wC2PBmn3rQ+RM2q6fHPBu3eTMl/Ekke7A3bXVl3Dg4yOCK1PCulNpOn XiS20cE9xqd7dPt25kD3EjI7EdSY9nXkAAcYxXN69/o2savZpzHNqGh6gxPUSPdpAQP9nbaxkDrk tzggAA5/w9/ydD4s/wCwVH/6Da17BXj/AIe/5Oh8Wf8AYKj/APQbWvYKACiiigAooooAKKKKACii igArx/4Qf8lD+J3/AGFR/wCjbivYK8f+EH/JQ/id/wBhUf8Ao24oA9grn/Bv/IDuf+wrqX/pbNXQ Vz/g3/kB3P8A2FdS/wDS2agDoKp6lqtjpFus9/cxwI7iOMNy0rkEhEUcu5wcKoJPYGq+q6lNBcW+ m2CxtqV2jvEZQfLijQqHlfBBYKXQBAQWLAZUbnU03QLHTbhrwLJc6g6FJL66bzJ2UkEqGP3ELDd5 aBUBJwooAp/8Jlpf/Prrn/givf8A4zUc/ivRbq3lt7iw1maCVCkkcnh+9ZXUjBBBhwQRxiukooA4 uzvfB2n291b2Xhq7toLtNlzHD4XukWZcEYcCDDDDEYPqfWiC98HWtvFb2/hq7hgiuBdRxx+F7pVS YDAkAEGA4HG7rXaUUAcf/avhP/oAX3/H39u/5Fm7/wCPj/nt/qP9Z/tdferFj4j8P6ZZx2dhpWq2 lrHnZDB4dvI0XJJOFEOBkkn8a6iigDn/APhM9IXmVNVgjHLTXGj3cUcY7s7vEFRR1LMQAOSQK3IJ 4bq3iuLeWOaCVA8ckbBldSMggjggjnNSVz9/4b8n7TfeHpP7N1N98u1G221zKcn99Hgqdzbd0igS 4GA46UAdBRVPS9Sh1awW7hWRAXeN45AA0ciOUdDgkZVlZcgkHGQSMGrlAHP+BP8Aknnhr/sFWv8A 6KWugrn/AAJ/yTzw1/2CrX/0UtdBQBz/AIN/5Adz/wBhXUv/AEtmo8Zl/wDhH0jjnnh87ULGF3gm aJ9j3cSMA6kMMqxHBHWjwb/yA7n/ALCupf8ApbNR4y/5Adt/2FdN/wDS2GgA/wCEN0v/AJ+tc/8A B7e//HqP+EN0v/n61z/we3v/AMeroKKAOf8A+EN0v/n61z/we3v/AMeo/wCEN0v/AJ+tc/8AB7e/ /Hq6CigDn/8AhDdL/wCfrXP/AAe3v/x6j/hDdL/5+tc/8Ht7/wDHq6CigDn/APhDdL/5+tc/8Ht7 /wDHqP8AhDdL/wCfrXP/AAe3v/x6ugooA5//AIQ3S/8An61z/wAHt7/8eqvodoNM8ZaxYQXN9Jar p9lMqXd7Nc7XaS5DEGVmIyEXp6CuorlG1CGw+IerearnfpVjjaB2lu/f3oA6uis621m3u7hYI0lD NnBYDHAz61o0Ac/47/5J54l/7BV1/wCimroK5/x3/wAk88S/9gq6/wDRTV0FAFdb+zfy9t3A3myv BHiQHfIm7cg9WGx8jqNrehrL1nxTpuiWFxqNxdWjWdvb3Esm25XzWaJ1QoinhjubYfmGHKrgluOf 1Twxq41m/vdPeQwWzjUbC2Rwiy3DNEZIl+bEZYQSAyEYP2+Trh98es+EdRTQ49Osl+2SR+GtRsHn JWM3F1N5BDMC33pGSRiSTySScnJAOkTxTpp1k2T3VpHA9vaS2ty1yu25a4aYIidmJEORgndu4HHO xNPDbIHnljiQuqBnYKCzMFUc9yxAA7kgVxevaDe6v/wk97Hpe261Dw0ljaCVo/MWU/aS8W4MQOXi yc7SQOTjjQ+IMP2jwmYPs0F15moWCeRcHEcubuEbXOG+U9DweD0PSgDQfxFZyNor2EsF9a6pdvbJ cQTBkXbFLIWBGQ3MJXGe/titCG/s7j7P5F3BL9piM8GyQN5sY25dcfeX515HHzD1FcnbaRqc+tW2 qyWElsk2um+eCWSMyQRDTmtgX2sVJLqMBWbhgTjkCPwvpmrWeo+H7a70qe3h0bRJdPku2liaOeTN sAYwrl9pELnLKpxjIB4oA6SbX9N+z3rWupabLPapMXR7tVVGiA3iRhkoFLJuODt3DI5GbB1bTVv0 sG1C0F47siW5mXzGZUDsAuckhWViOwYHoa8rXSb2706z0uDTYDdHwVe6bb3Uc8bfbyotlVkYHHkk tlCzA/O2VTq3WXfhy7e4164isY/Pvdd025SQFA0lvCbQsSc5wpjmIU89cD5uQDtK8/8AE3/Iz6h/ 3L3/AKcpa9Arz/xN/wAjPqH/AHL3/pyloA5/w9/ydD4s/wCwVH/6Da17BXj/AIe/5Oh8Wf8AYKj/ APQbWvYKACiiigAooooAKKKKACiiigArx/4Qf8lD+J3/AGFR/wCjbivYK8f+EH/JQ/id/wBhUf8A o24oA9grn/Bv/IDuf+wrqX/pbNXQVz/g3/kB3P8A2FdS/wDS2agA8O/6dqOtay3Pn3bWUGeGWG2L RlSBx/rvtDA8kq65PAVdyOeGZ5kiljd4X2SqrAlG2hsN6HaynB7EHvWH4N/5Adz/ANhXUv8A0tmr L0+DXpfEniptL1LTbaD+04wyXWnvOxb7HbchlmQAYxxjseeeADYm8aeFbZwk/iXRonKK4V7+JSVZ QynluhUgg9wQaj/4Tvwf/wBDXof/AIMYf/iq5/Rf+RY+Fv8A2w/9Ns9dBef8lD0b/sFX/wD6NtKA LkPiXQbnVDpcGt6bLqAdkNol0jShlzuGwHORg5GOMGrGpatpujW63GqahaWMDOEWS6mWJS2CcAsQ M4BOPY1x+gaPqWq2Msc+o2i6Smu3dwLdLNhPui1CSRR5pkK43oM/u/u5HB+atTxel5JqHhZbCeCC 6OqvsknhMqL/AKHc5yoZSeM/xD156UAbkOrabc6WdUg1C0l08Izm7SZWiCrncd4OMDByc8YNEOra bc6WdUg1C0l08Izm7SZWiCrncd4OMDByc8YNcvf6VNpJs9R1G5juIn1gX+rSpEY4EVbZoo28ssxC K6W7Elm2spkJUL8tPUZrPUX1vVrS53aM39myR3tsBJB9qhuGZpm5AeNALfzHBHyRsu4GM7QDqP8A hLPDf9nf2j/wkGlfYfN8j7T9tj8vzMbtm7ON2OcdcVY0zXdH1vzf7J1Wxv8AyceZ9kuEl2ZzjO0n GcHr6GsPwpqC6nrOqXIvNN1Rxb28Z1TTAywSANMRBt8yQb0yWJDZImXIGATc8Cf8k88Nf9gq1/8A RS0AFx/xKPF9pOn/AB761m1ljHa4jjaRJMcDmNJFZjknZCBwDXQVz/iH/kOeE/8AsKyf+kV1XQUA c/4E/wCSeeGv+wVa/wDopa6Cuf8AAn/JPPDX/YKtf/RS10FAHP8Ag3/kB3P/AGFdS/8AS2ajxl/y A7b/ALCum/8ApbDR4N/5Adz/ANhXUv8A0tmo8Zf8gO2/7Cum/wDpbDQBn+PdN/teTw1Y+XYyebqr fLf2v2mE4tLk/NHuXd045GDg9sVj6nappl3LpcNvYwQ2/wDYDbbO0WBN7alJvIAyQpIyFLHGT3JJ 7zUNTttMEL3ckcUUjsplklRFjCxvIWJZhkBUPTJHXGASMtvG/hvz9Mig1mxuf7Ru2s4Ht7qN18wI XIJDf7q8ZO6RBj5hQBz/AIC1/XdX1EjU7+xm32nnXNnDOJZLGfK/umVYU8jGXBSV5HJTgnY5NfVN Uvf+Eol8SxWN8+kaXL5D3KSRiEQRCZLtiC4kGHfJRY23mzjIJ3KU7yz1bTdQuLq3stQtLme0fZcx wzK7QtkjDgHKnKkYPofSo313R47y6s5NVsUurSIz3MLXCB4YwAS7rnKrgg5PHIoA8r0aeTTNcjnj 8QXd5dQJ4hSO0MUErPMl0j+WI0VGd2GJSgZScDaVUkG5p3i/VnnnsbzX4F05ZbdpdbhnimWCORLk 5WY28cO3zIIo8lGAaR13bsBPTNN1bTdZt2uNL1C0voFco0lrMsqhsA4JUkZwQce4rP8AD3iKTxDb wXaaJqVnZ3FutxDc3TQbZFYAqAElZgSDnkDoc4PFAHF6NqGowT61q1trn2y1/wCEgs7VR9kVFu1l S0hMjkj5vkdWVo9iswL/ADIyqtfSvFniWaxmuLrVLEs8ULXsUMqzSaUXmiWQsogUQeWjzErM0hBi zyEkJ9Eg8S6DdX8Vhb63ps15KgeO3jukaR1KbwQoOSCvzZ9OelF34i0q1e/g+32kl5Y27XM9mtzG sqIFDZYMwCjBXliByMkDmgDD8BXH2qTxLML77ep1VQl35Xl+cotLYK+OhyADuUBW+8oCkCqWsf8A JQ9Q/wCwVZ/+jbqux0zUodVtXuIFkVEuJ7chwAd0UrRMeCeNyEj2x06Vx2sf8lD1D/sFWf8A6Nuq ANHRv+QtB/wL/wBBNdZXJ6N/yFoP+Bf+gmusoA5/x3/yTzxL/wBgq6/9FNXQVz/jv/knniX/ALBV 1/6KaugoAw9O8X6DqWiXGsxanaR6fb3ElvLcSzoEVkfZktuwA3ysuTyHU962IJ4bq3iuLeWOaCVA 8ckbBldSMggjggjnNcXBpmrW1nZznSp5JNN8QX175CSxb7mGY3IRoyXC/wDLwpIcqflbjOA3QeGL G4sNFMd1H5U013dXRjLAmMTTySqrEZG4BwDgkZBwSOSAXLLVtN1J5EsNQtLp40jd1gmVyquu5CcH gMvIPccio7O/0fxDZmWyu7HU7VJVy8MiTIsiEOvIyAwO1h3HBrz/AMH6RqN74S0NoNGsbeO38NS2 0a3JV7a7kuFgdWKr820+W3mBlBy5C7xlq1NJ0PWLu48SvrNtd3NvqOmQ2kMep3MCSSAG4DxubZMR j94OV3nDA5zlFAOstdd0e+06fUbPVbG4sYN3nXMNwjxx7RubcwOBgEE56CpIdW0250s6pBqFpLp4 RnN2kytEFXO47wcYGDk54wa5ODS9XvNM1N76yvpnP2Zrdrx7SO+LxSGTIaEGEqh2tGr9X3h8I2a3 PC8GoQ2Vy+oxSJLNcF1a4WEXLrsRcz+T+7L5UgFf4BGDyDQBj6V4l8KwGz1ayt9N0+z1uyl1G51B jFD8ySRLtlYcF91wQctwwI5JrqLzVtN0+4tbe91C0tp7t9ltHNMqNM2QMICcscsBgeo9a5Pw1oN7 H/whkuo6X5MmkaJNaSec0btDP/o6AqVZvvLHLgg/dODgnFYbeD9dGjWViyakqXXhyz0m6hsZrVVV 41lDiZ5VYhP3uA0IY8OcH5cgHqlef+Jv+Rn1D/uXv/TlLXoFef8Aib/kZ9Q/7l7/ANOUtAHP+Hv+ TofFn/YKj/8AQbWvYK8f8Pf8nQ+LP+wVH/6Da17BQAUUUUAFFFFABRRRQAUUUUAFeP8Awg/5KH8T v+wqP/RtxXsFeP8Awg/5KH8Tv+wqP/RtxQB7BXP+Df8AkB3P/YV1L/0tmroK5/wb/wAgO5/7Cupf +ls1AB4N/wCQHc/9hXUv/S2aiLxnokusX2nrewBbDK3Vy1xEscUoUuYjl924IrsTt2gI43ZVgDwb /wAgO5/7Cupf+ls1Zc3hy7ufEwuZ7GOW0HiNdQBcowEa6aIlkwT1EwAHcEA9OaAOoj1bTZtUm0uL ULR9QhTfLaLMplReOWTOQPmXkjuPWq58S6CLe4uDrem+RbpE88n2pNsSyAGMsc4AYEFSeueM1z9h pGpx6pp1pJYSJBYaxe6k16ZIzFKk32naiANv3j7SudyqPkfBPy7o/DXhWXTf+EM8/TIIv7K0SaGb AQ+RdSfZ9xGP4m2zZZeuWyfm5AO0nnhtbeW4uJY4YIkLySSMFVFAySSeAAOc1HY39nqdnHeWF3Bd 2smdk0EgkRsEg4YcHBBH4VzdppWp2vwy0nTFto/7StLKzR4m8t2R4xHv8vdlPNXaShb5d4UnjNSe C9P1axTWpdXE/nXmoC4ia4kieRo/s8KDf5SqgYFCpAGAV4LDDMAamh+IdN8Q2UVxYXMbO9vDcPbl 1MsCyoHQSKCdpKnPv2zVNvG/hvz9Mig1mxuf7Ru2s4Ht7qN18wIXIJDf7q8ZO6RBj5hXL+HvDesw 6HpllJoVjZTad4fuLAxXLpLbXM83ktyE5K5ibzMgcudpcfNUdlovib/hM7PWbyz1K5t1uLUBrua0 8+OMRX0bFli2IArTo2FLkq2QScooB3GoeIdN06y1e4a5jnfSbc3F5bwOrSxqELgFc8FlBIzjNXLW /s77z/sd3BceRK0E3kyB/LkX7yNjowyMg8iuLutC1OTwx4k0ddIje4kt9UFreGWP96bqR5Ejj7gf MocvsAZFxvHzDoNP0prHxVfTw20cGnnTLO1txHtVQYnuCUCjoAsidsc8dDgAj8Q/8hzwn/2FZP8A 0iuq6Cuf8Q/8hzwn/wBhWT/0iuq6CgDn/An/ACTzw1/2CrX/ANFLXQVz/gT/AJJ54a/7BVr/AOil roKAOf8ABv8AyA7n/sK6l/6WzUeMv+QHbf8AYV03/wBLYaPBv/IDuf8AsK6l/wCls1HjL/kB23/Y V03/ANLYaAK/jrw3eeJ9Hjs7KSCORftGTMxA/eWk8C9Af4plJ9ge/Bj1Tw7qU/jey121No0EL2we OWVkbaiXiORhSCcXSEDjO0gleDWx4g1dtD0n7clnJeP9ot4FgjdVZzLMkXBbAz8+eSAcYJHUc/ae O5ktb241jSo7ZLe3v7hRZ3RuC62cvlTA7kjwSxUr1yM524wQCx4c8O6lptxpK3ptBBo2mNpts8Mr O1yrGH946lVERxAPlBf75+b5fm5/X/h7rOqS3SwXNokbvfMpe6nCyfaIJ0X9wP3URRplBZVZpPmc lWLK+xB411SbS7yc+GbsXFu8YAEV0ImV93OWt1lYjbghInxvQ5wWKWLnxdfQppckejRyR3iBjMLz MTkthVhlVCjF+CnmtCH8yMA7iwQA2INNmi8VahqjNH5FxZW1uigncGjedmJ4xjEq457Hp35/wL4W m8N29rBceHfD9pPBZJbyajYSlp7hlCglgYUOGK7j8x5A69RXt/iQZZmhfSJEedFawO+TZNvmihXf I0QTG6eIloWmXG4gn5d5dfEK9trqXTj4fk/tOK4kiaISSzIVjigdnDQQyPgm4TblBkDLFGISgCPT PAV5p2lWdnGbGPybTR4nERIUyWt0087fd/i3Eg9SxOcdap6/8PdZ1SW6WC5tEjd75lL3U4WT7RBO i/uB+6iKNMoLKrNJ8zkqxZX6TxHreqR+ELTUNItPIur2W0i8u+byZLcTyInI2OBIpcDBBAOSQ23a 3Pw+Pry2isZjBPeNf6VpsttbspciaZbqSRnaGJmPyQD7sZGQPlUEkAHaaBps2ladLbztGzve3dwC hJG2W4klUcgc7XAPvnr1rifE9lcXnxDvPI1O7sdulWmfs6xHfmW56+YjdPbHWu60TUn1fR4L2Wzn s5JNwaCeNkZSrFSQHVW2nGVLKpKkEgE4HJax/wAlD1D/ALBVn/6NuqAKuk6HqDanCo8VauhO75li tMj5T6wV0/8Awj2qf9Dnrn/fmy/+R6p6N/yFoP8AgX/oJrrKAOD8aaFqMPgXxDK/izWZ0TTLlmik iswrgRN8p2wA4PTgg+hFdhq15Np2jX17b2kl5Pb28ksdtHndMyqSEGATkkY6Hr0NZfjv/knniX/s FXX/AKKaugoAx7XxFZsuzUZYNOumu3to7e4mCvJ+9kjiYBsE+YIiyjHPOM4zVy81bTdPuLW3vdQt Lae7fZbRzTKjTNkDCAnLHLAYHqPWuH8TWF3qXirxJZWWmR3M994cgsFud6K1t5r3Q3Hdg+VkAttJ b5Vwjfw6HinSNTurjXYrOwkuU1vR001JUkjVbZwbjLy7mB2fv1PyBz8rcdMgHSJf6Pp95a6HHd2N tdGIfZrBZERzGoONkfXaAp6DA2n0qnp3i/QdS0S41mLU7SPT7e4kt5biWdAisj7Mlt2AG+VlyeQ6 nvWXf6XqQ8UM1lZT/Zbm7guZy728lnIUEYaSRWHnJMqxgII8puSJieXxnzaJrZ0e38q3vra40/xB e3o+yvbGaaGVrna0XmEx8i4XIk2kBXwM7cgHaPq2mx29pcPqFosF66JayNMoWdnGUCHOGLDkAZz2 rLHiyzg8Aw+Lb9Ps1q2npfPEHBI3IGEak7QzEkKOmSR61hwaFeabFptzLpF3qsRt9Qhu7N5bd52N 1OkxMmfLiI+RgyqSAWAG8Zarn9iaj/wpv+wPs/8AxM/+Ef8AsXkb1/132fZt3Z2/e4znHvQBcPia aHTobqeHTZHleyASy1AzDbc3HlK4JjXKbSGBx8xDDjbuOxHq2mzapNpcWoWj6hCm+W0WZTKi8csm cgfMvJHcetc3ruiajea7eXNvb74ZP7G2NvUZ8i+kll4J/hRgffOBk8VT0jw7qtv4lhF2dSe0tNTv NQiJlthaDzjNt2AKZ2fE+CH2qDvIYgKGAOk0jWLzUb+9t7nSZ7KO3z5csmcTYnnj4yo/hhSTqeJV 7YJ8v+JPhfVNa8a3U9l4ovtOjji0mMwxD5SZbySND8rL/q2BkG7cdzHBUYx7RXn/AIm/5GfUP+5e /wDTlLQB5JpXgTXrn4y654fi8calBqFrZLLLqyh/NnUiE7G/eA4+derH7g49O7/4VB4w/wCis65+ U3/x+jw9/wAnQ+LP+wVH/wCg2tewUAeP/wDCoPGH/RWdc/Kb/wCP0f8ACoPGH/RWdc/Kb/4/XsFF AHj/APwqDxh/0VnXPym/+P0f8Kg8Yf8ARWdc/Kb/AOP17BRQB4//AMKg8Yf9FZ1z8pv/AI/R/wAK g8Yf9FZ1z8pv/j9ewUUAeP8A/CoPGH/RWdc/Kb/4/R/wqDxh/wBFZ1z8pv8A4/XsFFAHj/8AwqDx h/0VnXPym/8Aj9cJ4E8Ca9rfirxjZWXjjUtMn069EVzcwh9162+Ub3xIpzlCeS33zz6/TdeP/CD/ AJKH8Tv+wqP/AEbcUAH/AAqDxh/0VnXPym/+P1l6B8LPFV9p0s0HxO1m1Rb27iMaCXBZLiRGfiYc sylz7seT1Pulc/4N/wCQHc/9hXUv/S2agDP+Gen3Gl+Dvsl1qM+oTRahextPMACxW5kUn1+YqXO4 scsecYA3JvEOmW+qDTpJ5BPvWNnEEhijdsbUeULsRzuXCswJ3pgfMuafg3/kB3P/AGFdS/8AS2aq d54d1KbVLyOI2n9n32p2upSztKwliaDyP3ax7SHDfZ1+YuuPMPynb8wBuaNreneINOTUNKuPtNo+ NkwRlVuAeMgZxnBx0YMpwykCvD4p0aezubqO8zDb7Sx8pwXDnEbRrjMiueEZAwc8KWNSeGtNm0bw rpGl3DRtPZWUNvI0ZJUsiBSRkA4yPQVh23hvWI/CFtokslj/AMSz7ELIqz/v/ssiOGkbH7vzPLUb Qr7OTukzgAGpJ4v0OGyhu5ruSJJbj7KkctvKkvnbC4jMRXeHZRlVIBbcu3O5cxnxt4dWKaU6hiOG J5ZXMMmIyil3jY7eJlVWYwn94ACSuBVO28O6k+p22qXZtIp21g6jcQRStIsa/YmtQqOVUuSQjHKr jJHOATn614K1LUvCp0uGe0Wc3uqXG53YLtuUvFjHC5yDcpnjs2M4GQDc/wCE28O/9BD/AGv9TJ/q v+e/3f8Aj3/6b/6r/aq5D4h0y41Q6dHPIZ97Rq5gkEUjrnciSldjuNrZVWJGx8j5Wxl694bvNU/4 SfyJIF/tXRE0+DexG2QfaclsA4X98vIyeDx0zT/4RbWZPGdjq1xeRy29pezTktdzkyRvFKiKsH+q iMe9UyAS4BYlTlWANjTfGGgatbtc2mpRm3Fubrz5EaKNogAWdXcAMEyA+CdhOG2nijR/E9pres31 haJJizt4JZGlR4pFaRpRseJ1DIQIgwz1Dg4xgnD/AOEIvJ/D2l6TPdQR+R4auNGnlQF8SSpAodQQ NyjymPJB6epxsaNZax/wkOpatq1tY232i0traOK0unn/ANW8zFiWjTGfOAwAehoAPEP/ACHPCf8A 2FZP/SK6roK5/wAQ/wDIc8J/9hWT/wBIrqugoA5/wJ/yTzw1/wBgq1/9FLXQVz/gT/knnhr/ALBV r/6KWugoA5/wb/yA7n/sK6l/6WzUeMv+QHbf9hXTf/S2Gjwb/wAgO5/7Cupf+ls1HjL/AJAdt/2F dN/9LYaANi9sbfUIFhuo/MjWWOYDcRh43WRDx6Mqn3xzxVNfDmkKSTYxuClyjLIS6stxIJJgVJII ZgDg9OgwOK1KKAMMeEdHFu8Rju3d3V/tMl9O9wpUEDbOXMigBnGFYDDuP42ySeENDlSFGtJAkabH VLiVRcKWLET4b9+CzOSJN2S7k53tncooA5e78DaT5Ez6dbQW980XkRT3HmzLDHvR9iKJFKKpjUoE ZRG3KY5zHpXgPT7OykS6kke7muGuJLiylmtG3MiIwDLIZMMIkZ9ztvcFjzjHWUUAU5dKsZrCCwa2 jW0geF4oY/kVDE6vHgLjAVkXjpxjpxWf/wAIhoYt4oUtJIhDbwW0TxXEqSRRwhxGEdWDKQJJAWBB Icgkg4rcooAr2Njb6dZx2trH5cKZIBYsSSSWZmOSzEkksSSSSSSTXFax/wAlD1D/ALBVn/6Nuq72 uC1j/koeof8AYKs//Rt1QBo6N/yFoP8AgX/oJrrK5PRv+QtB/wAC/wDQTXWUAc/47/5J54l/7BV1 /wCimq5r3iHTfDVhHe6pcxwQSXEVurO6r8zuFz8xAwASx9FVj2qn47/5J54l/wCwVdf+imqTxbbX d1oSrZWsl3PFe2dx5EbIrOsVzFIwBcqudqHqRQBce/0e31xbN7uxj1e6iG2EyIJ5Y13kYX7zKP3h HYfN71HqniHTdGv9Ksr25jin1S4NvbKzquWCFs8kHGQF4z8zoO9c/f6RqcmqajaR2EjwX+sWWpLe iSMRRJD9m3I4Lb95+zNjarD50yR823Y1+2u5tR8O3FrayXCWmp+ZOEZAUja3mi3/ADEZAaRSQMnG cA9KAJNG8RWervJb+bBFfJLcr9k84NIY4bh4PM28HaSnXGATjJq5Hq2mzapNpcWoWj6hCm+W0WZT Ki8csmcgfMvJHcetcvp3hy7tH0pxYxxOniO/1C6ZSgJjkW7WORsH5iVkhHcgYBxg4r6R4d1W38Sw i7OpPaWmp3moREy2wtB5xm27AFM7PifBD7VB3kMQFDAHQaxrGpWus2Ol6Xp1pdz3VvPcM11eNAqL E0S4G2NySTMOw6GrEOpzWlkZvEP9m6a5dguy+MiFVQuTudI+QquSMcBSc9cYfizSFvvEOkXlz4Y/ t+xgtLqJ4dtu/lyO8BRtszqOkcgyMkfjUcegW9ydBFp4Tj0i0s9YN3PavFbKBi2lVZtsTspO9owD ncCoOABmgDqINW026uIre31C0mnltxdRxxzKzPCTgSAA5KE8bulFnq2m6hcXVvZahaXM9o+y5jhm V2hbJGHAOVOVIwfQ+lcvp3hy7tH0pxYxxOniO/1C6ZSgJjkW7WORsH5iVkhHcgYBxg4r+GtH8Qwe KrK61KCSOztdMntAga3WCKUvAdtukahhARGdhkYvhcMFOC4B0mla5/aWovZ+XAdmn2t751vP5sb+ cZRhG2jco8rIb+IN0Fcv4m/5GfUP+5e/9OUtaHgrRNR0j7N9ut/K2eH9Msm+dWxND5/mLwT03rz0 OeCeaz/E3/Iz6h/3L3/pyloA5/w9/wAnQ+LP+wVH/wCg2tewV4/4e/5Oh8Wf9gqP/wBBta9goAKK KKACiiigAooooAKKKKACvH/hB/yUP4nf9hUf+jbivYK8f+EH/JQ/id/2FR/6NuKAPYK5/wAG/wDI Duf+wrqX/pbNXQVz/g3/AJAdz/2FdS/9LZqADwb/AMgO5/7Cupf+ls1U9W127sfEN7biWT7PGmkh ETYCGuLyWJzkqcgqqgj0BwVJ3C54N/5Adz/2FdS/9LZqsX3huz1C/mvJZJ1kl+x7gjAAfZp2njxx 3ZiD6jpg80AYdh4+aTRo9V1PR5LO3n0eTV4EjuFmkaKJYzIGGFAJ81dnzHcOW8s/LWh4X8WQ+Iri 9tVfTZJ7RIpHfTL8XcG2QuFG/apDgxtldvAKnJzgSJ4O0sadY2EvnzWtppUmkBHfHmQSCINuKgHd iFeRjqfbGhpmmS6f5rXGqX2ozSYHmXZQbVGcALGqIOSedu45AJICgAHP6F4n1GW6jg1Gzzb3Oq31 hb3XmrvZopZ2UeWBgRiOEruLbiy/dIO8mm+L9U1fTtIltNCgjvNUtGvoYLq/2IsCiLcWdI3+YtMu 1ccrySrfINCw8I2dhqK3S3l9KiXc99HbTSho47iYybpF+XcPlldQudmDnaXyxB4Tgg07Sbax1G+s ptLtBZQXcPlNIYcICrB0ZDkxRknaDleCASCAZbfEaxTTRfSWskSSJbXMCSN8z2ksRlaY7QQpRIro 7MknyMD765k1Lxx9j3slvYxW5u5reK91K/8AsttJ5O1XBfYxWTzDIqoR8whdgcYzqL4R0VXsv9Cj aCzsjYx28iiRGi2hVDbgSxVTIoJPAmlHO80L4aEGl2VlYatqVk9qhU3MLRs8+7BdpA6MjOzDcX27 slsEbmBAMef4hW1v4gXTJorSB1uLe1mtp79FvRLMIyuyBQwdB5yBmDjG2TAO0btzQNZuNaW9lk0/ 7LbwXc9rE5mDmYxSvGzAAfKvyDGTnO4YwAzV7LwjZ6ZPENOvL6zsU8ovYwyjy5WiRI0LMVMnCxxg gOFYJ8wO5t2ppmmw6VavbwNIyPcT3BLkE7pZWlYcAcbnIHtjr1oAy/EP/Ic8J/8AYVk/9Irqugrn /EP/ACHPCf8A2FZP/SK6roKAOf8AAn/JPPDX/YKtf/RS10Fc/wCBP+SeeGv+wVa/+ilroKAOf8G/ 8gO5/wCwrqX/AKWzVoa1pKa3phspLme2/exTJNBt3o8ciyKRuVl+8g6g1n+Df+QHc/8AYV1L/wBL Zq6CgDn/APhHtU/6HPXP+/Nl/wDI9YeoW2uWl9JBH4v1cquMFoLPPIB/5967yue1PTLy41CWWKHc jYwdwHYe9AHN/wDE/wD+hu1b/vxZ/wDxij/if/8AQ3at/wB+LP8A+MVs/wBjah/z7/8Aj6/40f2N qH/Pv/4+v+NMZy8174jj8QWdgPFup+VNazzMTb2e4MjxAY/cdP3jZ+gq/wD8T/8A6G7Vv+/Fn/8A GKbdaTfDxvpUZg+Y6beEDevQSW2e/uK2/wCxtQ/59/8Ax9f8aAMb/if/APQ3at/34s//AIxR/wAT /wD6G7Vv+/Fn/wDGK2f7G1D/AJ9//H1/xo/sbUP+ff8A8fX/ABoAxv8Aif8A/Q3at/34s/8A4xTL axnj1G4v7zU7u/upoo4S9wsS7UQuVAEaKOsjdc1uf2NqH/Pv/wCPr/jR/Y2of8+//j6/40AGjf8A IWg/4F/6Ca6yue0zTLy31CKWWHai5ydwPY+9dDSEc/47/wCSeeJf+wVdf+imroKr39jb6np1zYXk fmWt1E8MybiNyMCGGRyMgnpWf4Yvri80OFL+Tfqdp/ot+SoUmdOGbaMYV+JF4GUdTgZoA2KKKKAC s/TtWTVF8y3tpxCJbmFpH2gK8MpiII3Z+YqxGB0XnBwDzf2O0XxnfS6lo93c6hJewvpt3FbOTDbi KIMBcDCxoHWctGXBYFvlbzAGx30rWmguVsLa7ivGsvEaW8gzEVllvUaHDnAUsBuU5GQMjgZoA9Mq ve31vp8CzXUnlxtLHCDtJy8jrGg49WZR7Z54rzO30KWfR7+K1t5Es7i90tRBp+jTaSilLtWlkWNn Mm/YVLSAKAEXDEqdtzWNAt00PWrJ9D83TLTxBYzWlnHYmVEgH2QzGKJVOV5uN2wc7pPU0AekUUUU AFef+Jv+Rn1D/uXv/TlLXoFef3/+n6fea8fmjvdb0uGzc9TaxXkKoeOCrSNPIrDO5JVOcYAAOf8A D3/J0Piz/sFR/wDoNrXsFeP+Hv8Ak6HxZ/2Co/8A0G1r2CgAooooAKKKKACiiigAooooAK8f+EH/ ACUP4nf9hUf+jbivYK8f+EH/ACUP4nf9hUf+jbigD2Cuf8G/8gO5/wCwrqX/AKWzV0Fc/wCDf+QH c/8AYV1L/wBLZqAC3/4lHi+7gf8A499axdRSHtcRxrG8eeBzGkbKoyTsmJ4AroKr31hZ6nZyWd/a QXdrJjfDPGJEbBBGVPBwQD+FY/nap4f/AHT2s+qaUn3J4pPMu4F9HQ8yqoB+dSZGyo2O2XYA6Ciu f/4TLS/+fXXP/BFe/wDxmj/hMtL/AOfXXP8AwRXv/wAZoA6Ciuf/AOEy0v8A59dc/wDBFe//ABmo x450Vrh7dYtZM6IrvGNEvdyqxIUkeVkAlWAPfafSgDpKK5//AITLS/8An11z/wAEV7/8Zo/4TLS/ +fXXP/BFe/8AxmgDoKK5/wD4TCwf5YLDXJZjwkf9jXUe9uw3SRqi5PdmVR1JA5o/s/Ude+bWR9j0 88f2XFIsn2hTzi4bb9AY0O3hgzSq2AAGj/8AE61Z/ER/49Vie005T1MfmZkmyOCspSMr94bI1YEe YyjoKKKAOf8AAn/JPPDX/YKtf/RS10Fc/wCBP+SeeGv+wVa/+ilroKAOf8G/8gO5/wCwrqX/AKWz V0Fc/wCDf+QHc/8AYV1L/wBLZq3J54bW3luLiWOGCJC8kkjBVRQMkkngADnNAElFc3BZ6l4jt4rv Ubu70+wnQSR6bbbrecKRkCeUHeHHynbGY9p3KTIOTJ/wgvhNuZfDelTyHlpri0SWSQ92d3BZ2PUs xJJ5JJoA6Ciuf/4QTwf/ANCpof8A4Lof/iaP+EE8H/8AQqaH/wCC6H/4mgAvP+Sh6N/2Cr//ANG2 ldBXP/8ACCeD/wDoVND/APBdD/8AE0f8IJ4P/wChU0P/AMF0P/xNAHQUVz//AAgng/8A6FTQ/wDw XQ//ABNH/CCeD/8AoVND/wDBdD/8TQB0FFc//wAI0+n/AD+H9Sn09hwLactc2hHQKImYGNVBO1Ym jA4yGCha0NH1P+1LN3kh+z3UEr29zAW3GORTg84BKkYdSQCyOrYGcUAaFFFFABWPfaTcJeSalpFz 9nu2w01u+PIvCAAPM+UsrbRtEiYPC7hIqKlbFFAHP/8ACV29j+7162n0iRfvzTqWtMdNwuAPLVSc hRIUc8ZQFgCf8J34P/6GvQ//AAYw/wDxVdBRQBz/APwnfg//AKGvQ/8AwYw//FUf8J34P/6GvQ// AAYw/wDxVdBRQBz/APwnfg//AKGvQ/8AwYw//FUf8J34P/6GvQ//AAYw/wDxVdBRQBz/APwnfg// AKGvQ/8AwYw//FUf8Jx4ak4s9Xg1GTqYdMDXsij+8UhDMF6DcRjJAzkiugooA5//AImPiP8A5/tH 0wf7sdzdg/m0MZU/7MuT/wAstnzx+K4IbXw3ZW9vFHDBFqemJHHGoVUUXkAAAHAAHGK6Suf8Zf8A IDtv+wrpv/pbDQB5/wCHv+TofFn/AGCo/wD0G1r2CvH/AA9/ydD4s/7BUf8A6Da17BQAUUUUAFFF FABRRRQAUUUUAFeP/CD/AJKH8Tv+wqP/AEbcV7BXj/wg/wCSh/E7/sKj/wBG3FAHsFc/4N/5Adz/ ANhXUv8A0tmroK5/wb/yA7n/ALCupf8ApbNQB0FFFFABRRRQAV4f4H8e/wBsfH7xFbm9/wBAvomt rONX85JGtz8jIwHyqV8+TAIX5z1OCfcK4vR/DWg6d8RtSex0TTbV4NMs3haC1RDGzyXauVwOCygA kdQADQB2lFFFABRRRQAUUUUAc/4E/wCSeeGv+wVa/wDopa6Cuf8AAn/JPPDX/YKtf/RS10FAHP8A g3/kB3P/AGFdS/8AS2ai4/4mnjL+z5+bTTbSG9MJ5WaaSRxGx/65+QxAOQWkVsBo1NHg3/kB3P8A 2FdS/wDS2ajQ/wB/4l8T3MnzTRXcNkjdMQpbxyquPZ55Tnr82M4AAANi+v7PTLOS8v7uC0tY8b5p 5BGi5IAyx4GSQPxqvpmu6Prfm/2Tqtjf+TjzPslwkuzOcZ2k4zg9fQ1j/EGb7P4TM/2mC18vULB/ PuBmOLF3CdzjK/KOp5HA6jrWPe63can4fnFr4v0q9m/tDTohPoaBHtxJdxq27MsoO4EgAjBwwIYH FAHoFRzzw2tvLcXEscMESF5JJGCqigZJJPAAHOa8/dbnT7jUZYdU1Jk0zXbCxtIpbt5FSKY2vmh9 xJlLee4BkL7ONm3Fc+/iK9+z66tnd3cYbw5qF27vqUs86XEYj2+YpRUtp08xt0URwpYZAATIB7BH PDM8yRSxu8L7JVVgSjbQ2G9DtZTg9iD3omnhtkDzyxxIXVAzsFBZmCqOe5YgAdyQKw/D3/Ic8Wf9 hWP/ANIrWuTtLtbvwVZSvqN3dag17o76lFM7Otvdm7h81OR+7fdw0IICYXCJu+YA9IhnhuULwSxy oHZCyMGAZWKsOO4YEEdiCKkryvUdVvVgsRd3saae17q6yy3msy6anmJelYU+0RgtkJ5gWPgEKT/A MSahNrA07Vr671e+F9pfhS0vlWF3gja8AuiZWjKqesYzGwCkcOh2qFAPTIZ4blC8EscqB2QsjBgG VirDjuGBBHYgisPWP+Jf4j0XU4/kW4lOn3bnhDGyO8ZY/wB4SqiIScDz3AGXFU/h7FaW+hX9va3E kpi1jUElEly8zRsLmTAJZiQduxsd9245LEm545+TwNrVyvE1naPewN/cmhHmxtjvh0U4PBxggjIo A6CiiigAooooAKKKKACiiigAooooAKKKKACuf8Zf8gO2/wCwrpv/AKWw10Fc/wCMv+QHbf8AYV03 /wBLYaAPP/D3/J0Piz/sFR/+g2tewV4/4e/5Oh8Wf9gqP/0G1r2CgAooooAKKKKACiiigAooooAK 8f8AhB/yUP4nf9hUf+jbivYK8f8AhB/yUP4nf9hUf+jbigD2Cuf8G/8AIDuf+wrqX/pbNXQVz/g3 /kB3P/YV1L/0tmoAp69pOm6z460S31TT7S+gXTL51juoVlUN5toMgMCM4JGfc1c/4QTwf/0Kmh/+ C6H/AOJovP8Akoejf9gq/wD/AEbaVc1LxLoOjXC2+qa3ptjOyB1jurpImK5IyAxBxkEZ9jQBT/4Q Twf/ANCpof8A4Lof/iaP+EE8H/8AQqaH/wCC6H/4mthL+zkvGs0u4GukzuhEgLrgITlevAkjJ/31 9RVigDn/APhBPB//AEKmh/8Aguh/+Jo/4QTwf/0Kmh/+C6H/AOJrYmv7O3+0efdwRfZohPPvkC+V Gd2HbP3V+RuTx8p9DUkc8MzzJFLG7wvslVWBKNtDYb0O1lOD2IPegDD/AOEE8H/9Cpof/guh/wDi aP8AhBPB/wD0Kmh/+C6H/wCJroKjhnhuULwSxyoHZCyMGAZWKsOO4YEEdiCKAMP/AIQTwf8A9Cpo f/guh/8AiaP+EE8H/wDQqaH/AOC6H/4mugqOGeG5QvBLHKgdkLIwYBlYqw47hgQR2IIoA5/wNBDa +G5Le3ijhgi1PUEjjjUKqKLyYAADgADjFdJXE+Gtb+yadeQfZ9+3VdR+bfjObyY+ldJp+rfb7hov I2YXdnfnuPb3oAo+BP8Aknnhr/sFWv8A6KWugrn/AAJ/yTzw1/2CrX/0UtdBQBz/AIN/5Adz/wBh XUv/AEtmo8Pf8hzxZ/2FY/8A0itaPBv/ACA7n/sK6l/6WzUeHv8AkOeLP+wrH/6RWtAHQVj2XijR 76fWoor6Af2NL5V67SptjwgcsTnhRllJOMNG4/hrYri7zSNTmfxGqWEhD6xY6lbN5keLlIVtS6J8 2Q+bdwN+0ZZecZIAOssb+z1OzjvLC7gu7WTOyaCQSI2CQcMODggj8Kpw+IdNutZTS7W5juZyk5do XV1iaFoldHwcq4MycY9c44zX8O212kusX93ayWh1G9FxHbysjSRqsEMWH2FlyTESMMeCOhyBxcXh PVrvTodKbR/slxbeFLnQ31GZ4vLuJGEKx7SjNJ5eUkYblBAboCSKAPQLXXdHvtOn1Gz1WxuLGDd5 1zDcI8ce0bm3MDgYBBOegoutd0ex06DUbzVbG3sZ9vk3M1wiRybhuXaxODkAkY6iuPTQdXu7bUL+ aLVZbtpdPdU1Oa0E0iWtyZyiLbgRjIZgpZ+WODsUBjqSwaha6lpetw+H5CEt7yKWws5YfNRp5YpA 7FmRCf3TF8MfnfguMtQBsa54h03w9ZS3F/cxq6W81wluHUSzrEhdxGpI3EKM+3fFWJNW02HVIdLl 1C0TUJk3xWjTKJXXnlUzkj5W5A7H0rzvUvCerWnhK50j+x/7XkuvDVrpS/Z3i2RXECzYdvOZPl3S oVKgkbCSAQM6l54d1WXxZeEnUn0+81O11ACCW2S1XyVg/wBaWUzb90GcJ8pGwblyxUA7yuf8d/8A JPPEv/YKuv8A0U1dBXP+O/8AknniX/sFXX/opqAOgooooAKKKKACiiigAooooAKKKKACiiigArn/ ABl/yA7b/sK6b/6Ww10Fc/4y/wCQHbf9hXTf/S2GgDz/AMPf8nQ+LP8AsFR/+g2tewV4/wCHv+To fFn/AGCo/wD0G1r2CgAooooAKKKKACiiigAooooAK8f+EH/JQ/id/wBhUf8Ao24r2CvH/hB/yUP4 nf8AYVH/AKNuKAPYK5/wb/yA7n/sK6l/6WzV0Fc/4N/5Adz/ANhXUv8A0tmoALz/AJKHo3/YKv8A /wBG2lV20u9n+Id5ex319Z2qafZAiGOMx3JWW5LIzOjHgEZ2FSA/XkYsXn/JQ9G/7BV//wCjbSrF /wCI7LSrq8jvX2x20VtIfKjklkJnleJBsVDnLIANpJJJyAACwBw/iC28SSeKNVnsVvkRfNjin8qR 1jt2GlmXywpDHKrckLGQ5ZX2HeM11ngqO9i0aZbu7u7mP7Qxt3uraWBhHtXICzSPMRv38yHPJwNg TMa+O9JfXLfTh56RvaXFzPPcW8sItvK2ErKHQbMq5bLFcDYekiE7Gma1Zav5otWnWSLBeG5tpLeR Qc4bZIqttOGAbGCVYA5BwAeV+J9H8Q3mg6xrx0WRhqVvc5t7aeY3eyeOFIkNusYKupt7bzB5jDAm 4YMAND7BPaR6+umjxBBBc6nbTPcTLfTMLc2abW27hM580FGEbq6/LvOxNh7RvGugpBJMbqfy02FC LOY/aAzrGrQ/J++Us6DdHuHzrzhhmS88T2kXhXVdctEknGn280slvKjwSBkTfsdXUMhIwRlejA4I IyAcXpT621tCPESeI0mjieLT1sVlVxMtzOv7zazof3YtcG4d4zydzAyMZG03xHp2lyXWitqX9qXW p6siQuf3UcbfbJIT5bDywGlELCRhk7wN2wha6DTPHFjNYXt/qWo+H4rS1eFHm07VftioZH2L5h8t PLG7GCcjqTgDNamj+KNJ12V4rGafzE3/ACXFpLbltjbH2iRV3bW+VsZ2kgHBIoA4exh1WK1/fX2u XWiG7j+1+XZ31vMq+VNny/Mle6P7z7NnZhQBxkGXHWeBYLu28LKl9FdxXBvb12W7VFlO66lYFtny ZIIOV+U5yOMVIfGOkyKPs0+5mlhSMzxSxJMskqRb4mKESrmRcMmV+ZMsoYNWhoWp/wBt+HtM1byf J+3WkVz5W7ds3oG25wM4zjOBQBwejf6m/wD+wrqH/pXLXT+Hv+P+T/rkf5iuY0b/AFN//wBhXUP/ AErlrp/D3/H/ACf9cj/MUxkvgT/knnhr/sFWv/opa6Cuf8Cf8k88Nf8AYKtf/RS10FIRz/g3/kB3 P/YV1L/0tmo8Pf8AIc8Wf9hWP/0itaPBv/IDuf8AsK6l/wCls1Hh7/kOeLP+wrH/AOkVrQB0FFFF AEc88Nrby3FxLHDBEheSSRgqooGSSTwABzmsN/GugxRK891Pbs8ohSG4s5opmdldlAjZA53CNwuB 8zKVXLcVoa7pn9t+HtT0nzvJ+3Wktt5u3ds3oV3YyM4znGRXL6Z4QvodasdUmigt5IbtXlU6pc3z tGsFzGMSTAfxXHCBQBhjuYkAAHQWPinRtRvI7W1vPMmfKgGJ1AkAJaJmIAWYAEmIkOACSoAqvJ4x 0k6dqF1bT7vslpJdqZ4pYo5o0GS8blD5kf3cvGHADKedy5r2vhu8g/sndJAfset3uoSYY8xzfato HH3h56ZHThuTxnn5vAmv3X9pNdX8Es1zol7poklvJ5PNmm8vE21spCrFDmONcJgAFxgIAdxo2p/2 vYyXPk+Vsu7m227t2fJmeLdnA67M47Zxz1rQrL0DTZtK06W3naNne9u7gFCSNstxJKo5A52uAffP XrWpQAVz/jv/AJJ54l/7BV1/6Kaugrn/AB3/AMk88S/9gq6/9FNQB0FFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFc/wCMv+QHbf8AYV03/wBLYa6Cuf8AGX/IDtv+wrpv/pbDQB5/4e/5Oh8Wf9gqP/0G 1r2CvH/D3/J0Piz/ALBUf/oNrXsFABRRRQAUUUUAFFFFABRRRQAV4/8ACD/kofxO/wCwqP8A0bcV 7BXj/wAIP+Sh/E7/ALCo/wDRtxQB7BXP+Df+QHc/9hXUv/S2augrn/Bv/IDuf+wrqX/pbNQAXn/J Q9G/7BV//wCjbSjU/DH9o6pcXv2zy/O/s/5PKzj7LctP1z/Fu2+2M89KLz/koejf9gq//wDRtpWf 438SaxoWRpMdi2zSr7UJGu1dsfZ/KIACkZ3eYVwSMZDZO3awAX/gX+0Na1K7k1Hba6lFdW9zCsHz iOeC3iOx92AwNsGyVIO4jHGa2NJ0m8tdRu9S1K9gur65iityba2MEaxxmRl+Vnc7syvk7sY28DBJ 5++8U67aW8mnw2sF7q66qNNEsEACPm1F1vETzL0X5MGUdN2f4KjbxZr5tbWdoNNthCjnUd7LMIis rxgy+XKTboxjPzgThDv34ERZgCO3+GKQapBfDUYBJF5as6WCrJcBLmCcPNIG3STN5BDOTgl9wVSG 3dBe+GPtml+KbL7Zs/t7f8/lZ8jdbRwdM/N/q93brjtmsPVfF2tafe3GF037NLcfY7AFSwml3+Xh JVkIeUNwYXWHnf8AvNsTPVfTPHOr6g81k6aba3di9213PdELEy2627Mh8uWQQn/ScF98mzyySpJ2 qAdJNo2sajYm21bVLGXbd2tzG1pYPDjyZllKkNM+d2wDIxjk89KNM8Mf2dqlve/bPM8n+0Pk8rGf tVys/XP8O3b75zx0rl9F8deItWbT7oaVB9gP2GK7kHlonmXEUMhKyPOGXHnqAgicttADZf5bnjzU NVsb8vb3ka2MGhalfNbASI0ksSIqkyRyKQP33A7YJ+9saMAjt/hikGqQXw1GASReWrOlgqyXAS5g nDzSBt0kzeQQzk4JfcFUht3YaFpn9ieHtM0nzvO+w2kVt5u3bv2IF3YycZxnGTXn8fjDxFam/gsL L7bHp8t5dXMs7x4Mf226REMkk0fkqqwEbsSAA/dAUBvUKAPM9G/1N/8A9hXUP/SuWun8Pf8AH/J/ 1yP8xXMaN/qb/wD7Cuof+lctdP4e/wCP+T/rkf5imMl8Cf8AJPPDX/YKtf8A0UtdBXP+BP8Aknnh r/sFWv8A6KWugpCOf8G/8gO5/wCwrqX/AKWzUeHv+Q54s/7Csf8A6RWtHg3/AJAdz/2FdS/9LZqN L/0bxp4gs05jmitNQYnqJHEkBA/2dtrGQOuS3OCAACvrniy40jUdRhj0r7Ra6bp8epXdwbgJtiJm DKq4JaTEJKjhTzlkwN1PUvHjaQ7WupWNpYXjvCYReagscCpKszL50u0iN8W8oKqHG4oAzBiV3NS8 N2eqf2v58k6/2rp66fPsYDbGPNwVyDhv3zcnI4HHXMepeF7bUNUbVBd3drfhIVingKEwmPzgGUOr KSVuJVO4EYIwAQDQBjy/ECE6Jp+oQJpqJdvOhuL3URBZhoX8tgs4RtxZgWQbRuRWb5cYq4PFsreI 4dJNhBBI2wNb3V8kd425AxeKHBWWNMkMwk6xygBio3aE2hSvZ20UGuarbTw7t10kiO8u45bcsiNH ycEYUbfuptUlTXXwjZxfY4Iby+j0y18gppvmh4S0O3yjllMg2mOM4VwpK5IO5twBlxfEK2juNTiv YrQPY2VxfPBY36XM8SQlQ6TIABHL84AUM4JDjd8oJkuvGtxpS6qmsaXBZzWEVo/mC+DQObiV4kPm FQVjUqNzMoI+bCkKC0n/AAgtjBbyqsl3eoumT6Zb2V1c7IEt5AmIQUXKgeWB5nzPgncXwuK+k+EL 6Y6nc6/dyNd3iWqh47rz2R7eR5I5Q3lRopDOvyCPb+7y24u1AGp4f8S/8JHpN9PZLYzXVpK1ufs1 751tJJ5auu2YJkrh1BOzIIYYOMnk9I8Ua5No8F1d3cn2u8TRrwqDE0UUd3dmNo4wIlYDYv8AGzkb sBiV3N6Bptg2n27RyX13eyu5d57plLMcADAUKigAAYVQOpOSSTj2/grTba1t7dJ7spBb6fbqS65K 2cpliJ+XqWOG9R0x1oAp2Hj6zvvFC6Opsf3t3PZxxpfB7tZIRJuaSDb8kZ8p8NuJOY+BuO3Q8d/8 k88S/wDYKuv/AEU1WLPw+ljqLXEOoXwtTLJOlhvUQpLIWZ2yFDtlnc7WZlBbIA2rtr+Mf9J0P+x1 5k1mVdP2jgmN8mcqegZYFmcE8ZUDBJCkA6CiiigAooooAKKKKACiiigAooooAKKKKACuf8Zf8gO2 /wCwrpv/AKWw10Fc/wCMv+QHbf8AYV03/wBLYaAPP/D3/J0Piz/sFR/+g2tewV4/4e/5Oh8Wf9gq P/0G1r2CgAooooAKKKKACiiigAooooAK8f8AhB/yUP4nf9hUf+jbivYK8f8AhB/yUP4nf9hUf+jb igD2Cuf8G/8AIDuf+wrqX/pbNXQVz/g3/kB3P/YV1L/0tmoALz/koejf9gq//wDRtpWxc2Fnebvt VpBPuieA+bGGzG+N6c/wttXI6HAz0rHvP+Sh6N/2Cr//ANG2ldBQBTudJ029t7m3u9PtJ4Lpw9xH LCrLMwCgFwRhiAiAE/3R6Co5dC0eb7D5ulWMn9n4+xbrdD9mxjHl8fJjavTH3R6VoUUAZ76Fo8l5 dXkmlWL3V3EYLmZrdC80ZABR2xllwAMHjgVn6l4Rsb6K0itZP7MjtZVnRLS0tiPMRVSN8SxPhkVQ qlcEDjoBjoKKAMu08N6LZPYSwaXaCfT7dbW0naIPLDEqlQiyHLYwSOvc+pq5c2FnebvtVpBPuieA +bGGzG+N6c/wttXI6HAz0qxRQBnzaFo9xLbSzaVYySWsrT27vboTFIzb2dSR8rFvmJHJPPWtCiig DzPRv9Tf/wDYV1D/ANK5a6fw9/x/yf8AXI/zFcxo3+pv/wDsK6h/6Vy10/h7/j/k/wCuR/mKYyXw J/yTzw1/2CrX/wBFLXQVz/gT/knnhr/sFWv/AKKWugpCOf8ABv8AyA7n/sK6l/6WzVY1uxuDLbat p0fmajZZVYywAmgdkM0XOBuIQFTlcOi5YKWBr+Df+QHc/wDYV1L/ANLZq6CgCvY31vqNnHdWsnmQ vkAlSpBBIZWU4KsCCCpAIIIIBFWKx77QEkvJNR0yf+zdTkx5txDErC5AACrOpH7xRgc5VwMhXXcc 1/tPjCP5P7K0O428ed/ac0Pmf7Xl+Q+zPXbubHTcetAHQUVz/wBs8Yf9ALQ//BzN/wDItH2zxh/0 AtD/APBzN/8AItAHQUVycmveKotZttLbQNG8+4t5rhGGsS7QsbRqwP8Ao2c5lXHHY9O9z7Z4w/6A Wh/+Dmb/AORaAOgorn/tnjD/AKAWh/8Ag5m/+RaPtnjD/oBaH/4OZv8A5FoA6Cufsf8Aifa5HrA+ bS7WIpp7HpNI+RJOB3UKFSNxgkPMRlHVif2Bcav83iWeC8gPI0uKIfZFPUb9wLTMuSMnahwreWrK COgoAKKKKACiiigAooooAKKKKACiiigAooooAK5/xl/yA7b/ALCum/8ApbDXQVz/AIy/5Adt/wBh XTf/AEthoA8/8Pf8nQ+LP+wVH/6Da17BXj/h7/k6HxZ/2Co//QbWvYKACiiigAooooAKKKKACiii gArx/wCEH/JQ/id/2FR/6NuK9grx/wCEH/JQ/id/2FR/6NuKAPYK5/wb/wAgO5/7Cupf+ls1dBXP +Df+QHc/9hXUv/S2agC5qvh/T9ZuLe4u/taz26OkUlrezWzBXKlgTE6kglEODnoKp/8ACG6X/wA/ Wuf+D29/+PV0FFAHmf8AY0f/AEEtc/8AB3ef/HaP7Gj/AOglrn/g7vP/AI7XT/8ACPXf/PSD/vo/ 4Uf8I9d/89IP++j/AIUxnMf2NH/0Etc/8Hd5/wDHaP7Gj/6CWuf+Du8/+O10/wDwj13/AM9IP++j /hVOOwll1m50tWTz7e3huHYk7SsjSKoHGc5ibPHcdewBif2NH/0Etc/8Hd5/8do/saP/AKCWuf8A g7vP/jtdP/wj13/z0g/76P8AhR/wj13/AM9IP++j/hQBzH9jR/8AQS1z/wAHd5/8do/saP8A6CWu f+Du8/8AjtdP/wAI9d/89IP++j/hR/wj13/z0g/76P8AhQBg2NjBp1qLe3Egj3u5MkrSMzOxZiWY kklmJyT3re8Pf8f8n/XI/wAxR/wj13/z0g/76P8AhV7StKnsbppZXjKlCvyk56j29qAK3gT/AJJ5 4a/7BVr/AOilroK5/wACf8k88Nf9gq1/9FLXQUhHP+Df+QHc/wDYV1L/ANLZq6Cuf8G/8gO5/wCw rqX/AKWzV0FABRRRQAUUUUAeZ698SvCWj/Ea0TUNTkt3sLK8trlXs58pI8lsyD7nIKxsQwyCADnk Z9Mrw/xx4C/tj4/eHbgWX+gX0S3N5IyeckjW5+dXUn5VK+RHkgL846nIPuFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFc/4y/wCQHbf9hXTf/S2Gugrn/GX/ACA7b/sK6b/6Ww0Aef8A h7/k6HxZ/wBgqP8A9Bta9grx/wAPf8nQ+LP+wVH/AOg2tewUAFFFFABRRRQAUUUUAFFFFABXj/wg /wCSh/E7/sKj/wBG3FewV4/8IP8AkofxO/7Co/8ARtxQB7BXP+Df+QHc/wDYV1L/ANLZq6Cuf8G/ 8gO5/wCwrqX/AKWzUAdBWHP4iaS4ltdI0u71OWNzFJMm2K3icHGGlcjcAwYN5QkKlWBXOAS8nm1f VJ9GtZZILe3RGvrmJiH+fJEEbD7jlQGZshlV028uHTYgghtbeK3t4o4YIkCRxxqFVFAwAAOAAOMU AYf2zxh/0AtD/wDBzN/8i0fbPGH/AEAtD/8ABzN/8i10FFAHP/bPGH/QC0P/AMHM3/yLWfDb+MIv EN7q39kaGftNpBbeV/a83y+U8zbs/Zuc+djGONvfPHYUUAc/9s8Yf9ALQ/8Awczf/ItH2zxh/wBA LQ//AAczf/ItdBRQBz/27xZH88ugaU8a8stvq7tIw7hA9uqlvQMyjPUgc1YsfElndXkdhdRz6bqU mdlnfKEeTAJPlsCUlwvJ8tm25G7B4rYqnqumw6vpdxYTtIiTJgSREB4m6q6Eg7XVgGU9iAe1AFyi svStSmnuLjTb9Y11K0RHlMQPlyxuWCSpkkqGKOChJKlSMsNrtqUAc/4E/wCSeeGv+wVa/wDopa6C uf8AAn/JPPDX/YKtf/RS10FAHP8Ag3/kB3P/AGFdS/8AS2ajxmX/AOEfSOOeeHztQsYXeCZon2Pd xIwDqQwyrEcEdaPBv/IDuf8AsK6l/wCls1HjL/kB23/YV03/ANLYaAD/AIQ3S/8An61z/wAHt7/8 eo/4Q3S/+frXP/B7e/8Ax6ugooA5/wD4Q3S/+frXP/B7e/8Ax6j/AIQ3S/8An61z/wAHt7/8eroK KAObPgbRWuEuGl1kzojIkh1u93KrEFgD5uQCVUkd9o9Kk/4Q3S/+frXP/B7e/wDx6ugooA5//hDd L/5+tc/8Ht7/APHqP+EN0v8A5+tc/wDB7e//AB6ugooA5/8A4Q3S/wDn61z/AMHt7/8AHqr6HaDT PGWsWEFzfSWq6fZTKl3ezXO12kuQxBlZiMhF6egrqK5RtQhsPiHq3mq536VY42gdpbv396AOrorO ttZt7u4WCNJQzZwWAxwM+taNABRRRQAUUUUAFFFFABRRRQAUUUUAFc/4y/5Adt/2FdN/9LYa6Cuf 8Zf8gO2/7Cum/wDpbDQB5/4e/wCTofFn/YKj/wDQbWvYK8f8Pf8AJ0Piz/sFR/8AoNrXsFABRRRQ AUUUUAFFFFABRRRQAV4/8IP+Sh/E7/sKj/0bcV7BXj/wg/5KH8Tv+wqP/RtxQB7BXP8Ag3/kB3P/ AGFdS/8AS2augrn/AAb/AMgO5/7Cupf+ls1AB4R/e2OpXr83Fzqt55r/AN7ypmgTjoMRwxrx125O SSTT8V+JJtG1nS7JdZ0bSILq3uJXudUjLKWjaEKi/vYxkiRj1P3elXPBv/IDuf8AsK6l/wCls1Sa xo+pXWs2OqaXqNpaT2tvPbst1ZtOrrK0TZG2RCCDCO56mgCuPFENno2l3MlxHrcmoXDW0E2jQgxz SBZHAAMjBRiMqWLkA8sVXJUt/GljO6BrLUoo2eWDzWt9w+0RK7SQKqks7qI5PmQMhKlVctxVx9Jv LttFnv72CS6067e5doLYxpLmKWIKFLsVwJQc5OdvbPGfN4O8/Trez/tOeHytQvb3zrddkg+0C5GE bJ2sv2nIbnlOgzwASSeKgIpEmsrvTryK4s0e3ukjkby7icRIw8uQrgkOPvZXaSVIwGk07xJv8DaV r9/Hma8tLaQw26/fmmCBUTceMu4UbjgZ5IGTWPp/w7Sxe8kS5sYGu5bCV4rDTVtoUNrcGX5UDE/O CASzMQcnOMIuwnhjy/BenaALz95p8VqIrkxcNJblGRmTP3S0a5UMDgkBgeaAKfiXxbNpGh2epR28 luJXuFnjurctJF5VrcSnCh1DENCBw21hna2CGrQuPFFtbao9obS7eCG4itJ71QnlQzybPLjYFg5J 82LlVKjeMkYbbT8Q+E7jxHoEGn3eq/6Qn2gyXAtxhjLbzQ4VARhV8/IBJOEAJJJao7jwPbT+LH1s LprGa4iuZHn01JbpXjVFURTMcImI142EglyGUkFQCxB4ytrm4aGHTdSb/SLizhkaNFWe4hMm6JCz jJKxOwY4TjBYMCoueFNWuNe8JaTq13bfZ7i8tI5pIxjGWUHK4ZvlPUZOcEZwciq9v4Y+z/2b/pm7 7Fqt3qX+qxv8/wC0fJ142/aOvOdnQZ4ueG9Km0Pw1pukz3Md09lbpbiZIjEHVBtU7SzYO0DPPJye OgAKes/6N4q8NXicyTS3GnsD0EbwtOSP9rdaxgHpgtxkgjoK5/xD/wAhzwn/ANhWT/0iuq6CgDn/ AAJ/yTzw1/2CrX/0UtdBXP8AgT/knnhr/sFWv/opa6CgDn/Bv/IDuf8AsK6l/wCls1HjL/kB23/Y V03/ANLYaPBv/IDuf+wrqX/pbNR4y/5Adt/2FdN/9LYaAK/xBtvtnhM2u2BvO1CwjxcRebGc3cI+ dMjcvPK5GRxkVy/jnTE8PeAEsoLXSoWn+3mf7Bp628bH+z7shlQlijYVQWDZIBGcEivUKKAPP9G1 /XbvxzJaXN/YiH7Xcwyab54aaKBC4jl8lYQ8e4LG295ShEnABdAM/wAWLKvjPVEi1bZdTRaG9vbT IjIuNRK7toCuyq2Cfm/5akE/c2+gQ67o9xLcxQ6rYySWsqwXCJcITFIzbFRgD8rFvlAPJPHWga7o 7SwxDVbEyTRJPEguEzJG7BEdRnlWZlUEcEkAcmgDg9X1/XLKW50qPWJFNpevAt7MIopLj9xbyrHu EEitKTO4WJIdzhOCCjCS58MNRl1Ua5fXWoedeXktpeS2w2AQ+bZQOCoA3BTkoNxPEQ5Lbi3UWHin RNQntrWLVLEX9xEkq2X2uJ5gGQSD5UY5+U5ypII5BI5on8UaPGs3k30F3Jb3cFncRWsqSPDJLKIl DgH5fmPOeflPBIxQBxeoeKvFek2V1N5Md0dJQWFwTEGNzdskvlvsT5su32EhU4UXTqclcx5+meK9 fbS9QtLzxNpryW6Wkg1dJl8hzJ5wcLcfZhFGm6EAExyDcWj372Gz0iy8Q6be2t3cfaY4Es3mFwJ3 VTEsUskRdueELQyEE9lPTBA1KAMvw5eNqHh+zunuJLjzEJEskSozrk4J2koxxj50+R/vJ8rCuW1j /koeof8AYKs//Rt1Xe1wWsf8lD1D/sFWf/o26oA0dG/5C0H/AAL/ANBNdZXJ6N/yFoP+Bf8AoJrr KACiiigAooooAKKKKACiiigAooooAK5/xl/yA7b/ALCum/8ApbDXQVz/AIy/5Adt/wBhXTf/AEth oA8/8Pf8nQ+LP+wVH/6Da17BXj/h7/k6HxZ/2Co//QbWvYKACiiigAooooAKKKKACiiigArx/wCE H/JQ/id/2FR/6NuK9grx/wCEH/JQ/id/2FR/6NuKAPYK5/wb/wAgO5/7Cupf+ls1dBXP+Df+QHc/ 9hXUv/S2agA8G/8AIDuf+wrqX/pbNWXqOsalo3iXxXqEs8dzp+naFBeRWQVkO4G4P39xAJ8tgSE5 BT+582p4N/5Adz/2FdS/9LZq0JtE0641G4vp7fzZrm0FlOruzRywgsQrRk7G5duSM4YjOCRQBT0e /wBS/tm+0jVJbS4ntreC6W4tYGgUrK0q7CjO5yDCTu3c7gMDGTl3HiTWI/DniHXo47E2tlFf/Zom V96SWzug3nOJFcxluNhXhfnzuHQaZotlpHmm1WdpJcB5rm5kuJGAzhd8jM20ZYhc4BZiBknNeTwt o039oCSz3LfxSQzr5r7dkn+sCDOI95+Ztm3cwDHJANAHN614t1zSb17IWsc15bWSX0lvaabc3YuC 7yhYFkTiIgRbfNcEMW3bFClauaz4qutM8Qx26PBLa/a7a0eCKynlbMzom57kfuoWHmBvLYElQvI8 wbdzUvD2matcLPeQSM4QRuEnkjWZASQkqqwEqct8rhh8zcfMcx3vhbRtQ1Fb+6s/MnWWOcfvXCCW MqUl2A7fMG1V343FRtJ28UAcXY+Jtc0+zt7G4vo5ru5vdUcXSaTc3mxILry/L8mOQuAS+Q27CKqp gnDV3EGqzSeFYtXuLaOxnayF1Jb3kpiWBtm4pI5XKhTwW28YJx2qu/hHR2R1WO7iLXEtz5kF9PE6 vK26QK6uGVGYBigIUkA4yM1qfYLP+zv7O+yQfYfK8j7N5Y8vy8bdm3ptxxjpigDg4PGeuXGrW+jW 4tJrua4iQ3N1plzYqqSQ3T8QyMXYqbbOdwD7ivyEFx2Hh/UptV0nz7hYxPHcXFrIYwQrtDM8RcAk lQxTdtycZxk4ya9n4Q0Owv0v4LSQ3iurm4luJZZHZUlRS7OxLkLNIoLZ4IHRVxqWdjb6fA0NrH5c bSyTEbicvI7SOefVmY+2eOKAMfxD/wAhzwn/ANhWT/0iuq6Cuf8AEP8AyHPCf/YVk/8ASK6roKAO f8Cf8k88Nf8AYKtf/RS10Fc/4E/5J54a/wCwVa/+ilroKAOf8G/8gO5/7Cupf+ls1HjL/kB23/YV 03/0tho8G/8AIDuf+wrqX/pbNR4y/wCQHbf9hXTf/S2GgDoKKKKAPO38Cale6dpOm366a9ppFvBY oDI0gvYVuLWR2kQoBGSlrjZlwTJgsAMmPXbG6uPFEmn2tn9oWbW7HVTNLYz/ALoxCBXVJCgiGI4m bzPMyctGEyc1nr8RtRvzKukX+lXklxd2strGtwoKW7XvklWCq5TdG1qSHAcGeUjlPLXYtPGet2ui o95pkF3qEuoX0SRwzSyBYoZ2TpFA0h2nCg+XtwAWZWdVIBJovgrUtN8KjS5p7Rpxe6Xcbkdiu22S zWQcrnJNs+OO65xk4z4Ph7rMeoafM9zaeVZpDFj7VO4k8u7tZjIkbfu4AywOBDGoVDtG5gRs6TR/ Flx4haO60rSvM0z9wJpJbgJOhlijmBWPBVlVJkLHzAeHwGwu7D034gX1p4T0m81nTJHub3TIbi3e N973DloImZ0jQ7A0lxGyhA5Kk/KGAQgFiTwpMl3YWriRhd3t62oeRnypLNrh7lFkJGGO5o49hzlJ 7gAEFmHeVx9l4zv77yLeLw9Ot+3nSPDK0kCvFF5W5ojNGjOx89AA6xqWDgsAoZtjwnfXGp+DdDv7 yTzLq60+3mmfaBudo1LHA4GST0oA2K4LWP8Akoeof9gqz/8ARt1Xe1wWsf8AJQ9Q/wCwVZ/+jbqg DR0b/kLQf8C/9BNdZXJ6N/yFoP8AgX/oJrrKACiiigAooooAKKKKACiiigAooooAK5/xl/yA7b/s K6b/AOlsNdBXP+Mv+QHbf9hXTf8A0thoA8/8Pf8AJ0Piz/sFR/8AoNrXsFeP+Hv+TofFn/YKj/8A QbWvYKACiiigAooooAKKKKACiiigArx/4Qf8lD+J3/YVH/o24r2CvH/hB/yUP4nf9hUf+jbigD2C uf8ABv8AyA7n/sK6l/6WzV0Fc/4N/wCQHc/9hXUv/S2agA8G/wDIDuf+wrqX/pbNXQVz/g3/AJAd z/2FdS/9LZq6CgArm/GGpahYw6Xb6ct2Zb+9+zsbIQ+eFEMsuY/OPl5zGAd2flLY5wR0lV76ws9T s5LO/tILu1kxvhnjEiNggjKng4IB/CgDi7K/8Q6td6Lp76nJpxmt9Ra5aNLeWc+RcRRx5Yb4llw3 z4BXJcBVO0pTt/E2sjTNIvLzU/n13ShdiO3tExbymS2RI4Ax+8/2nbulZlD7WIVAyn0CGws7f7P5 FpBF9miMEGyML5UZ25RcfdX5F4HHyj0FRnSdNa3S3bT7QwJbtapGYV2rCwAaMDGAhCqCvQ7R6UAc Po2v3mpX2nW9w0khtPEctiXu1t3nwNPkkYM0OY1cOzLlMHaNp53Z6TwJ/wAk88Nf9gq1/wDRS1qQ aTptqIhb6faQiJw8YjhVdjCPygRgcER/Jn+7x04qT/Q9L07/AJYWdjaxe0ccMaj8AqgD6ACgCxRW XbeINPuhbFftcJurg20K3VlNAzyCNpCAsiKcbUY7unBGc8VqUAc/4h/5DnhP/sKyf+kV1XQVz/iH /kOeE/8AsKyf+kV1XQUAc/4E/wCSeeGv+wVa/wDopa6Cuf8AAn/JPPDX/YKtf/RS10FAHP8Ag3/k B3P/AGFdS/8AS2ajxl/yA7b/ALCum/8ApbDR4N/5Adz/ANhXUv8A0tmo8Zf8gO2/7Cum/wDpbDQB 0FV7+xt9T065sLyPzLW6ieGZNxG5GBDDI5GQT0qxRQBl654e0zxHb20GqQSSpbXC3UJjnkiaOVQQ rhkYEEbj3qu/hDQ5EdHtJGR7iW4ZTcSkMZW3Sofm5idhlov9Wx5KmtyigDDt/CGh2j2rQWkkaWqR LHCLiXyj5ahY2ePdsd1Cph2BYbE5+UYkbwtozWdnamz/AHNlafY7YCVwYosxkbWzkMDDGQ+dwKAg g1sUUAYZ8IaG9ukMlpJIFdmZ5LiV5JtwAZZXLbpUYKgKOWUhEBBCqBqWFjb6Zp1tYWcfl2trEkMK bidqKAFGTycADrViigArgtY/5KHqH/YKs/8A0bdV3tcFrH/JQ9Q/7BVn/wCjbqgDR0b/AJC0H/Av /QTXWVyejf8AIWg/4F/6Ca6ygAooooAKKKKACiiigAooooAKKKKACuf8Zf8AIDtv+wrpv/pbDXQV z/jL/kB23/YV03/0thoA8/8AD3/J0Piz/sFR/wDoNrXsFeP+Hv8Ak6HxZ/2Co/8A0G1r2CgAoooo AKKKKACiiigAooooAK8f+EH/ACUP4nf9hUf+jbivYK8f+EH/ACUP4nf9hUf+jbigD2Cuf8G/8gO5 /wCwrqX/AKWzV0Fc/wCDf+QHc/8AYV1L/wBLZqADwb/yA7n/ALCupf8ApbNXL23hWKSXT5Z9MnMl 34g1EXzsHBe0LXbpG5/592YRNs/1bFgSCWOeo0X/AIluuato7/JHJKdQsl7GOTBlAJ5ZhP5jsOQo mjGQCFHQUAeV6hpV79j0uO6so20u2uNUi+z3mjS6jEn+lD7Ntt4yGAEKuEfG1UO0Y3jNi00m5stb 0k3Nnd6hqSJZq899YObgBUjWRkvY5GSFBh3aFiS7eaMsJVJ9MooA83ewnt/EeoyWejT314/2pmZr eWyuSrI5QG/V/LljJKIkY+aMNGxw0Jxn6fp1+LbXIYdL8rSW/s2UQ2ejyWENxEty5usW7MzMxiXa wIDOoUbWBQt6xVe+sLPU7OSzv7SC7tZMb4Z4xIjYIIyp4OCAfwoA8f8A7OE2q6g0Gl+XoUeoTD7J qGjzaiiO1rYmE/ZkbdH8gl2kgeWp2EIWCjuNc0m4uPhBe6XdQz6hfDRGjKzxiSaWdYflJAL5k3gH hm+boT1rqLGws9Ms47OwtILS1jzshgjEaLkknCjgZJJ/GrFAHl+u6HqirqdvodhPBINVlNj9nTyl jH9imKNkbgIokwgbIAbjINbngSwNpcalNDHHBZyJCqQW+iyaXAJFMhdhFI5YuQyBn2gEKgBYqQva UUAc/wCIf+Q54T/7Csn/AKRXVdBXPr/xO/FEc6/Np2kb/LkH3Zbxg0bYPH+qTep6qWmYcNEcdBQB z/gT/knnhr/sFWv/AKKWugrn/An/ACTzw1/2CrX/ANFLXQUAc/4N/wCQHc/9hXUv/S2atDWtJTW9 MNlJcz2372KZJoNu9HjkWRSNysv3kHUGs/wb/wAgO5/7Cupf+ls1dBQBz/8Awj2qf9Dnrn/fmy/+ R6w9QttctL6SCPxfq5VcYLQWeeQD/wA+9d5XPanpl5cahLLFDuRsYO4DsPegDm/+J/8A9Ddq3/fi z/8AjFH/ABP/APobtW/78Wf/AMYrZ/sbUP8An3/8fX/Gj+xtQ/59/wDx9f8AGmM5ea98Rx+ILOwH i3U/KmtZ5mJt7PcGR4gMfuOn7xs/QVf/AOJ//wBDdq3/AH4s/wD4xTbrSb4eN9KjMHzHTbwgb16C S2z39xW3/Y2of8+//j6/40AY3/E//wChu1b/AL8Wf/xij/if/wDQ3at/34s//jFbP9jah/z7/wDj 6/40f2NqH/Pv/wCPr/jQBjf8T/8A6G7Vv+/Fn/8AGKZbWM8eo3F/eand391NFHCXuFiXaiFyoAjR R1kbrmtz+xtQ/wCff/x9f8aP7G1D/n3/APH1/wAaADRv+QtB/wAC/wDQTXWVz2maZeW+oRSyw7UX OTuB7H3roaQgooooAKKKKACiiigAooooAKKKKACuf8Zf8gO2/wCwrpv/AKWw10Fc/wCMv+QHbf8A YV03/wBLYaAPP/D3/J0Piz/sFR/+g2tewV4/4e/5Oh8Wf9gqP/0G1r2CgAooooAKKKKACiiigAoo ooAK8f8AhB/yUP4nf9hUf+jbivYK8f8AhB/yUP4nf9hUf+jbigD2Cuf8G/8AIDuf+wrqX/pbNXQV z/g3/kB3P/YV1L/0tmoA0NT0lNS8qVLmezvIciG7ttvmRhsbl+ZWVlbAyrAjIU43KpFODX1tLiLT tdaO0vncRxTFWS3u2JwvlueA7c/uixcENjcoDtuVHPBDdW8tvcRRzQSoUkjkUMrqRggg8EEcYoAk orn/APhBPB//AEKmh/8Aguh/+Jo/4QTwf/0Kmh/+C6H/AOJoA6Ciuf8A+EE8H/8AQqaH/wCC6H/4 mvN/DI8J638ZvE/h+PwtoctjaWiLC4sEUI8LbZQUK8sXmILDHES9etAHtFFc/wD8IJ4P/wChU0P/ AMF0P/xNH/CCeD/+hU0P/wAF0P8A8TQBuTzw2tvLcXEscMESF5JJGCqigZJJPAAHOaw/7VvNe/d6 EPKsW+WTVJVK8HnNujLibI6SH938ykebhlqSDwX4VtbiK4t/DWjQzxOHjkjsIlZGByCCFyCDzmty gCvY2Nvp1nHa2sflwpkgFixJJJZmY5LMSSSxJJJJJJNWKKKAOf8AAn/JPPDX/YKtf/RS10Fc/wCB P+SeeGv+wVa/+ilroKAMOfwX4VuriW4uPDWjTTyuXkkksImZ2JySSVySTzmo/wDhBPB//QqaH/4L of8A4mugooA5/wD4QTwf/wBCpof/AILof/iaP+EE8H/9Cpof/guh/wDia6CigDn/APhBPB//AEKm h/8Aguh/+Jo/4QTwf/0Kmh/+C6H/AOJroKKAODuvBfhVfHWk26+GtGED6Zeu8YsItrMstqFJG3BI DMAe24+tbn/CCeD/APoVND/8F0P/AMTXhHxG8CpqPx+sdKth+51zybqZIFWIxJlhMwJ4LYieTOOS 3Qnr9L0Ac/8A8IJ4P/6FTQ//AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTXQUUAc/8A8IJ4P/6FTQ// AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTXQUUAc/8A8IJ4P/6FTQ//AAXQ/wDxNH/CCeD/APoVND/8 F0P/AMTXQUUAc/8A8IJ4P/6FTQ//AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTXQUUAc/8A8IJ4P/6F TQ//AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTXQUUAc/8A8IJ4P/6FTQ//AAXQ/wDxNH/CCeD/APoV ND/8F0P/AMTXQUUAc/8A8IJ4P/6FTQ//AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTXQUUAc/8A8IJ4 P/6FTQ//AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTXQUUAc/8A8IJ4P/6FTQ//AAXQ/wDxNSQeC/Ct rcRXFv4a0aGeJw8ckdhErIwOQQQuQQec1uUUAeP+Hv8Ak6HxZ/2Co/8A0G1r2CvH/D3/ACdD4s/7 BUf/AKDa17BQAUUUUAFFFFABRRRQAUUUUAFeP/CD/kofxO/7Co/9G3FewV4/8IP+Sh/E7/sKj/0b cUAewVz/AIN/5Adz/wBhXUv/AEtmroKw5/BfhW6uJbi48NaNNPK5eSSSwiZnYnJJJXJJPOaANyiu f/4QTwf/ANCpof8A4Lof/iaP+EE8H/8AQqaH/wCC6H/4mgDoKK5//hBPB/8A0Kmh/wDguh/+Jo/4 QTwf/wBCpof/AILof/iaAOgryfwt8LdH0H4q3Woxahqt1dWVpFeLJdzI5lkuDcxyFzsBPCAjock5 JruP+EE8H/8AQqaH/wCC6H/4msO18F+FW8datbt4a0YwJplk6Rmwi2qzS3QYgbcAkKoJ77R6UAd5 RXP/APCCeD/+hU0P/wAF0P8A8TR/wgng/wD6FTQ//BdD/wDE0AdBRXP/APCCeD/+hU0P/wAF0P8A 8TR/wgng/wD6FTQ//BdD/wDE0AdBRXP/APCCeD/+hU0P/wAF0P8A8TR/wgng/wD6FTQ//BdD/wDE 0AHgT/knnhr/ALBVr/6KWugqOCCG1t4re3ijhgiQJHHGoVUUDAAA4AA4xUlABRRWPrd9cCW20nTp PL1G9yyyFQRDAjIJpecjcA4CjDZd1ypUMQAF9r6R3kmnaZB/aWpx4823hlVRbAgFWnYn92pyOMM5 GSqNtOK/2bxhJ8/9q6Hb7ufJ/syaby/9nzPPTfjpu2rnrtHSqfiLUF8I6bo9tYXmm6Xb3F6beS61 INJHGDFNKWYmRCzs6DLM2SXJOSajsfGmywje5T+1Gm1A2Fnc6TDmK9byDMGQF2CqCHiJ3lQyEsVG 7aAaH2Pxh/0HdD/8E03/AMlUfY/GH/Qd0P8A8E03/wAlVJb+KLa51RLQWl2kE1xLaQXrBPKmnj3+ ZGoDFwR5UvLKFOw4Jyu6ODxdZz6O+pizvlt28k2paID7YszBYTGd20b2IGHKsuQXCAg0AZ9z4a8S XeuWGrzazob3VhFNFb50WQhPN2bmGbnIbCYBBHDMOc1ofY/GH/Qd0P8A8E03/wAlUf8ACWQfZc/2 dff2h9r+xf2b+687zvK87bu3+V/qv3md+McZ3fLQ/itBKsUej6rLMkQmu4khXfaIWdQWUsC/McmP KEm7ZlchkLAB9j8Yf9B3Q/8AwTTf/JVH2Pxh/wBB3Q//AATTf/JVSa7rV3pereH7S3sJLiPUb1re aRSn7pRDI+eXU5ym7oflRx94qDl6B48t77w9aahq1vPYs+lf2k8rQkRyoiIZ2jXJfajOo+YDcCCm 8c0AaH9v3GkfL4lggs4BwNUilH2Rj0G/cQ0LNgnB3IMqvmMzAHoKy9K1oalcXFpNYXen3luiSPbX RjLeW5YI4MbuuCUcYzn5TkAEE07H/iQ65Ho4+XS7qIvp6npDImTJAD2UqVeNBkgJMBhEVQAdBRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB4/4e/5Oh8Wf9gqP/0G1r2CvH/D3/J0Piz/ALBUf/oN rXsFABRRRQAUUUUAFFFFABRRRQAV4/8ACD/kofxO/wCwqP8A0bcV7BXj/wAIP+Sh/E7/ALCo/wDR txQB7BRRRQBz+s3usf8ACQ6bpOk3NjbfaLS5uZJbu1ef/VvCoUBZExnzicknoKPsfjD/AKDuh/8A gmm/+SqLz/koejf9gq//APRtpXQUAc/9j8Yf9B3Q/wDwTTf/ACVR9j8Yf9B3Q/8AwTTf/JVdBRQB z/2Pxh/0HdD/APBNN/8AJVU49B8VRazc6ouv6N59xbw27qdHl2hY2kZSP9JznMrZ57Dp36yigDn/ ALH4w/6Duh/+Cab/AOSqPsfjD/oO6H/4Jpv/AJKroKKAOf8AsfjD/oO6H/4Jpv8A5Ko+x+MP+g7o f/gmm/8AkqugooAx/DGoXmp6KZ78wNdR3d1bO0EZjRvKnkiDBSzEZCA4yetbFc14QurePRrpJJ4l YarqOQzgEf6bNXQR3MEzbYpo3YDOFYE0AS0UUUAFc/pf+k+NPEF4nEcMVpp7A9TIgknJH+ztuowD 1yG4wAT0Fc/4e/5Dniz/ALCsf/pFa0AaGo6Z9vvtJufO8v8As+7a527c+ZmGWLbnPH+tznn7uO+Q ajpn2++0m587y/7Pu2udu3PmZhli25zx/rc55+7jvkeZzajrMGk69d3epSS382ma6wngknhWL7LM kMflxeayIRkncAG+7yTuZ+ouvFuoJ4suNPtbWSWC1vbezkgTTbiUyCRYmaX7Sv7qIIJslGBJEZ5G 8YANC18LzW+qW8jX8b6faXtxqFtALciUTTebv3ybyGT9/LgBFI+TLHB3Vx4LaTwm3h671CO5s4Ut 4rOOS1UoiQMrRiVScyliqh+VDAYVUJJMmuTawfGWj2mk3MEPm6fevIbkO8a7ZLbDeWpXew3FRllw HY5ONrY+q+Prq38PWWuW6QRxvpUeqS2S2k93IwZC+xnjAW3X5SBK4YMdx2gRnIBqR+DBD4am0qL+ xk8648+WBdHjFk/AG1oN2SPlVsmTdvAOdo2VXuvAbXNhY2ZvrQpbo6iSXT1aS1LOWLWb7gbcrkKm TIEEcWB8pLXL3XdTtfFC2kggtrEyxxxie0mZbhXCjeLpf3cTbmKLE6lmZAMjzFIw9M+IOoT6Ndax Np8k1oNHl1VVGn3FqsBRVZYDNICkxYOcOgA/dk7SGGADsNX0qbUbrSLiC5jgfT737UQ8RkEimKSJ k4ZdpKykhucEDg9Kx18Dwvo2naXcX0jwWuhTaLI0cYVpFkWFTIMkhSBD0wfve3MmhzawPGWsWmrX ME3lafZPGbYOkbbpLnLeWxbYx2hThmyEU5Gdqx2fiLUptUs5JRaf2ffandabFAsTCWJoPP8A3jSb iHDfZ2+UIuPMHzHb8wBc8MeGU8PfanEelRyXGwMumaatnHhc4JAZmZvmPJbGAMAHcWPGP+jaH/bC 8SaNKuobhyRGmROFHQs0DTIAeMsDkEBhl+GvEWvaqmiG/GmxPq+mDUUEETkQqjQb1JLfMXWbI6eW Rg+b1Op47/5J54l/7BV1/wCimoA6CiiigAooooAKKKKACiiigAooooAKKKKACiiigDx/w9/ydD4s /wCwVH/6Da17BXj/AIe/5Oh8Wf8AYKj/APQbWvYKACiiigAooooAKKKKACiiigArx/4Qf8lD+J3/ AGFR/wCjbivYK8f+EH/JQ/id/wBhUf8Ao24oA9gooooA5+8/5KHo3/YKv/8A0baV0Fc/ef8AJQ9G /wCwVf8A/o20roKAOHv9T1a0k8W60uqztb6FKTHppii8mWNLSGZlLbPMDEu+G34B2nawBU6l14om t9UuI1sI30+0vbfT7mc3BEomm8rZsj2EMn7+LJLqR8+FOBuj1W18I6PrA1TWNQgsri7lE4S81N4o ZpI1RQ/ks4jZlCx87cgqp6gGrDWnhq+1i3vRcwS3Vx5U8ccd63l3B2s0UpiDbJG2xEq5UnEQIPyD ABT0/wAXX15LoMsmjRx6frj5tLhLzeyIYJJl81Cg2uVQDapcfey3C78+f4g3xubmCx0COYwXEcDS TX3loC99NZrnCM2S0QfhSMFsnKqH3P8AhCtB6i1nVl4gZbyYNajutuQ+YFI+UrHtBUBSMACjTvC3 hqK2ddNs4Ft/NQFYJW2K8Fy8yqADhdkzSHaMY+6RgYABl33jyW3tbAW2kST39y90jwjzpEjNtKIZ cNDDI5G8jaSigjk7ThSDxrqUoubmHQY47OG4trTF3dtFcCa4jhaNXiETBQGuEVjvJADEBiAp2Lvw /oZS3t5fMtne4maBoL2W3laSVmmlVXR1chiGcoDj5AcfKMWE8OaRFbyW8VjHFBJcQXJjjJVRJCIx EQAcKFEMQ2jA+XpycgFfwbf32q+CtE1DUzGby5soppWRshyyg7vuqASCCQBgEkAkDJ3Kp6Vpdpou l2+m2CSJaWybIkeV5Cq9huck4HQDPAwBwBVygDzPRv8AU3//AGFdQ/8ASuWun8Pf8f8AJ/1yP8xX MaN/qb//ALCuof8ApXLXT+Hv+P8Ak/65H+YpjOlooopCCuf8Pf8AIc8Wf9hWP/0ita6Cuf8AD3/I c8Wf9hWP/wBIrWgCxL4W0aeCWGSz3RyxXcLjzXGUuXEk46/xMAfbtgVJN4e0y41QajJBIZ96yMgn kEUjrja7xBtjuNq4ZlJGxMH5VxqUUAZeq+HtM1q4t7m9gka4tkdIJ4p5IpIQ5UtsdGBUnYASDnGR 0Yg19S8H6Bq1uttd6bGbcW4tfIjdoo2iAIVGRCAwTJKZB2E5Xaea5fVvEusaKNV1KW7kdI0vRaIY 4JbCV4Y5XSNSjCdZQIjvL/LuSVRjKED6x4mtLO/tzPd2863Gmrby6stpLOPPuvKk3R2zBfK2gAZ2 sSZMNwNoB2E3h7TLjVBqMkEhn3rIyCeQRSOuNrvEG2O42rhmUkbEwflXEdr4W0az88R2e+OaJoDD PK80aRN96KNHJWOM4AKIApCqMYUY5/8AtPVvtf8AYP8Aas+7+2/7P/tDyovtHl/YftecbPL3bvkz sxs7bvmrHsdQ1uC0sNJtTfSTT3es3FxLpEdskhaK+28C5YosZMrEjJbO3BwGyAd5pXh/T9GuLi4t PtbT3CIksl1ezXLFULFQDK7EAF3OBjqaIfD2mW+qHUY4JBPvaRUM8hijds7nSItsRzubLKoJ3vk/ M2cPwRqms63JfXup3sBjj+zxpa2qIY1d7S3lciQFt67nbbg9GbJcFdvYUAZcPh7TLdNOSGCSIadb i1tdk8imOING2zIbLAmGPOc5AIOQSDT8d/8AJPPEv/YKuv8A0U1dBXP+O/8AknniX/sFXX/opqAO gooooAKKKKACiiigAooooAKKKKACiiigAooooA8f8Pf8nQ+LP+wVH/6Da17BXj/h7/k6HxZ/2Co/ /QbWvYKACiiigAooooAKKKKACiiigArx/wCEH/JQ/id/2FR/6NuK9grx/wCEH/JQ/id/2FR/6NuK APYKKKKAOfvP+Sh6N/2Cr/8A9G2ldBXP3n/JQ9G/7BV//wCjbSugoA5fXNLvdQ8ZaPJa319YRxaf eh7q0jjbBaS2whMiOoztY9ATsODgGqeqQalN8StLcRXb6fC9u4YKxiRvI1FXPoD80IJ90B6iu0oo A8/8BQ6+mol9Xvr6WY2n+nwzWc8caXOV+7JLKyNg+aB9nVYyOTgeWKz9NsTp1streR+I49ITUNUN wIGvmmMxuQbdg0eZWjMRkO5SYyxyxLkV2k/i/Q7W4lhmu5EKOYw5t5fLllBwYo327ZZcgjy0LPlW GMqQI38aaInkrvvnml8zFvFpty8ybNm7fEsZdOJIz8wGQ6kZBFAGHrcGrzeHvBr6pFqT3sNxG+qt pygyp/ocyyn5Og3MQTH83OI/nK1h3kPiuV7f/TtVtYRE/wDZe2zubiRm+0TeX5myVFDeT9l/4+8q STuwRLnvPD/ie08RXWrRWaSGKwuEiSfY+ydWiSQOjFQCPmOME5AVs4dc7lABRRRQB5no3+pv/wDs K6h/6Vy10/h7/j/k/wCuR/mK5jRv9Tf/APYV1D/0rlrp/D3/AB/yf9cj/MUxnS0UUUhBXP8Ah7/k OeLP+wrH/wCkVrXQVz/h7/kOeLP+wrH/AOkVrQB0FFFed6xoNzKPF97b2kn2ubU7UK8kLyq9osdm ZwsQI8xGVJA6JzJs2HJCgAHcR6TpsOqTapFp9omoTJslu1hUSuvHDPjJHyrwT2HpUdnoWj6fZmzs tKsba1MqzmGG3REMikFX2gY3AqpB6jaPSuDttKMWh2xu7KS50P8AtgzXFlFo0kEIt/srIFSyJeQp 9o2OQVzvJk27QHMfivR7+81GMLbzxRvpUEOnmfTZNSuba5Bl3mOZZQtvMN0OZXfDFVO/CEgA9Al0 /S9Siv7S506CeGWVTdRz2uUncKhDHcMSYAQbucbcZyuBHJ4a0GbS4dLl0TTX0+F98Vo1qhiRueVT GAfmbkDufWuHvvD2pT+LtfMFtItnrl7HY3xZGxLbrb2zZzj5U8tb2LcpB8yVBnIBSTUdJv5viBPM 6bZG1C1ls510mSaZbZVh8xUu96xwxkrOGjPJDPgMZFBAO4v9Gs7+BomTyt93BeSPCArSSQvG6ljj n/VIp77RjI4wf23p39sf2V9o/wBL6bdjbN23f5e/G3zNnz7M7tvzY281l+DtKXT7PULh7aSK7utT vXkaXduZPtUxjxu6JtbcAMD5yw5Yk82v2+x8UXGoNp99cXTahLNdQ/YZHhtYQFiS4gb5Vkka3jjV lVnkBlYooxJE4B6RXP8Ajv8A5J54l/7BV1/6Kaugrn/Hf/JPPEv/AGCrr/0U1AHQUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAeP+Hv8Ak6HxZ/2Co/8A0G1r2CvH/D3/ACdD4s/7BUf/AKDa17BQ AUUUUAFFFFABRRRQAUUUUAFeP/CD/kofxO/7Co/9G3FewV4/8IP+Sh/E7/sKj/0bcUAewUUUUAc/ ef8AJQ9G/wCwVf8A/o20roK5+8/5KHo3/YKv/wD0baV0FABRRRQBxer+A21i9vZJ760EFw6yMn9n rvuGR1eNLk7ts0SlAANivtG3zBly9zQfB6aLqNteo9jG0cVzG8Fhp62sJMpg5VQSRgW4zuLEljyA Ao6iigDm/B/hebwraT2jX8d3A6WwTFuY2VoreKBiTvIIYQqwGBjJGW7dJRRQAUUUUAeZ6N/qb/8A 7Cuof+lctdP4e/4/5P8Arkf5iuY0b/U3/wD2FdQ/9K5a6fw9/wAf8n/XI/zFMZ0tFFFIQVz+h/uP Evie2k+WaW7hvUXrmF7eOJWz7vBKMdflzjBBPQVz9x/xK/GX9oT8WmpWkNkZjwsM0cjmNT/1089g CcANGq5LSKKAOgrl7jx/oVt4c1rXJZJxa6Ndy2V0giJcTI4Tao6HcWTBzj5hkjBx1FeT6r4D1m7g 1N44MyXEWpuib05cvfCBM7v+Wi35bP8AD5WDy3ygHcar4x0vRdO1e/vvPjtdKu4rW6cJuwZBEQwA OSoE6578NgHjNw6/YjxUnhwNIdQaya+KhflWIOEBJ9SxOAM/dOccZw7zRNRl/tvZb5+0+INPvYvn X5oYvse9uvGPJk4PJ28A5Gc/wb4R1HQNYspbhd0MVpc2zvlRjYtlBE2Ax/1iWhlx/Du2nkZIB0Gh +J5teisrmLw7qtvY3kSzR3c722zYy7lJCzM/Ix/D35xzVgeKNH/4SG70Nr6BL61ihlkR5UH+tcoq gZzuzs4x/wAtY+u4Vy/gbR7jSrXRbW80LxHbXVtaJFNPPrAltFdYtrYiFyw2k5CgR8ZHAxxoa5pU t1q3iFrk/Y7C60SBI9Vdk2Wk0Mk7byCwYMnmJIG4A2Z3AgUAdJPq2m2olNxqFpCInKSGSZV2MI/N IOTwRH8+P7vPTmo5dd0eH7D5uq2Mf9oY+xbrhB9pzjHl8/PncvTP3h61w9xbXC6X4QvZ9K+1X97r b6nNZ3GEkV3trmRYyXHMkS7EQtt5iQZQfdpz+D9dcagpTUkg1q3mhlgsprVRGJLm6l23DSqxUBbl QTDvIIkwGwmQD1Suf8c/P4G1q2Xma8tHsoF/vzTDyo1z2y7qMngZySBk10Fc/rH/ABMPEei6ZH86 28p1C7Q8oI1R0jDD+8ZWR0BGD5DkHKCgDoKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPH/D3 /J0Piz/sFR/+g2tewV4/4e/5Oh8Wf9gqP/0G1r2CgAooooAKKKKACiiigAooooAK8f8AhB/yUP4n f9hUf+jbivYK8f8AhB/yUP4nf9hUf+jbigD2CiiigDn9ZstY/wCEh03VtJtrG5+z2lzbSRXd08H+ seFgwKxvnHkkYIHUUfbPGH/QC0P/AMHM3/yLXQUUAcT/AMJb4l/6F7Sf/BvJ/wDI1H/CW+Jf+he0 n/wbyf8AyNUVFMZL/wAJb4l/6F7Sf/BvJ/8AI1H/AAlviX/oXtJ/8G8n/wAjVFRQBL/wlviX/oXt J/8ABvJ/8jUf8Jb4l/6F7Sf/AAbyf/I1RUUAS/8ACW+Jf+he0n/wbyf/ACNR/wAJb4l/6F7Sf/Bv J/8AI1RUUAUNIt7m3s5ftixJPNd3NyyQyF1XzZnkChiqk4DgZwOldL4e/wCP+T/rkf5ismtbw9/x /wAn/XI/zFAHS0UUUhBUc8EN1by29xFHNBKhSSORQyupGCCDwQRxipKKAObgvNS8OW8VpqNpd6hY QII49Stt1xOVAwDPEBvLn5RujEm47mIjHAk/4TrwmvEviTSoJBw0NxdpFJGe6ujkMjDoVYAg8EA1 0FFAHP8A/Cd+D/8Aoa9D/wDBjD/8VR/wnfg//oa9D/8ABjD/APFV0FFAHP8A/Cd+D/8Aoa9D/wDB jD/8VR/wnfg//oa9D/8ABjD/APFV0FFAHP8A/Cd+D/8Aoa9D/wDBjD/8VR/wnfg//oa9D/8ABjD/ APFV0FFAHP8A/CSvqHyeH9Nn1BjyLmcNbWgHUMJWUmRWAO1olkB4yVDBq0NH0z+y7N0km+0XU8r3 FzOV2mSRjk8ZJCgYRQSSqIq5OM1oUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHj/h7/k6 HxZ/2Co//QbWvYKjEEK3D3CxRid0VHkCjcyqSVBPUgFmIHbcfWpKACiiigAooooAKKKKACiiigAr x/4Qf8lD+J3/AGFR/wCjbivYKjjghheZ4oo0eZ98rKoBdtoXLep2qoyewA7UASUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFAH//Z ------=_NextPart_000_0012_01C0595F.1F358420-- From owner-ietf-ediint@mail.imc.org Wed Nov 29 20:38:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07342 for ; Wed, 29 Nov 2000 20:38:39 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA21294 for ietf-ediint-bks; Wed, 29 Nov 2000 17:04:14 -0800 (PST) Received: from bbs.ht.net.cn (IDENT:root@[202.103.160.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA21290 for ; Wed, 29 Nov 2000 17:04:12 -0800 (PST) From: V@tzw.de Received: from h809 (1Cust82.tnt1.mia5.da.uu.net [63.30.194.82]) by bbs.ht.net.cn (8.8.7/8.7.3) with SMTP id JAA14481; Thu, 30 Nov 2000 09:22:50 +0800 Date: Thu, 30 Nov 2000 09:22:50 +0800 Message-Id: <200011300122.JAA14481@bbs.ht.net.cn> To: V@tzw.de Subject: Lady V: The Pleasure Pill for Women! Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LADY V: The Pleasure Pill for Women! Men Have Their Viagra®! Finally, A Pill for Women! It's Here! The Revolutionary Woman's Sexual Sensation is Now Available. Researchers are calling Lady V the greatest breakthrough for women since the Birth Control Pill. And you don't even need a prescription to get it! Welcome to the New Sexual Revolution! It's no secret that men have been having the time of their lives since the wonder pill Viagra® was made available. But, women were left out in the cold with no pill... nothing! Well now thanks to an all-star team of medical researchers who have been working around the clock, those days are finally over. The perfect female "pleasure pill" has been created and you don't even need a prescription. You can now get it from Lion Sciences! Lady V is the world's first pleasure pill scientifically designed for women. Lady V is an all-natural proprietary herbal blend of prosexual nutrients from around the world synergistically blended to naturally stimulate neurotransmitter endorphin signals. This magical combination increases targeted blood flow, unleashes natural stimulator for maximum stimulation, triggering pleasure responses quickly. Lady V is safe, natural and doctor-recommended. Since its introduction Lady V has been taking the world by storm! From Malibu to Miami women are enjoying the most intense pleasure of their lives! • 100% Natural • Safe • The Highest Quality Pharmaceutical Pure Nutraceuticals • Guaranteed Potency • Certified Purity Lady V is Sweeping the Nation! Women are going crazy over Lady V. Suddenly couples are falling in love all over again. The passion and pleasure that women are reporting is off the charts! Lady V has an incredible 88% success rate. Best of all, while Viagra costs $10 a pill, Lady V costs less than $1 a pill! It's not just a man's world anymore! Just look at what a few women have to say: "I thought my love life was good before, but now it is out of this world! Lady V is remarkable." — Mary J., Interior Designer "I haven't smiled like this in a long time. My husband and I feel like a couple of 19 year olds again!" — Debra T, Assistant Buyer "Imagine what it would feel like to have incredible passion and pleasure anytime you want." — Jennifer C., Film Editor "Suddenly my husband and I are spending more time in the bedroom instead of the TV room." — Angie R., Realtor Ingredients: Vitamin D, Niacin, Vitamin B6, Folic Acid, Vitamin B12, Avena Sativa, Kava Kava, Guarana, White Willow Extract, Mura Puama, St. John's Wort, Siberian Ginseng, Cordyceps, Damiana, and L-Taurine. Each bottle of Lady V contains 30 tablets. Take three capsules one hour before romantic activity as a dietary supplement. Risk Free: Double Your Money Back Guarantee If Lady V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked! Order Now: Safe, Fast, Secure, Private Lady V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Lady V contains 30 tablets. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Lady V $24 ______ 2 Bottles of Lady V $44 ______ 3 Bottles of Lady V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ] International Orders Please add $18 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$42, 2 bottles=$62, 3 bottles=$77 ] We cannot accept foreign checks. International money orders or credit cards only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 273 S. State Rd. 7, #193 Margate, FL 33068-5727 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Lady V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Lady V helps provide herbal and nutritional support for female sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From owner-ietf-ediint@mail.imc.org Thu Nov 30 12:16:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12471 for ; Thu, 30 Nov 2000 12:16:51 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA27877 for ietf-ediint-bks; Thu, 30 Nov 2000 08:22:21 -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 IAA27869 for ; Thu, 30 Nov 2000 08:22:18 -0800 (PST) Received: by mailman.8760.com from localhost (router,SLMail V3.2); Thu, 30 Nov 2000 10:24:08 -0600 Received: from gamma [192.168.21.133] by mailman.8760.com [192.168.21.90] (SLmail 3.2.3113) with SMTP id 6C8B3E6BB97F11D4BB0C0060974E38DD for ; Thu, 30 Nov 2000 10:24:08 -0600 Reply-To: From: "Dick Brooks" To: "EDIINT" Subject: Yet another interesting development Date: Thu, 30 Nov 2000 10:20:08 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 X-SLUIDL: B4EA5A2A-C56D11D4-BB0C0060-974E38DD Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit VeriSign, Microsoft and webMethods Announce Breakthrough XML-based Specification to Enable Interoperable Digital Signatures and Encryption for B2B and B2C Transactions New Open Specification to Accelerate Deployment of Secure E-Commerce Applications MOUNTAIN VIEW, CA, November 29, 2000 - VeriSign Inc., Microsoft Corp. and webMethods Inc. today introduced a breakthrough XML-based framework -- the XML key management specification (XKMS) -- to enable a broad range of software developers to seamlessly integrate digital signatures and data encryption into e-commerce applications. To accelerate the development of applications incorporating these advanced technologies, the XKMS specification -- jointly designed and prototyped by VeriSign, Microsoft and webMethods with industry support from other technology leaders -- was made publicly available today and will be submitted to the appropriate Web standards bodies for consideration as an open Internet standard. In addition, XKMS will be built into the Microsoftb.NET architecture to ensure broad and rapid adoption of this framework in both B2B and B2C environments. More information on XKMS can be found at: www.verisign.com/developer/xml. Full story can be found at: http://www.verisign.com/press/2000/vs_xmlxkms.html 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 Thu Nov 30 19:06:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13165 for ; Thu, 30 Nov 2000 19:06:00 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA23979 for ietf-ediint-bks; Thu, 30 Nov 2000 15:35:59 -0800 (PST) Received: from mail.governacio-ri.gencat.es (gencat.es [194.179.95.227]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA23974 for ; Thu, 30 Nov 2000 15:35:58 -0800 (PST) Date: Thu, 30 Nov 2000 15:35:58 -0800 (PST) From: Younger@bdsm.at Message-Id: <200011302335.PAA23974@ns.secondary.com> Received: from aks011 (1Cust54.tnt1.mia5.da.uu.net [63.30.194.54]) by mail.governacio-ri.gencat.es with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id X8T2JXXN; Fri, 1 Dec 2000 00:36:25 +0100 To: Younger@bdsm.at Subject: REVERSE the AGING PROCESS 10-20 Years! MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)??? Released by your own pituitary gland, HGH starts declining in your 20s, even more in your 30s and 40s, eventually resulting in the shrinkage of major organs-plus all other symptoms related to old age. THIS CAN NOW BE REVERSED!!! IN THOUSANDS OF CLINICAL STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING: * Reduce Body Fat Without Dieting Build Lean Muscle WITHOUT EXERCISE! * Enhance Sexual Performance * Remove Wrinkles and Cellulite * Lower Blood Pressure and improve Cholesterol Profile * Improve Sleep, Vision and Memory * Restore Hair Color and Growth * Strengthen the Immune System * Increase Energy and Cardiac Output * Turn back your body's Biological Time Clock 10-20 years in 6 months of usage !!! You don't have to spend thousands of dollars on shots. You don't have to spend the $139.00 per bottle that HGH is selling for at some Clinics in the United States. For the next 30 Days, you can obtain a complete one-month supply of our HGH releaser for our special "New Customers" price of just $69.95 plus $6.00 shipping and handling. To ensure a constant supply and to SAVE EVEN MORE, you can order with confidence 3 bottles of HGH and GET 1 FREE - that's just $209.85 for 4 bottles, plus $6.00 shipping and handling. You SAVE $69.95! ORDER TODAY! Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express payments. Money Orders are accepted only by Postal Mail. Step 1: Place a check by your desired quanity. ______ 1 Bottle of HGH $69.95 ______ 2 Bottles of HGH $131.90 ($65.95 a bottle) ______ 4 Bottles of HGH (Buy 3 get 1 FREE. SAVE $69.95) $209.85 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$75.95, 2 bottles=$137.90, 4 bottles=$215.85 ] International shipping, please add $35 for any size order [ Total cost including shipping & handling, 1 bottle=$104.95, 2 bottles=$166.90, 4 bottles=$244.85 ] Foreign checks are not accepted. Credit cards & international money orders only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: Lion Sciences National 273 S. State Rd. 7 #193 Margate, FL 33068-5727 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: HGH is not intended to diagnose, treat, cure or prevent any disease. The FDA has not evaluated these statements.