See also: IRC log
Minutes accepted without objection.
MarkN: planned to act as co-chair
for a month
... changes due to new employment - will act as an observer for
the next month
... reduced to bark, no bite
Bob: assuming we can get document
into shape, consider LC period on WSDL document ended at the
end of March
... any objections?
TonyR: Instead of including the resolution of CR15 under 3.5, which would result discussing SOAP 1.1 under SOAP 1.2 heading, I put it into a new section 5
DaveO: the new text is missing the intended pointer to the one-way binding.
TonyR: had trouble constructing a pointer to a document that doesn't exist yet
DaveO: need a placeholder that we can update
<anish> we can make the Note/WD go through LC as well
<uyalcina> +1 to Anish
DaveO: very important to include this pointer when discussing non-anon with SOAP 1.1
<dorchard> davidhull, it's not that tricky because xmlp is talking about soap 1.2 and my comment is on soap 1.1
Hugo: could insert a link to the e-mail archive in an editorial note
<scribe> ACTION: Tony to insert an editorial note linking to the SOAP 1.1 proposal [recorded in http://www.w3.org/2006/02/13-ws-addr-minutes.html#action01]
Marc: re: my implementation of
the resolution of issue 70 - softening language
... resolution ended with suggestion that editor should insert
an example.
... instead I added a para saying
<marc> Example text : dditional runtime information could override the value of the [destination] message addressing property for messages sent to an endpoint, e.g. a runtime exchange might result in a redirection to a different EPR. Note that WS-Addressing does not define any normative mechanism for such redirection.
<uyalcina> Resolution2006-01-20
<uyalcina> point the editors to the resolution of i056 and especially at "in the absence of additional information", and add an example for it (runtime override)
Katy: like the text, but not sure about the text after eg:
Umit: do we need an example?
Bob: want to get this document
into LC - feel free to raise LC issues against this
Bob: Jonathan's Option 3 proposal - is this an obsolete consideration?
Jonathan: still not comfortable
Bob: let's close this item, can
always raise a new item
... all other AIs are done
Bob: considering this now because Paco has limited time on call today
<anish> URL to my proposal: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Feb/0094.html
Paco: extract option 3 from
original e-mail as separate proposal
... meaning of Anon depends on the transport binding
<Zakim> marc, you wanted to mention issue 70 resolution
<Jonathan> Is this the latest proposal? http://lists.w3.org/Archives/Public/public-ws-addressing/2006Feb/0091.html
Paco: in HTTP this means using the reply channel, which means there are no accepted semantics for Anon in To of a request
DaveH: is this normative or not?
Paco: I have no problem if we think that using anon in a request should fault
<Zakim> dhull, you wanted to ask if this is normative
DaveH: either we make a normative change, or we are just making a note on the status quo
Anish: with this proposal, will we require a request to always carry a serialised wsa:To?
Paco: yes, to be consistent
... we can either be explicit about existing situation, or make
up new semantics for anon for To on request
<bob> link to Anish's 4a version http://lists.w3.org/Archives/Public/public-ws-addressing/2006Feb/0094.html
Paco: let's not allow ambiguity, by stating explicitly situation regarding anon in To of request
Anish: not happy with keeping core unchanged and making meaning of anon depend on the binding
Paco: rather than include information about a transport in the core, keep core generic
DaveH: have an interop problem
because we don't state what we mean
... status quo is already ambiguous, and any resolution will
involve introducing new semantics
... willing to see any of several resolutions, but must not
special-case HTTP in SOAP binding
Paco: fact that SOAP 1.2 defines
abstract properties doesn't change situation
... status quo is broken
... the only accepted semantics is anon=HTTP response
DaveH: if we state general case: anon disallowed for request in SOAP 1.2 is OK
Umit: supporting what Paco is saying
<pauld> would say the status quo is "we say nothing" which was only broken for me because *I* made assumptions.
Umit: adding extra semantics is dangerous; leaving it dangling is dangerous; Paco's proposal is safe
Jonathan: is there a concrete scenario that relies on this being undefined?
DaveH: faulting if you get anon
on request is OK, but what I find objectionable is referring to
HTTP in the context of SOAP 1.2
... if we make a blanket statement about HTTP, then we make the
SOAP 1.2 binding have to have special handling for HTTP - lose
generality
... may be abstract, but it's an important issue
... holding onto the layering is important
Bob: now let's look at Anish's proposal
Anish: we did the defaulting (to
anon) to simplify the common case of response over an HTTP
link
... problem is that we have made the request more complicated
(have to serialise wsa:To)
... perhaps the optimum is to specify defaults not in the core
but in the bindings
... proposal removes default from the core; adds wording to
binding to say anon refers to HTTP response channel
... this allows [destination] to be undefined
... different protocols may have reason to leave wsa:To
undefined
... protocol specific header may provide the equivalent
information in place of wsa:To
... suggest making wsa:To required, but not provide a
default
Umit: not really making To
unrequired, really making it defined by underlying
protocol
... what is assumption if [destination] is undefined?
Anish: it's the other way around:
the value of the [destination] property may come from somewhere
other than wsa:To
... the [destination] property may be set from other
information
Umit: trying to understand how you specify [destination] in a transport-independent way
Anish: the [destination] property means what it means today if present, but if it is not present, nothing is stated
Umit: if you don't have [destination], how do you know where to send the message?
<anish> wsa:To is already optional
Katy: uncomfortable that
[destination] is not mandatory in this proposal
... are you suggesting that anonymous becomes HTTP anon?
Anish: fine with having [destination] mandatory, but must have mandatory wsa:To as well. Not happy with having default to anon, and not requiring binding to define anon
Paco: understand wanting to get rid of defaulting, but not happy with adding "magic" to handling message destination
Anish: maybe destination is not
required with some protocols
... happy to split proposal
... started by assuming people did not wish to change the
cardinality of [destination], but people seemed happy with
it
... would you be happy with defining defaulting at the binding
level?
Vikas: Anish raised the point during discussion
<Zakim> TonyR, you wanted to ask if Anish is making wsa:To optional, or [destination] optional
<uyalcina> great point Tony!
<vikas> Tony, what I was saying is wsa:To mandatory in Core but optional in soap binding
Marc: just checking: the proposal is to move defaulting from Core to binding
<TRutt> I like the flavor of Tony R proposal, at the soap binding level
Bob: are we looking at a third proposal?
Paco: Anish and my proposals seem to be coalescing
<uyalcina> i like the fact that we ack destination is mandatory
Anish: I tend to agree. Perhaps Paco and I can take a joint action to revise to produce a converged proposal?
<anish> i believe that the interop issue has kicked up a whole bunch of stuff
<anish> and we need to deal with it
<anish> i.e., the dragons in 'anon'
Jonathan: I think we're heading into the weeds here. A simple proposal (like PaulD's) could address this, without wide impact on spec text.
<TRutt> I sympathize with Jonathan, the we do a minimal fix, which has the affect of making to required for soap request
Jonathan: don't see value in big change
Anish: changes aren't so big
Jonathan: not sure you're addressing Marc's objections
Anish: not ignoring Marc's problem, if we focus on SOAP binding (instead of SOAP/HTTP)
Paco: see this as resolving the dragons that we roused in the interop
<TRutt> Could Tony restate his compromise on te IRC using the proper wording of soap binding?
DaveH: Marc's objections to defaulting in the binding are the same as mine
TonyR: my suggestion is that wsa:To is optional, but if it is not specified in the message, then the binding MUST provide the value of the [destination] property (which is mandatory)
<vikas> core shouldn
TonyR: in my head we don't have a default for wsa:To, we have a default for [destination], and it is provided by the binding.
<Zakim> Jonathan, you wanted to restate the interop problem
TonyR: in other words, we remove the defaulting from the Core, we leave wsa:To as optional, we leave [destination] as mandatory.
Jonathan: the interop problem was that two different implementations interpreted the meaning of wsa:To being anonymous in different ways
Anish: isn't that CR18?
<Zakim> pauld, you wanted to ask about expected impact on CR implementations
Jonathan: don't see an issue in CR20 at all
<Nilo> i keep getting dropped from the call...any thoughts why?
PaulD: interesting ideas, but we're in CR. We have demo'd interop already. Should not go changing things that will impact code
DaveH: is interop working because we removed the test cases that showed the problem?
Jonathan: no, there were test
cases that relied on a non-existent feature (anon To on
request)
... we just fixed the To in the test cases that depended on
this undefined behaviour
Anish: what happened with implementation?
Jonathan: it faulted when given an anon To on request
<Nilo> zakim seems to be hanging up on me after one ring...with three beeps!!!
Hugo: like to support Jonathan and Paul - we don't have a clear solution for the problem. Seem to be revisiting past decisions.
<Zakim> anish, you wanted to say that this is an interop issue since we haven't defined what it means to have 'anon' uri for was:To
Anish: disagree - this raised dragons that were lurking
<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Feb/0056
DaveH: three way choice on topic
of anon destination in a request
... 1. define it
... disallow it
... 3. define it and make it the backchannel
DaveH: prefer to keep status quo, add PaulD's warning note
<bob> In our Core specification for anonymous URI, we say:
<bob> """
<bob> The precise meaning of this URI is defined by the binding of
<bob> Addressing to a specific protocol..
<bob> """
<bob> Section 3.5 of the SOAP Binding "Use of Anonymous Address in SOAP"
Bob: Paul's proposal short - pasted into IRC
<bob> states the meaning of anonymous addresses in practical terms
<bob> when moving messages down a channel.
<bob> To explicitly state the Status Quo, I suggest adding the
<bob> following sentence:
<bob> """
<bob> A value of "http://www.w3.org/@@@@/@@/addressing/anonymous" for
<bob> the [destination] property implies no particular semantics.
<bob> """
<dhull> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Feb/0061.html
<marc> ?
PaulD: this sentence gets added to the SOAP Binding in new section 5
Bob: does this mean that DaveH is now advocating Paul's proposal?
DaveH: yes
PaulD: providing clarification of meaning of anonymous To (we already say meaning of anon ReplyTo)
Anish: so you say we do not specify the meaning of anon To no matter which message it appears in?
<Zakim> dhull, you wanted to clarify
DaveH: rules in 3.4 say if ReplyTo was anon must put anon in To
<TRutt> what about optionality/defaulting of To Value on response
DaveH: the intent of this note is that one must not do this except when replying to an EPR that had anon in ReplyTo
<Zakim> marc, you wanted to discuss whether anon to means this was sent to anon or not
Marc: it's not accurate to say we
don't assign any semantic to anon - we do in the case of
reply
... we just don't have semantics for anon in To of request
DaveH: or in a one-way
<marc> we don't have semantics for any address in To really
<marc> [destination] is jets wehere the message was sent same for anon or any address
TonyR: anon has meaning only when used in response to an EPR with an anon ReplyTo
DaveH: anon To has meaning only when used in response to an EPR with an anon ReplyTo
<anish> [destination] prop with the value of 'anon'?
DaveH: [destination] value of anon URI has meaning only in a response to an EPR with ReplyTo having value of anon URI
<bob> [anon destination] has meaning only when used in response to an EPR with an anon ReplyToq?
Marc: response endpoint having value of anon URI
<anish> what don't we say that 'anon' means the "response channel" -- if you use it for response, it is defined. If you use it for 'request' u are on your own
<anish> that way we define what it means -- and it says the response. If your going to use it for request message -- we don't know what it means
Jonathan: why don't we just say Anon means the response?
DaveH: trying to say that we should say that we specify this in one case, but not say anything in other cases
<vikas> because not all transports have response; in which case anon means something specific to transport
TomR: I thought we were allowing someone in the future to come up with a binding that defines a different meaning for anon
Jonathan: I think the concern is that we won't know whether anon is valid until we reach the binding level - makes general coding impossible
Anish: instead of Paul's wording,
why don't we say that it means the response channel?
... instead of saying "there are no semantics", say that we
have semantics for response, but not for request
Bob: Martin G's words were "the
binding knows what to do".
... perhaps Jonathan and Paul could join the Anish/Paco team to
come up with a resolution
... let's talk about this on the list during the time between
meetings
<bob> thanks tony for scribing
<anish> Bob: I would like to resolve these issues ASAP and would like to get some email discussion early, rather than a day before the call
<anish> anish: i'll send out a proposal to paco today. Don't know what Paco's schedule looks like, but if he can respond quickly, we'll send out a proposal today or tomorrow
<bob> Goal is to at the beginning of the next call to afree on a joint proposal.
<bob> thanks and good night