See also: IRC log
Minutes accepted without objection.
Because of invitation to Dug, his issue will be the first item of business
Dug: Described the problem presented in CR33
... Hopes WSDL spec will soften
wording to allow change of wording of use of anon URI from MUST
to SHOULD
... Considered using a ref param, but seems inappropriate for
this use.
Jonathan: You have to know out of band whether a URI is needed or not
Dug: You need to know whether RM supports anon URI.
Jonathan: RM assertion would have to extend the addressing layer
<anish> RM anon URL is not 'anonymous', there is an embeded identity in it
<anish> so, can't use the ws-addr anon uri
<Jonathan> exactly. It's a identifiable anonymous.
<Jonathan> A named anonymous, if you will.
<Jonathan> An oxymoron.
<anish> the other issue with using refps is that, what happens when there are more than one refps in the EPR
<anish> which makes use of refps for this purpose very tricky
<Jonathan> Why would you have more than one?
<anish> well, the user could be using refps for other purposes (outside of polling)
<anish> i.e., interaction of polling refp with other refps
<anish> anonymous name is an oxymoron, has to do with its history
<anish> it no longer means "anonymous", it means backchannel
<anish> afaiui
Jonathan: The question comes down to
exactly what anonymous means?
... it is context dependent
<pauld> thinks if we were earlier in the process, I'd suggest an "anonymous=true" attribute. but given we're a rec ..
<anish> i should note that it is context-dependent, but the context is defined by the binding not the MEP
Jonathan: In the spec, it is one to
one mapping to anon URI. With RM it is no long one to one
mapping of concept to the anon URI.
... Anish has another type of anon URI use.
Tony: Let's not make things sloppy, we should separate the concept of replying on the back channel, instead of changing it to SHOULD - that will weaken the spec
<mlittle> +1
<anish> how about replacing wsaw:Anonymous with wsaw:Backchannel ?
<Dug> I like the idea of anon=true attribute on the wsa:Address element
<Dug> then it can be any URI - which would make sync and async much more alike :-)
<Dug> no, in the EPR itself
<Dug> I think that's what PaulD was suggesting, but I'm just guessing.
Gil: Idea of anon attribute on the address element seems to solve the problem.
<Dug> +1 Gil
<TonyR> +1
GilP: Problem is we are rather late in how we define the anonymous
GlenD: What is the point of the
wsa:address markup?
... We are already using some contextual understanding of the
URI, so is it really a problem?
<Zakim> Jonathan, you wanted to propose the nuclear option
Jonathan: The more we make the marker open-ended, the anon marker will lose its value.
<Dug> killing the marker works too :-)
<Jonathan> +1 to Marc!
<bob> +2 to Marc
<Jonathan> but, RM isn't a REc yet ;-)
<pauld> we've shipped!
MarcH: This is already a RC, which should be stable
Anish: Agree with Jono that it is an oxymoron, but should not let that prevent us from moving forward.
Tony: Suggest RM is changed rather than changing a spec that has gone to RC.
<GlenD> IIRC, the reason we originally said "you can have other anon uris" was also for RM, but that was about the idea that RM endpoints might actually send you a message that IS NOT the response to your request down the HTTP response, even though you are doing a req/resp...
Dhull: We are getting further away from the HTTP concept of anon.
<GlenD> but I think since then we backed off a little on saying "anonymous URI == specifically the response of a SOAP req/resp"
Dhull: Valid concern that WSA is already in RC, should look at how much room there is for change before seeing what to do
MarcH: If I am unaware of the RM spec, how do I know the meaning of the anon URI to be used?
<David_Illsley> yes, CORE 3.2.1
<marc> http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#compiri
Jonathan: not heard any solution that
I am completely comfortable with
... What about talking about the endpoint instead.
Turn it the other way round
<anish> i.e, wsaw:NewConnection={prohibited|required|optional} ?
<GlenD> yah, just have to get the specese right
Dug: Not sure this will solve the problem.
Jonathan: is it possible to solve this in conjunction with the policy document?
<Dug> bob - if I'm allowed (not being a WSA member) I can work on some text with Anish
Alistair: Have we established that they are completely orthogonal?
Jonathan: We have established that the two specs don't allow the use of the RM URI in the use of our markup WSDL
<scribe> ACTION: Dug and Anish to go away and work on a text by thurs/fri. [recorded in http://www.w3.org/2006/08/14-ws-addr-minutes.html#action01]
<Dug> yup
Bob: invites Dug back to next
Monday's call
... Action item review
... Still looking for testers
Bob: Arun not present at the moment, but the updated table is posted.
Bob: CR27 Philippe's action-
pending, due Wednesday
... CR30 Tony's action- pending, due Wednesday
<marc> Updated table: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Aug/att-0050/anonymous-semantics.htm__charset_WINDOWS-1252
Bob:Per the minutes of the last meeting it is our intention to include table in the spec.
Anish: Want to point to another
issue that might change the content of this table.
... Also there is an issue with rule 4
Philippe: Is this related to CR32?
Gil: If Anish thinks 4 E is incorrect, is 8 D also incorrect?
Jonathan: Will this also affect 9, 10 , 11, 12?
Anish: Need to decide on None/Anon mismatch
<GlenD> +1 to Tony
<anish> may i suggest that we resolve the other issue first, it might make this much clearer
<agupta> got pulled over, now back
<GlenD> gotta run....
Discussion on Anish's and Tony's differing viewpoints
Tony: there are two issues
Anish: Do we need to say None URI is prohibited in response?
Tony: Don't think so
Resolution: Folks agree that none is acceptable for use when anon=required or anon=prohibited. This will close cr32.
<scribe> ACTION: Tony is to propose modifications to the table on discussions of sending notifications to the backchannel when wsa headers are invalid [recorded in http://www.w3.org/2006/08/14-ws-addr-minutes.html#action03]
<David_Illsley> gpilz, I can agree that there might be those situations but I think thery're edge cases and predictability is more valuable
<Jonathan> I don't want to force lazy evaluation, but I'm interested in enabling it.
<dhull> do we have an issue for this?
<gpilz> Jonathan, it's a little like being "slightly pregnant"
<anish> i'm begining to think that this (lazy eval as a MAY) is a good idea
<bob> I didn't think that it was our intention to be prescriptive about the sequence of error detection. Validate before use or validate at the point of use should both be acceptable.
<bob> yinleng, thanks for scribing