OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ebxml-msg] Pull, MPC, authorization

Hi Pim

I've been following this thread with some interest and was wondering if this was triggered by the conversation on the list between Rong and myself on this ?

Some of my thoughts and views on pull authorisation from a practical point of view and within the scope of the question (ie. interpretation of behavior of an MSH implementing Core Spec pulling' for the AS4 profile are as follows.

Sub-channels are an optional feature for the AS4 profile particularly for use in multi-hop cases and my view being that these need only be considered in cases where multi-hop is a requirement.

There are use cases for 'broadcasting' the same message to multiple pulling partners eg. RFQs.

Authorisation, either by UT or by Signature, on pulling from MPCs is a practical requirement in that pulling partners should not be able to pull messages (and in the process delete these from an MPC) if the message is not intended for them.

Configuring multiple separate P-Modes, each with a separate MPC, for cases where a large number of pulling partners exists is not practical.

Chapter 3 of the core spec does not mention the ability of partitioning messages on a single MPC based on the "user" in the user token as per your email below. 

Chapter 3 does state 'organizing the inflow of messages on receiving side, so that each flow can be consumed in a distinct way, yet without having to filter messages based on various header elements or payload content', but does inflow, and organisation of received messages, not indicate the context of the receiving (pulling) msh once pulled messages have been received ?

Chapter 3 also states the following ... 'It does not prescribe a particular way to implement MPCs or [how] to use them.' and 'There is no specific quality of service associated with an MPC. Security and reliability remain associated with parties or with MSHs, in a way that is orthogonal to MPCs; although an implementation is free to associate QoS with MPCs as long as this conforms to an agreement between parties."

 … so in reading Chapter 3, and the AS4 profile, I see nothing that prohibits or recommends against partitioning messages within an MPC by user …

Also pull requests without credentials (UTs and/or unsigned pull requests) or with shared UTs should be able to pull messages for basic pull functionality as you mention below.

For the question asked in EBXMLMSG-20 I see the following possibilities

a - return P1.
b - return empty MPC (EBMS:0006)  if only P2 messages are available.

I don't think that (a) goes against the notion of 'simple dequeue' surely… ?

On 04 Aug 2013, at 11:58 , Pim van der Eijk <pvde@sonnenglanz.net> wrote:

> Hello Jacques,
> Sub-channels and the Part 2 selective pulling are useful features.   But the question is about correct interpretation of behaviour of an MSH implementing the Core Spec pulling.   Also see https://tools.oasis-open.org/issues/browse/EBXMLMSG-20.   It seems at least one product is implementing a kind of sub-channels by sub-partitioning messages within an MPC based on the "user" in the user token.   Chapters 3 and 7 of the Core Spec do not seem to be fully aligned on this, with chapter 3 not mentioning it at all.
> If we want basic Pull functionality to be simple and implementable using simple mechanisms like FIFO queues,  any pull client authorized to pull from an MPC should be authorized to pull all messages in that MPC.  
> It would be great if we can discuss this at an upcoming TC call.
> Pim


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]