I have to agree with Michael and Andrew on this point. Having "standards" split
into 2 or 3 different subsets gets confusing and messy and costly.
Working in the retail industry and EDI I see this mess with X12 standards and
it's children VICS and UCS. We have to use UCS for our grocery suppliers, VICS
for general merch and X12 for carriers
Having to maintain multiple sets of standards is very messy and costly
>>> "Costa, Michael J." <CostaM@xxxxxxxxx> 01/16/03 08:52AM >>>
Mr.. Strickland makes the following point is his note.
"We certainly have companies that talk across industries (including retail and
energy) and to have to use two different standards would be nothing less than
ludicrous."
A very accurate point. As I utility I exchange data with retail chains,
educational institutions, government agencies, etc. By definition doesn't a
standard imply that we "should" all operate the same way? I do not in anyway
want to support two differing standards to accomplish the same end result.
Dick's comment that the energy industry is confused is a little bit of an
understatement. To be somewhat more accurate, we are confused and angry! We
are all spending a great deal of money to comply with orders from our local
commissions and we wonder how much of that money will need to be spent again?
We need to find a middle ground and we need to find it soon.
My humble opinion for what it is worth...
____________________________________________________
Michael Costa
Systems Specialist
IR -Network Systems
Mail To: costam@xxxxxxxxx
Voice Mail: 212.460.2994
Pager: 917.360.3197
-----Original Message-----
From: Andrew Stickland [mailto:Andrew.Stickland@xxxxxxxxxxx]
Sent: Thursday, January 16, 2003 6:11 AM
To: ietf-ediint@xxxxxxx
Subject: RE: Comments on the recent EDIINT AS2 v12 draft
All,
I've long been a participant of this group and rarely provided any input but I
have to say that I am deeply concerned about the rift that has just appeared.
One could ask what is the point of a independent and global standards body that
defines industry centric 'standards'.
We certainly have companies that talk across industries (including retail and
energy) and to have to use two different standards would be nothing less than
ludicrous.
Any moves away from a 'global' strategy will surely lay the foundations for
failure of EDIINT as a broadly accepted standard. While certain industries have
implemented EDIINT already, as they need to expand their data exchange
capabilities, they are likely to turn away from anything that does not give
them flexibility.
All that aside, we tend to consider EDIINT (AS1 & 2) as one package so we might
have a competitive edge over suppliers who narrow their options.
Regards
Andrew
-----Original Message-----
From: Dick Brooks [mailto:dick@xxxxxxxxxxxxx]
Sent: 16 January 2003 05:00
To: Gary Crough; ietf-ediint@xxxxxxx
Subject: RE: Comments on the recent EDIINT AS2 v12 draft
Gary, my comments are inline bounded by <db> and </db>.
All,
There is a subset of AS2 which has gone through formal interoperability
trials. These trails are currently sponsored by the UCC (packaged goods
industry) and UCC member companies are major consumers of this software.
There is also a subset of AS2 (v11 specification) used within the Energy
industry.
<db> The above statements may lead one to believe that formal interoperability
testing has occurred on the UCC subset of AS2 but no interoperability testing,
formal or informal, has occurred on the Energy industry's use of AS2.
Quite the contrary, there are hundreds of interoperable implementations of AS2
operating in production systems within the Energy industry. There are tens of
thousands of transactions exchanged daily. These transactions are mission
critical, and are considered part of the critical infrastructure by the United
States Federal Government. I don't know what more proof is needed to
demonstrate interoperability of AS2 in the Energy industry than the fact that
thousands of transactions are being exchanged daily. .If your gas stove is
working and your lights turn on, chances are good the Energy industries use of
AS2 is "interoperating" properly.
</db>
My belief is: software supporting one AS2 subset is NOT interoperable with
software supporting the other subset. The packaged goods industry and the
Energy industry have standardized on different subsets of the "AS2
specification". The planned EDIINT/HL7/GISB/AIAG convergence did not happen.
If we agree on this, the most important thing is to avoid confusing end
users.
<db>I'm afraid this latest "change" to AS2 has done more to confuse end users
than anything in the recent past. I've had several conversations with people
from around the Energy industry regarding this situation, trust me - they are
confused by this latest action.
It's also worth noting that software vendors can reasonably implement the full
range of functionality defined in AS2 to support the UCC and Energy industries.
There is nothing preventing vendors from supporting OpenPGP and S/MIME crypto
and RFC2388 and AS2/e-mail packaging (using the AS2-From and AS2-To HTTP
headers) and the multipart report types defined in MDN and the generalized
receipt delivery type defined in AS2.
The interoperability issue you describe is "self inflicted" by certain parties
that have misled vendors into believing that they only have to support a subset
of AS2 to be "certified".
</db>
The moves by Rik to "clean up" the subset of the AS2 specification used by
the UCC was appropriate for that community. There was pressure from end users
to move in this direction.
<db>So, you're saying it was the UCC end users that wanted the Energy industry
portions of AS2 removed. Would it have been acceptable if the Energy industry
end users changed AS2 to remove the UCC portions?
IMO, Rik did not "clean up" the AS2 specification. He has created a bifurcation
of AS2 that virtually guarantees the propagation of interoperability issues. If
allowed to continue this will result in separate "specifications", possibly one
spec per industry group.
If UCC wants to have it's own separate spec then it should consider developing
one under it's own process. The IETF process is all about consensus. The Energy
and Automotive industries joined in the IETF effort in good faith with the
belief that the open consensus process would produce a result that could
benefit many parties.
</db>
But this "AS2 cleanup" removed portions of the specification critical to the
Energy industry. Ideally, a parallel AS2 cleanup for the Energy industry would
have happened at the same time. I know this is an oversimplification but
perhaps Rik should have created an EDIINT(S/MIME) and an EDIINT(PGP/MIME) as
children of EDIINT AS2.
I favor splitting the old AS2 specification into two separate
specifications and accept the v12 draft as one of the specifications.
Dick's insinuation that Drummond Test Plans become de-facto standards is
correct. Further, the v12 draft modifies the AS2 specification around that
test plan. As Dick stated these changes were outside of IETF process. Still,
I have no problem with them ... my goal is to meet end user needs and I think
the v12 draft is a move in the right direction. It's NOT to late to go through
the IETF process?? Let's just view the v12 (Drummond) draft as a proposal and
get some input. Those most interested in a v12(GISB) draft should take the
lead in its creation ... maybe they keep the v11 draft and require PGP/MIME and
S/MIME or maybe they throw out S/MIME.
<db>This proposed solution, where two separate specs are created to serve the
same purpose, is what you are suggesting to ensure interoperability. I fail to
see the logic in this proposal.
As I see it your proposal will result in the creation of one specification for
the retail industry and another for the energy industry. If Dave Crocker and
Jonathan Postel had used this rational back in the 80's when they were working
on e-mail you would need to use different e-mail implementations to communicate
with different industries today. I for one am glad that there is only one SMTP
and addressing standard.
I hope others in this community see the same longer term flaws in this proposed
"splitting off" of AS2 that I see.
</db>
Hopefully, EDIINT members will weigh in on:
1 Do you support the spin-off of the AS2 v11 specification into a version
focused on UCC (packaged goods) requirements?
2 Should the Energy industry stick with the v11 base or do its own clean up?
3 Do you have an opinion on the names which should be assigned?
<db>I believe it would also be beneficial to hear from some experienced IETF
folks regarding this proposed split up. Is there a precedence for efforts that
split midway through development. If so, what was the outcome? What is the IETF
position regarding competing specifications that perform the same function
using two different (non-interoperable) approaches?
</db>
Dick Brooks
Systrends, Inc
7855 South River Parkway, Suite 111
Tempe, Arizona 85284
Web: www.systrends.com < http://www.systrends.com <http://www.systrends.com/> >
Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714
*******************************************************
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
*******************************************************
|
