|
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
|