W3C

Web Services Addressing Working Group Teleconference

28 Nov 2005

Agenda

See also: IRC log

Attendees

Present
Andreas Bjärlestam (ERICSSON)
Dave Chappell (Sonic Software)
Francisco Curbera (IBM Corporation)
Vikas Deolaliker (Sonoa Systems, Inc.)
Paul Downey (BT)
Robert Freund (Hitachi, Ltd.)
Marc Hadley (Sun Microsystems, Inc.)
David Hull (TIBCO Software, Inc.)
Yin-Leng Husband (HP)
David Illsley (IBM Corporation)
Anish Karmarkar (Oracle Corporation)
Paul Knight (Nortel Networks)
Mark Little (Arjuna Technologies Ltd.)
Jonathan Marsh (Microsoft Corporation)
Nilo Mitra (ERICSSON)
David Orchard (BEA Systems, Inc.)
Gilbert Pilz (BEA Systems, Inc.)
Tony Rogers (Computer Associates)
Tom Rutt (Fujitsu Limited)
Mike Vernal (Microsoft Corporation)
Steve Vinoski (IONA Technologies, Inc.)
Katy Warr (IBM Corporation)
Steve Winkler (SAP AG)
Ümit Yalçınalp (SAP AG)
Prasad Yendluri (webMethods, Inc.)
Absent
Abbie Barbir (Nortel Networks)
Rebecca Bergersen (IONA Technologies, Inc.)
Jacques Durand (Fujitsu Limited)
Michael Eder (Nokia)
Marc Goodner (Microsoft Corporation)
Arun Gupta (Sun Microsystems, Inc.)
Amelia Lewis (TIBCO Software, Inc.)
Philippe Le Hégaret (W3C)
Jeff Mischkinsky (Oracle Corporation)
Eisaku Nishiyama (Hitachi, Ltd.)
Ales Novy (Systinet Inc.)
Mark Peel (Novell, Inc.)
Rich Salz (DataPower Technology, Inc.)
Jiri Tejkl (Systinet Inc.)
Pete Wenzel (Sun Microsystems, Inc.)
Regrets
Glen Daniels (Sonic Software)
Hugo Haas (W3C)
Chair
Mark Nottingham
Scribe
Paul Knight

Contents


<scribe> scribe: PaulKnight

any corrections to minutes?

face-to-face minutes accepted

wait until next week to approve last week's meeting minutes

Action Item Review

CR10

suggestion to defer cr10 due to W3C representatives not being present

discussion of "on the web" definition -

Mark N: need to defer this discussion until W3C reps are here

Mark N: let's be prepared to make a decision next week, continue on email discussion

i059

Umit: describing her proposal 1

Proposal 1: <http://lists.w3.org/Archives/Public/public-ws-addressing/2005Oct/att-0116/ProposalTake3.htm>

Proposal 2: <http://www.w3.org/mid/D1503191-88CA-4537-A20A-1F891F43606D@Sun.COM>

uyalcina: wsaw:Async element may have three distinct values, “fullâ€, “never†and “alwaysâ€. Discussing behavior of end point with each value.

anish: question - anonymousUse Element at binding level?

Umit: no, at child level

anish: must set non-anonymous EPR? (if using addressing)

uyalcina: yes, does this need to be changed?

anish: WSDLRequired set to true in this case?

<Zakim> dorchard, you wanted to ask about problems of attribute extension

dorchard: attribute extension instead of element use?

uyalcina, others : use element notation so BP1.1 is not required

discussion of requiring BP1.1 rather than WSDL 1.1

what current products would have issues?

dorchard: allow extensibility point

thanks...

<Zakim> marc, you wanted to ask about HTTP 202 stuff in WSDL binding doc

marc: section 3.1.2 - somewhat repititious

uyalcina: it was written from perspective of anonymous usage

marc: is it in right place? it does not really have to do with WSDL, but with SOAP. Maybe move it to SOAP or adendum to SOAP binding?

uyalcina: depends on how we want to position it, that might be okay

<Zakim> dhull, you wanted to propose separating markup issues from semantics

<dorchard> Marc, I agree with the gist of where you are going with this..

dhull: separate semantics, based on my alternate proposal
... in context of SOAP... but don't want to address this in middle of conversation on markup
... talk first about angle brackets, then address the proposal (SOAP over HTTP) separately
... deal with section 3.1.3 separately, (still in WSDL doc)
... two separate subissues of i59

markN: what do people think?

uyalcina: this is a big change, not clear what dhull is proposing

dhull: 3.1.3 mentioned earlier is probably now 3.1.2

uyalcina: maybe it will be editorial, not adding a section

dhull: maybe no conflict, reviewing document
... what do people think?

dorchard: seems like two separable things

dhull: proposed asynch text is to give rules to say exactly what goes on wire

markN: we discussed this at F2F, seemed to have an agreement to go forward using the combined proposal. concerned about competing proposals on the table now.

<uyalcina> the chair reflects my understanding as well.

markN: suggest dhull expresses his text as a delta against the agreed text

