Subject: Re: GISB/E5 incorporation into EDIINT AS2

From: [email-masked]
Date: Sun, 7 Mar 1999 21:13:09 -0500

George,

Like you, I am excited about potential convergence - mainly on behalf of PA
EDEWG, where the GISB vs. EDI-INT (CommerceNet) discussions have been going
on for over a year, and appear to be in full roar once again.  As you know
, we have been ordered by the Commission to continue testing the GISB EDM,
with a targeted implementation date of 7/1/99, but comments regarding
reasonableness and feasibility from EDEWG members are currently under
consideration.

No apologies required for joining into these discussions.  As the PAPUC
technical advisor to EDEWG, your input is valuable and quite welcome.  I
will, however, have to defer to the experts (thus carboned) to tackle your
excellent questions.

Dick, Dave, Rik, Chuck, others - help with the following?

Thanks,

Chris

"Behr, George" <[email-masked]> on 03/05/99 01:28:01 PM

To:   Chris M Navadauskas/DLC
cc:   "[email-masked]'" <[email-masked]>, "[email-masked]'"
      <[email-masked]>, "[email-masked]'" <[email-masked]>,
      "[email-masked]'" <[email-masked]>,
      "[email-masked]'" <[email-masked]>

Subject:  GISB/E5 incorporation into EDIINT AS2

(Apologies in advance for any intrusion into your email)

I've been following the EDIINT/CommerceNet/GISB/AS1/AS2 convergence
discussion on the IETF discussion threads.  I am very excited about the
possibility of convergence, but I still have lots of questions:
1. Should an industry trying to adopt a standard adopt the IETF EDIINT
standard because it is a broader standard, supporting both EDIINT
AS1/SMTP/CommerceNet and AS2/HTTP/GISB/E5 traffic?  What is the impact of
not choosing that standard, then moving to it at a later date?
2. If the world has standardized on EDIINT/AS1/AS2, and I've invested in
GISB, what type of upgrade should I expect to be EDIINT/AS2 compliant?
Will
I still need AS1 to talk to the rest of the world that might be doing AS1,
since AS2 is only a subset of EDIINT.
3. What is the realistic timeframe that the different AS2 HTTP
implementations (GISB/E5) will agree on a standard, or are they essentially
already there?
4. I assume that 'EDIINT Compliance' means supporting both AS1 and AS2.
5. Will existing GISB vendors become fully EDIINT compliant?  AS2? AS1?
What is a realistic timeframe for this?
6. Will existing EDIINT AS1 vendors become fully compliant (ie support
AS2)?
What is a realistic timeframe for this?

Thanks in advance..

George Behr
Technical Consultant to the Pennsylvania PUC
[email-masked]
717.805.8767

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, March 05, 1999 12:30 PM
To: PPUC List
Subject: GISB incorporation into CommerceNet is looking really good....

Dick, great - I'm passing this info on to all in the PA Electronic Data
Exchange Working Group.  This is an important breakthrough.

Chris
---------------------- Forwarded by Chris M Navadauskas/DLC on 03/05/99
12:32 PM ---------------------------

Dick Brooks <[email-masked]> on 03/05/99 10:48:20 AM

To:   Chris M Navadauskas/DLC, [email-masked]
cc:

Subject:  GISB incorporation into CommerceNet is looking really good....

Hi Chris, as you know I've been working with the EDIINT group to consider
incorporating GISB for backwards compatability. Finally I believe we've
turned a corner - everyone is beginning to say that GISB/EDIINT
convergance is good - even Dave Darnell, Chuck Shih and Rik Drummond.

     To: "Rik Drummond" <[email-masked]>, "Dick Brooks"
<[email-masked]>,
             <[email-masked]>, <[email-masked]>
     From: Dave Darnell <[email-masked]>
     Subject: RE: where do we stand on the as1 -- http discussion?

     Rik,

     Great!

     If you can do this then I think the Utility industry would get behind
the
     ediint standard (IMHO)

     I think this is extremely important in this industry in order to avoid
     every state adopting a different Internet EDI method /standard for
Utility
     dereg.

     Thanks,
     Dave Darnell

     At 09:38 AM 3/5/99 -0600, Rik Drummond wrote:
     >yes, i think we adjust as2 to be the appropriate "base" for e5 an
