RE: profiles in AS2

John,

The list can remain open after the group is closed.  That's standard
operating procedure for an IETF working group mailing list.

-Scott-

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 
> Sent: Tuesday, December 20, 2005 4:47 PM
> To: Scott Hollenbeck; Rik Drummond; [email protected]
> Cc: Kyle Meadors
> Subject: RE: profiles in AS2
> 
> 
> Scott & Rik, 
> 
> While I understand that  EDIINT-Features, CEM, & 
> AS2-Reliability are not technically part of the charter of 
> the EDIINT WG, they are intended to improve the usability and 
> expand the use of AS1, AS2, & AS3.   
> 
> 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 participants? Thanks for your consideration. 
> 
> John Duker
> P&G 
> 
> 
> 	"Kyle Meadors" <[email protected]> 
> Sent by: [email protected] 
> 
> 12/20/2005 11:29 AM         
>         To:        <[email protected]> 
>         
>         Subject:        RE: profiles in AS2
> 
> The closing of WG is decision to be made by Rik Drummond and 
> Scott Hollenbeck. Discussion on EDIINT-Features, CEM and the 
> like are peripheral to EDIINT but not part of the charter. 
> When EDIINT charter is complete, and only a decision on AS3 
> is remaining, the elist will be closed as well. 
>   
> However, it is open for the time being - let's continue to 
> use this space for this discussion. We have only heard from a 
> relative handful of individuals - can others chime in? 
>   
> Kyle Meadors 
> DGI 
> 
> ________________________________
> 
> 
> From: Richard Bigelow [mailto:[email protected]] 
> 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 version should accept the 1.2 messages.  The 
> compression draft says that a version of 1.1 or greater 
> indicates compression.   
>   
> 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 will continue.  We 
> have some proposals on the table, including Reliability and 
> CEM and perhaps Profiles in the future. 
>   
>   
> Richard Bigelow
> Inovis
> [email protected] <mailto:[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 
>   
> The consensus seems to be that it should be possible to 
> support some AS2 features independently, rather than 
> cumulatively. Although I think the combinations of features 
> of Reliability, CEM, and Multipart could be coded up by 8 
> numbers, if more end user requirements get specified, that 
> encoding would become inconvenient to support. So moving to 
> an EDIINT-Features header seems to be a reasonable way to 
> advertise capabilities. 
>   
> Would AS1, AS2 and AS3 all use this header? I assume that CEM 
> and attachments are OK, but Reliability mainly pertains to 
> AS2. Also, would AS1 have to add an "X-" preface to the 
> header? (So we would have somemething like "X-EdiintFeatures" 
> as the header value?) 
>   
> I take it that there is some concern about the waste of 
> sending this header every time and that partially motivates 
> inventing new behavior to supply these values in a MDN (when 
> 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-Version 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. 
>   
> How will existing applications respond to this? Presumably 
> they would (or should) ignore an included "EdiintFeatures" 
> header and also never send 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 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 side 
> both has a version value greater than 1.1 and also has 
> included the feature in its EdiintFeatures header. 
>   
> 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 itself as a 1.1 
> version to promote interoperation? 
>   
> What should be done about detecting a change (upgrade) of 
> versions when the other side begins sending 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 some 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 Richard 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 greater than 1.1. 
>   
> So far the specifications have not really required that the 
> version be checked for every message. For example, the AS3 draft says 
>   
>     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 
>     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 
>     version header is missing. 
>   
>     AS3-Version: 1*DIGIT . 1*DIGIT 
>     
>     A version header value of "1.1" indicates an implementation can 
>     support EDIINT data compression [18]. A user agent MUST NOT send 
>     compressed messages to trading partners who do not use a version 
>     header of "1.1" or greater. 
>   
>   
> It seems to me that versions greater than 1.1 will need to 
> check the version values for every message. If a version 
> header is missing, it is version 1.0. 
>   
> 
> ________________________________
> 
> 
> 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 
>   
> Not a lot of comments on this thread. But to summarize. 
>   
> 3 in favor of Option 2 (Features header) and use of AS2-Version 1.2 
> 1 in favor Option 3 where filtering is done on a message 
>   
> Still does not fully address the initial start-up conditions 
> as Richard pointed out, but perhaps that just can not be done 
> without some manual setup. 
>   
> 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)? 
>   
> For those AS2 vendors supporting Option 2, would this impact 
> your product, including those deployed in existing supply 
> chains? Are their significant backward compatibility problems 
> with this choice? 
>   
> Kyle Meadors 
> DGI 
> 
> ________________________________
> 
> 
> From: Tim McCarthy [mailto:[email protected]] 
> Sent: Wednesday, December 07, 2005 9:14 AM
> To: Kyle Meadors; [email protected]
> Subject: RE: profiles in AS2 
>   
> Seems to me that a combination of features 2 and 4 would 
> provide everything we'd need. 
>   
> 
> ________________________________
> 
> 
> 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 
>   
> These are my comments.  Option 2 is preferred.  This memo 
> essentially supports John Duker's memo of Dec. 5, Features 
> Profile in AS2. 
>   
> 1. This option requires that implementers of feature 1.n also 
> implement all earlier features.  Is that reasonable?  What if 
> 1.5 is difficult and many vendors don't want to do it, but 
> many want to support 1.6?  Not recommended. 
>   
> 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 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 some 
> state for every message received from B.  B might stop 
> supporting some feature.  Recommended. 
>   
> 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 content.  
> It might be useful to send this capabilities message to 
> partners that would rarely receive normal messages. 
>   
> 3. This option allows receivers to ignore messages they don't 
> understand, and to detect those messages without looking for 
> unknown headers.  But it 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 send a 
> compressed 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 unsupported-feature, and A could then 
> send the uncompressed file, in this example.  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 original intent of the features header was that 
> the sender could know in advance if the receiver supports the 
> feature.  3 is not recommended. 
>   
> 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 for common 
> ones, like Multiple Attachments.  Not recommended. 
>   
> None of these protocols fully addresses the initial case.  
> Before any messages are exchanged, how do the partners know 
> each other's capabilities?  Each partner must assume that the 
> other supports only the basic 1.0 AS2 protocol.   Hopefully, 
> 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.  For CEM, either they must first 
> exchange test messages that are unencrypted and unsigned to 
> establish CEM capability, or exchange initial certificates manually. 
>   
> Alternatively, the partners would configure each other 
> manually the first time.  Thereafter, they would be 
> automatically updated on each other's capabilities. 
>   
> Richard Bigelow
> Inovis
> [email protected] <mailto:[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 
>   
> 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 
>   
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.362 / Virus Database: 267.13.10/189 - Release 
> Date: 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 
> 
>