According to the OASIS UDDI TC roster, T Jensen of HP is an observer, added
to the group on 02/01/2003. The mailing address, firstname.lastname@example.org
, is the one on record for this
I can remove you from the UDDI Spec TC mailing list, or you can remove
yourself - I would like confirmation, however.
From: Jensen, Thomas
Sent: Wed 19-Oct-05 17:02
Luc Clement; von Riegen, Claus; Rogers, Tony; email@example.com
Subject: RE: [uddi-spec] Agenda - Tuesday, 18
October 2005, 03:30pm to 05:00pm US ET
I don't know why, but I am receiving all your emails,
even they don't are my business.
I work by HP, PSG Category Management, in B÷blingen in
Germany, and I would preciate, if you didn't send me more
ooops... Tony: you did post them. Thanks.
We agree on this of course. Nonetheless the use case
presented by the WSDL is one we need to have a position on
Tony: could you post the minutes - I'd like to
see what was discussed.
Of course, WS-PolicyAttachment does not provide a
mechanism to query UDDI for WSDL operations and/or messages associated
with a given policy expression. This is because the UDDI data model was
not designed to cover all details of a WSDL portType and/or
WSDL binding rather than a limitation of WS-PolicyAttachment section
Luc has raised an issue which he believes is not addressed by
WS-PolicyAttachment in its current form.
TC to discuss, and decide on a course of action
Unfortunately I won't be on the call today. I would
like to ensure that it is understood that the reason that I sent the wsdl
was to use it as a source of use cases; my goal was not to poke holes at
WS-PolicyAttachment. I do believe that this demonstrates limitations of
Section 5 of WS-PolicyAttachment 2004 and most likely our own WSDL-UDDI 2.0.2
mapping (depending on how we approach policy with the use case I present). To
restate my email :
What this WSDL does is simply demonstrating is the need
whether a policy is a capability or a constraint; there are some that would
consider configuration policy (not a view that I hold). To my way of
thinking, one's capability is another's constraint. While the WSDL does not
clearly put this out as a consideration, we need to tackle this issue.
- As you can
tell from the WSDL, policy constraints (confidentiality and integrity
constraints) and policy capability (use of x509v3 token - you might not
agree on whether capability or constraint - so be it - not that important at
this point other than to clearly call out the need to understand both cases)
need to be expressed not only on the access point (i.e. the
uddi:bindingTemplate) but at the operation level and in this specific case
the message level.
imply that we have to map operations and messages to the registry and update
the WSDL/UDDI mapping and update ws-policyattachment? No. We surely may have
to review the WSDL/UDDI mapping but I would not jump to the conclusion that
we must map ops and msgs simply to be able to tack on a policy
expression. I think what is required is the means to express on the
uddi:bindingTemplates constraints and capabilities that apply to its
messages and operations. We might convince ourselves that we have to reify
operations in the registry, but once you do that what would be the rationale
for not reifying the messages (and maybe we will need to) ... ok so I
digress... I think you know where I'm going with
Attached please find the agenda for today's telephone conference.
Call details were e-mailed earlier.