See also: IRC log
<bob> zakin, mark_peel is katy
thanks
<anish> right on cue
<bob> Scribe: katy
thanks hugo - stops the phone from beeping
<Jonathan> tp://www.w3.org/2002/ws/addr/6/04/03-ws-addr-minutes.html
<Jonathan> http://www.w3.org/2002/ws/addr/6/04/03-ws-addr-minutes.html
RESOLUTION: Minutes were accepted
Action Item complete - not checking in yet
jonathan: Action item on clarifying conformance point done
RESOLUTION: LC125 closed with proposed text
Confusion arose because space between using and addressing.
RESOLUTION: Editors modify element names with different font
LC 129 Accepted as new issue
LC 130 accepted as new issue
Bob explained Last Call interval is now closed
Jonathan: 2 more issues for tomorrow
Group agreed to 24 hour extension LC issues until COB CA time tomorrow
Jonathan: Some discussion on email - still find issue a little confusing
optional value causing problems for WCF
similar concerns brought up but not the same as M/S does
dhull: Complaint is that by looking at WSDL endpoint can't tell whether want to use anonymous or not
this is as designed for spec
email thread confirmed issue
bob: can we respond by we understand but close with no change
<scribe> ACTION: Bob to respond to submitter with close issue with no action [recorded in http://www.w3.org/2006/04/10-ws-addr-minutes.html#action01]
Jonathan: At the point of locking
down what needs to be shipped for WCF
... Out of box WCF can have 2 soap bindings: AnonymousRequired
with backchannel
... other binding is : anonymous prohibited
Jonathan: No binding for WCF maps
to optional anonymous on a WSDL operation. It's not supported
'out of box' for WCF
... Other option that M/S considering is policy duplex
binding
... this would be M/S propriatary and indicate that anonymous
is prohibited. This is not a standard Policy assertion
... however, this policy assertion illustrates how the
UsingAddressing marker is not easily mapped to Policy
glen: if we don't put in anonymous then default to optional
jonathan: want to be able to say
that anonymous is not constrained: I.e. No statement defaults
to 'unspecified'
... currently not specified means 'optional' i.e. anon and
anonymous are supported
... anonymous is tied tightly to usingAddressing.
... What is being standardised doesn't map to what we are going
to ship. First choice would be not have anonymous until we have
Policy
Hugo: Concern is that such a big change will take us back to LC
Will defaulting to unspecified fix
jonathan: Yes - would allow us to have something stable to ship on quickly. Although would be another LC we would be able to participate fully
dhull: agrees with add
unspecified but not default as best option
... removing default more intuitive but bigger change
... if we can get away with it then remove the defaulting
otherwise just add unspecified
glen: Understand M/s close to a ship date. Are you going to have client support for duplex binding if Anon=Required
jonathan: not sure will need to check
glen: Stack that I work on do
optional and prefer that as default
... Like the optional default. Spec should reflect
architectural concerns not implementation concerns
jonathan: acknowledges different implementation approach for M/S but this stops involvement in CR
Anish: How would 'unspecified' helpin the WCF implementation
Jonathan: looking at policy as prefered vehicle for these kind of assertions. this fits better. 'unspecified' is simply a marker that does not require complete support for anonymous/non-anonymous
Anish: Unfortunately Policy is
not there yet so would like to point out that we shouldn't hold
up spec between this
... Katy expressed that should have default value to clarify
support
(I still think this ;o) ideally )
jonathan: this is a compromise in order for us to reach CR
Paco: agree with jonathan about
QName
... agree with concern about interoperability problems if there
is no default
... can we agree on what clients should do when see
anonymous='unspecified' for interoperabaility concerns
jonathan: If use unsupported
address then might get a fault back if WSDL specifies
'unspecified'
... runtime negotiation. There is nothing that the client can
assume about the handling of anonymous except that some
addresses may be rejected
paco: Should consider what out most common case is for the default: perhaps the more common case is Anonymous only
jonathan: problem is composibility with other specs wrt assuming anon required is default
paco: understood.
... another question WRT from mail option 2:Remove
specification of anonymous altogether. Make no conformance
statement that UsingAddressing necessarily implies full
support.
... How is testing of this going to work
jonathan: Not sure of this. Extensions that we will be able to test are WSDL 1.1 only
bob: what are acceptable
proposals
... Proposal 1: Anonymous removed from the spec
A few negative comments
Glen: Can you get an 'I can't deal with anonymous address' fault when faultTo set to anonymous?
Anish: If there is a mustUnderstand fault and addressing has not been processed will get somehting back on backchannel anyhow
Bob: Porposal 2:Remove specification of anonymous altogether. Make no conformance statement that UsingAddressing necessarily implies full support
jonathan: Advantage of this is UsingAddressing does not imply anonymous function
Paco: this would be more appealing if we could understand the behaviour of the client for this
jonathan: perhaps another default will work if can cope with spec composition issues
Anish: I would prefer proposal 4
Proposal 4: Remove the default. Lack of wsaw:Anonymous means there are no claims about Anonymous support.
Anish: Do we need to go back to last call again with this?
Hugo only if we remove the anonymous completely
Replace Anonymous with 2 or more likely 3 separate (from a conformance sense) assertions. The default value when just using the UsingAddressing assertion would make no design-time claims as to the handling of anonymous. We would likely support an AnonymousRequired assertion in this release, less likely an AnonymousProhibited assertion (we support this but not as an orthogonal option at this point), but unlikely an AnonymousOptional assertion at this point.
2. Remove specification of anonymous altogether. Make no conformance statement that UsingAddressing necessarily implies full support.
3. Introduce a new value to Anonymous of “unspecified” as the default. Make sure one can use UsingAddressing without fully supporting all values of wsaw:Anonymous.
4. (From Anish). Remove the default. Lack of wsaw:Anonymous means there are no claims about Anonymous support.
bob: are people leaning towards option 4?
<scribe> ACTION: Paco to extend option 4 to draft interoperablility assumptions clients can make when no value for the anonymous option is provided [recorded in http://www.w3.org/2006/04/10-ws-addr-minutes.html#action02]
<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Apr/0019.html
Anish: What happens if there are 2 policy assertions that are conflicting
Paco: Validation creates an
contradictory assertion that is thrown away
... nothing stopping 2 assertions e.g. usinganonymous and
anonymous assertion so long as you define some conflict
resolution for the different assertions
Nilo: concern about this in the same domain
Paco: best practice would be no
overlap
... UsingAddressing have no default wrt Anonymous => helps
this problem
... UsingAddressing has no overlap wrt Anonymous => helps
this problem
Jonathan: In section 4.1
The use of MUST in conjunction with "additional runtime information"
makes this phrase a bit confusing. The MUST implies that this condition
is testable, but the rest of the text shatters that implication.
Perhaps this could be reworded to remove the MUST, for example "the
value of [destination] ... typically matches the value of the {address}
property."
jonathan: 2 qualifications on the must - what has preference here?
bob: any objections to accepting
lots of poor jokes
bob: no objections
RESOLUTION: Close LC130 by accepting the proposal
<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Apr/0010.html
Jonathan: explains issue
... What does UsingAddressing mean that you need to support in
order to be conformant
Anish: Please clarify: What do
you mean by orthogal features that you don't need to
support?
... Conforming to binding spec requires understanding and
recognising feature
... ?
<bob> concern between conflicting wsdl and wdsl contained in an epr
Anish: E.g. if you have 'action' and 'UsingAddressing' then you would understand what a consumer's responsibility is
jonathan: Action and USingAddressing naturally go well together so a conformance statement relating the 2 is relevant
Anish: Why not same conformance statement about reference parameters
Jonathan: I would agree to
ReferenceParamaters, ACtion, Destination conformance statement
with UsingAddressing
... if anonymous was a separate policy assertion need not be
tied to UsingAddressing, at the moment when not a Policy
assertion, not so sure
ANish: What about Section 5?
Jonathan: If conforming to cor eiwll conform to section 5 by default
Anish: Would like some more
concrete text stating what UsingAddressing implies wrt section
5
... need to check the text again
Agreement that this is a boring issue
<scribe> ACTION: Jonathan agrees to look at some real text for this issue [recorded in http://www.w3.org/2006/04/10-ws-addr-minutes.html#action03]
<scribe> Chair: LIke to talk about where we are and schedule
bob: Assuming a
couple more issues over next 24 hours should be able to deal
with next call
... assuming we don't need to go back to LC - hope for
resolution to LC issues next monday
... Aim for final text for 24th April
... to CR no later than F2F
<bob> http://www.w3.org/2002/09/wbs/36696/May3MFA/
bob: so we can focus on test criteria in F2F
<scribe> ... New ballot for 3rd May at Boston museum fine arts plus dinner following
bob: please answer
poll no later than next monday for booking purposes
... Next week's call also scheduled for 2 hours
Discussion on WDSL 2.0 testing
<scribe> Chair: For us to declare victory we need WSDL 2 implementations
Hugo: That's correct
<scribe> Chair: Need to evaluate options in this area
Jonathan: Need to also understand what test suite looks like for this material
<anish> jonathan, doesn't having wsdl in the mix makes interop testing easier?
Jonathan: especially as WSDL interop ability is not there yet