Web Services Addressing Teleconference

11 Jul 2005


See also: IRC log


Abbie Barbir (Nortel Networks)
Andreas Bjärlestam (ERICSSON)
Glen Daniels (Sonic Software)
Vikas Deolaliker (Sonoa Systems, Inc.)
Paul Downey (BT)
Robert Freund (Hitachi, Ltd.)
Martin Gudgin (Microsoft Corporation)
Arun Gupta (Sun Microsystems, Inc.)
Hugo Haas (W3C)
Marc Hadley (Sun Microsystems, Inc.)
David Hull (TIBCO Software, Inc.)
Yin-Leng Husband (HP)
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.)
Mark Peel (Novell, Inc.)
Tony Rogers (Computer Associates)
Tom Rutt (Fujitsu Limited)
Steve Vinoski (IONA Technologies, Inc.)
Katy Warr (IBM Corporation)
Pete Wenzel (SeeBeyond Technology Corporation)
Steve Winkler (SAP AG)
Ümit Yalçınalp (SAP AG)
Prasad Yendluri (webMethods, Inc.)
Ugo Corda (SeeBeyond Technology Corporation)
Dave Chappell (Sonic Software)
Francisco Curbera (IBM Corporation)
Jacques Durand (Fujitsu Limited)
Yaron Goland (BEA Systems, Inc.)
Amelia Lewis (TIBCO Software, Inc.)
Philippe Le Hégaret (W3C)
Jeff Mischkinsky (Oracle Corporation)
Eisaku Nishiyama (Hitachi, Ltd.)
Ales Novy (Systinet Inc.)
Rich Salz (DataPower Technology, Inc.)
Davanum Srinivas (Computer Associates)
Jiri Tejkl (Systinet Inc.)
Rebecca Bergersen (IONA Technologies, Inc.)
Michael Eder (Nokia)
Mark Nottingham
David Hull


Corrections to 2005-06-27 minutes?

Minutes approved (no objection)

AIs: Anish, Umit done. DHull LC76: Needs to be more concrete. Due 15 July.

AI: LC107 (Marsh). Draft, not mailed yet. Editorial issue will be resolved. Marked as done.
... LC68 (marsh) Done.

Marc: Only issue not incorporated is 107. All other issues should be in editor's draft. Please let Marc know if that's not the case.

LC 104

Anish has made proposal, discussion is active.

Anish: Made draft of spec with abstract model of EPR.
... several +1s. Marsh would prefer to close no action but OK with it. There has bee nmore email in last 5 minutes.

MNot: Two related issues. Getting rid of abstract model for EPRs, and for MAPs.

Marsh: Only object to MAP part.

Anish: Issue is only about EPR, but did MAP too to see what it would look like.

Marsh: Collapsing EPR model makes sense. Collapses two concepts, not just sections of document. Infoset is not conveying that much extra information. Just isn't that much independent of the infoset.
... Anish has shown that collapsing will work. Bummer is that it's no longer consistent with MAP description.
... Not against getting rid of EPR section.

Mnot: Prasad, would you be OK with separating out EPR part, dropping abstract model in EPRs.

Prasad: No problem with that.
... Some editorial inconsistencies to be taken care of. No objection to collapsing.

Anish: Where?

Prasad: Section 2.1

Mnot: So some editorial work.

Prasad: [address] in metadata, for example.

(missed much of the detail there)

Umit: Comment on MAP change. What does separate abstract model enable? In WSDL, we talk about includes, imports etc. No comparable concept with EPRs. In favor of collapsing. We should look at MAPs the same way: What benefit to additional layer that infoset does not cover. Can separate issues this way. 101 and 104 appear to be only EPRs, not MAPs.

MNot: Anyone against EPR changes?

Hugo: Have some concerns about how it's written.

Katy: There are some advantages to abstract model, esp. for documenting. but not against collapsing.

