Features Profile in AS2
[email protected] Mon, 5 Dec 2005 18:05:43 -0500
| Newsgroups | gmane.ietf.ediint |
|---|---|
| Message-ID | <OF37C323C1.0A4475FB-ON852570CE.0070FC3B-852570CE.007EDF62@na.pg.com> |
This is a multipart message in MIME format. --=_alternative 007EDEFB852570CE_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As Kyle mentioned in his previous message, many end users as well as the=20 GS1 technology group (ecGIF) want additional features in AS2 software=20 systems to help manage operational complexity. In order to handle new AS2=20 Features such as the Certificate Exchange Message, AS2 Reliability, and=20 Multiple Attachments; we first need to ensure that AS2 software systems=20 using new Features will not cause problems for existing AS2 systems.=20 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=20 Features, b) a header (e.g. EDIINT?Features) advising which Feature(s) the new AS2 so= ftware system supports, and c) an expanded "profile" capability to keep track of the status of items=20 (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. ED= IINT?Features): 1. AS2 systems supporting any new Feature would use AS2?Version 1.2. This=20 will tell other AS2 version 1.2 systems that they can send the=20 EDIINT?Features header to a system also using AS2?Version 1.2. Version 1.0= and 1.1 systems could successfully receive=20 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 sys= tem supports.=20 3. An AS2?Version 1.2 system would keep track in a "profile" for every othe= r AS2 system with=20 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=20 you may see with it. =20 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 protected]> Sent by: [email protected] 12/01/2005 12:04 PM =20 To: <[email protected]> cc:=20 Subject: profiles in AS2 I am needing the opinion of the AS2 community on the use of a feature=20 profiles within AS2. Back in 2002, compression was added as an extra=20 feature. Using "AS2?Version: 1.1" in a message indicated the UA could=20 support compression even if the actual message did not contain the=20 compressed envelope. This assisted implementers in knowing if their=20 trading partners could support compression.=20 =20 Moving to the present, users are requesting new features. These include=20 I?Ds for Reliability (from GS1), Multiple?Attachments (oil & gas users)=20 and Certificate Exchange Messaging (Wal?mart, P&G and others GS1=20 companies). Given AS2's adoption, I am sure there will be others in the=20 future.=20 =20 My question to those on this elist is how to do move forward with new=20 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=20 profile)? Also, can anything be done to insure backward compatibility to=20 keep new Feature Header messages from being sent to & breaking older,=20 existing implementations (e.g. older implementation errors gracefully when = getting an unrecognized MA message).=20 =20 Here are some options. I would like to hear your thoughts on what is best=20 or other ideas.=20 =20 1. Use AS2?Version header to indicate UA support of profiles (e.g. 1.2=20 indicates CEM, 1.3 indicates CEM, Reliability). Works like compression=20 (e.g. "1.2" indicates capability of CEM but not an actual CEM message). =20 2. Use a new header, e.g. EDIINT?Features. The features header shows all=20 features supported by UA (e.g. EDIINT?Features: CEM, multiple?attachment)=20 but like AS2?Version does not indicate every message contains profile. =20 3. Use a new header for each feature which is present ONLY in the message=20 using that feature. For example, "CEM?Profile" for CEM messages. This=20 could allow receiving UA to filter in only profiles it recognizes. =20 4. Create a "Capability Query" AS2 Message which returns a Capability MDN. = MDN indicates what features receiving UA can support. =20 =20 Kyle Meadors Principal, Test Process Drummond Group Inc. 615.212.0826 --=_alternative 007EDEFB852570CE_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <br><font size=3D2 face=3D"sans-serif">As Kyle mentioned in his previous me= ssage, many end users as well as the GS1 technology group (ecGIF) want addi= tional features in AS2 software systems to help manage operational complexi= ty. In order to handle new AS2 Features such as the Certificate Exchange Me= ssage, AS2 Reliability, and Multiple Attachments; we first need to ensure t= hat AS2 software systems using new Features will not cause problems for exi= sting AS2 systems. </font> <br> <br><font size=3D2 face=3D"sans-serif">I believe that new AS2 systems need:= </font> <br> <br><font size=3D2 face=3D"sans-serif">a) a header telling other AS2 system= s with which they correspond that they support new Feature(s), and if the o= ther AS2 systems also support new Features,</font> <br><font size=3D2 face=3D"sans-serif">b) a header (</font><font size=3D2 f= ace=3D"Arial">e.g. EDIINT–Features</font><font size=3D2 face=3D"sans-= serif">) advising which Feature(s) the new AS2 software system supports, an= d</font> <br><font size=3D2 face=3D"sans-serif">c) an expanded "profile" c= apability to keep track of the status of items (a) & (b) for each AS2 s= ystem with which it communicates.</font> <br> <br><font size=3D2 face=3D"sans-serif">I'm proposing a variation of Kyle's = option #2 (</font><font size=3D2 face=3D"Arial">using a new header, e= .g. EDIINT–Features):</font> <br> <br><font size=3D2 face=3D"Arial">1. AS2 systems supporting any new Feature= would use AS2–Version 1.2. This will tell other AS2 version 1.2 syst= ems that they can send the EDIINT–Features header to a system also us= ing AS2–Version 1.2. Version 1.0 and 1.1 systems could successf= ully receive an AS2–Version 1.2 header, but version 1.2 systems would= not send them the EDIINT–Features header.</font> <br> <br><font size=3D2 face=3D"sans-serif">2. The </font><font size=3D2 face=3D= "Arial">EDIINT–Features</font><font size=3D2 face=3D"sans-serif"> hea= der would indicate which Feature(s) a sending system supports. </font> <br> <br><font size=3D2 face=3D"sans-serif">3. An </font><font size=3D2 face=3D"= Arial">AS2–Version 1.2</font><font size=3D2 face=3D"sans-serif"> syst= em would keep track in a "profile" for every other AS2 system wit= h which it communicates:</font> <br><font size=3D2 face=3D"sans-serif">- the </font><font size=3D2 fa= ce=3D"Arial">AS2–Version</font><font size=3D2 face=3D"sans-serif"> nu= mber </font><font size=3D2 face=3D"Arial">of that system, and if applicable= ,</font> <br><font size=3D2 face=3D"Arial">- the EDIINT–Feature(s) that the sy= stem supports</font> <br> <br><font size=3D2 face=3D"Arial">Please let me know your thoughts about th= is proposal, and any issues that you may see with it.</font> <br><font size=3D2 face=3D"sans-serif"> </font> <br><font size=3D2 face=3D"sans-serif">John Duker</font> <br><font size=3D2 face=3D"sans-serif">e-Commerce Specialist</font> <br><font size=3D2 face=3D"sans-serif">Procter & Gamble</font> <br><font size=3D2 face=3D"sans-serif">and</font> <br><font size=3D2 face=3D"sans-serif">Chair GS1 ecGIF</font> <br> <br><font size=3D1 color=3D#800080 face=3D"sans-serif">----- Forwarded by J= ohn Duker-JP/PGI on 12/05/2005 05:19 PM -----</font> <br> <table width=3D100%> <tr valign=3Dtop> <td> <td><font size=3D1 face=3D"sans-serif"><b>"Kyle Meadors" <kyle= @drummondgroup.com></b></font> <br><font size=3D1 face=3D"sans-serif">Sent by: [email protected].= org</font> <p><font size=3D1 face=3D"sans-serif">12/01/2005 12:04 PM</font> <br> <td><font size=3D1 face=3D"Arial"> </font> <br><font size=3D1 face=3D"sans-serif"> To: &nbs= p; <[email protected]></font> <br><font size=3D1 face=3D"sans-serif"> cc: &nbs= p; </font> <br><font size=3D1 face=3D"sans-serif"> Subject:= profiles in AS2</font></table> <br><font size=3D2 face=3D"Arial">I am needing the opinion of the AS2 commu= nity 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 me= ssage did not contain the compressed envelope. This assisted implementers i= n knowing if their trading partners could support compression.</font><font = size=3D3 face=3D"Times New Roman"> </font><font size=3D2 face=3D"Arial"><br> </font><font size=3D3 face=3D"Times New Roman"> </font><font size=3D2= face=3D"Arial"><br> Moving to the present, users are requesting new features. These include I&#= 8211;Ds for Reliability (from GS1), Multiple–Attachments (oil & g= as users) and Certificate Exchange Messaging (Wal–mart, P&G and o= thers GS1 companies). Given AS2's adoption, I am sure there will be others = in the future.</font><font size=3D3 face=3D"Times New Roman"> </font><font = size=3D2 face=3D"Arial"><br> </font><font size=3D3 face=3D"Times New Roman"> </font><font size=3D2= face=3D"Arial"><br> My question to those on this elist is how to do move forward with new featu= res. 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 F= eature Header messages from being sent to & breaking older, existing im= plementations (e.g. older implementation errors gracefully when getting an = unrecognized MA message).</font><font size=3D3 face=3D"Times New Roman"> </= font><font size=3D2 face=3D"Arial"><br> </font><font size=3D3 face=3D"Times New Roman"> </font><font size=3D2= face=3D"Arial"><br> Here are some options. I would like to hear your thoughts on what is best o= r other ideas.</font><font size=3D3 face=3D"Times New Roman"> </font><font = size=3D2 face=3D"Arial"><br> </font> <br><font size=3D2 face=3D"Arial">1. Use AS2–Version header to indica= te UA support of profiles (e.g. 1.2 indicates CEM, 1.3 indicates CEM, Relia= bility). Works like compression (e.g. "1.2" indicates capability of CEM but= not an actual CEM message).</font> <br><font size=3D2 face=3D"Arial"> </font> <br><font size=3D2 face=3D"Arial">2. Use a new header, e.g. EDIINT–Fe= atures. 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.</font> <br><font size=3D2 face=3D"Arial"> </font> <br><font size=3D2 face=3D"Arial">3. Use a new header for each feature whic= h is present ONLY in the message using that feature. For example, "CEM̵= 1;Profile" for CEM messages. This could allow receiving UA to filter in onl= y profiles it recognizes.</font> <br><font size=3D2 face=3D"Arial"> </font> <br><font size=3D2 face=3D"Arial">4. Create a "Capability Query" AS2</font>= <font size=3D2 color=3D#000080 face=3D"Arial"> </font><font size=3D2 face= =3D"Arial">Message which returns a Capability MDN. MDN indicates what featu= res</font><font size=3D2 color=3D#000080 face=3D"Arial"> </font><font size= =3D2 face=3D"Arial">receiving UA can support.</font> <br><font size=3D2 face=3D"Arial"> </font> <br><font size=3D2 face=3D"Arial"> </font> <br><font size=3D2 face=3D"Arial">Kyle Meadors</font> <br><font size=3D2 face=3D"Arial">Principal, Test Process</font> <br><font size=3D2 face=3D"Arial">Drummond Group Inc.</font> <br><font size=3D2 face=3D"Arial">615.212.0826</font> --=_alternative 007EDEFB852570CE_=--