Subject: Features Profile in AS2

From: [email-masked]
Date: Mon, 5 Dec 2005 18:05:43 -0500

As Kyle mentioned in his previous message, many end users as well as the 
GS1 technology group (ecGIF) want additional features in AS2 software 
systems to help manage operational complexity. In order to handle new AS2 
Features such as the Certificate Exchange Message, AS2 Reliability, and 
Multiple Attachments; we first need to ensure that AS2 software systems 
using new Features will not cause problems for existing AS2 systems. 

I believe that new AS2 systems need:

a) a header telling other AS2 systems with which they correspond that they 
support new Feature(s), and if the other AS2 systems also support new 
Features,
b) a header (e.g. EDIINT?Features) advising which Feature(s) the new AS2 software system supports, and
c) an expanded "profile" capability to keep track of the status of items 
(a) & (b) for each AS2 system with which it communicates.

I'm proposing a variation of Kyle's option #2  (using a new header, e.g. EDIINT?Features):

1. AS2 systems supporting any new Feature would use AS2?Version 1.2. This 
will tell other AS2 version 1.2 systems that they can send the 
EDIINT?Features header to a system also using AS2?Version 1.2.  Version 1.0 and 1.1 systems could successfully receive 
an AS2?Version 1.2 header, but version 1.2 systems would not send them the 
EDIINT?Features header.

2. The EDIINT?Features header would indicate which Feature(s) a sending system supports. 

3. An AS2?Version 1.2 system would keep track in a "profile" for every other AS2 system with 
which it communicates:
-  the AS2?Version number of that system, and if applicable,
- the EDIINT?Feature(s) that the system supports

Please let me know your thoughts about this proposal, and any issues that 
you may see with it.
 
John Duker
e-Commerce Specialist
Procter & Gamble
and
Chair GS1 ecGIF

----- Forwarded by John Duker-JP/PGI on 12/05/2005 05:19 PM -----

"Kyle Meadors" <[email-masked]>
Sent by: [email-masked]
12/01/2005 12:04 PM

        To:     <[email-masked]>
        cc: 
        Subject:        profiles in AS2
I am needing the opinion of the AS2 community on the use of a feature 
profiles within AS2. Back in 2002, compression was added as an extra 
feature. Using "AS2?Version: 1.1" in a message indicated the UA could 
support compression even if the actual message did not contain the 
compressed envelope. This assisted implementers in knowing if their 
trading partners could support compression. 
  
Moving to the present, users are requesting new features. These include 
I?Ds for Reliability (from GS1), Multiple?Attachments (oil & gas users) 
and Certificate Exchange Messaging (Wal?mart, P&G and others GS1 
companies). Given AS2's adoption, I am sure there will be others in the 
future. 
  
My question to those on this elist is how to do move forward with new 
features. What do we do to insure only those who support a feature receive 
it (e.g., only sending CEM message to trading partners who support that 
profile)? Also, can anything be done to insure backward compatibility to 
keep new Feature Header messages from being sent to & breaking older, 
existing implementations (e.g. older implementation errors gracefully when 
getting an unrecognized MA message). 
  
Here are some options. I would like to hear your thoughts on what is best 
or other ideas. 
 
1. Use AS2?Version header to indicate UA support of profiles (e.g. 1.2 
indicates CEM, 1.3 indicates CEM, Reliability). Works like compression 
(e.g. "1.2" indicates capability of CEM but not an actual CEM message).
 
2. Use a new header, e.g. EDIINT?Features. The features header shows all 
features supported by UA (e.g. EDIINT?Features: CEM, multiple?attachment) 
but like AS2?Version does not indicate every message contains profile.
 
3. Use a new header for each feature which is present ONLY in the message 
using that feature. For example, "CEM?Profile" for CEM messages. This 
could allow receiving UA to filter in only profiles it recognizes.
 
4. Create a "Capability Query" AS2 Message which returns a Capability MDN. MDN indicates what features receiving UA can support.

Kyle Meadors
Principal, Test Process
Drummond Group Inc.
615.212.0826