Marc: Same camp as Prasad. Not violently opposed, but like consistency with MAPs. As far as MAPs, have we broadened the discussion? (Mnot: No) Would be against for MAPs. No editorial problems. Some strange items to sort out, e.g., we're talking abougt address and metadata, not XML elements.

<anish> yes, the editors have full license to change the title ;-)

Hugo: Same position as Marc. Uncomfortable with section 2.1 "EP representatation" Not representation, but definition. Can see this as editorial problem, or mixing representation with definition.
... Mildly uncomfortable with this. Like having abstract props.

Marsh: A couple other items: Don't have to solve 101 or 104 to declare victory. No implementation consequences. Stability of document is important. Can live with status quo.

Anish: Editors have full license with editorial changes. Do think 101 and 104 are important. We have created abstract model, claim extensibility, but don't say how. Don't say how to reverse map infoset to abstract, specifically for EPR. EPR infoset is extensible, but what about abstract model? Not clear what happens. Katy's example is the first I've heard where someone wants to...
... actually do something with abstract model (but think documenting infoset would be as easy). Don't see reason for having abstract model. Documentation alone is not enough, given 101 and 104.

<Marsh> I note that we've successfully using the (extensible) Infoset abstraction without over-architecting the extensibility model

Tom: I like the proposal. Not do or die. Simplifies by having only one level. Always know where to put text.

Gudge: Don't think one-way mapping is a problem. Common in specs, e.g. SOAP 1.2 datamodel. We've discussed "how does extensibility work?" It's up to other specs to say how it works. Fond of keeping abstract models; it's cleaner. Pure infoset does not make life better.

MNot: Does anyone feel very strongly about this?

Anish: Have to address extensibility issue.

MNot: That's 101, right?

Anish: 101 and 104 go hand in hand.

MNot: Of course, but on table now is collapsing. Would solve 101 but there are other ways. Do you feel strongly about this, Anish?

Anish: This is a good way to go. Need to resolve 101 and 104 somehow.

Gudge: What about doing nothing.

Anish: Not happy with that.

<mnot> Prasad's proposal: "The information model of an end point reference is extensible in that additional properties and attributes on the properties may be added. See the XML Infoset model section for a formal specification of the extensibility points at the XML Infoset level."

Umit: Prasad sent message today about extensibility. Would need to add something to abstract model per what prasad said, saying that abstract extensibility follows infoset ext.
... Would this meet Anish's requirement? As AI owner, I was going to propose something much like this, so think Anish's proposal is viable for EPRs.

Glen: Prasad's was about what I was going to say. Tells extension writers to update abstract model as well. (except for Must Understand :-)

<uyalcina> Let me add though I like collapsing 2.1 and 2.2 better.

Anish: Whole issue is what happens to abstract model? We're handwaving as it is. Can use attribute, any, whatever, with no guidance.

Glen: How else can you do it?

Anish: What is value of abstract model?

MNot: Old argument.
... What do people think of Prasad's proposal?

Umit: Chad?

MNot: More complex than that. This discussion is to see if group wants to revisit issue. But there is still a lot of doubt.

Umit: We were talking about extensibility of MAPs, not EPRs. MAP extensibility was the big item, not EPR. This is a bit different.
... 101 and 104 is talking about EPR, not MAP. Anish happened to do extra work for MAPs. Doing one and not the other would be inconsistent, but collapsing EPR doesn't reopen MAP issue.

MNot: Not talking about MAPs, but about vote on collapsing out abstract model. If group doesn't have a problem, not a problem. But if there are doubts, we need a higher standard.

Anish: Not trying to raise abstract model issue again. But if we do have one, we need to address extensibility if we want interoperability. Handwaving now. If there is value in abstract model, there is more work to be done.

Mnot: for group to decide.
... Proposals on table (EPRs): Collapse abstract model, or Prasad's proposal to map infoset extensions to abstract model.

