inline
From: Moberg Dale [mailto:]
Sent: Wednesday, March 05, 2008 2:19 PM
To:
; Durand, Jacques R.
Cc:
Subject: RE: [ebxml-msg] A first
assessment of ebMS profiling for AS2
Jacques noted a need for
accomodating
3- Header fields: ebMS header mapping or
profiling of AS2 headers & system identifiers (AS-From...)
Tim mentioned one
approach:
For endpoint resolution (AS-To, AS-From, MessageId,
etc), was thinking along the lines of what WS-Addressing provides, and honestly
I'm not sure how ebMS 3.0 incorporates WS-Addressing
AS4-To
AS4-From
and so on could be HTTP
entity headers as in AS2. (But that is not in the spirit of WS-* in that
message metadata foi them is to be scrunched into the message bodyparts in
various ways. ebMS follows this pattern.)
I don’t think that
WS-Addressing is relevant for AS4 identifiers, however. These party identifiers
are logical identifiers of parties by values such as DUNS numbers that are used
in the X12 EDI world, for example. Corresponding WS-Addressing values tend to be
EPRs (or just URIs, er, IRIs).
<JD> agree. wsa:From and
wsa:To are primarily "address" information (IRI, EPRs). Although we could
have logical info as EPR properties, I do not see much value in doing so, and
I'd rather keep these headers available for future use that really support an
addressing function.
If these Froms and Tos
were mapped into what is available in ebMS 3, however, I would say
that
AS4-To corresponds to
the ebMS To field
AS4-To corresponds to
the ebMS From field.
<JD> more precisely,
eb:To/eb:PartyId and eb:From/eb:PartyId. (if AS4-To maps to eb:To, that means it maps to a complex element like
partyid+role . I guess could be done using composed AS2-name -
e.g. a quoted name of the form "partyId role").
Service, Action, and
Role correspond with no current metadata values in the EDIINT AS1 2 3
versions.
Message-ID Need
to consider what that is used for. RM functionality (like duplicate checking) or
MDN/NRReceipt functionality.
<JD> the eb:Receipt would
have a RefToMessageId that refers to the eb:MessageId of the acknowledged
message.
That woudl be the prime role of
eb:MessageId here.
In turn, in case the eb:Receipt is
not well formed, its own eb:MesageId would be referred by a later Error
message.
I would expect all dup checks to be
supported by whatever RM module is there, i.e. make use of some sequence number
info (not eb:MessageId)
Conversation-Id in ebMS
has no corresponding value in EDIINT AS1,2,3.
AS4-Version etc. also
will need some discussion.
