Subject: RE: Split within EDIINT: Multiple versions of AS2

From: "Terry Vaughn" <[email-masked]>
Date: Mon, 20 Jan 2003 10:00:15 -0600

Hello.

I am following this discussion thread with interest.  Although I am not fully versed in the difficulties of merging AS2(ucc) with AS2(other), I am nevertheless an advocate of unification efforts.  I believe if it's remotely "feasible" to achieve a single standard, then the responsible community should proactively strive for that standard.  The current state of internet technologies has enough entropy without contributing to the forward momentum by NOT making an effort to consolidate standards.

Terry Vaughn
Interested Party

>>> "Gary Crough" <[email-masked]> 01/17/03 01:33PM >>>

Dick,
	This is starting to remind me of a Pro-Life vs Anti-Abortion debate.  No one is anti-life or pro-abortion.  
	I, along with everyone else, favor of a single EDIINT standard ... and am opposed to gravity!  But a single AS2 standard does NOT exist and gravity does.  I choose to face reality.  AS2(UCC) and AS2(GISB) are very different things using the same name.
	As you know, Dale M (and Terry H) participated on the GISB/HL7/EDIINT/AIAG convergence team ... their goal was to converge the various standards.  Over 3 years later the EDIINT task force is not much closer to converging GISB into the original AS2 than they were on day 1.  The two specifications were placed in a single document but little other "convergence" took place.  The differences between AS2(GISB) and AS2(S/MIME) are substantial.  So much so, that any vendor choosing to offer both would implement the two separately and allow trading partners to be configured to use one or the other.  That is how convergence is going to happen.  Do you disagree????
	
	The demand for secure Internet trading was such that it did not wait on the slow-moving EDIINT AS2 conversion effort.  Last year, several hundred AS2 installations went into the packaged goods, healthcare, financial and transportation industries.  In the packaged goods industry alone several thousand AS2 installations are anticipated this year.  In all cases these installations will be incompatible with hundreds of AS2 installations within the Energy industry and vice versa.  Why  pretend otherwise?
	
	Most interested parties are yet to be heard from.  The EDIINT workgroup has been quite for some time.  Let's give people a couple of weeks to wake up and chime in.  And there is now a more important interest group: users.  Maybe we can get some input from them.

-----Original Message-----
From: Dick Brooks [mailto:[email-masked]] 
Sent: Thursday, January 16, 2003 10:08 PM
To: [email-masked] 
Subject: RE: Split within EDIINT: Multiple versions of AS2

It seems clear from the comments provided that Cyclone Software (represented
by Dale Moberg and Gary Crough) and Rik Drummond oppose a single AS2
standard for exchanging EDI/XML data.

On the other hand we've heard from Andrew Strickland, Mike Costa, Steve
Lowery, Wayne Mackintosh, and myself who appear in favor of developing a
single AS2 standard for exchanging EDI/XML data.

I believe we must resolve this issue before we can move on and address the
deeper technical issues.

Based on the comments provided thus far, there appears to be more support
behind developing a single AS2 standard. However we've only heard from a
relatively small subset of the EDIINT community.

I believe more community input is needed to help the EDIINT workgroup decide
how to proceed  - should the group develop one standard or multiple
standards to exchange EDI/XML data over HTTP?

Your opinions are important, please give the group the help it needs to make
the proper decision going forward.

Thanks,

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-masked] 
[mailto:[email-masked]]On Behalf Of Gary Crough
Sent: Thursday, January 16, 2003 1:09 PM
To: [email-masked] 
Subject: Split within EDIINT: Multiple versions of AS2

All,
	For some time now EDIINT has been split into AS1 and AS2.  These "subsets"
did not upset anyone.  Why the uproar over a suggestion to create another
subset?

	When UCC companies demand trading partners use EDIINT AS2 (and many do)
they mean the EDIINT "AS2" subset certified by the UCC ... AS2 using S/MIME
and compression options.  But within the energy industry "AS2" means
PGP/MIME not S/MIME.
	AS2 subsets already exist.  The Energy industry (> 100 installations) uses
one subset of EDIINT AS2 and the packaged goods, healthcare, financial, high
technology and transportation industries (> 1000 installations) uses
another; currently the two AS2 subsets are incompatible.  Pretending
otherwise is creating considerable confusion in the user community.

	Using Dale Moberg's proposed terms ...AS1, AS2 (UCC certified) and ASx (PGP
version): there is no reason a vendor can't support EDIINT AS1, AS2 and ASx.
Such a vendor could claim to support all major subsets of EDIINT.  Further,
such a vendor would create convergence ... enabling trading between
industries which standardized on different subsets.
	With clear subsets within the EDIINT specification, there is no requirement
for a small company like iSoft, the WalMart AS2 vendor, to support AS1 or
ASx since WalMart dictates UCC-certified AS2 interfaces.

Gary Crough
Cyclone Commerce, Inc.
8388 E. Hartford Drive, Scottsdale, AZ 85255
Office: 480-627-8780        Cell: 602-885-9010

---

From: [email-masked]
Date: Mon, 20 Jan 2003 08:38:11 -0800 (PST)

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.