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]
>