Anish: As the proposal stands, properties in abstract model are extensible, see infoset for infoset extensibility, but doesn't address extension to abstract model.

Glen: THink it needs tweaking as well. Not hard.

Umit: If collapse, don't need to do anything.

<mnot> scribe: mnot

<pauld> option 1: colapse abstract model and EPRs

<pauld> option 2: tweak text make extensibility per extension

<pauld> option 3: status quo

<pauld> question: way forward for LC104

<pauld> chad, question: way forward for LC104

<GlenD> vote: 2, 3, 1

<pauld> chad, option 1: colapse abstract model and EPRs

<pauld> chad, option 2: tweak text make extensibility per extension

<pauld> chad, option 3: status quo

<GlenD> vote: 2, 3, 1

<anish> vote: 2

<anish> vote: 1

<Nilo> vote: 1

vote 2,1

<dorchard> vote: 1

<TonyR> vote 3, 2, 1

vote: 2,1

<marc> vote: 2,3

<Katy> vote 2, 3

<andreas> vote: 1

<PaulKnight> vote:3

<hugo> vote: 2, 3, 1

<prasad> vote: 2, 3, 1

<mlpeel> vote: 3, 1, 2

<TomRutt> vote:1,2

<Katy> vote: 2, 3

<abbie> vote: 3

<scribe> scribe: dhull

<TonyR> vote: 3, 2, 1

<bob> vote: 3,2,1

<vinoski> vote: 2, 3

<anish> vote: gudge: 3, 2

<uyalcina> vote: 2, 3, 1

<pauld> vote: 3, 2

<Arun> vote: 2, 3

<steve_winkler> vote: 2, 1, 3

<pauld> chad, count

<chad> Question: way forward for LC104

<chad> Option 1: colapse abstract model and EPRs (5)

<chad> Option 2: tweak text make extensibility per extension (10)

<chad> Option 3: status quo (7)

<chad> 22 voters: abbie (3) , andreas (1) , anish (1) , Arun (2, 3) , bob (3, 2, 1) , dhull (2, 1) , dorchard (1) , GlenD (2, 3, 1) , gudge (3, 2) , hugo (2, 3, 1) , Katy (2, 3) , marc (2, 3) , mlpeel (3, 1, 2) , Nilo (1) , pauld (3, 2) , PaulKnight (3) , prasad (2, 3, 1) , steve_winkler (2, 1, 3) , TomRutt (1, 2) , TonyR (3, 2, 1) , uyalcina (2, 3, 1) , vinoski (2, 3)

<chad> Round 1: Count of first place rankings.

<chad> Round 2: Eliminating candidate 1.

<chad> Round 3: Eliminating candidate 3.

<vikas> vote: 3

<chad> Candidate 2 is elected.

<chad> Winner is option 2 - tweak text make extensibility per extension

<pauld> chad, count

<chad> Question: way forward for LC104

<chad> Option 1: colapse abstract model and EPRs (5)

<chad> Option 2: tweak text make extensibility per extension (10)

<chad> Option 3: status quo (8)

<chad> 23 voters: abbie (3) , andreas (1) , anish (1) , Arun (2, 3) , bob (3, 2, 1) , dhull (2, 1) , dorchard (1) , GlenD (2, 3, 1) , gudge (3, 2) , hugo (2, 3, 1) , Katy (2, 3) , marc (2, 3) , mlpeel (3, 1, 2) , Nilo (1) , pauld (3, 2) , PaulKnight (3) , prasad (2, 3, 1) , steve_winkler (2, 1, 3) , TomRutt (1, 2) , TonyR (3, 2, 1) , uyalcina (2, 3, 1) , vikas (3) , vinoski (2, 3)

<chad> Round 1: Count of first place rankings.

<chad> Round 2: Eliminating candidate 1.

<chad> Round 3: Eliminating candidate 3.

<chad> Candidate 2 is elected.

<chad> Winner is option 2 - tweak text make extensibility per extension

