- From: Gilbert Pilz <Gilbert.Pilz@bea.com>
- Date: Mon, 4 Dec 2006 11:15:08 -0800
- To: "Gilbert Pilz" <Gilbert.Pilz@bea.com>, <public-ws-addressing@w3.org>
- Message-ID: <E16EB59B8AEDF445B644617E3C1B3C9C02C383C0@repbex01.amer.bea.com>
I see no responses to this message. It seems that a.) people read this message but didn't think this was a problem b.) people read this message, agreed it was a problem, but didn't have any ideas or solutions c.) people read this message, agreed it was a problem, had some ideas, but were too busy to share them d.) nobody read this message _____ From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-request@w3.org] On Behalf Of Gilbert Pilz Sent: Tuesday, November 28, 2006 1:08 PM To: public-ws-addressing@w3.org Subject: WS-Addr policy attachment While working on my AI to write-up our conclusions from the concall of 11/27 I realized that we haven't discussed where the policies that contain WS-Addr assertions MAY/SHOULD/MUST be attached as per Web Services Policy - Attachement [1]. Here are some things we need to figure out: 1.) What is the permissible set of "policy subjects" for policies containing WS-Addr assertions? 2.) What is the permissible set of WSDL elements for attaching policies containing WS-Addr assertions (e.g. wsdl:binding, wsdl:message, wsdl:portyType, etc.)? 3.) To what degree should the answer to the above questions be constrained by the fact that we already say: "The wsaw:UsingAddressing element SHOULD appear as a child of the wsdl:binding element. Alternatively, the wsaw:UsingAddressing element MAY instead be included as a child of the wsdl20:endpoint (or wsdl11:port) when an endpoint intends to indicate compliance with WS-Addressing for a specific endpoint only." [2] [1] <http://www.w3.org/TR/2006/WD-ws-policy-attach-20060927/> http://www.w3.org/TR/2006/WD-ws-policy-attach-20060927/ [2] <http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/#uaee> http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/#uaee - gp
Received on Monday, 4 December 2006 19:15:44 UTC