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

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

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


Subject: 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)


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