We didn't vote to do it, but we certainly seemed to agree.
Speaking as an individual (neither company voice, nor TC chair), I'm not
sure why it isn't in a standards body already - if there were a good reason,
maybe we'd be more sympathetic to their situation.
Tony (on vacation, jetlagged, and ever-so-slightly irritable!)
-----Original Message----- From:
dave.prout@bt.com [mailto:dave.prout@bt.com] Sent: Wed 27-Jul-05
7:12 To: uddi-spec@lists.oasis-open.org Cc:
Subject: RE: [uddi-spec] WS-Policy
All,
Did we agree that the TC should write to the
authors of the WS-Policy spec urging them to get it into a standards body ?
I know many others have probably done this, but I believe we should do it
anyway.
Does anybody disagree
?
Thanks
Dave
-----Original Message----- From:
von Riegen, Claus [mailto:claus.von.riegen@sap.com] Sent:
26 July 2005 20:12 To: Pete Wenzel;
uddi-spec@lists.oasis-open.org Subject: RE: [uddi-spec]
WS-Policy
Pete,
As far as the OASIS WS-RX TC is concerned, the
charter clearly states that WS-ReliableMessagingPolicy (which is based on
WS-Policy) is in scope and that the TC will work on it. Only if at the time
the WS-RX TC moves to ratify its deliverables WS-Policy is "outside of
a standardization process", normative references to WS-Policy will
be removed.
The OASIS UDDI TC can similarly decide to develop
material that references WS-Policy and not ratifying these deliverables as
long as WS-Policy is outside of a standardization
process.
Claus
-----Original Message----- From: Pete Wenzel
[mailto:pete@seebeyond.com] Sent:
Dienstag, 26. Juli 2005 02:34 To:
uddi-spec@lists.oasis-open.org Subject: [uddi-spec] WS-Policy
UDDI
Spec TC folks,
While I realize the eventual need for a policy
expression language and framework, I have definite misgivings with respect
to adoption of WS- Policy, which to my knowledge is not under the control
of any sort of standards organization.
Ignoring possibly significant
IPR issues for the moment, my technical concerns include potential lack of
stability, maturity/vetting, and consensus-driven development and
change-control accountability.
Other TCs have agreed that it is not
appropriate to reference WS- Policy, and are content to describe the
required functionality in an abstract manner, while building in extention
points for use when a suitable standards-track framework becomes
available. Following are excerpts from WS-Notification,
WS-ReliableExchange and WS-Security TC documents that illustrate
this. Perhaps there are other examples.
I note that the authors
of WS-SecurityPolicy have preannounced its contribution to OASIS, as
reported in http://www.infoworld.com/article/05/07/15/HNwsibm_1.html but
that depends directly on WS-Policy, so it doesn't seem to alleviate any of
these concerns.
Is this an accurate assessment of the situation?
What do others think?
--Pete
WS-BaseNotification:
wsnt:SubscriptionPolicy This
optional component is an open component intended to be used in an
application specific way to specify policy related
requirements/assertions associated with the subscribe requests. This
mechanism could be used to govern the message rate (e.g. maximum
3 messages per second), reliability of the Notification delivery,
etc. The semantics of how the NotificationProducer MUST or MAY react
to the policy requirements and assertions appearing in this
component are specific to the actual policy grammar used. If
this component is not specified in the Subscribe request message,
then the NotificationProducer SHOULD use other means (such as
directly contacting the NotificationConsumer) to resolve any
policy-related inquiries.
NotificationProducer MAY
choose to communicate its caching policy by some means not specified
in this document, such as using a policy assertion.
NotificationProducers MAY advertise their behavior in this situation
via policy assertions. In the absence of a specific policy
assertion, Subscribers SHOULD NOT assume any particular behavior on
the part of the NotificationProducer.
WS-BrokeredNotification:
NotificationBrokers SHOULD advertise,
whether through policy assertions or other means, what security
measures they take.
WS-ReliableExchange TC
Charter:
If an above specification [including WS-Policy] is
outside of a standardization process at the time this TC moves to
ratify its deliverables, or is not far enough along in the
standardization process, any normative references to it in the TC
output will be expressed in an abstract manner, and the incarnation
will be left at that time as an exercise in
interoperability.
WS-Security 2004: The following
topics are outside the scope of this document: ...
Advertisement and exchange of security policy.
--Pete Pete Wenzel
<pete@seebeyond.com> Senior Architect, SeeBeyond Standards &
Product Strategy +1-626-471-6311
(US-Pacific)
--------------------------------------------------------------------- To
unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. You may a link to this group and all your TCs
in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--------------------------------------------------------------------- To
unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. You may a link to this group and all your TCs
in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--------------------------------------------------------------------- To
unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. You may a link to this group and all your TCs in
OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|