OASIS ebXML Messaging Services TC

Some 
routing questions we should 
answer:
 
- We have assumed so far that ebms routing is based 
on header fields in eb:Messaging.
Do we assume eb:Messaging is never encrypted? Or 
else do we assume that the fields
used for routing must be "replicated" in a new header that will never be encrypted (something acting as the "delivery" header 
in 
RNIF?)
 
- inside eb:Messaging header, the routing of user 
messages is likely done based on 
subelements in eb:UserMessage: eb:PartyInfo, eb:CollaborationInfo, 
eb:MessageProperties, eb:PayloadInfo.
Probably not based on eb:MessageInfo that only 
holds ID data and timestamps.
In that case, how do we plan to route the ebMS 
Receipt signal? And other ebMS Error signals?
These signals have none of all the above 
eb:Usermessage elements, and only share eb:MessageInfo in common with  user messages. On the other hand, because they 
are "response" messages, we know their destination (or what is the last intermediary on its way). 
It appears that a different routing function is needed for such response messages. SHouldn't it rely 
on wsa?
 
Jacques

Jacques,

in the "requirements document" assumption A.2 says that routing must be 
based on information available in the header of the message without 
saying in which part of the message. This could be either the ebMS 
header or any other SOAP header. However it seems logical to me that 
ebMS messages are routed based on information in the ebMS header.

Anyway, information needed for routing messages may not be encrypted, so 
when information from the ebMS header is used it means the ebMS header 
can not be encrypted. Duplicating the information to a non ebMS header 
will indeed allow for encryption of the ebMS header, but I wonder why 
one would do that as the encyrpted is also available in clear text (in 
the duplicated header) ?
So, I think we should require clear text headers if assumption A.2 is 
correct. Maybe we have to make the assumption more explicit by saying 
that all the routing information should be available in the SOAP header 
(which includes the ebMS header).

Regards
Sander


Durand, Jacques R. wrote:
> Some routing questions we should answer:
>  
> - We have assumed so far that ebms routing is based on header fields 
> in eb:Messaging.
> Do we assume eb:Messaging is never encrypted? Or else do we assume 
> that the fields
> used for routing must be "replicated" in a new header that will never 
> be encrypted (something acting as the "delivery" header
> in RNIF?)
>  
> - inside eb:Messaging header, the routing of user messages is likely 
> done based on subelements in eb:UserMessage: eb:PartyInfo, 
> eb:CollaborationInfo, eb:MessageProperties, eb:PayloadInfo.
> Probably not based on eb:MessageInfo that only holds ID data and 
> timestamps.
> In that case, how do we plan to route the ebMS Receipt signal? And 
> other ebMS Error signals?
> These signals have none of all the above eb:Usermessage elements, and 
> only share eb:MessageInfo in common with  user messages. On the other 
> hand, because they are "response" messages, we know their destination 
> (or what is the last intermediary on its way). It appears that a 
> different routing function is needed for such response messages. 
> SHouldn't it rely on wsa?
>  
> Jacques

Inline