See also: IRC log
minutes are accepted without objection
Bob: Katy sent a proposal: do we
need to say anything about anon in wsdl at all?
... Last Wednesday I had a coordinating chat with the wsrx chairs
... The week before we had a previous discussion with philippe and others about having joint meeting with the wsrm WG
... last meeting we had a strawpoll on this issue which was evenly split between close with no action and continuing discussion
... the next wsrx meeting is this coming Thursday and the chairs are willing to table any comment made by us concerning this issue
... 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 (W3C) don't have any IP concerns at this point
Bob: so it is up to them to get clearance from Jamie
Jonathan: 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
anish: I also sent in a proposal for issue 33 shortly before this meting
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
motivationion/attitute was that the anon 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
Tokyo was not due to legacy app considerations
... I would like to staticly assert use or non-use of anon
... I am opposed to removing this marker unless some other feature provides this facility
... it is not the perview of policy. THIS group has the domain knowledge
<GlenD> +1 to Anish
<GlenD> also +1 that a Policy assertion, if any, would be in the purview of this group, not WSP
<Jonathan> by synchronous, you mean http response channel?
<prasad> Can the server that does not support Anon (async response) return a Fault on the back channel that comunicates that?
<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: You don't want to model that
at the binding level but at the abstract level
... you 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 you any additional info
Glen: so the transport value is different?
Paco: i want to note that when you
wnat to indicate async reply, you 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
anish:It is a nice interoperable way to indicate to clients their right to use sync/async messaging
Philippe: don't understand paco's
... 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 you do this without a bpel engine
paco: what people do is use
... mixing abstract-level and binding-level
glen: it is the right solution
... 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.
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.
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
<scribe> paco and anish discuss relative merits of solving the problem in policy or WSDL
dhull: don't see the
... if rm is enabled then u just change the WSDL
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.
<Dug> ok - as long as 'optional' can mean anon, any non-addressable URI or ibm.com - then ok :-)
<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.
<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 ?
<scribe> 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=... :)
<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.
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 you 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 WS-Addressing 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 poit to another such that the destination 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 you 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: My intention was to provide a guideline for a solution
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
... 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 you are positing that wsrx read wsa specification and consult common members and decided to write a spec that violates 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 wsrx WG
... like we think you 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: I think personally that 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
... 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 am of the opinion that the TAG issue was relevant in to the deliberations of this WG, but not necessarily relevant if taken out of context by other WGs.
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., you are right, it is broken.
<pauld> thrust of issue should be, if you mint your own magic URIs then it's broken
<scribe> 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
... 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?
<bob> Anish, thanks for scribing, I appreciate it