See also: IRC log
<marc> scribe: marc
2. Agenda review, AOB
no ob
3. Call for corrections to the minutes
2005-11-21: <http://www.w3.org/2002/ws/addr/5/11/21-ws-addr-minutes.html> approved
2005-11-28: <http://www.w3.org/2002/ws/addr/5/11/28-ws-addr-minutes.html> corrections pending
4. Review action items <http://www.w3.org/2002/ws/addr/admin#actionitems>
Umit - done
Jonathan - open
5. Co-ordination
* TAG request for help
<http://www.w3.org/mid/OFC99039BA.A290C545-ON852570C8.005A851F-852570C8.006A6181@lotus.com>
Mark reviews note from TAG
Mark: does WG feel the need for formal response ?
<pauld> wonders what we can do, or care about how other people use our specs
dhull: wonders if we need something to explain migration from submission
WG is OK with informal response to TAG
other 5. Proposed and New Issues
Jonathan reviews the issue
<GlenD> Nothing prevents anyone from using <wsa:UsingAddressing> as a policy assertion element under <wsp:Policy>, does it?
<uyalcina> Exactly
<uyalcina> this is what I wrote on my email
<GlenD> +1 on extensibility
Mark: such a policy assertion would need to be compatible with WS-Policy ?
Jonathan: yes
<uyalcina> +1
<GlenD> dammit!
Mark: have discussed with several people, feedback indicates that charter changes might be required
Jonathan: charter requires us to define a mechanism for indicating use - policy is one way of doing that. can be done without normative reference to WS-Policy.
<mnot> scribe: mnot
march: know of people developing
policy constraints; would like to use that instead of a
specific policy language.
... Would like to speak against domain-specific policy
langauge; want to use something domain-independant one (which
is usable with WS-Policy).
... Urge WG to look at WS-PolicyConstraints.
<scribe> scribe: marc
<GlenD> +1
<GlenD> <wsp:Policy>+1</wsp:Policy>
<pauld> AIUI Anne's OASIS dipal working group is based upon XACML: http://research.sun.com/projects/xacml/
<bob> and it is looking very interesting
umit: can use existing extension elements in WS-Policy, good enough, lets move on
<dhull> +1
Paco: in favor of defining policy
assertions
... existing elements can be r-used in policy language when
that gets standardized
anish: can't see any need to say anything about policy right now
jonathan: need a policy assertion, I can either talk to paco and IBM and MS can define it or we can do it in the WG. Former is not that unattractive as bilaterally we can define waht we want and twiddle it whenever we want. Doing it in the WG is a low cost way to get this on a standards track.
umit: don't want to see another
policy assertion document elsewhere, lets do this in the
WG
... just need an indication that the elements we define can be
used in policy and leave it at that
<Zakim> hugo, you wanted to answer the question: should we open the issue?
hugo: don't think we need to open
an issue for this
... from charter pov, we have defined WSDL extensions
anish: thinks jonathans suggestion re MS and IBM defining this is the best way to go
<Zakim> dhull, you wanted to ask a quick question
<uyalcina> why are we abstracting concrete QNames, Anish?
dhull: nothing prevents our elements being re-used - right ?
jonathan: nothing structural, but thinks such use would be viewed as abuse
umit: (to hugo) thinks if we don't open this issue then we are asking for it to happen elsewhere
glen: doesn't think use of our elements elsewhere would be viewed as abuse
mark: if we open this to use with policy then we would need to track usage quite closely
<anish> +1 to marc
<hugo> +1 to Marc
<bob> +1 to Marc too
marc: either do the job and define use in each framework or don't do it, making some vague statement will do nobody any favours
mark: what is your preference ?
<TonyR> +1
<bob> note that you are now requiring a very high bar...
marc: would like a standardized policy framework to do the work against, in absence of such don't see what we can do
tony: policy not in a state where we can reliably define something for use in it
pauld: would like to see some concrete proposals
Mark: could accept this as an issue and explore solutions that are not specific to any policy framework
hugo: there was quite a bit of opposition, can we poll to see level of interest
mark: if we open the issue then ill be tightly scoped to a couple of generic sentences saying elements can be used elsewhere
jonathan: that's acceptable
paco seconds the issue
<mnot> ACTION: Jonathan to make concrete, non-referencing proposal for new issue WRT policy. [recorded in http://www.w3.org/2005/12/05-ws-addr-minutes.html#action01]
umit presents her proposal
mark: lots of discussion on email
umit: lets agree to incorporate the proposal and then work on the comments as separate issues
jonathan: q re prohibited value, is that really a common requirement ?
umit: voted at F2F
<pauld> ack, pauld
dhull: seems that WS-AT requires this
jonathan: any other cases ?
umit: application level requirements
anish: nice indication at binding that responses will not come back on back channel, good to know beforehand rather than find out at runtime
<dorchard> +1 to app level requirements
<uyalcina> what I am saying is that application level requirements may require async bindings. In this case, this marker will be useful even it is at the binding level
<uyalcina> of course, you can build async applications on top of sync protocols too, but if we had a long running request response at the app level, it will REQUIRE an async binding.
gil: thinks there are cases where this is important and that it would be odd if that was not possible in WSDL
<Zakim> dorchard, you wanted to add a bit to gil's point about ws-rx.
dorchard cites WS-RX case where WS-Addr capability can be used to indicate support for anon/non-anon RX replies
paco: doesn't understand RX use case well enough but looks like partitioning of functionality isn't the most appropriate way to do it
<Zakim> uyalcina, you wanted to ask a q to Anish
umit: same use case as anish,
long running request response
... the markup enables applications, think we should keep
it
anish: WSDL 1.1 abstract isn't that abstract so use of this markup isn't that counter
umit: make a high level decision on whether to incorporate this or not
marc: don't want to incorporate a lot of text that is open to change, don't think the proposal is ready yet
http://www.w3.org/mid/239DAF7F-6BAE-47D6-A2FC-5B06F55575E5@Sun.COM
working through point raised in above referenced email
(i) agree this is an issue
(ii) similar to wsaw:Action seems appropriate
<dorchard> + to MarcH
<dorchard> +1 to MarcH
<gpilz> +1 to not cramming everything into the WSDL binding document
(iii) agreed
(iv) and (v) generated a lot of discussion wrt to whether new bindings are being defined or required
http://www.w3.org/mid/54E8F43C-242F-48FF-A099-C7AC17980AD6@Sun.COM
jonathan: in wsdl 2.0 we always include an explicit way of saying the same thing as the default
marc: ok with leaving it in
http://www.w3.org/mid/43949EE5.6020106@oracle.com
umit: didn't think too deeply on this one, wanted to keep BP semantic but also thought there were cases where a reply envelope would be required
jonathan: related to the RM question of sending ack back ?
umit: yes
<gpilz> this "open door" is just "request with optional response" by another name
<gpilz> not that that is a bad thing
<dhull> not convinced
<dhull> (either way)
anish: so 202 SHOULD NOT include a SOAP envelope and we can revisit
umit: yes
<gpilz> WS-RX has problems if there is no SOAP envelope
<dhull> How about SHOULD follow BP, as opposed to SHOULD NOT not follow it?
<dorchard> Hard to imagine w3c spec normatively referring to ws-i spec. Pretty much flies in the face of "we just do profiles"...
<pauld> where is the WS-I 'one-way' binding, is there a URI?
look for 202 in BP