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.

ebxml-msg message