Subject: Re: EDIINT and HIPAA

From: Gunther Schadow <[email-masked]>
Date: Thu, 02 Nov 2000 11:12:44 -0500

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

---

From: "Dick Brooks" <[email-masked]>
Date: Thu, 2 Nov 2000 12:26:46 -0600

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 <DB> </DB>, so here goes:

> -----Original Message-----
> From: Gunther Schadow [mailto:[email-masked]]
> Sent: Thursday, November 02, 2000 10:13 AM
> To: Dick Brooks
> Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow;
> David@Drummondgroup. Com; [email-masked]; [email-masked]
> Subject: Re: EDIINT and HIPAA
>
>
> Dick,
>

<DB>
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:[email-masked]

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
--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: [email-masked]
Date: Wed, 18 Oct 2000 23:24:59 GMT
Message-ID: <[email-masked]
<mailto:[email-masked]>>
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--

</DB>

> Isn't it true that both AS#2 and GISB use the MIME security wrappers?

<DB> The AS2 compliant version of GISB uses the MIME security wrappers, the
old GISB simply placed encrypted data into an application/octet-stream
wrapper. </DB>

> payload while GISB use multipart/form-data?

<DB> 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
</DB>

> directly (i.e. filling out an HTML form?)

<DB> 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.
</DB>

> sure how much that is actually used.)

<DB> No problem HL7 and HIPAA can support both interactive and batch mode
clients using the GISB/AS2 profile.
</DB>

> use form-data presentation.

<DB> 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.
</DB>

> has got to speed up its processes!

<DB> 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.
</DB>

> our few additional requirements back into the IETF?

<DB> I'm interested in talking with you about your requirements and would be
happy to assist.</DB>

> to happen for the sake of sanity :-)

<DB> 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?
</DB>

> -Gunther

Thanks, and sorry for the loooong message,

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
[email-masked]
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

---

From: Terry Harding <[email-masked]>
Date: Thu, 2 Nov 2000 14:51:26 -0700

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" <[email-masked]>
To: "Gunther Schadow" <[email-masked]>
Cc: "Rik Drummond" <[email-masked]>; "Kepa Zubeldia"
<[email-masked]>; "CLEM" <[email-masked]>; "Gary Crough"
<[email-masked]>; "Beth Morrow" <[email-masked]>;
"David@Drummondgroup. Com" <[email-masked]>; <[email-masked]>;
<[email-masked]>; "Dick Brooks" <[email-masked]>
Sent: Thursday, November 02, 2000 11:26 AM
Subject: RE: EDIINT and HIPAA

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

---

From: "Dick Brooks" <[email-masked]>
Date: Thu, 2 Nov 2000 17:55:12 -0600

> style message using RSA security, or must the security layer be PGP as in

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/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
[email-masked]
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

---

From: Gunther Schadow <[email-masked]>
Date: Fri, 03 Nov 2000 10:03:38 -0500

> packaging style in the next version of the AS2 spec and remove references to

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

---

From: Terry Harding <[email-masked]>
Date: Fri, 3 Nov 2000 13:46:22 -0700

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

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.
<tnh>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.
<tnh> 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.
<tnh> 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..

<tnh>
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: Terry Harding <[email-masked]>
Date: Fri, 3 Nov 2000 15:22:07 -0700

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: [email-masked]
Date: Fri, 03 Nov 2000 14:54:31 -0700 (PDT)

> a compressed unit, which when uncompressed will give us

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: "Carl Hage" <[email-masked]>
Date: Fri, 3 Nov 2000 16:53:36 -0800

From:           	Terry Harding <[email-masked]>
Date sent:      	Fri, 3 Nov 2000 13:46:22 -0700

> content-encoding in email even as an option just isn't acceptable.

Seems like "Content-Encoding" is a resonable extension, but...

> 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
<mailto:[email-masked]> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086

---

From: [email-masked]
Date: Sat, 04 Nov 2000 00:47:32 -0700 (PDT)

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

This has the same problem as content-encoding -- while content-description is a
known field, its semantics in email don't affect data interpretation.

> or  Content-Type: applicatoin/xml; conversion= gzip.

Again, this has the same problem.

> 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: Terry Harding <[email-masked]>
Date: Fri, 3 Nov 2000 15:22:07 -0700

Terry Harding
Cyclone Commerce

---

From: Terry Harding <[email-masked]>
Date: Fri, 3 Nov 2000 13:46:22 -0700

<tnh>

Open for comments...

Terry Harding
Cyclone Commerce

---

From: "Carl Hage" <[email-masked]>
Date: Fri, 3 Nov 2000 16:53:36 -0800

Example:

(Test software can use:

---

From: [email-masked]
Date: Fri, 03 Nov 2000 14:54:31 -0700 (PDT)

Ned

---

From: [email-masked]
Date: Sat, 04 Nov 2000 00:47:32 -0700 (PDT)

Ned

---

From: Terry Harding <[email-masked]>
Date: Fri, 3 Nov 2000 13:46:22 -0700

<tnh>

Open for comments...

Terry Harding
Cyclone Commerce

---

From: Terry Harding <[email-masked]>
Date: Fri, 3 Nov 2000 15:22:07 -0700

Terry Harding
Cyclone Commerce

---

From: [email-masked]
Date: Fri, 03 Nov 2000 14:54:31 -0700 (PDT)

Ned

---

From: [email-masked]
Date: Sat, 04 Nov 2000 00:47:32 -0700 (PDT)

Ned

---

From: "Carl Hage" <[email-masked]>
Date: Fri, 3 Nov 2000 16:53:36 -0800

Example:

(Test software can use: