To Split or not to Split - that is the question.

Perhaps it's time to examine the clarity issue a bit further, and this may
help us decide whether to split the spec or not.

I'll begin by providing a little background on the original GISB standard.
This will be followed by a description of the GISB/AIAG AS2 profile and,
lastly, I'll compare the GISB/AIAG and UCC AS2 profiles (at a very high
level).

In 1996 the Energy industry needed a secure, reliable means to transport EDI
documents over the Internet. A relatively new specification was emerging
from the IETF that would permit file exchanges using web browsers/HTTP, the
spec eventually became known as RFC 1867. RFC 1867 has been updated/replaced
by RFC 2388. If you've ever uploaded a file using a web browser to Yahoo,
E-Bay or one of the picture sharing sites chances are good you've used the
RFC  2388 standard.

If you would like to see a GISB standard upload in action simply go to
http://www.tech-comm.com/gisbupload.html and send a file to the server. The
information you send will be "mirrored" back to your browser so that you can
see what data was sent. You don't have to encrypt the data to see how this
works, but feel free to do so if you wish. To send a file, click the browse
button, pick a file, then send it using the submit button. I've limited the
amount of data allowed so please pick a small file to send.

*IMPORTANT NOTE FOR CLARITY*
The example above uses an interactive web browser to demonstrate a GISB
standard upload, however this DOES NOT mean users must use interactive
browsers to send files. There are numerous, automated scripting tools
available which implement this same functionality that run in an unattended
manner. In fact, the majority of implementations in the Energy industry use
automated tools to encrypt/decrypt and send/receive files using the GISB
standard.

Also, the standard response to a file upload, as defined by GISB,is an
acknowledgement timestamp, which is not shown in the example above. In an
attempt to help people understand how this works I've chosen to display the
data that was received by the server so that you may see what a GISB
standard message looks like.
*END NOTE*

As you can see by this example the GISB standard upload procedure is
relatively simple to understand, there are 4 identification elements:
FROM: Duns number of sender
TO:   Duns number of recipient
INPUT-FORMAT: Describes the type of data being sent (X12)
TRANSACTION-SET: Specific identifier for the type of data in the encrypted
payload
INPUT-DATA: This is the actual file being sent.

The message packaging is entirely based on RFC 2388, which is well
documented and very easy to understand. All a developer needs to do is view
the output from any browser using the HTML form above to see a GISB standard
message.

The GISB standard for crypto is PGP, and all senders are expected to encrypt
their business data before sending it to the server. This approach was
fairly easy for people to understand and explicit command line examples
using PGP to encrypt files are available for those needing assistance,
e.g. pgp -esa foo.bar receiver-pubkey -u signer-key

After completing the encryption step, a sender can use a simple web form,
like the one above, to upload the encrypted data.

One of the benefits of the GISB approach is that an end user doesn't need
expensive or complex software to send a file. All that's needed is a web
browser and PGP.

In 1999, the decision was made to converge the functionality defined by GISB
and AIAG into the IETF AS2 effort. The result of this convergence may be
seen in another AS2 compliant html form,
http://www.tech-comm.com/as2upload.html

This AS2 conformant approach was adopted by GISB in 2000 and is now an
official standard of the Energy industry.

As you can see by the as2upload form there are many more identification
elements available than with the original GISB standard. These are all part
of what people refer to as the  GISB/AIAG AS2 profile. Some of these
elements are specifically related to AS2's mechanism for receipt delivery,
and security options. In this sense the UCC profile and GISB/AIAG profile
are alike and use the same element names to request receipts.

So how do the UCC and GISB/AIAG approach's differ within AS2?

At a high level, and at the risk of oversimplifying...

The UCC approach defines HTTP extension headers to convey similar
information to the "identification elements" used by GISB and AIAG, which
you can see the as2upload.html form above. Instead of using the element
names "FROM" and "TO" to identify sender/receiver the UCC profile uses
"AS2-From" and "AS2-To".

Additionally, the UCC profile specifies the use of S/MIME version 2 for all
crypto functions. The GISB/AIAG AS2 profile specifies OpenPGP.

Lastly, the UCC profile uses MDN's for receipt acknowledgements, whereas
GISB uses a generic "multipart/report" containing tracking identifiers and
timestamps.

In terms of function the two profiles are virtually identical; to provide
reliable, secure delivery of business data.

I hope this helps.

Dick Brooks
Systrends, Inc
7855 South River Parkway, Suite 111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>
Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714


-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Andrew Stickland
Sent: Tuesday, January 21, 2003 2:01 AM
To: [email protected]
Cc: '[email protected]'; [email protected]
Subject: RE: Split within EDIINT: Multiple versions of AS2



All,

Since throwing in my own comments a few days ago, I have been watching
developments with interest.

So far, it would seem that the split is fairly even between those advocating
the splitting and those for keeping the merge but Ned now raises some
interesting points.

