[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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: duker.jp@xxxxxx [mailto:duker.jp@xxxxxx]
> Sent: Tuesday, December 20, 2005 4:47 PM
> To: Scott Hollenbeck; Rik Drummond; ietf-ediint@xxxxxxx
> 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" <kyle@xxxxxxxxxxxxxxxxx>
> Sent by: owner-ietf-ediint@xxxxxxxxxxxx
>
> 12/20/2005 11:29 AM
> To: <ietf-ediint@xxxxxxx>
>
> 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:richard.bigelow@xxxxxxxxxx]
> Sent: Monday, December 19, 2005 12:56 PM
> To: Dale Moberg; Kyle Meadors; ietf-ediint@xxxxxxx
> 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
> richard.bigelow@xxxxxxxxxx <mailto:richard.bigelow@xxxxxxxxxx>
>
> ________________________________
>
>
> From: owner-ietf-ediint@xxxxxxxxxxxx
> [mailto:owner-ietf-ediint@xxxxxxxxxxxx] On Behalf Of Dale Moberg
> Sent: Saturday, December 17, 2005 7:49 AM
> To: Kyle Meadors; ietf-ediint@xxxxxxx
> 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: owner-ietf-ediint@xxxxxxxxxxxx
> [mailto:owner-ietf-ediint@xxxxxxxxxxxx] On Behalf Of Kyle Meadors
> Sent: Thursday, December 15, 2005 3:21 PM
> To: ietf-ediint@xxxxxxx
> 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:TMcCarthy@xxxxxxxxxxxxx]
> Sent: Wednesday, December 07, 2005 9:14 AM
> To: Kyle Meadors; ietf-ediint@xxxxxxx
> Subject: RE: profiles in AS2
>
> Seems to me that a combination of features 2 and 4 would
> provide everything we'd need.
>
>
> ________________________________
>
>
> From: owner-ietf-ediint@xxxxxxxxxxxx
> [mailto:owner-ietf-ediint@xxxxxxxxxxxx] On Behalf Of Richard Bigelow
> Sent: Tuesday, December 06, 2005 5:07 PM
> To: Kyle Meadors; ietf-ediint@xxxxxxx
> 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
> richard.bigelow@xxxxxxxxxx <mailto:richard.bigelow@xxxxxxxxxx>
>
> ________________________________
>
>
> From: owner-ietf-ediint@xxxxxxxxxxxx
> [mailto:owner-ietf-ediint@xxxxxxxxxxxx] On Behalf Of Kyle Meadors
> Sent: Thursday, December 01, 2005 9:04 AM
> To: ietf-ediint@xxxxxxx
> 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
>
>