Hi Tony I only opened the issue on email because the main reason Steve pointed out to use it was bandwidth sparcity in poor countries.
So, let's see a message with attachements using proper email headers, short email headers and the verbose SOAP XML: === [START] Email header with lots of control stuff === Delivered-To: [EMAIL PROTECTED] Received: by 10.151.144.2 with SMTP id w2cs151643ybn; Wed, 14 May 2008 01:03:05 -0700 (PDT) Received: by 10.140.251.1 with SMTP id y1mr335170rvh.195.1210752184215; Wed, 14 May 2008 01:03:04 -0700 (PDT) Return-Path: <[EMAIL PROTECTED]> Received: from n27b.bullet.sp1.yahoo.com (n27b.bullet.sp1.yahoo.com [209.131.38.244]) by mx.server.com with SMTP id k2si1212331rvb.4.2008.05.14.01.03.03; Wed, 14 May 2008 01:03:04 -0700 (PDT) Received-SPF: pass (server.com: domain of [EMAIL PROTECTED] designates 209.131.38.244 as permitted sender) client-ip=209.131.38.244; DomainKey-Status: good Authentication-Results: mx.server.com; spf=pass (server.com: domain of [EMAIL PROTECTED] designates 209.131.38.244 as permitted sender) [EMAIL PROTECTED]; domainkeys=pass [EMAIL PROTECTED] Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lima; d=yahoogroups.com; b=kCrlCgzTKxpLXEg4R9bhYZf6uc8CjxLLSQ+AOm895SjpyGfkL0BwkaJbQJGixaRyiri86uk5pyCAIrbfyu1T0jU5FWOS9YJ/NTBcBYTEgFp/Z0RcpnxYfmROQo1EJE/E; Received: from [216.252.122.216] by n27.bullet.sp1.yahoo.com with NNFMP; 14 May 2008 08:03:02 -0000 Received: from [66.218.69.5] by t1.bullet.sp1.yahoo.com with NNFMP; 14 May 2008 08:03:02 -0000 Received: from [66.218.67.109] by t5.bullet.scd.yahoo.com with NNFMP; 14 May 2008 08:03:02 -0000 MIME-Version: 1.0 Message-ID: <[EMAIL PROTECTED]> Date: 14 May 2008 08:03:01 -0000 From: openhealth@yahoogroups.com To: openhealth@yahoogroups.com Subject: This is the optional message description. Reply-To: "No Reply"<[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] Content-Type: multipart/mixed; boundary="--MIME_boundary" --MIME_boundary Content-Type: image/gif; name=thepinkpanther.gif Content-Transfer-Encoding: base64 X-Attachment-Id: f_fg84awv10 Content-Disposition: attachment; filename=thepinkpanther.gif ...Base64 encoded GIF image goes here... --MIME_boundary-- === [ENDED] Email header with lots of control stuff === Of course, a few headers could be removed but others should be in place to assure the email procedence, block position (in case of spliting it), content hash check, etc et al. In a minimum format the message headers would be like this: === [START] Email header shortened === Received: by 10.151.144.2 with HTTP; Wed, 14 May 2008 09:19:42 -0700 (PDT) Message-ID: <[EMAIL PROTECTED]> Date: Wed, 14 May 2008 17:19:42 +0100 From: "Server" <[EMAIL PROTECTED]> To: "Client" <[EMAIL PROTECTED]> Subject: This is the optional message description. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--MIME_boundary" Delivered-To: [EMAIL PROTECTED] --MIME_boundary Content-Type: image/gif; name=thepinkpanther.gif Content-Transfer-Encoding: base64 X-Attachment-Id: f_fg84awv10 Content-Disposition: attachment; filename=thepinkpanther.gif ...Base64 encoded GIF image goes here... --MIME_boundary-- === [ENDED] Email header shortened === In this second example the message is rather small but has no certification email headers so it will be less secure. Now, the same message in SOAP With Attachements[1] (which is more verbose than plain XML-RPC or REST): === [START] SOAP With Attachments === POST /insuranceClaims HTTP/1.1 Host: www.risky-stuff.com Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml; start="<[EMAIL PROTECTED]>" Content-Length: XXXX SOAPAction: http://schemas.risky-stuff.com/Auto-Claim Content-Description: This is the optional message description. --MIME_boundary Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <[EMAIL PROTECTED]> <?xml version='1.0' ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <claim:insurance_claim_auto id="insurance_claim_document_id" xmlns:claim="http://schemas.risky-stuff.com/Auto-Claim"> <theSignedForm href="cid:claim061400a.tiff@claiming-it.com"/> <!-- ... more claim details go here... --> </claim:insurance_claim_auto> </SOAP-ENV:Body> </SOAP-ENV:Envelope> --MIME_boundary Content-Type: image/tiff Content-Transfer-Encoding: base64 Content-ID: <[EMAIL PROTECTED]> ...Base64 encoded TIFF image goes here... --MIME_boundary-- === [ENDED] SOAP With Attachments === The TIF file in the above case could be anything, BZiped, encrypted, etc. Could even be a CSV file ready to be imported by your Spreadsheet app. The SOAP part is the one inside <SOAP-ENV:Envelope /> tags. ------------------ If there is some error on the client receiving the email you must send a reply email back to the server with the error, wait for a new server email pool fetching and then re-fetch the email message from the server. The POP3 protocol was not thought for this. With IMAP is feasible without less burden to the server and client. With SwA (or other XML style message) the same procedure is faster because client asks info, server replies, client checks and on error repeat the procedure. And the message that goes forth and back is smaller. And SOAP is one of the more verbose protocols of the kind :) Best, Lopo [1] Modified SwA example grabed from here: http://www.w3.org/TR/SOAP-attachments --- In openhealth@yahoogroups.com, Tony McCormick <[EMAIL PROTECTED]> wrote: > > Hi all, > This is a fascinating conversation. more useful than most I've seen > on this and other venues. I am a bit confused by the email/encryption > discussion. Is it still "illegal" to use greater than 48bit inscription > across international borders? Because higher levels of encryption, even > without Steve's extra indirection, are, for all practical purposes, > unbreakable and meet HIPAA regs just fine. I have a similar > application for in home health care data collection that uses 1024 bit > PGP encryption with email as the primary (but not sole) delivery system > into the OpenEMR system. I can't see how that's a problem. > > I think that much of Lopo's suggestions are great alternatives as well, > be email is tried and true and dirt simple to implement. It may have > higher band width, compared to socket-to-socket or similar protocols, > but no so much as it would be an issue, in my opinion. > > Tony McCormick > Medical Information Integration, LLC > www.mi-squared.com > > > > > [Non-text portions of this message have been removed] >