Dale,
Thank-you for your response (and Dick Brooks' as well).
Rest assured that I did not intend to cast any dispersions on the authors or
editors or the work done to date.
My preference for a single document is based on the issue that there are
areas of both 'flavours' of AS2 implementation that are the same. If the
document is split then these common areas would be duplicated and there is a
danger of diversification. I hold my hand up right now and state that I have
not dug through the document to see what this would mean - I'm simply
raising the point (in any case, see below).
As I said, I've not been technically involved in EDIINT for some time and my
thanks for the overview/update.
You're absolutely correct in that there are fundamental differences in the
communications methods. My apologies in that I had intended to phrase my
comments more as a question than a proposal. The root of my 'question' is
that, in principle, we take a very modular approach to things such as this.
For example, the module that sends and receives data through HTTP is the
same for AS2 and ebXML. The preparation of data to send and handling of data
received occurs in other modules depending on the 'delivery' protocol (AS2,
ebXML etc.).
Having seen the various responses and revisited the IETF standards process,
I'm going to turn around and conclude that the split needs to happen -
things are too different.
Both camps have stated that there is very little in common between the two
variants other that the high-level framework. There was a suggestion that
the variants could be called AS2(1) and AS2(2) (or similar) but if the
differences are that great then I don't think this is appropriate.
At the risk of creating more angst (but with a view to preventing a battle
over which variant keeps the name AS2), is it time to put AS2 to sleep and
create AS3 & AS4?
Regards
Andrew Stickland
Manager, Technical Services
mailto:andrew.stickland@xxxxxxxxxxx
-----Original Message-----
From: Dale Moberg [mailto:dmoberg@xxxxxxxxxxxxxxxxxxx]
Sent: 21 January 2003 19:42
To: ietf-ediint@xxxxxxx
Cc: Andrew Stickland
Subject: RE: Split within EDIINT: Multiple versions of AS2
Andrew Strickland wrote:
"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. "
Dale Moberg>> I hope you had a chance to review some earlier messages in
which I explained how the integration framework (also describable as the
extension framework) created confusion and was what we wanted to remove.
I think your opinion, expressed above, is one with which I do not agree.
However, I suspect it will be necessary to go into some technical
matters here in greater detail because the restructuring of which you
dream is not one we foresee working (unless we have two distinct specs
concatenated into one document-that might work except for confusing or
annoying current implementers about what it means to implement what is
in the document.)
GISB introduced the idea of placing metainformation about a business
data payload into separate body parts of a MIME entity in a POSTed HTTP
PDU. The reason for this is that GISB wanted to be able to make use of a
HTTP/HTML browser in sending data. Browsers typically cannot add HTTP
headers, so an entirely new implementation technique was introduced to
convey metainformation. These interactive browser limitations have never
played well with AS2 as it originally was speced by this working group.
We introduced the unification framework-the agreed upon source of most
of the confusion we hope to eliminate-in order to put both approaches
into one document. You now propose some unspecified restructuring that
will solve the clarity issue by reintroducing some unification
perspective. I am not hopeful and several years of having several
authors and editors work on this suggests that a clean break with this
approach is much more promising. Let me elaborate some of the problems
that having them together creates:
Should the multipart/form-data way of formatting metainformation also be
useable with the original POST of the core EDIINT security formats or
should it be restricted to when you also use the GISB receipt mechanism
and/or PGP based formats (open pgp)?
Should transport headers be used to convey GISB metainformation instead
of bodyparts in a multipart/form-data? How much should we mix and match
the mechanisms? Can you supply both? When both are used, and the same
metainformation item has different values, which one do you mean?
Perhaps "confusion" is the wrong word here. Implementers basically just
did not want to have to implement with this degree of generality and
complexity and called what they did not want to do, "confusing". We
believe they have a point. In point of fact, no one has implemented a
fully general unified AS2 as it is now written. They have picked and
chosen one or the other of the two "parts" they find in it (actually you
should see that the "two parts" phrase already embodies a
misunderstanding). Given that this is what we have ended up having in
working code, we just want to get rid of the complexity and break the
two implemented specs out into separate documents, each of which can be
implemented independently of the other, and both of which can be done by
a single product.
Andrew continues writing:
"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."
Dale Moberg>> I will not shoot you, but I think you are laboring under
serious oversimplifications of the technical issues involving in using
SMTP versus using HTTP. There are, I suppose, ways that the variants
(and we will here adopt the simplification which we are hoping to make
true)-the _two_ AS2 variants "could" be carried by either mechanism. For
example, one could ignore the HTTP specification and used
content-transfer-encodings and put them in the HTTP MIME entity. [Not a
good thing for an IETF working group to do, and not something endorsed
here, by the way Ned.) Or, you could make certain that you used ESMTP
mechanisms to make certain your MTAs handled binary content-transfer
encodings (with arbitrarily long strings of octets without a CRLF), and
maybe omit the content-transfer-encoding header (to conform to HTTP
recommended practice). These are not prerequisites we are interested in
enforcing for business users; we want them to be able to use existing
available MTAs and webservers when possible.
In other words, Andrew, the MIME of HTTP and of SMTP and its cousins
differ in some basic ways that frustrates having byte-for-byte identical
PDUs. If you wish to invent a PDU that has this property, please submit
your proposal (and we will shoot it, not you, down.)
Add to the MIME differences, the differences in header conventions! Or
the defaults that govern omitted headers (omit the content-type in mail,
and text/plain (with a 7-bit cte) will be assumed but in HTTP the cte is
as always binary, with a content-type of text/html. Or the fact that
"From" is given different semantic functions as a header.
The result is that while we have had the goal of keeping the PDUs
similar in AS1 and AS2, the existing standards themselves upon which we
are building do not allow identical PDUs to be used. Since we mainly are
describing or profiling PDUs in AS1 and AS2, keeping the profiles in
separate documents is and will remain a far cleaner way to proceed.
While your idea is not silly (it is one we aspired to and which we
asymptotically approached until we added the GISB techniques), in
practice it cannot be realized. I do not want to spend time revisiting
these issues, as they were ironed out over 4 years ago. I would very
strongly oppose trying to follow the regroupings you propose later in
your message at this point; it would definitely not remove the
confusions we wish to remove and would in all likelihood create new ones
to boot!
*******************************************************
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
*******************************************************
|