gisb, if
     >possible.... we need to align these as much as possible to facilitate
     >worldwide EC.....
     >
     >> -----Original Message-----
     >> From: Dick Brooks [mailto:[email-masked]]
     >> Sent: Thursday, March 04, 1999 6:58 PM
     >> To: [email-masked]; [email-masked]; [email-masked];
     >> [email-masked]; [email-masked]
     >> Subject: RE: where do we stand on the as1 -- http discussion?
     >>
     >>
     >> What about making all the necessary changes to AS2, it's still in a
     >> "formative" stage.
     >>
     >> Dick
     >>

     ================
     Dave Darnell
     SysTrends, Inc. &  Arizona EC/EDI Roundtable
     Tel: 602.899.4787
      mailto://[email-masked]     http://www.systrends.com
     ===================================================

---
You are currently subscribed to edtwg as: [[email-masked]]
To unsubscribe, forward this message to
[email-masked]

---

From: "Carl Hage" <[email-masked]>
Date: Mon, 8 Mar 1999 12:27:59 -0800

From:           	[email-masked]
Date sent:      	Sun, 7 Mar 1999 21:13:09 -0500
Subject:        	Re: GISB/E5 incorporation into EDIINT AS2

> incorporating GISB for backwards compatability...
>  .... we need to align these as much as possible to facilitate
>      >worldwide EC.....

Rather than argue over installed base and what standards exist, I 
think it's useful to highlight the features and differences between 
the various approaches to EC messaging. I've gone through the 
differences and discussed alternative strategies and future 
development changes below.

With respect to http there are 2 or 3 basic approaches to 
packaging top-level data for exchange:

----------------
1. Data Packaged into browser-forms variables & CGI variables
1.a. Data in &xxx=value&yyy=value strings
1.b. Data using Netscape file upload html extension (multipart-form)
(---sep\n Content-Disposition: form-data; name="xxx"\n\n value )

2. Data Packaged using MIME standards (RFC822)
(e.g. xxx:value,  Message-ID: [email-masked])

----------------------

There are tradeoffs between these approaches, and both 
concievably could exist. For the 2 approaches above

1. Browser-forms format:
 - Compatible with most current legacy browsers (manually 
operated)
 - Does not include digital signatures (within the browser format)
other than uploading externally signed data.
2. MIME
- Compatible with existing MIME email and data-parsing software
- Uses existing IETF standards for messaging, encryption, and 
receipt/non-repudiation
- Interoperable with email-based messaging and gateways 
(including store-and-forward)

If there is a requirement for using a manually operated existing 
browser to exchange a transaction, then the first method is better. 
If support for signatures, non-repudiation, and interoperability is 
important, then the second method is better.

There is a possibility of convergence. The RFC822, etc. standards 
list keyword:value pairs, e.g. "To", "Message-ID", etc. which are 
referenced in the EDIINT standard, i.e. EDIINT elaborates on how 
the MIME/RFC822 headers apply. If a browser-forms format is used 
and the form variables correspond to the RFC822/MIME keywords, 
then it is possible to write a gateway to convert the formats.
-----

Beyond packaging of the top-level data, industry-specific standards 
like GISB typically combine general (application independent) 
aspects and application specific aspects (info specific to a GISB 
transaction, for example). In GISB, for example, there are 
provisions for informational WWW pages, types of informational 
postings, etc. which encompass a much greater scope then just
messaging.

If GISB and EDIINT were aligned, GISB would still include a great 
deal of specifications as part of the Gas Industry application, which 
isn't applicable to the lower-level EDIINT spec. In fact, most of the 
current GISB spec addresses higher level issues not relevant to 
EDIINT. For example, GISB indicates how "Rate Schedules" must 
be incorporated into an HTTP server accessable to a generic 
WWW browser.

[Note, I think it would be more interesting for GISB to work on xml 
and rdf formatting to permit automated indexing and tracking of this 
info. It would be best for GISB to move away from transport-specific 
issues, and focus on migrating away from human-only HTML or 
machine-only X12 to machine&human readable XML/HTML 
addressing all communications needs and facilitating a much 
greater level of automation and net-services.]

> possibility of convergence, but I still have lots of questions:

 1. Should an industry trying to adopt a standard adopt the IETF 
EDIINT standard
> because it is a broader standard, supporting both EDIINT
> AS1/SMTP/CommerceNet and AS2/HTTP/GISB/E5 traffic?

I think this is the fundamental point. AS1/AS2 are almost the 
same. The difference is mostly in the syntax of the data transport-- 
a lower-level part of the system. A specialized SMTP-based 
software system can be trivially retrofitted to accomodate HTTP.

A major question is what kind of software would be used to do 
EDIINT or whatever EC messaging. EDIINT AS1 works OK with a 
decent SMTP software package (though many are indecent). 
However, I think the usual general purpose/legacy system does not 
meet EC reliability requirements and much simpler, more robust, 
and fault-tolerant packages will be used.

Likewise, a general purpose HTTP server with custom CGI program 
could be used. Besides lack of robustness, the usual HTTP 
system has no error-recovery, so an even more complex set of 
software is required for reasonable automated operation. Writing a 
small, highly optimized, fault-tolerant message processing system, 
I believe, is less complex than the chewing gum and baling wire 
needed to utilize general HTTP/CGI software.

The question of software interoperabilty in my opinion goes to 
interoperation with existing browsers (which do not have error 
recovery, non-repudiation, etc.) vs interoperation with 
upcoming/future EC messaging software which includes high 
reliability, fault-tolerance, digital signatures, non-repudiation, and 
auditing.

What is the impact of
> not choosing that standard, then moving to it at a later date?

You can continue using forms-HTML and migrate to MIME. 
However, I think it would be a lot of extra work to develop GISB-
unique systems for non-repudiation, error recovery, etc. Better to 
implement these using the more general standards (kind of what 
GISB did anyway).

 2. If the
> world has standardized on EDIINT/AS1/AS2, and I've invested in 
GISB, what
> type of upgrade should I expect to be EDIINT/AS2 compliant?

Depending on the type of software used, it is likely to be relatively 
easy to upgrade. The main difference would be modifying the CGI 
programs to parse MIME data instead of HTML-forms data.

The GISB-1.3 spec is missing a few fundamental concepts (e.g. 
Message-ID) required for more general operation. These additions 
would not be substantial.

The main potential future divergence is how non-repudiation is 
handled. EDIINT uses the relatively new MIME MDN format for 
receipts. Though MDNs aren't ideal, they are much better than 100 
proprietary systems or several other wrappers specific to narrow 
applications like XML.

At the core of MDNs are certain concepts like Message-ID and 
MIC (MD5/SHA) of a MIME message. Concepts of Message-ID 
span protocols and allow interoperation/gateways. If an industry 
specific standard layers on EDIINT/MIME/MDNs, then it must 
include the general requirements of Message-ID, etc., though might 
restrict usage of Message-Id, To, From, Subject, etc. to follow 
certain conventions.

In the existing GISB, there is almost a Message-ID obtained from 
the trans-id@server-id. However, there is no restriction that the 
trans-id be unique across all internet messaging, and this ID 
comes from the server (making it unsuitable for non-repudiation).

Will I still
> need AS1 to talk to the rest of the world that might be doing 
AS1, since
> AS2 is only a subset of EDIINT.

If you use AS2, then you are interoperable with AS1. You will likely 
be able to get software that handles both. (I think most AS2 
software will automatically also do AS1, since supporting both is 
trivial-- assuming an implementation not based on chewing gum 
and baling wire).

> 3. What is the realistic timeframe that
> the different AS2 HTTP implementations (GISB/E5) will agree on 
a standard,
> or are they essentially already there?

I don't know what is planned for the future with GISB (I've read the 
1.3 July/1998 version). The only feature in GISB-1.3 not in 
AS2/AS1 is the ability to use a manual upload with a legacy 
browser (without using the java feature). In other words, AS2 does 
not have the ability to use HTML form-data wrappers.

If form-data were to be supported, I think the best approach would 
be to define a mapping between form-variables and MIME header 
names, or else form a complete RFC822/MIME compliant 
message file including Message-ID, etc., then upload it. I 
personally, do not see a need to support form-data wrappers in 
AS2. I think software available in the near term encorporating the 
security features will use basic AS1/AS2/MIME. There is no need 
to support form-data, since browsers that use it can't support the 
security requirements anyway.

The main feature in AS2 not in GISB-1.3 is non-repudiation. This is 
the root of the difference in layering and use of message headers. If 
GISB were to add non-repudiation, I think it would be best to base 
in on the existing MIME standards (like EDIINT has done)-- for 
overall Internet standards interoperability.

 4. I assume that 'EDIINT
