Comments on the comments on the recent EDIINT AS2 v12 draft

My preferences for EDIINT document organization:

1.	AS1 remains as its own document.
2.	AS2 reverts to its original state, but excludes PGP formats.
3.	ASx is produced as a new document, and contains use of
multipart/form-data for metainformation (and payload), use of a special
"GISB" form of multipart/report for its acknowledgement (with its own
distinctive values in the report type), and PGP is used for its security
formats. [I prefer calling ASx, AS3.]
4.	We make no attempt to document an extension framework for AS2
and AS3 with respect to metainformation, receipt formats, or security
formats.


Rationale:

Item 4: Some developers looking for a straightforward implementation
recipe noted that the complexity of the merged AS2 and GISB document was
a barrier to understanding or, equivalently, made the specification
unclear. A lot of this complexity arose from the fact that GISB had made
quite different choices in how to do things from the original AS2
approach. For example, the original AS2 stuck metainformation in the
message headers, but GISB spread metainformation across bodyparts in a
multipart/form-data. GISB receipts included some industry specific
values not present in the basic MDN style receipt of the original AS2.
We have tried for several years to figure out ways to simplify the
documents, make the implementers' lives simpler, and arrive at a basis
for interoperability. In my opinion, the rough consensus overwhelmingly
expressed by implementers with working code was to skip the
multipart/form-data option, skip the GISB receipt option, and even skip
the PGP option. The reason for this is that if you had AS1 support of
the kind that had passed AS1 interop tests, the easiest way to move to
AS2 support was to omit PGP support, multipart/form-data support, and
either GISB receipt or generalized receipt support. 

Item 3: Once we remove 4 (and some other stuff that mentioned what
implementers could do that early list members had mentioned), there are
two unconnected implementations of secure acknowledged messaging for
business data: a GISB flavor and the original AS2 flavor. Each one of
these implementation approaches will not interoperate with the other.
It therefore makes sense to put each into its own document. 

Item 2: In order to remove overlaps in implementation options, PGP
support can be found in ASx and removed from AS2. Ironically, over time
CMS/SMIME has both become more widely implemented, and its IPR situation
has become stable. There is, on the other hand, only one major
commercial vendor for PGP and the royalty situation there is not
favorable for developers. 

General remark:

Vendors can implement AS1, AS2, or AS3 separately or together. Clearly,
AS1 only vendors won't interoperate with AS2 only products, nor will AS3
only products interoperate with AS2 or AS1 only products. If there is an
integrated AS1, AS2 and AS3 product let us hope it could interoperate
with AS1 only, AS2 only and AS3 only products. 

The question of what products will implement what flavors of EDIINT
should,
in my opinion, not influence our decisions on how to break up the
documents
we produce in this group. 

We need to have understandable useful specs, each showing a way
to realize the original EDIINT requirements for secure and acknowledged
transfer of business data.  This goal, together with the IETF
"rough-consensus andworking-code" principle, is what leads me to the
preferences I endorsed.

I do not see this as any real change in the true interoperability story,

except we will now have three flavors to keep track of, and products can
be interoperable in all flavors or just one. This will clarify product
interoperability claims and help customers choose the products they need
for their communities.