Features Profile in AS2

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" <kyle@xxxxxxxxxxxxxxxxx> Sent by: owner-ietf-ediint@xxxxxxxxxxxx 12/01/2005 12:04 PM

To:        <ietf-ediint@xxxxxxx>         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