> Compliance' means supporting both AS1 and AS2.

Compliance mainly means exchanging a message with some 
basic RFC822/MIME headers (Message-ID, etc.), digitally signing 
and optional encryption using MIME standards, and using MIME 
MDNs for signed receipts. If the message is transmitted on an 
SMTP/POP/IMAP/UUCP, etc. system, it's AS1. If it's transmitted 
using HTTP, it's AS2. The content of the MIME data exchanged 
and logged is identical.

Non-repudiation also requires a system to keep a message log 
which includes all the signatures and receipts. EDIINT compliance 
likely means message logs would be compatible with general 
MIME tools that might be used by an auditor.

[Note one topic missed by GISB is recordkeeping requirements. If 
GISB was layered over EDIINT, it would be easy to add 
recordkeeping standards, e.g. maintaining MIME message logs in 
a mail folder file format (e.g. the usual Unix format supported by 
most existing software).]
 5. Will existing GISB
> vendors become fully EDIINT compliant?  AS2? AS1? What is a 
realistic
> timeframe for this?

A future system that supported non-repudiation could be EDIINT 
compliant, and could have a back-compatibility interface for HTML 
form-data. Changes to existing batch-mode GISB software involves 
changing the format of the data wrappers, plus whatever additional 
features might be needed for supporting signed receipts, etc. 
Changing the wrapper format should be relatively easy. Adding new 
features for non-repudiation is significantly more, and would be 
required no matter what the wrapper format is.

In terms of time-frame one issue is arriving on an agreement to 
support full non-repudiation, etc. in GISB. One way to do this is to 
reorganize GISB so it is layered over AS1/AS2/MIME, so GISB 
covers topics not covered by MIME/EDIINT or adds usage 
conventions on top of MIME/EDIINT. Also, it would be useful to 
define a mapping between GISB-1.3 and this future layered 
approach. Layering would mostly entail removing material from the 
standard.

Layering GISB also would decouple the GISB standard from future 
evolution of MIME/EDIINT/MDNs, etc. EDIINT is already mostly 
decoupled from the standards upon which it's layered-- message 
headers, digital signatures, receipts, etc.

 6. Will existing EDIINT AS1 vendors become fully
> compliant (ie support AS2)? What is a realistic timeframe for 
this?

AS2 cannot support all users (those without real-time net 
connections). I suspect AS1 vendors will support AS2 since it's not 
hard. A better question is will AS2 vendors all support AS1 (SMTP-
mode) as well. I predict yes.

--------------------------------------------------------------------------
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: "Rik Drummond" <[email-masked]>
Date: Tue, 9 Mar 1999 10:33:30 -0600

Excellent questions. comments below in the text.... Rik

> Sent: Sunday, March 07, 1999 8:13 PM
> To: Behr, George
> Cc: [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'

Rik: AS1 is, will be an international standard, while gisb will be an
industrial standard. in the gas industry gisb should work fine as the gas
industry connects with other industries they should use the ietf standard --
as1 -- when it becomes standard.. which should be shortly.

> since AS2 is only a subset of EDIINT.

Rik: see above. If we can make the as2 a proper subset of the gisb and e5
standard (our current discussion focus) then while they may be different
non-interoperable standards -- as1, as2, gisb and e5 -- the cost to produce
and maintain them will be greatly reduced for the software producers.  Maybe
it is possible to have the new as2 to switch transparently to e5, gisb or
as2 -- negotiating the session -- thus making it transparent to the user
which it is using.

> implementations (GISB/E5) will agree on a standard, or are they

Rik: under discussion as we speak.

> 4. I assume that 'EDIINT Compliance' means supporting both AS1 and AS2.

Rik: Yes. However, at this time because of the commercenet interoperability
test, most would consider compliance, correctly or incorrectly, to be as1
using s/mime.

> What is a realistic timeframe for this?

Rik: Don't know at this time.

> 6. Will existing EDIINT AS1 vendors become fully compliant (ie support

Rik: That is our hope. If as2 is done correctly those who have produced code
for as1 should in a straightforward manner be able to implement as2. Our
hope is that 90% of the as1 code is reusable in the as2.

> What is a realistic timeframe for this?

Rik: This will happen much more quickly if we can have a face to face
meeting to hammer out the details. Does anyone wish to fund the meeting to
make this happen?