See also: IRC log
minutes are accepted
Bob: katy sent a proposal: do we need to say
anything about anon in wsdl at all
... had a coordinating chat with wsrx chairs
... had a previous discussion with philippe and others to have a larger joint
meeting with wsrm WG
... previous strawpoll on this was split
... the next wsrx meeting is coming thursday and the chairs are willing to
table any comment made by us
... the wsrx chairs felt that either this WG or a member of the WG should
make a comment to the wsrx WG on CR33
... when this is done they will raise that in the WG
... they will also talk to OASIS regarding IP concerns
Philippe: we don't have any IP concerns at this point
Bob: so it is up to them to get clearance from Jamie
JM: and this issue would be generic at this point, like your facility does not compose with our facility?
Bob: yes, or if we come to a resolution which results in a conflict then we need to be specific. If our resolution results in no conflict, then we don't have an issue
<Dug> Bob - I don't think we need a joint meeting since this isn't an RM issue - see previous comment to tony
anish: i also sent in a proposal for issue 33
bob: lets start with Katy's proposal
<TRutt_> Anish proposal is at: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Sep/0028.html
Paco: we had a discussion about this in IBM.
Katy & Umit worked hard in Japan on this. The motivation/attitute was
that the anony stuff we don't understand but will help legacy apps
... we are seeing that as specs become more specific, this marker is naively
constraining
... the fact that there is only one and only one uri for anon isn't true.
... we thought it was right to ack that and withdraw the bit
... and wait and rely on specifications like policy to fine tuning the
back-channel aspect
... the proposal is to remove the wsaw:Anonymous tag and indicate support or
no support at runtime
<bob> anish: Motivation in Tokyo was not due to legacy app considerations
<bob> ... I would like to staticly assert use or non-use of anon
<GlenD> +1 to Anish
<bob> ... ... I am opposed to removing this marker unless some other feature provides this facility
<GlenD> also +1 that a Policy assertion, if any, would be in the purview of this group, not WSP
<mlittle> +1
<Jonathan> by synchronous, you mean http response channel?
<bob> ... it is not the perview of policy. THIS group[ has the domain knowledge
<prasad> Can the server that does not support Anon (async response) return a Fault on the back channel that comunicates that?
<bob> s/\[//
<dhull> we want to cover a couple of important cases with special markers, but policy is needed for the full answer, so we can't get in the way. Does status quo in fact get in the way?
paco: u don't want to model that at the binding
level but at the abstract level
... u want to model this at two separate interactions
<GlenD> Different connection != long running, in general
<Jonathan> +1to paco
paco: my view is that it is wrong to solve this problem this way
<dhull> right. Long-running at least mostly implies separate connection, but not vice versa
<GlenD> And there are plenty of good reasons to do multi-channel async interactions that aren't long running
tom: in agreement with anish
<GlenD> (cellphones, etc)
glen: i'm also with anish on this, it is fairly
important to do that. It may be possible to not have a fault
... the interesting case is that there is a fairly imporatnt implementation
WCE: duplex channel
... if there is a duplex channel that handle non-anon uri it would be pretty
handy to have this
daveh: we got here 'cause of doug's analysis
<pauld> full-duplex and half-duplex? having phone coupler flash-backs
daveh: i'm sympathetic to keeping the work,
otoh, we have sidestepped the issue with what address i can send you (email,
jabber etc)
... we should not preclude anything
... we may be good just with a clarification of what all of this implies
jonathan: i wanted to talk about what glen was
saying. We provide two different bindings: one corresponds with 'required'
and other to 'prohibited'
... each binding has markup in the wsdl. the anon marker does not give u any
additional info
Glen: so the transport value is different?
jonathan: yes
Paco: i want to note that when u wnat to
indicate async reply, u already know that
... it doesn't help us
... we dont' understand how this is done. The marker is so restricted.
... better to be done as a policy
<bob> anish: It is a nice interoperable way to indicate to clients their right to use sync/async messaging
Philippe: don't understand paco's point
... don't see how this would work with in-only and out-only, since out-only
is being removed from WSDL 2.0
paco: no, two in-only operations
<bob> My point is that the anon url implys ONLY the implicit use of an underlying protocol's back channel
anish: how do u do this without a bpel engine
paco: what people do is use partner-links
... mixing abstract-level and binding-level
glen: it is the right solution for some
... different between long-running and async
<dhull> +1 to glen
paco: again mixing abstract and bindings
<GlenD> Just because the fallacies of distributed computing exist does NOT mean that it isn't possible to successfully build a worthwhile stack of distributed computing abstractions.
<bob> anish: How does moving this to policy solve this problem?
paco: policy has a composibility framework
<GlenD> Whether it's policy or WSDL markup really doesn't matter, IMHO. It's metadata which in at least some cases gets checked for compatibility with a communicating peer. C'est ca.
<bob> anish: policies can conflict as well
paco: policy allows separate assertion
<dhull> "It's all metadata" -GD
anish: but the policy assertions will still conflict
<bob> paco and anish discuss relative merits of solving the problem in policy or WSDL
<bob> s dhull
dhull: don't see the conflict
... if rm is enabled then u just change the WSDL
<bob> s/s dhull$//
dhull: i also don't agree with the assertion that the marker is redundunt to the binding
<Dug> dave - it sounds like "optional" means any non-addressable URI - is this true?
<Dug> (to you)
<dhull> no. It just means that anon is acceptable but not required. If you don't give anon, you have to look elsewhere to find out what you can give.
<dhull> It means what it says it means: Anon is optional.
<dhull> At least that's how I read the text.
<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Sep/0028.html
<Dug> ok - as long as 'optional' can mean anon, any non-addressable URI or ibm.com - then ok :-)
<Dug> LOL
<dhull> It's a bit of a technical point. Optional doesn't implicitly prohibit or allow any particular non-anon. It's silent on that.
<pauld> made this proposal at the 14-Aug telcon, but thought/thinks this is too late given it impacts our core and SOAP recs, no?
<Dug> so its like not having the marker at all then?
<dhull> It's sort of an expiclit default, I gues.
<Dug> gotcha
<GlenD> not quite - IIRC it indicates that nothing horrible will happen if you do use anon, but it's not required
<pauld> and if we have this on-the-wire and WSDL marker and they differ ?
<bob> Anish: reviews his proposal located at http://lists.w3.org/Archives/Public/public-ws-addressing/2006Sep/0028.html
<GlenD> as opposed to no marker, you use anon, and you get silence (no fault, no response)
<dhull> ""optional": This value indicates that a response endpoint EPR in a request message MAY contain an anonymous URI as an address."
<Dug> although, I'm still confused at how a WSA-only client knows that only anon/none is allowed and not ibm.com
<dhull> It doesn't. You need more bits for that.
<Dug> since wsa doesn't define any other marker for the wsa-only to look at to know this
<Dug> so you want wsa to define another marker?
<dhull> That's right. That's why I say you need something else (Policy?) to say, e.g., "You can use mailto:" or "You can use http://mydomain.com/*"
<dhull> No. Not at this point. Might have been nice.
<GlenD> allowedBindings=... :)
<dhull> :-)
<Dug> so your proposal is to tweak the wording of "optional" and, at some point, add some other policy marker?
<dhull> Yeah. "Tweaking" would be just amplifying the (implicit) disclaimer.
<GlenD> LOL
<GlenD> this one is still funny no matter how many times I hear it :)
<GlenD> "oh, the old 'why isn't wsa:To an EPR?' joke..."
<dhull> Stop me if you've heard this one before
<Dug> LOL trying to imagine an entire spec written like that
<dhull> No! Stop!
jonathan: what about was:To?
anish: not really an issue. it is independent of RM
glen: really needs to be in the core
<dhull> +1 to nice thing to do, but +1 to concerns about intrusiveness
anish: yes, but don't see this as a fundamental problem
jonathan: it seems like could be stuck in the
metadata section
... if u imagine that this could go in a metadata, it is an epr extension and
not an address extension
... this would have introduced a fair bit of change in makeconnection
thing
... concerned about extended eprs
dug: want to see that discussion doesn't go into what rm may or may not do. this is a wsa issue
jonathan: i thought we were going to file an issue against wsrm
dug: yes, but this is a wsa issue
bob: anon is a back channel, not an issue of addressability
tony: i disagree
... none is used in both things
<bob> +1 Jonathan
<pauld> +1 to not allowing others to specify URIs 'special' to WS-Addressing
<Dug> how can we possibly think that no other spec for all eternity would never need to define a new special uri? seems so limiting.
more discussion about how wsrm anon and how it would conflict or not with another anon uri
bob: given that this issue was raised by the
wsrx team member. The context is wsrm. Is there a way that RM can do what
they want to do.
... addressing doesn't allow rm to do what they want to do. We could say:
here is a way to do it without having a conflict
... are there ways to solving the problem without changing the spec
<gpilz> I thought it was this working group that decided that the service provider had no business cracking open and examining refP's ?
<GlenD> I believe we are silent on that, Gil.
anish: wsrm can use refps, but it goes in identification/comparison issue that no one want to go into
<gpilz> my mistake then
<GlenD> we might say it's not a great idea, but it certainly don't say you can't. :)
<dhull> that's our general approach, no?
<Dug> that's quite a change for current impls - I doubt most look at anything other than the wsa:To of the outgoing message
bob: they want to send a msg from one pt to
another such that the destn can respond on the back channel with content
whcih contains a msg selected by something in the request message which in
this case is a special version of anon uri template or potentially someother
info.
... we said that URIs are the way to identify, but we still have
parameters
... gets to what is a resources etc
tom: this is a difficult issue. the trouble is
that everyone has a different view. My interpretation is that refps is for
higher layer
... but everyone thinks of layering in a different way
<gpilz> I don't think of WS-Addressing as a "layer" at all; more like a utility library
+1 to gil
tom: nobody here can speak to what wsrx committee can agree to
Dug: wrt whether we can do what rm needs to do,
I don't know. If u want to push back on rx and say rework your proposal, that
would be ok. But all the questions about refps have to be addressed
... identification, opacity, change in processing model for the server
... it is a radical change and RM did want to limit changes
... check for special uri is not a big deal but looking for refps is
... another problem is that wsa 'anon' uri is for a particular back
channel
... wsrm 'anon' is any back channel
... some people think of wsa as a layer some think of it as a utility
library
<pauld> actually I think WS-A should have been burnt into SOAP
<dhull> +1 to answering the questions concretely
<Jonathan> "layers" are an abstraction allowing a variety of implementation strategies. Breaking "layers" usually prevents some implementation strategies.
bob: i intention was to provide a guideline for a solutmyon
anish: don't view wsa as a separate layer, but more as a utility api
<Dug> I still think even if RM changes this just postpones the issue since I think some other spec, at some point, may need to define some new special URI and they're in trouble.
gil: A lot of overlap between wsa and wsrm
... wsa concerns were the top motivator for the existing solution
... chrisf was adamant on not requiring change to wsa implementation (wrt
refps)
... so was daveo
<Dug> proposal: change MUST to SHOULD
bob: so u are positing that wsrx read wsa specification and consult common members and decided to write a spec that violate ws-addressing
gil: this was the least violation of wsa construct
<Dug> violate is a bit strong :-)
gil: other violation were worse
<dhull> can we at least agree on whether there /was/ a violation
glen: what was the violation?
bob: they use a different URI for anon
glen: which we allow
<Dug> but WSA defines URI with behavior??? why can't others?
bob: jonathan now thinks that this was a mistake
tom: wsrm spec has two major uses for the new
anon with makeconnection
... one is replyTo use
... their use of this for ackTo has no concern to ws-addr
tony: the idea about layering -- it is like RM is trying to write the layering to fit it's stuff in. Some way if we could separate the layer, i would be more interested in that.
anish: not a violation but a need to work more closely
dug: change 'MUST' to 'SHOULD' was also another proposal made
bob: do folks feel comfortable with an issue to
be raised with wsrm WG
... like we think u should use refp
tom: and clarify about replyTo
jonathan: another way is to use wsa:From header
paco: there is no evidence that we are converging on a solution that will move us from the status quo
<Dug> how can RM come to a conclusion if WSA can't?
tom: this mechanism does not have a problem
with acks to
... i don't think we should speak to what they would agree to
<Dug> well, they did already
bob: personally our response should be narrowly constrained to the request made to us
anish: would like to know how folks feel about my proposal
paco: don't dislike it, but concerned about going back to core
jonathan: not clear to me either
bob: more discussion on the proposal is needed,
but thinking about our response to wsrm WG
... we can continue headbanging
<gpilz> everyone seems worried about sending core back to last call or some such; what about an errata?
gil -- i don't think core is affected at all
bob: i would like to send a response to wsrx
dug: in the response back to me or wsrm about having to rethink it. we would need more information
<TRutt_> The problem seems to be the use of wsrm:anonWithPolling with ReplyTo has implications on the definiton of anonymous marker in using addressing
bob: i'm of the opinion that the TAG issue were relevant in W3C, but not necessarily have to go over other WGs.
q_
dug: if that is what the WG feels then i would like to see such a note to ignore the TAG
<TRutt_> The ws-rx group has a mechanism which is optimized for use in wsrm:acksTo. The key point of this new issue is that its use for ReplyTo has implications on the wsa:wsdlbinding's definition of the anonymous tag of the usingAddressing wsdl marker. relay the original issue cr33 from Dug back to them
anish: will take an action to send an email exploring the core issue
<Dug> tom - MakeConnection was not written for acksTo !!!!
tom: relaying the original issue from dug back to them would be the best way to go procedurely
bob: yes, we could say that things don't quite
work right
... i agree that tom's way is a good way to move forward
... are folks willing to allow me to open an issue on wsrx with the meat of
Dug's issue to us -- i.e., u r right, it is broken
<pauld> thrust of issue should be, if you mint your own magic URIs then it's broken
ACTION: bob to send an email to WSRX that this is an issue [recorded in http://www.w3.org/2006/09/18-ws-addr-minutes.html#action01]
<gpilz> can we get big L's tatooed on our foreheads at the same time?
Jonathan: come up with a couple of nits
... editorial issues, rx issues
bob: will look at them
Jonathan: prefer that we send the comments as ws-addr
bob: do i have your consent?
no objections
meeting adjourned