WS-Addressing Working Group Teleconference

 

 

<scribe> scribe: Bob Freund

resolution: minutes of 2006-11-13

Tom: the proposals are using policy parameters, which are not being used by the intersection algoritm
... I did not see any problems

Paco: Intersection only looking at qnames, we are not leveraging the policy framework

Marc: Nested approach taken only for aesthetic reasons

Anish: Would be better to have independant assertions that are not parameterized

Gil: Agrees with marcH, we should not have to define our own intersection model

Anish: If we are going that route, would addressingrequired be replaced with anonresponse etc at the top level?
... there is a lot of duplication

Gil: there is a difference in meaning between missing wsdl markers and missing policy asssertions

Anish: there are a lot of implementations that use usingaddressing as a policy assertion

MarcG: usingaddressing works fine since it works well as mapped to a policy assertion
... anonymous did not map well
... current proposals focused on policy assertions for anonymous

Anish: There is no fundemental problem in using the same QNames
... the problem is parameterizing the assertion itself

Marc: three assertions; usingaddressing usinganon using nonanon?

Anish: If we keep the structure as is, with children elements, we are not solving the problem with parameterization
... thus we need top level independednt QNames

<Dug> do we have a URL?

http://lists.w3.org/Archives/Public/public-ws-addressing/2006Nov/0026.html

cr33 proposal 7

gil: UsingAddressing is equivalent to addressing required

Anish: I don't think that we need to have a distinction between the WSDL and Policy assertion QNames
... I think that we could used the same QNames for both

Marc: UsingAddressing says nothing about the forms of addresses required

Tom: Is it important to say that I can never have applies?

Marc: allows others to define other assertions with their own assertions

Gil: we cannot define all kinds of addresses

<Dug> hate to ask but does wsa:None need to be taken into account here or is it just assumed to always be allowed?

Anish: will never use usingaddressing alone because no address form is used
... even one way messages might use replyto
... likes the proposal since it states things in the positive

<David_Illsley> Dug, it's assumed to be allowed.. see reply from Marc to me somewhere down the thread

<gpilz> I had another ugly thought: what if the message contains a ReplyTo that is not targeted at the receiving node?

Anish: it is composable with other specs if they define their own form of anonymous addresses

<Dug> gil - very common scenario

<Zakim> gpilz, you wanted to speak to David's proposal

Gil: DaveO was concerned with default behavior
... his problem with positive assertions and because of the lack of positive assertions, a client might give up
... with neg assertions, SW will try to communicate
... need to weigh default behavior with the cr33 trap
... need to avoid cr33 trap trumps default behavior

Tom: Negative assertions from a high level might have intersection issues

ack: tom
... first lets decide on removing nesting

Paco: likes additive behavior, but still have an issue with an assertion that does not have enough meaning by itself
... I would like to keep using addressing, but would like to have single assertions that has whole meaning without the need for an additional assertion

<Paco> (i) <wsaw:AddressingRequired/> - the endpoint supports and requires WS-Addressing, no constraint is placed on the replies the end point cansend.

Gil: prefers that marc's approach is closer to the bone

<Dug> why do we need wsaw:AnonymousRequired - why not just wsaw:FullWSASupport to mean anon and non-anon is supported?

<Dug> if you want just one then use just wsaw:AnonReplies

<Dug> no assertion means no WSA support at all

Gil: thinks it is more confusing to have the same QName and optionality when policy is contained in wsdal file
... it is less confising to have different names

Paco: meaning is exactly the same, but contained in a different context

Anish: I see Gil's point that a naive user looking at a wsdl document might be confusees, but the important point is that the framework within it operates is ket
... If it is viewed at the infoset level, then there is no confusion

Bob:Can we get down some hard text?

marcG:Are we now not going to pursue mapping this to wsdl markers?

http://lists.w3.org/Archives/Public/public-ws-addressing/2006Nov/0026.html

(i) <wsaw:AddressingRequired/> - the endpoint requires WS-Addressing,

optionality can be conveyed using WS-Policy constructs.

current text in proposal 7 above

<anish> I would rather say: , that can be used to indicate that an endpoint conforms to the WS-Addressing specification.

<Paco> (i) <wsaw:AddressingRequired/> - the endpoint supports WS-Addressing, no constraint is placed on the replies the end point can send.

<Paco> (i) <wsaw:UsingAddressing/> - the endpoint supports WS-Addressing, no constraint is placed on the replies the end point can send.

Paco: one of the three would be used, no need for more

<marc> seems like UsingAddressing should just say that addressing is supported but not say anything about the addresses that are supported

(i) <wsaw:UsingAddressing/> - the endpoint supports WS-Addressing,

no constraints are placed on the replies the endpoint can send

(ii) <wsaw:AnonymousReplies/> - the endpoint can send replies using

WS-A anonymous.

(iii) <wsaw:NonAnonymousReplies/> - the endpoint can send replies

using other addresses.

Assertion (iii) is deliberately vague, its presence means that a non-

anon address might work but doesn't constrain what such an address

might look like - a receiver can still reject an address that it

doesn't grok or that requires a binding it doesn't support. The WG

decided against specifying things like available response bindings so

I think this is in line with that decision.

proposal final text subject to editorial revisions

(i) <wsaw:UsingAddressing/> - the endpoint supports WS-Addressing,

no constraints are placed on the replies the endpoint can send

(ii) <wsaw:AnonymousReplies/> - the endpoint can send replies using

WS-A anonymous.

(iii) <wsaw:NonAnonymousReplies/> - the endpoint can send replies

using other addresses.

<gpilz> (i) + (ii) = (ii)

<gpilz> (i) + (iii) = (iii)

<Dug> i+ii=i i+iii=i

<gpilz> I don't agree Doug

<marc> i'm confused, i thought (i) = (ii) + (iii) ?

<gpilz> (i) leaves open the possibility for anon responses

<gpilz> (iii) does not

<Dug> I'm ok with either but I think the spec needs to be clear what i+ii means

Editors to add text that indicates that one assertion is required. Also add some info relating to the intent and the relationship of one to another

<Dug> ii+iii=i i+ii=i i+iii=i

<David_Illsley> imo i+ii=i

<gpilz> I think the important thing is that all assertions are additive

<gpilz> so (i) means addressing is supported but you take you chances w/regards to using anon or non-anon etc.

<TomRutt> 1 says addressing is supporte, maybe anon maybe non anon 2 says anon is supported, 3 says non anon is supported

<gpilz> (ii) is positively affirming that anon is supoorted

<gpilz> so (i) && (ii) means that anon is definitely supported and non-anon may be supported

<TomRutt> 1+2 = 2 , 1+3 = 2

<gpilz> similarly for (i) && (iii)

<anish> yes, 2 & 3 subsume 1

<TomRutt> s/1+3=2/1+3=3/

<anish> i'm wondering if we should have some wordings for (iii) that say something like "... typically non-anon addresses are used to specify response addresses that go to a different place from where the request came in ..."

<anish> that would be non-normative, of course

<David_Illsley> anish, I'm not sure I agree with the statement... my gues is that the common case is async-callback invocation

<anish> david, isn't that a different place from the back channel?

<anish> perhaps the words need tweeking

<David_Illsley> so the back channel is a place now? :-)

<anish> lol

<David_Illsley> anish, I think we head back towards new connection which we might slip through in non-normative text

<anish> all i'm trying to say is that, we should include how typically this is used (i.e. the async scenarios) where the replyTO address is a dereferenceable URL

<anish> ah, sure, that would work, David

<TomRutt> yes

ai: gil to produce stab at final text before wednesday this week