Rik,
I like the name changes you propose. However, I would prefer for you to send
me the source for draft 11, which will be edited and republished as
draft-ietf-as2-g-12.txt.
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: Rik Drummond [mailto:rvd2@xxxxxxxxxxxxxxxxx]
Sent: Wednesday, January 29, 2003 9:14 AM
To: 'Dick Brooks'; ietf-ediint@xxxxxxx; 'Dale Moberg'; 'Ponko, Vince'
Subject: RE: Split within EDIINT: Multiple versions of AS2
Sounds like an approach. Dick, the version ll draft is really
confusing.... You may wish to consider more than basing the next version
on it... If people are not going to use the gisb standard to implement
but the as2-g ietf draft it may cause serious problems....
I will resubmit the v12 draft with any comment changes to it, with a
change record if necessary to the ietf ediint wg as
draft-ietf-as2-u-13.txt and resubmit v11 as draft-ietf-as2-g-11.txt....
Is that appropriate? If so we can then work them in parallel....
Best regards, rik
-----Original Message-----
From: Dick Brooks [mailto:dick@xxxxxxxxxxxxx]
Sent: Tuesday, January 28, 2003 11:19 AM
To: rvd2@xxxxxxxxxxxxxxxxx; ietf-ediint@xxxxxxx; 'Dale Moberg'; Ponko,
Vince
Subject: RE: Split within EDIINT: Multiple versions of AS2
Clearly, there are two opposing viewpoints expressed by AS2
implementers. Supporters of the UCC profile favor splitting the
specification, supporters of the GISB/AIAG profile favor a single
specification. The responses thus far have indicated strong support on
both sides.
In an earlier posting, Ned Freed stated:
"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 believe we should consider taking the same approach as MIME. In an
attempt to reach consensus I propose the following course of action:
- Create two documents and call them AS2-U and AS2-G
- The draft produced by Rik and Dale will be called AS2-U
- A new draft will be created for AS2-G, which will be largely based on
the text that was removed from AS2 draft 11.
- Following the MIME model, the group will create a conformance document
along the lines of RFC 2049. This will spell out in detail what is
required to be AS2 conformant.
I believe this will address the clarity issues which Rik identified,
that ultimately led to this situation.
Does this bring us closer to agreement?
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: owner-ietf-ediint@xxxxxxxxxxxx
[mailto:owner-ietf-ediint@xxxxxxxxxxxx]On Behalf Of Ponko, Vince
Sent: Friday, January 24, 2003 10:20 AM
To: 'Dale Moberg'; 'ietf-ediint@xxxxxxx'
Subject: RE: Split within EDIINT: Multiple versions of AS2
As an implementor and interested party it is my view that
we have two separate standards and they ought to remain
that way, in part for the reasons that Dale Moberg cites
below.
-----Original Message-----
From: Dale Moberg [mailto:dmoberg@xxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, January 21, 2003 2:42 PM
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!
|