dhull: I am trying to do this
... want to be able to handle both cases if it can be done easily, hoping to get opinions on the technical feasibility
... there may be no conflict, just trying to get opinions, and hope to hear where my proposal might fit in

markN: let's proceed with other decisions and syntax, get that finished, then come back to this.

dhull: okay, I do want to see this discussed at some point, not want to disrupt momentum

uyalcina: not want to rehash earlier decisions

<Zakim> Jonathan_Marsh, you wanted to ask whether specification of default values is really necessary.

Jonathan: getting complicated; can we remove the defaulting attribute?

uyalcina: considered it, it makes sense, would simplify proposal

Jonathan: would it be inconvenient not to have the default

Jonathan scremed and disappeared

Jonathan: in anonymousUseDefault, can we say that you specify one of three values, otherwise it will be allow. (?)
... can we get rid of ... ( can someone post the proposal?)

anish: we discussed some sort of marker for this

Jonathan: are there simplifications we can make?

gpilz: if you get rid of this, it makes the spec more clear

mnot: is this needed or syntactic sugar?

can we get rid of it or do we need multiple properties that need to be reconciled at run time?

Jonathan: unless restricting anonymous is the main case, we should consider this

gpilz: these issues can be skirted if there is no defaulting mechanism

mnot: jonathan wants to get rid of the attribute, umit can go either way...

anish: the default should not cause restriction on the values of the attribute vs. the element

mnot: should we keep the attribute byDefault?

anish: it should be a syntactic roll-up

mnot: can we remove the attribute for now?

Marc: is there still a default for ReplyTo?

mnot: any problem with dropping defaultUse attribute?

uyalcina: it appears several places

<marc> UsingAddr means either anon or non-anon if other element not present

<marc> right ?

mnot: we are asking Umit to remove this item, then look at this to see if it causes other issues

uyalcina: allowed, always, never - should we keep these values, or modify?

anish: I have a use case where defaulting is useful
... response going back on HTTP response channel... (describes use case)

<Zakim> marc, you wanted to ask if there is a default if we drop the attribute

mnot: still syntactic sugar?

anish: yes

mnot: still at a point where we can ask Umit to remove this for now

no objections to action item for Umit for this.

<mnot> ACTION: Umit to revise i059 sub-proposal 1 to remove defaulting attribute [recorded in http://www.w3.org/2005/11/28-ws-addr-minutes.html#action01]

uyalcina: syntax of element?

???: required, prohibited, optional

<marsh> +1

<marc> +1 to johnathan, i proposed exactly that at the end of the F2F

support for using Jonathan's suggested values

does not work well with operation level granularity

uyalcina: yuckyness

Katy: can we keep ....

Jonathan: support 3 elements, no operation level support

mnot: this sounds like we are reconsidering the F2F agreement

Katy: at F2F, we said we needed a separate proposal?

<mnot> ACTION: keep syntax option 3 up-to-date as alternate proposal [recorded in http://www.w3.org/2005/11/28-ws-addr-minutes.html#action02]

anish: reconsider decison from F2F on operation level granularity?

mnot: decisions were to help us move forward, but we can consider all proposals as they come forward, one by one
... focus for now on Umit's proposal

anish: decisions independent of proposal - are we reconsidering them?

uyalcina: these are not just my proposals, I'm incorporating the decisions made at the F2F

TomRutt: having this available does not mean everyone has to use it

but this may bear on how conformance to the standard is measured

mnot: moving forward, we'll take Umit's proposal as the baseline going forward, with additional proposal by Jonathan to be considered later

dhull: is the one-element solution compatible with re-using the same elements in policy assertions?

mnot: what else do we need to do to address i59?

<mnot> ACTION 2=Jonathan to keep syntax option 3 (three elements) up-to-date as an alternate proposal

mnot: how do people feel about WSDL dependency? to include MEPs

dhull: MEPs beginning with in are easy to define, but those with out are harder, no clue..

dhull: i have already done the action, see the proposal
... flowing into Umit's text is the main issue

<dhull> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0051.html

mnot: please look at how to flow it into Umit's text

dhull: okay, this is fairly well covered now

xmlp recharter is expected after AC meeting

mnot: reformulation of option 1 by Umit due Friday
... look at David Hull's proposal
... hopeful we can close i59 by end of year
... only a few more meetings this year
... any other thoughts on i59? none

agenda item 7, testing

PaulD: will have regular meetings for remainder of year

mnot: any other business?

<pauld> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0081.html

vikas: recent email on async cases? does it fall under i59? How source routing works?

mnot: anyone want to respond? It's not part of i59, which is async in general; this is not in scope for us.

Meeting adjourned

Summary of Action Items

[NEW] ACTION: keep syntax option 3 up-to-date as alternate proposal [recorded in http://www.w3.org/2005/11/28-ws-addr-minutes.html#action02]
[NEW] ACTION: Umit to revise i059 sub-proposal 1 to remove defaulting attribute [recorded in http://www.w3.org/2005/11/28-ws-addr-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2005/12/15 00:56:10 $