Hi Ashok,
On 9/29/11 10:31 PM, ashok malhotra wrote:
Eric, Danny:
Feel free to make a proposal.
All the best, Ashok
That's a fair question. But I believe I've made two different
proposals so far. They're just not in the concrete form of changes
to the specification. Specifically:
* Process proposal: To move this question forward, exactly what are
the use-cases for supporting policies with pub/sub?
* Directional proposal: Since I don't have any use cases, and nobody
else has yet offered up any, I've suggested that we simply punt on
the issue, and add no additional normative statements about
policies, although perhaps some explanatory text.
Of course, I could put my directional proposal in the form of actual
changes to the spec, but if nobody else agrees with me, then I'm not
sure I want to spend the time. So at this point, it is merely a
directional proposal.
-Eric.
On 9/29/2011 9:54 AM, Danny van der Rijn wrote:
On 9/29/2011 2:21 AM, Eric Johnson wrote:
Maybe we should have this conversation the other way around.
What existing defined policy intents and policy sets do people
actually think they want to apply to pub-sub situations? What
do they hope those policies will acheive? And then maybe we
can look at what should be in the model?
(hmmm - at the moment, OASIS is not responding, so I'm working
from an older copy of the policy spec)
For example, of the following intents: serverAuthentication,
clientAuthentication, authentication, mutualAuthentication,
confidentiality, integrity, there are possibly only two that
apply for pub-sub - namely "confidentiality", and "integrity".
Both matter to the producer, but may be incidental or
irrelevant to the consumer and the channel.
However, I can imagine a new intent, perhaps called
"credential.token", or "SAML" that might be interesting to
apply at a producer, to ensure that something like a SAML
token gets applied to the outgoing message. That's tricky,
though, insofar as actually determining the SAML token might
be difficult to separate from business logic.
Reliability intents seem to make no sense. Likewise,
transactions.
The miscellaneous intents of Chapter 10 don't seem all that
important, although "JMS" & "EJB" might be useful to apply
to a channel.
Anyone with *specifics* of how they think intents &
policySets should be used, that they're willing to discuss?
Otherwise, I vote the "punt" option.
As per your previous note, in a hub-and-spoke model, some kind
of authentication can make sense. How to interpret what
"client" means, though? Squinting a little funny, you could
also make the argument that some kind of authentication can
makes sense in point-to-point media as well as (squinting
farther) in the broadcast case.
I recall discussing the problems with these policies at the face
to face. Apparently, either my interpretation of the issues
included more people thinking the problem is difficult, or
Martin's included fewer ;-) Or there are far more voting
members than people who attended the face to face.
-Eric.
|