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?
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.
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