[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] WS-Policy
+1, thanks Claus -----Original Message----- From: von Riegen, Claus [mailto:claus.von.riegen@sap.com] Sent: Tuesday, July 26, 2005 2:15 PM To: dave.prout@bt.com; uddi-spec@lists.oasis-open.org Subject: RE: [uddi-spec] WS-Policy Provided that there is no disagreement, I can take this as a formal action item and forward it to the WS-Policy authors' team if you like. Thanks, Claus -----Original Message----- From: dave.prout@bt.com [mailto:dave.prout@bt.com] Sent: Dienstag, 26. Juli 2005 17:13 To: uddi-spec@lists.oasis-open.org 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 --------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]