<TonyR> chad, details

MNot: will this cover both 101, 104?

Omnes: various

<mnot> ACTION: Glen to review proposal for LC 101; due EOW [recorded in http://www.w3.org/2005/07/11-ws-addr-minutes.html#action01]

<scribe> ACTION: Dhull to provide concrete faults writeup. [recorded in http://www.w3.org/2005/07/11-ws-addr-minutes.html#action02]

Anish: Haven't discussed MAPs (but don't expect support for that).

MNot: Does anyone want to speak for the MAP aspect?


MNot: LC 101. Can we discuss this now, or wait for Glen's proposal?

Glen: Just need to tweak text. Corresponding parts in abstract and infoset descriptions.

Umit: +1

Mnot: Deferring discussion of 101, 104


Mnot: semantics of anon URI. Dhull made proposal for "return to sender" semantics. Not much discussion yet.
... Where do we sit?

<mnot> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jun/0117

glen: In wsdl, we had a discussion of the breadth of reply; we came up with text. Should we refer to that?

dhull: there's only a paragraph here, let's go over it

tomr: name change may be a problem, but otherwise like it

glen: seems more restrictive than WSDL

glen: restricts it to the underlying transport facilities.

glen: that's OK; wouldn't refer back to wsdl.

dhull: I think the touchstone is that if the receiver gets anon, would it know what to do? In HTTP, it has a nice, well-defined place to throw the message.

glen: I can imagine a system that replies to a fixed queue, and therefore I don't need something on the wire; in that case you'd use another URI. I like this.

dhull: Right; we'd define other pseudo-URIs.

glen: I like the crisper URIs.

Tony: as far as the name goes, I don't like anon; I prefer sender.

<TomRutt> I can live with the name change to "sender"

<marc> sender could be taken to imply that one should send the reply to the [source] endpoint

<TonyR> and shouldn't that be the same?

Marsh: I have concerns that some semantics are lost; before, it was 'use the underlying layer', now there are some cases taht can't be covered.

<marc> so the Source EPR should have a 'sender' address - seems a little recursive

<TonyR> good point

<TomRutt> Sender is not the correct word. We need to connote use of an underlying back chanel

dhull: there are two different levels; there's the transport level, and the higher MEP level where I would like anon to mean 'send it right back to me.'

dhull: there might be multiple ways to realise that at the transport level.

dhull: there are differnet meanings, depending on how you look at it.

dhull: either way is valid; but I'm uncomfortable leaving it open.

<GlenD> +1 to David

dorch: I agree that it's not quite right, but I can't think of anything better.

dorch: I think sender is worse than anon.

dorch: unless somebody can come up with something better; I don't see us doing it anytime soon.

dhull: I think sender is the right way to say send it back to the sender; we probably want to say both.

dorch: I could come up with a protocol that has a back channel that goes somewhere other than the sender.

dhull: in that case, you'd use anon

dorch: feels like angels on a pin

dhull: no, there are two different meanings being thrown around

dorch: do we have two words now?

dhull: no

<mnot> ACTION: David Hull to revise proposal lc20 [recorded in http://www.w3.org/2005/07/11-ws-addr-minutes.html#action03]

<scribe> scribe: dhull


<TomRutt> If we have two different uri values, we have to decide which is the "default" for reply to, and "to"

Mnot: Jacek's issue: Mandatory reply-to. Reopened I50. Katy has put forth two proposals.

<TonyR> the binding might specify which is default

Katy: Wrote up proposal for "no reply" URI. Did two proposals because there were two interpretations of proposal.
... Wanted to see it all written down. Suspect that everyone would be happy with one or the other. Does make things more complex. There is a general issue of whether introducing another URI is a good way to go, then discuss particular proposals. Does fix problem, but at expense of complexity. Is there a better way? The two proposals are very similar. No point in discussing them...
... without disucssing larger issue.
... Do support the proposals. No specific preference. But is there an easier way?
... Maybe attributes? Specifically, would address Paco's concern.

Glen: Does solve problem. More common use case (and solution) is going to be that "no reply expected" will generally be captured elsewhere. Adding new URI addresses concern, not complicated, but probably won't be used.

MNot: Will this be required if no reply expected?

Glen: I hope not.

MNot: Is "no reply EPR" required if no reply expected?

Katy: Should be fine, I think.

Marc: Default is anonymous.

Glen: decided at higher level.

Marc: Question: is meaning "not-valid URI"? Or more like "dev null" (can't send to it, vs.can send to bit-bucket). More comfortable with /dev/null.

Katy: Missed that. Slightly different semantics.

MNot: Very good question. Popping up, is everyone comfortable with general direction.

Gudge: not required to use it if you don't expect a reply?

Mnot: yes.

Gudge: Why is it useful.

Mnot, Glen: Gets us to CR.

Umit: Gudge has point? What is usage pattern. Recommended?

Tom: Avaialbe for use.

Mnot: Loss of information if default is anonymous.

Glen: Interestingly, doesn't let you default to From:. If you want that, put it in explicitly.

MNot: Jacek and WSDL say that anonymous is common case. Paco doesn't want to lose information with defaulting.

Glen: Could get default to From: anyway.

Mnot: Two subquestions. Which proposal is better, fault vs. /dev/null.

Katy (summarizing): First introduces new URI for "no reply" for [reply endpoint]. Second says more general URI OK for [reply ..] [fault ..][source ..] whatever.

<marc> my preference is for general purpose URI (reply and fault) that means > /dev/null

MNot: Reply only or more generic.

Tony: Not a small difference. No fault URI is weird.

<TomRutt> I like general uri

Marc: Thus general URI for reply, fault or both.

Tony: What does it do?

Gudge: How can you send with no address.

Marc: By default.

MNot: Allows you to say "drop faults on floor".

Tony: Maybe we need two new URIs (one for fault, one for bit-bucket)

MNot: That's second subissue.

Tom: Faults coming from sender? 3-way handshake?

MNot: Don't think so.

Marc: What is use case for "faulting" URI.

Tony: If you're inside Axis or whatever, if it attempts to send to reply to that's sent to faulting URI, service implementation will get fault/exception. /Dev/null will be silently used.

MNot: Let's go back to first subissue (good point, though).
... Where do we sit on making it generic, or just specific to replies.

<TomRutt> usefull to be generic

Marc: Generic


MNot: Specific, anyone?
... Looks like generic "not-valid" URI. Subissue 2: Bit-bucket or faulting behavior?
... Tony, cases for both versions?

Tony: Prefer having a selection of standard URIs rather than one-size-fits-all.

Marc: What happens if you put faulting URI in fault to?

Tony: Back-channel.

Mnot: There might be cases that don't work.

Katy: Some cases have unconstrained behaviour.

Marc: Effectively the same as /dev/null.

Mnot: Might be useful in reply

TonyR: It's the case of idiot web service, framework is smart and does appropriate thing (e.g., guns web service)

MNot: So proposal is two variant URIs.

Marc: second would say "I don't want replies", first (?) would say "I want fault if someone tries to reply"

Tom: Don' tunderstand that faulting behavior.

Marc: Don't see point of it either. Shouldn't care if someone tried to send a reply, as long as I don't get it.

TonyR: Doesn't make sense with only two parties, but WSs will live in frameworks.

Tom: Don't we already have afaults for unsupported to: address?

MNot: Who thinks faulting version is a good idea. Everyone seems to like /dev/null version.

Tony: Just realised ... Now speaking against my own topic ... If we do have /dev/null, framework can still chastise web service.
... (or its author)

Mnot: Anyone else still interested in faulting version? No.
... Proposal is now "generic not-valid URI, /dev/null semantics".
... (currently faults)

Katy: Correct. Shall I write this up?

MNot: Trying to close the issue right now. Can write this up after the fact.
... Proposal understood.

Omnes: Silence.

<steve_winkler> Mark, Are you going to ask about dates for August F2F?

MNot: Would close I50, LC69, LC108. Jonathan, is this likely to be OK with WSDL group?

Marsh: THink so.

Marc: Captures text to be edited, but needs work. Think not valid is a bad name. Can I change?

Tony: Still like /dev/null.

Mnot: None is better. Give editor license!

<TomRutt> I like none better than null

Mnot: Any objections?
... None. Issue closed.
... Thanks Katy for detailed proposal. V. helpful.

TOPIC LC 55, 87

LC 55, 87

Marc: Two buckets of comments. Tweaks and nits, e.g., used property not in EPR, meant one in EPR. Significant discussion around whether section should be normative.
... Idea was to specify mechanism that SHOULD but not MUST be implemented. If in use, this is how you should garner trust. Pushback: Two sentences is not nearly enough. Shouldn't specify anything, just give example. A couple of +1s to that.

MNot: This is re-opening an issue. Had had shoo-in to re-open and close with this. Is that still the case or is there controversy. Can those who opposed normativity speak to this?

Anish: Clarification: Normative if you choose to use it, right?

MNot: Does it require testing?

Hugo: Marc summarized accurately. Basic security model is an improvement on status quo. May need minor tweaks. Spoke with security experts at W3C. They were worried that it was underspecified. E.g., talks about domain comparison, several ways to do this in X509. Need to hammer out deatils for interop. Two sentences is far from what we need for that. A lot of effort/expertise...
... required, maybe more than we have in this WG. If we recommend a mechanism, need to test that it works.
... Introducing significant new text, so back to working draft.

MNot: This discussion is re-opening an issue. Can we incorporate this proposal quickly and easily? Are we comfortable? Talk about it now or next week?

Marc: Clarification: Considering whole of text, or parts? Can we accept as-is and discuss taking normative bit out?

MNot: Don't think we can do that. Could get into nasty situation about normativity.
... Hugo -- is non-normative version OK?

Hugo: As example, won't impact CR, will improve model.

MNot: Others?

Omnes: nadie

Marc: Would prefer not to make normative section example.

MNot: Intention for F2F is to ask if people are for or against re-opening. We'll see what group decides. If we can't come to consensus, suppose we won't re-open. Will have discussion F2F.

LC 76

MNot: Proposal just needs to be more concrete. Get crackin'
... Plan going forward. Very few LC issues on SOAP and Core. Rest seem to have clear way forward. Will look at expanded faults, maybe adjust. LC 5 is utility of source. LC 69 Jacek responded with possible modification. A few more ends to tie up. Hope to close rest of LC issues on Monday.
... Then need to do other things to get into CR. Implementation and testing schedules, PR entrance criteria. Want to have docs ready for CR at or near end of F2F. Come ready to vote. Will be worried if we can't get out of LC by end of last meeting. If so, break for meetings in August.
... Then back into WSDL doc, depending on timing. May be able to leave F2F early instead. Start on WSDL in September. Still need host.
... Will provide dates soon. Probably last half of week of 5 Sept. Or maybe week preceding.

Marsh: WSDL wanted week of 12th.

MNot: Won't be able to do that, won't need to co-locate.

Summary of Action Items

[NEW] ACTION: David Hull to revise proposal lc20 [recorded in http://www.w3.org/2005/07/11-ws-addr-minutes.html#action03]
[NEW] ACTION: Dhull to provide concrete faults writeup. [recorded in http://www.w3.org/2005/07/11-ws-addr-minutes.html#action02]
[NEW] ACTION: Glen to review proposal for LC 101; due EOW [recorded in http://www.w3.org/2005/07/11-ws-addr-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.126 (CVS log)
$Date: 2005/07/21 18:30:04 $