RE: profiles in AS2
[email protected] Tue, 20 Dec 2005 16:47:06 -0500
| Newsgroups | gmane.ietf.ediint |
|---|---|
| Message-ID | <OFD537B73B.EC09827E-ON852570DD.00759155-852570DD.0077AE4A@na.pg.com> |
This is a multipart message in MIME format. --=_alternative 0077AD75852570DD_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Scott & Rik, While I understand that EDIINT-Features, CEM, & AS2-Reliability are not=20 technically part of the charter of the EDIINT WG, they are intended to=20 improve the usability and expand the use of AS1, AS2, & AS3.=20 Is it possible to either keep the WG open while these drafts are resolved, = or at least keep the elist open to maintain the group of interested=20 participants? Thanks for your consideration. John Duker P&G "Kyle Meadors" <[email protected]> Sent by: [email protected] 12/20/2005 11:29 AM =20 To: <[email protected]> =20 Subject: RE: profiles in AS2 The closing of WG is decision to be made by Rik Drummond and Scott=20 Hollenbeck. Discussion on EDIINT?Features, CEM and the like are peripheral = to EDIINT but not part of the charter. When EDIINT charter is complete,=20 and only a decision on AS3 is remaining, the elist will be closed as well. = =20 However, it is open for the time being ? let's continue to use this space=20 for this discussion. We have only heard from a relative handful of=20 individuals ? can others chime in?=20 =20 Kyle Meadors DGI From: Richard Bigelow [mailto:[email protected]]=20 Sent: Monday, December 19, 2005 12:56 PM To: Dale Moberg; Kyle Meadors; [email protected] Subject: RE: profiles in AS2 Concerning a 1.2 version interoperating with a 1.1 version: The 1.1=20 version should accept the 1.2 messages. The compression draft says that a = version of 1.1 or greater indicates compression.=20 =20 I have some concern about Kyle's comment that this WG may be closing soon. = Is this in response to IETF's requirement to make progress on AS3? I=20 hope that this WG will continue. We have some proposals on the table,=20 including Reliability and CEM and perhaps Profiles in the future. =20 =20 Richard Bigelow Inovis [email protected] From: [email protected] [mailto:[email protected]= ] On Behalf Of Dale Moberg Sent: Saturday, December 17, 2005 7:49 AM To: Kyle Meadors; [email protected] Subject: RE: profiles in AS2 =20 The consensus seems to be that it should be possible to support some AS2=20 features independently, rather than cumulatively. Although I think the=20 combinations of features of Reliability, CEM, and Multipart could be coded = up by 8 numbers, if more end user requirements get specified, that=20 encoding would become inconvenient to support. So moving to an=20 EDIINT-Features header seems to be a reasonable way to advertise=20 capabilities. =20 Would AS1, AS2 and AS3 all use this header? I assume that CEM and=20 attachments are OK, but Reliability mainly pertains to AS2. Also, would=20 AS1 have to add an "X-" preface to the header? (So we would have=20 somemething like "X-EdiintFeatures" as the header value?) =20 I take it that there is some concern about the waste of sending this=20 header every time and that partially motivates inventing new behavior to=20 supply these values in a MDN (when requested). While that might be more=20 elegant, I guess the logic would be that you can only use that form of=20 request when the original has an AS2-Version of "1.2"? My preference here=20 is not to try to develop option 4 into a new capability query and response = pattern, but just accept that the Ediint-Features header may waste a few=20 bytes per message.=20 =20 How will existing applications respond to this? Presumably they would (or=20 should) ignore an included "EdiintFeatures" header and also never send=20 one. If they never sent one (and their ASx-version was either 1.0 or 1.1), = then they must not be sent multiparts or CEM. In that case, messages with=20 the new features would not even be sent to older applications and could=20 not cause them to malfunction. So it should be stated that you may not use = these features unless the other side both has a version value greater than = 1.1 and also has included the feature in its EdiintFeatures header. =20 What should be said about a 1.2 version interoperating with a 1.1 version? = Since a 1.1 level app. would be entitled to ignore a message with a higher = version, should a 1.2 app be advised to be configurable to advertise=20 itself as a 1.1 version to promote interoperation? =20 What should be done about detecting a change (upgrade) of versions when=20 the other side begins sending the higher "1.2" value? Are implementations=20 expected to check the version or is this left to the implementation?=20 Richard B. says "A should update some state for every message received=20 from B" I think it would be sufficient to check the state and update if a=20 change is noticed. (Maybe that is what Richard meant though.) I suppose an = empty message could be sent to announce a change in capabilities, but=20 again only to ediint agents with a version greater than 1.1. =20 So far the specifications have not really required that the version be=20 checked for every message. For example, the AS3 draft says=20 =20 The AS3-Version header is a header which is required only if the value of the header is not "1.0". Its purpose is to allow systems to=20 determine which version of this specification, should the specification evolve over time, the sender of a document has used to package the document. A user agent MUST NOT reject a message if the=20 version header is missing. =20 AS3-Version: 1*DIGIT . 1*DIGIT =20 A version header value of "1.1" indicates an implementation can support EDIINT data compression [18]. A user agent MUST NOT send=20 compressed messages to trading partners who do not use a version=20 header of "1.1" or greater.=20 =20 =20 It seems to me that versions greater than 1.1 will need to check the=20 version values for every message. If a version header is missing, it is=20 version 1.0. =20 From: [email protected] [mailto:[email protected]= ] On Behalf Of Kyle Meadors Sent: Thursday, December 15, 2005 3:21 PM To: [email protected] Subject: RE: profiles in AS2 =20 Not a lot of comments on this thread. But to summarize? =20 3 in favor of Option 2 (Features header) and use of AS2?Version 1.2=20 1 in favor Option 3 where filtering is done on a message =20 Still does not fully address the initial start?up conditions as Richard=20 pointed out, but perhaps that just can not be done without some manual=20 setup. =20 Since this EDIINT WG will likely be closing relatively soon, I hope we can = get some more to weigh in on this. Do others object to Option 2 (with=20 AS2?Version 1.2)? =20 For those AS2 vendors supporting Option 2, would this impact your product, = including those deployed in existing supply chains? Are their significant=20 backward compatibility problems with this choice? =20 Kyle Meadors DGI From: Tim McCarthy [mailto:[email protected]]=20 Sent: Wednesday, December 07, 2005 9:14 AM To: Kyle Meadors; [email protected] Subject: RE: profiles in AS2 =20 Seems to me that a combination of features 2 and 4 would provide=20 everything we'd need. =20 From: [email protected] [mailto:[email protected]= ] On Behalf Of Richard Bigelow Sent: Tuesday, December 06, 2005 5:07 PM To: Kyle Meadors; [email protected] Subject: RE: profiles in AS2 =20 These are my comments. Option 2 is preferred. This memo essentially=20 supports John Duker's memo of Dec. 5, Features Profile in AS2. =20 1. This option requires that implementers of feature 1.n also implement=20 all earlier features. Is that reasonable? What if 1.5 is difficult and=20 many vendors don't want to do it, but many want to support 1.6? Not=20 recommended. =20 2. The features header allows the partner A receiving the message to know = the other partner's (B's) capabilities. So when A sends to B, A knows=20 what is allowed. A can also check B's AS2-version; 1.1 does not allow any = of the controlled features, but does allow compression. A should update=20 some state for every message received from B. B might stop supporting=20 some feature. Recommended. =20 A possible variant of (2) is that a partner could send some message to all = its trading partners when its capabilities change. This message would=20 have headers only, no content. It might be useful to send this=20 capabilities message to partners that would rarely receive normal=20 messages. =20 3. This option allows receivers to ignore messages they don't understand,=20 and to detect those messages without looking for unknown headers. But it=20 does not provide a mechanism for the sender to know whether a receiver can = receive the message. Suppose we had done compression this way. A could=20 send a compressed file to B, and B could ignore it based on the feature=20 header, but then the file is lost. B could return a new MDN code=20 indicating unsupported-feature, and A could then send the uncompressed=20 file, in this example. In other cases, A would have to use some other=20 mechanism. A could remember that B rejected the file and not try that=20 feature again, but how would A know if B upgraded and can now support the=20 feature? The original intent of the features header was that the sender=20 could know in advance if the receiver supports the feature. 3 is not=20 recommended. =20 4. Before sending a message to B, A should ask B for B's capabilities, and = check if B supports the feature. Since B might stop supporting a feature, = A should ask each time. This is ok for rare messages, like CEM, but not=20 for common ones, like Multiple Attachments. Not recommended. =20 None of these protocols fully addresses the initial case. Before any=20 messages are exchanged, how do the partners know each other's=20 capabilities? Each partner must assume that the other supports only the=20 basic 1.0 AS2 protocol. Hopefully, they will be able to exchange normal=20 messages, which will contain at least the 1.2 version header. They can=20 then use option 2 to discover each other capabilities. This probably=20 works for most features. For CEM, either they must first exchange test=20 messages that are unencrypted and unsigned to establish CEM capability, or = exchange initial certificates manually. =20 Alternatively, the partners would configure each other manually the first=20 time. Thereafter, they would be automatically updated on each other's=20 capabilities. =20 Richard Bigelow Inovis [email protected] From: [email protected] [mailto:[email protected]= ] On Behalf Of Kyle Meadors Sent: Thursday, December 01, 2005 9:04 AM To: [email protected] Subject: profiles in AS2 =20 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 =20 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.13.10/189 - Release Date:=20 11/30/2005 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.13.12/193 - Release Date: 12/6/2005 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.0/203 - Release Date: 12/15/2005 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.1/207 - Release Date: 12/19/2005 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.1/207 - Release Date: 12/19/2005 --=_alternative 0077AD75852570DD_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <br><font size=3D2 face=3D"sans-serif">Scott & Rik,</font> <br> <br><font size=3D2 face=3D"sans-serif">While I understand that EDIINT= -Features, CEM, & AS2-Reliability are not technically part of the chart= er of the EDIINT WG, they are intended to improve the usability and expand = the use of AS1, AS2, & AS3. </font> <br> <br><font size=3D2 face=3D"sans-serif">Is it possible to either keep the WG= open while these drafts are resolved, or at least keep the elist open to m= aintain the group of interested participants? Thanks for your consideration= .</font> <br> <br><font size=3D2 face=3D"sans-serif">John Duker</font> <br><font size=3D2 face=3D"sans-serif">P&G</font> <br> <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/20/2005 11:29 AM</font> <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"> </font> <br><font size=3D1 face=3D"sans-serif"> Subject:= RE: profiles in AS2</font></table> <br><font size=3D2 color=3D#000080 face=3D"Arial">The closing of WG is deci= sion to be made by Rik Drummond and Scott Hollenbeck. Discussion on EDIINT&= #8211;Features, CEM and the like are peripheral to EDIINT but not part of t= he charter. When EDIINT charter is complete, and only a decision on AS3 is = remaining, the elist will be closed as well. </font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">However, it is open for t= he time being – let's continue to use this space for this discussion.= We have only heard from a relative handful of individuals – can othe= rs chime in? </font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">Kyle Meadors</font> <br><font size=3D2 color=3D#000080 face=3D"Arial">DGI</font> <div align=3Dcenter> <br> <hr></div> <br><font size=3D2 face=3D"Tahoma"><b>From:</b> Richard Bigelow [mailto:ric= [email protected]] <b><br> Sent:</b> Monday, December 19, 2005 12:56 PM<b><br> To:</b> Dale Moberg; Kyle Meadors; [email protected]<b><br> Subject:</b> RE: profiles in AS2</font> <br><font size=3D3 face=3D"Times New Roman"> </font><font size=3D2 col= or=3D#000080 face=3D"Arial">Concerning a 1.2 version interoperating with a = 1.1 version: The 1.1 version should accept the 1.2 messages. Th= e compression draft says that a version of 1.1 or greater indicates compres= sion. </font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">I have some concern about= Kyle's comment that this WG may be closing soon. Is this in response= to IETF's requirement to make progress on AS3? I hope that this WG w= ill continue. We have some proposals on the table, including Reliabil= ity and CEM and perhaps Profiles in the future.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D1 color=3D#808080 face=3D"Verdana">Richard Bigelow<br> Inovis</font><font size=3D1 color=3Dblue face=3D"Verdana"><u><br> </u></font><a href=3Dmailto:[email protected]><font size=3D1 color= =3Dblue face=3D"Verdana"><u>[email protected]</u></font></a> <div align=3Dcenter> <br> <hr></div> <br><font size=3D2 face=3D"Tahoma"><b>From:</b> [email protected].= org [mailto:[email protected]] <b>On Behalf Of </b>Dale Moberg= <b><br> Sent:</b> Saturday, December 17, 2005 7:49 AM<b><br> To:</b> Kyle Meadors; [email protected]<b><br> Subject:</b> RE: profiles in AS2</font> <br><font size=3D3 face=3D"Times New Roman"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">The consensus seems to be= that it should be possible to support some AS2 features independently, rat= her than cumulatively. Although I think the combinations of features of Rel= iability, CEM, and Multipart could be coded up by 8 numbers, if more end us= er requirements get specified, that encoding would become inconvenient to s= upport. So moving to an EDIINT-Features header seems to be a reasonable way= to advertise capabilities.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">Would AS1, AS2 and AS3 al= l use this header? I assume that CEM and attachments are OK, but Reliabilit= y mainly pertains to AS2. Also, would AS1 have to add an "X-" preface to th= e header? (So we would have somemething like "X-EdiintFeatures" as the head= er value?)</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">I take it that there is s= ome concern about the waste of sending this header every time and that part= ially motivates inventing new behavior to supply these values in a MDN (whe= n requested). While that might be more elegant, I guess the logic would be = that you can only use that form of request when the original has an AS2-Ver= sion of "1.2"? My preference here is not to try to develop option 4 into a = new capability query and response pattern, but just accept that the Ediint-= Features header may waste a few bytes per message. </font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">How will existing applica= tions respond to this? Presumably they would (or should) ignore an included= "EdiintFeatures" header and also never send one. If they never sent one (a= nd their ASx-version was either 1.0 or 1.1), then they must not be sent mul= tiparts or CEM. In that case, messages with the new features would not even= be sent to older applications and could not cause them to malfunction. So = it should be stated that you may not use these features unless the other si= de both has a version value greater than 1.1 and also has included the feat= ure in its EdiintFeatures header.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">What should be said about= a 1.2 version interoperating with a 1.1 version? Since a 1.1 level app. wo= uld be entitled to ignore a message with a higher version, should a 1.2 app= be advised to be configurable to advertise itself as a 1.1 version to prom= ote interoperation?</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">What should be done about= detecting a change (upgrade) of versions when the other side begins sendin= g the higher "1.2" value? Are implementations expected to check the version= or is this left to the implementation? Richard B. says "A should update so= me state for every message received from B" I think it would be sufficient = to check the state and update if a change is noticed. (Maybe that is what R= ichard meant though.) I suppose an empty message could be sent to announce = a change in capabilities, but again only to ediint agents with a version gr= eater than 1.1.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">So far the specifications= have not really required that the version be checked for every message. Fo= r example, t</font><font size=3D2 face=3D"Courier New">he AS3 draft says </= font> <br><font size=3D2 face=3D"Courier New"> </font> <br><font size=3D2 face=3D"Courier New"> The AS3-Version heade= r is a header which is required only if the value</font> <br><font size=3D2 face=3D"Courier New"> of the header is not = "1.0". Its purpose is to allow systems to </font> <br><font size=3D2 face=3D"Courier New"> determine which versi= on of this specification, should the</font> <br><font size=3D2 face=3D"Courier New"> specification evolve = over time, the sender of a document has used to</font> <br><font size=3D2 face=3D"Courier New"> package the document.= A user agent MUST NOT reject a message if the </font> <br><font size=3D2 face=3D"Courier New"> version header is mis= sing.</font> <br><font size=3D2 face=3D"Courier New"> </font> <br><font size=3D2 face=3D"Courier New"> AS3-Version: 1*DIGIT = . 1*DIGIT</font> <br><font size=3D2 face=3D"Courier New"> </font> <br><font size=3D2 face=3D"Courier New"> A version header valu= e of "1.1" indicates an implementation can</font> <br><font size=3D2 face=3D"Courier New"> support EDIINT data c= ompression [18]. A user agent MUST NOT send </font> <br><font size=3D2 face=3D"Courier New"> compressed messages t= o trading partners who do not use a version </font> <br><font size=3D2 face=3D"Courier New"> header of "1.1&q= uot; or greater. </font> <br><font size=3D2 face=3D"Courier New"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">It seems to me that versi= ons greater than 1.1 will need to check the version values for every messag= e. If a version header is missing, it is version 1.0.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <div align=3Dcenter> <br> <hr></div> <br><font size=3D2 face=3D"Tahoma"><b>From:</b> [email protected].= org [mailto:[email protected]] <b>On Behalf Of </b>Kyle Meador= s<b><br> Sent:</b> Thursday, December 15, 2005 3:21 PM<b><br> To:</b> [email protected]<b><br> Subject:</b> RE: profiles in AS2</font> <br><font size=3D3 face=3D"Times New Roman"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">Not a lot of comments on = this thread. But to summarize…</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">3 in favor of Option 2 (F= eatures header) and use of AS2–Version 1.2 </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">1 in favor Option 3 where= filtering is done on a message</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">Still does not fully addr= ess the initial start–up conditions as Richard pointed out, but perha= ps that just can not be done without some manual setup.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">Since this EDIINT WG will= likely be closing relatively soon, I hope we can get some more to weigh in= on this. Do others object to Option 2 (with AS2–Version 1.2)?</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">For those AS2 vendors sup= porting Option 2, would this impact your product, including those deployed = in existing supply chains? Are their significant backward compatibility pro= blems with this choice?</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">Kyle Meadors</font> <br><font size=3D2 color=3D#000080 face=3D"Arial">DGI</font> <div align=3Dcenter> <br> <hr></div> <br><font size=3D2 face=3D"Tahoma"><b>From:</b> Tim McCarthy [mailto:TMcCar= [email protected]] <b><br> Sent:</b> Wednesday, December 07, 2005 9:14 AM<b><br> To:</b> Kyle Meadors; [email protected]<b><br> Subject:</b> RE: profiles in AS2</font> <br><font size=3D3 face=3D"Times New Roman"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">Seems to me that a combin= ation of features 2 and 4 would provide everything we'd need.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <div align=3Dcenter> <br> <hr></div> <br><font size=3D2 face=3D"Tahoma"><b>From:</b> [email protected].= org [mailto:[email protected]] <b>On Behalf Of </b>Richard Big= elow<b><br> Sent:</b> Tuesday, December 06, 2005 5:07 PM<b><br> To:</b> Kyle Meadors; [email protected]<b><br> Subject:</b> RE: profiles in AS2</font> <br><font size=3D3 face=3D"Times New Roman"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">These are my comments. &n= bsp;Option 2 is preferred. This memo essentially supports John Duker'= s memo of Dec. 5, Features Profile in AS2.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">1. This option requires t= hat implementers of feature 1.n also implement all earlier features. = Is that reasonable? What if 1.5 is difficult and many vendors don't w= ant to do it, but many want to support 1.6? Not recommended.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">2. The features hea= der allows the partner A receiving the message to know the other partner's = (B's) capabilities. So when A sends to B, A knows what is allowed. &n= bsp;A can also check B's AS2-version; 1.1 does not allow any of the control= led features, but does allow compression. A should update some state = for every message received from B. B might stop supporting some featu= re. Recommended.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">A possible variant of (2)= is that a partner could send some message to all its trading partners when= its capabilities change. This message would have headers only, no co= ntent. It might be useful to send this capabilities message to partne= rs that would rarely receive normal messages.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">3. This option allows rec= eivers to ignore messages they don't understand, and to detect those messag= es without looking for unknown headers. But it does not provide a mec= hanism for the sender to know whether a receiver can receive the message. &= nbsp;Suppose we had done compression this way. A could send a compres= sed file to B, and B could ignore it based on the feature header, but then = the file is lost. B could return a new MDN code indicating unsupporte= d-feature, and A could then send the uncompressed file, in this example. &n= bsp;In other cases, A would have to use some other mechanism. A could= remember that B rejected the file and not try that feature again, but how = would A know if B upgraded and can now support the feature? The origi= nal intent of the features header was that the sender could know in advance= if the receiver supports the feature. 3 is not recommended.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">4. Before sending a messa= ge to B, A should ask B for B's capabilities, and check if B supports the f= eature. Since B might stop supporting a feature, A should ask each ti= me. This is ok for rare messages, like CEM, but not for common ones, = like Multiple Attachments. Not recommended.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">None of these protocols f= ully addresses the initial case. Before any messages are exchanged, h= ow do the partners know each other's capabilities? Each partner must = assume that the other supports only the basic 1.0 AS2 protocol. Hope= fully, they will be able to exchange normal messages, which will contain at= least the 1.2 version header. They can then use option 2 to discover= each other capabilities. This probably works for most features. &nbs= p;For CEM, either they must first exchange test messages that are unencrypt= ed and unsigned to establish CEM capability, or exchange initial certificat= es manually.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D2 color=3D#000080 face=3D"Arial">Alternatively, the partne= rs would configure each other manually the first time. Thereafter, th= ey would be automatically updated on each other's capabilities.</font> <br><font size=3D2 color=3D#000080 face=3D"Arial"> </font> <br><font size=3D1 color=3D#808080 face=3D"Verdana">Richard Bigelow<br> Inovis</font><font size=3D1 color=3Dblue face=3D"Verdana"><u><br> </u></font><a href=3Dmailto:[email protected]><font size=3D1 color= =3Dblue face=3D"Verdana"><u>[email protected]</u></font></a> <div align=3Dcenter> <br> <hr></div> <br><font size=3D2 face=3D"Tahoma"><b>From:</b> [email protected].= org [mailto:[email protected]] <b>On Behalf Of </b>Kyle Meador= s<b><br> Sent:</b> Thursday, December 01, 2005 9:04 AM<b><br> To:</b> [email protected]<b><br> Subject:</b> profiles in AS2</font> <br><font size=3D3 face=3D"Times New Roman"> </font> <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> <br><font size=3D3 face=3D"Times New Roman"> </font> <p> <p><font size=3D2 face=3D"Times New Roman">--<br> No virus found in this outgoing message.<br> Checked by AVG Free Edition.<br> Version: 7.1.362 / Virus Database: 267.13.10/189 - Release Date: 11/30/2005= </font> <p> <p><font size=3D2 face=3D"Times New Roman">--<br> No virus found in this incoming message.<br> Checked by AVG Free Edition.<br> Version: 7.1.371 / Virus Database: 267.13.12/193 - Release Date: 12/6/2005<= /font> <p> <p><font size=3D2 face=3D"Times New Roman">--<br> No virus found in this outgoing message.<br> Checked by AVG Free Edition.<br> Version: 7.1.371 / Virus Database: 267.14.0/203 - Release Date: 12/15/2005<= /font> <p> <p><font size=3D2 face=3D"Times New Roman">--<br> No virus found in this incoming message.<br> Checked by AVG Free Edition.<br> Version: 7.1.371 / Virus Database: 267.14.1/207 - Release Date: 12/19/2005<= /font> <p> <p><font size=3D2 face=3D"Times New Roman">--<br> No virus found in this outgoing message.<br> Checked by AVG Free Edition.<br> Version: 7.1.371 / Virus Database: 267.14.1/207 - Release Date: 12/19/2005<= /font> <p> <p> --=_alternative 0077AD75852570DD_=--