Web Services Addresssing WG Teleconference

Minutes of the last meeting (2006-09-11)

minutes are accepted without objection

CR33

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

anish:Motivation in 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

<mlittle> +1

<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?

jonathan: yes

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 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 you 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.

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 conflict
... 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 :-)

<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 ?

<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=... :)

<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.

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 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 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> LOL

<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 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 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 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 adjurned

<bob> Anish, thanks for scribing, I appreciate it