>From my own point of view, I don't see that creating two documents really
solve the clarity issue when a single document can be restructured to
achieve the same effect. Personally, I found the splitting of the MIME
specification over multiple documents to be a real pain when we first
started doing some work in this area.

I've been out of the deep technical loop on this for some time so please
don't shoot me if I get some things a little bit wrong...

The original split between AS1 and AS2 was purely due to the difference in
delivery mechanism - one used SMTP/POP3 and the other HTTP. Could it not be
said that this is still true today and in fact both the 'UCC' and 'Energy'
variants could be carried by either mechanism? Actually, if this is not true
then maybe it should be.

This would therefore suggest that it may be time to take a step back from
AS2 and re-think the definition of EDIINT as a whole.

It would seem to me that a possible rework of the specifications would be...

  Doc 1 - Delivery mechanisms (SMTP/POP3 and HTTP)
  Doc 2 - Enveloping (S/MIME and PGP)

There is a lot I could say on the matter but I think I'll leave it there for
initial comments.

Regards
Andrew Stickland
Manager, Technical Services
mailto:[email protected]



-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: 20 January 2003 16:38
To: [email protected]; [email protected]; [email protected]
Subject: RE: Split within EDIINT: Multiple versions of AS2



Area Director hat on...

I've been reading the comments on this issue with considerable interest. At
this point I think it is important to point out that at least two entirely
issues are being conflated here. Specifically, splitting something into two
documents doesn't mean that the two documents comprise separate
specifiations.
Nor, for that matter, does having a single document mean that there wouldn't
or
couldn't be two conformance levels to AS2.

There are plenty of examples of specifications split into multiple documents
in
the IETF. MIME, for example, is split into 5 documents, RFCs 2045-2049. I'm
not
aware of any case where this has caused problems: You frequently hear people
refer to "MIME conformance", but not "RFC 2045 conformance".

SNMP is an even better example. Here we have multiple specification
versions,
each split up into who knows how many base documents. Yet again, I've never
heard of there being a problem with peoeple claiming selective conformace to
a
specific documents within an SMNP version. (Conformance to different SNMP
versions is another matter, but we really don't want to go there...)

When I hear claims that there's a problem of clarity in the single document
--
a claim I don't think has been contested -- I start to think that splitting
things into multiple documents is worth considering. I therefore suggest
that
this issue be dealt with indepenently of what it means to conform to AS2. If
splitting the material into two documents makes it clearer it is something
that
should be done. If not, it shouldn't.

In regards to specification conformance and assuming AS2 is split into two
documents, there are all sorts of ways this could be handled:

(1) (MIME approach) Everybody has to support both documents in order to
claim
    conformance to AS2.
(2) (PL/I approach) You can support what you want and claim conformance to
    AS2(1) or AS2(2), but you cannot claim to conform to AS2 without
    supporting both.
(3) (PostScript approach) There's no such thing as conformance to AS2 as a
    whole, you implement and claim conformance to either part independently.
(4) The issue is left to other groups to address.

Of these the only one I'd have issues with is (4). The goal of IETF
specifications is interoperability. And one of the tools that's been
effective
in achieving interoperability has been conformance criteria. Therefore the
decision to abandon this tool should not be taken lightly.

I'm well aware, however, that this is a case where various other groups will
likely profile anything the IETF produces. So what the IETF says constitutes
conformance may not end up being what matters to vendors. But that's not an
excuse for not doing our jobs.

In any case, I do think that the two issues should be dealt with
independently
and the document structure issue needs to be addressed first. If nothing
else,
it would help to make it clear to everyone what's in each part.

				Ned

P.S. I've used the term "conformance" rather than "compliance" throughout
this
message. This was an intentional choice: To me, compliance tends to imply
measurement or testing will be done to insure things work as intended. But
this
is not something the IETF does, at least not directly.

*******************************************************
This email has originated from Perwill plc (Registration No. 1906964)
Office registered at: 13A Market Square, Alton, Hampshire, GU34 1UR, UK
Tel: +44 (0)1420 545000
Fax: +44 (0)1420 545001
www.perwill.com
*******************************************************
Privileged, confidential and/or copyright information may be contained
in this email, and is only for the use of the intended addressee.
To copy, forward, disclose or otherwise use it in any way if you are not
the intended recipient or responsible for delivering to him/her is
prohibited.
If you receive this email by mistake, please advise the sender immediately,
by using the reply facility in your email software.

We may monitor the content of emails sent and received via our network
for the purposes of ensuring compliance with policies and procedures.
This message is subject to and does not create or vary any contractual
relationships between Perwill plc and the recipient.
*******************************************************
Any opinions expressed in the email are those of the sender and not
necessarily of Perwill plc.
*******************************************************
This email has been scanned for known viruses using
McAfee WebShield 4.5 MR1a
*******************************************************