Web Services Addressing Working Group

8 Nov 2004



Anish Karmarkar
Davanum Srinivas
David Orchard
Francisco Curbera
Glen Daniels
Harris Reynolds
Jacques Durand
Jonathan Marsh
Marc Goodner
Marc Hadley
Mark Little
Mark Peel
Martin Gudgin
Michael Eder
Paul Downey
Philippe Le Hégaret
Rich Salz
Steve Vinoski
Steve Winkler
Tom Rutt
Yin-Leng Husband
Ales Novy
Eisaku Nishiyama
Greg Truty
Jeff Mischinsky
Jiri Tejkl
Rebecca Bergersen
Robert Freund
Hugo Haas
Mark Nottingham
Steve Vinoski


Mark described the agenda, wants to find owners for new issues, and then go into existing issues


Mark: hugo will post minutes to public list after each meeting, WG members should review and reply with any changes or additions, changes will be reviewed at next meeting before being made final

Anish: wonder about process, some groups post unapproved minutes to the WG list and final minutes to the public list

Mark: I asked hugo to watch for confidential information in the minutes and scrub that from the minutes before publication

Philippe: I support Mark’s approach. Mark says this approach is fastest and easiest

Jonathan: mentioned that this approach also makes the info from meetings available in a more timely fashion

<GlenD> +1

Review of action items

Mark: corrections to action item list?

Anish: just sent a description to mailing list

Marc: I started issue 006

Mark: many action items are open, must work through issues and not let mailing list discussions inhibit work i want to assign due dates to some action items

Marc: owners should repost a summary of discussions of their issues every few days

<anish> +1 to marc’s suggestion

Marc: it would be easier to stay on top of the issues, instead of wading through email

Mark: add field to issues list to capture summaries, or just post it to the list

Mark: issue 3?

Gudge: ready on thursday

Mark: issue 3 seems editorial issue 3 by Thursday Nov 11 issue 8, that’s glen can we give you a due date for issue 8?

Glen: thursday nov 11 is fine

Mark: issue 16, once again glen

<Paul> on the WSDL WG, the issues list stylesheet generated a search for the text "issue 999" in the mailing list and via google, e.g. http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/issues/wsd-issues.html#x106

Glen: thursday for issue 16 too

Mark: issue 17, anish?

Anish: Thursday for issue 17

Mark: issue 23, rebecca. to rebecca was originally a different issue

steve: i can talk to rebecca about moving it forward

Mark: proposals need to be refined for this issue

steve: thursday for this issue, will talk to becky

Anish: this issue is related to the issue i’m working on

Mark: i can see how there could be a relationship there

Anish: will wait for steve/becky email and will reply to tie it into my issue

<Anish> the related email that i was talking about has already been sent ― AI: why Service QName is required if client has WSDL + engaged in conversation?

Mark: i have an issue regarding referencing ws-policy. would like to close this issue. Paco had an action about taking policy out and then layering it back in. close this issue, will reopen it if we can later remember why we kept it opened

RESOLUTION: issue 002 “WS-Policy dependence” is closed.

<Paul> notes current draft of our spec does reference ws-policy

December f2f

Mark: remember to register for the F2F Dec. 7-9, will start working on agenda soon. if you intend to participate in F2F remotely, send me or the admin list an email

Jonathan: traditionally hard to get Internet access and IRC from Microsoft meetings

Mark: will look into better access for remote participants

Working Drafts

Gudge: progress is being made, fill in TBD sections by end of this week

Mark: if people could look at working drafts over the weekend, we could vote to publish as public working drafts by next Monday need a summary regarding patent policy

Philippe:See Implication of the publication of the first public Working Draft with regards to the Patent Policy. two milestones, first is first public working draft, second is last call draft. you have 150 days from the first public draft to work through patent issues. after last call draft, you have 60 days to address claims that are in that draft but were not in the first

<Paul> the 150 day rule is described here: 4.1. Exclusion With Continued Participation

New issues

Mark: first, issue 26

Vinoski: i will own the issue

Mark: focus the discussion, with concrete proposals. action to summarize discussion and make concrete proposals

vinoski: will have that ready by Friday Nov. 12

Paul: concerned about this issue, with respect to issue 009. seems to be some overlap

Mark: seems to be related, resolution could affect 026

ACTION: Steve to summarize discussion to date of issue 26 and make some concrete proposals. Due 2004-11-12

Mark: perhaps have multiple ReplyTos, or extend EPRs for issue 026

Paul: agreed they’re related, if i can get issue 009 resolved it could help with 026

Mark: mailing list is wrong, it names issue 26 as 28 instead. issue 27, should there be a wsdl pointer

Anish: volunteers to own issue 27

Mark: issue 28? partially touches on issue 006. perhaps, should we look at 006 first? we can discuss them in parallel, i think they’re related

Marc: i will own issue 28 will kick off discussion for 28 by Thursday

ACTION: marc to start discussion of issue 28. Due 2004-11-12

Mark: issue 29

Harris: i will own issue 29, will start the discussion by Thursday

ACTION: Harris to start discussion of issue 29. Due 2004-11-11

Mark: issue 30, requiring ReplyTo in responses

Rich: would like to withdraw or close this issue

Mark: if everyone agrees, we can drop issue 30

Marc: related to 6, we can close 30 and leave it on 6

Mark: we are closing 30

RESOLUTION: issue 030 “Requiring ReplyTo in Responses” is closed.

Mark: issue 31?

DavidO: i can take issue 31

Mark: wants to move this issue forward, probably not this week. dave can you get something out with Mark Little later this week?

DavidO: fair amount of discussion already

ACTION: DaveO to work with MarkL and make some proposals for issue 31. Due 2004-11-10.

Mark: move the discussion forward, come up with proposals for next week

Issue 023: Required properties in EPRs

Mark: Steve/Becky have action item to come up with proposals, can we give them ideas on how to resolve this issue we can say nothing in an EPR is required, we can say all three items are required. any other proposals? steve will come up with proposals, would like to see discussion on this issue 023

Issue 001: EPRs as Identifiers

Mark: Nice summary of issue from DavidO summarizes the summary and proposal two questions, first is, is this a good way forward for this WG resolution could be to publish another document to justify and explain the EPR

DavidO: wants to talk with WG, hard to gauge response. wants to ask WG whether they’ve read the summary and proposal, and wants to know whether the note has swayed anyone’s opinion one way or the other

[Marc, Michael, Anish, Glen, and others also have made only quick passes through it]

Glen: might need a middle ground in there

Mark: glen would you take an action item around that?

Glen: yes I will

DavidO: i raised possible technical solutions at the F2F, but WG didn’t seem to have thought through other possibilities so as to take solid positions

Mark: haven’t heard other proposals on this issue

DavidO: i agree, haven’t heard anything else about what technically needs to be done to the spec for this issue, would like to see middle ground proposal

Glen: instead of URI and that’s it, could be middle ground EPR proposal

DavidO: XML structure of EPR might be encoded into a URI

Glen: not quite what i’m saying. what i’m saying is that i’m not sure it’s appropriate to map all EPR info into a URI an EPR is URI + metadata, would like to explore issues around metadata

DavidO: spectrum of possibilities, one extreme is no ref properties, and URI contains ref prop info, all the way up to here’s how ref props get added into URIs

Gudge: not what glen is saying. there may be a world where URI is the only address of the thing, and other data is not designed to be part of the identifier

Glen: other data is things you need to know how to use the URI

Mark: would ref props still be part of the identifier in your proposal glen?

Marc: described possible simplifications around EPR

Mark: core of issue 001 is that ref properties are part of identifier

Marc: EPR is partially a container for policies

Glen: ref props are part of identifier, is that to account for systems that can’t use URIs alone?

DavidO: architectural properties of a URI-only system are the ones that you want, you might be able to use URIs easily, but properties of a URI-only system might not really work, has nothing to do with ease of minting URIs

Glen: might separate out conceptually passing around an XML address with URI and metadata from the idea of ref props going to that bucket

Gudge: ref props and params don’t belong in the second bucket the metadata bucket

Anish: ref props belong in the address bucket?

Gudge: yes

DavidO: same way a browser don’t use frag ids during uri comparisons

Anish: so ref props are kind of like frag IDs?

DavidO: right can choose whether info is a ref prop or a ref param based on whether info should be part of the identifier or not

Anish: questions comparison with frag IDs, ref params are no different as far as communicating with service

Mark: everyone needs to look at Dave’s summary and proposal

Philippe: have a different idea on how to approach the problem, would like to see examples of using URIs vs ref props vs. ref params, sort of a primer style

Mark: should be do a primer, or a WG note?

DavidO: i know what Philippe is talking about, i focused on justifying ref properties. would it be better to focus on URIs and simplicity?

Philippe: another aspect is reusability of EPR from other technologies

DavidO: exchange of EPRs in other systems, yes, that’s good feedback

[Paco just joined]

Mark: proposals can fall into 3 buckets, first is dave’s approach, second is to relate EPRs to URIs (mapping), 3rd is to get rid of ref props don’t hear much support for 3rd option

Glen: i will explore these issues, but can see 3rd option as a viable alternative

Paco: OTOH 1 and 2 are not incompatible

Mark: correct

Glen: it’s scary that you develop a URI construction language, tweaks me a bit URIs in general are supposed to be more opaque

DavidO: URIs are as opaque as the minter of the URI wants them to be don’t need to go into the issue of whether URIs are opaque or not

Mark: i agree 100%

<anish> we had a discussion about this at the f2f

Mark: if people are interested in option 2, we need to get that discussion going not hearing much interest

Issue 012: EPR Life Cycle

Mark: moving on to issue 012, EPR lifecycle bob isn’t here, we could discuss without him his email makes 3 points, one is no lifetime mechanism for EPRs, 2 is EPRs will live indefinitely, 3 is that 404 is returned for unrecognized EPRs

Jonathan: asked about the part about living indefinitely

Paco: "indefinitely" is a very strong statement number 3 is tied to HTTP

Mark: what does it mean for an EPR to be recognized by an endpoint

Anish: i wonder if he meant to say recognized as having expired

Mark: could come up with generic expiry fault

Anish: that’s what i thought he wanted to say

Paco: need to qualify what endpoint is

Michael Eder: relates to question about multi-port EPRs

Mark: issue 26 talks about that issue, and we’d need to include that as part of resolution for 26

Marc: defining addressing fault might not be appropriate at this level

Anish: endpoint unavailable is different from expired

<Paul> wonders how useful it is to know that an endpoint has expired as opposed to never existed

Marc: shouldn’t define faults for things we don’t specify

Paco: i will go for 2, EPR lifetime is not defined by this spec drop 3

[many +1s]

Paco: this specification will not specify time-to-live for an endpoint reference

Anish: possible friendly amendment, not only does this spec not specify TTL for EPRs, but there could be future or other specs that do specify it

Paco: ok with that, make it clear that TTL spec for EPRs is not prevented

RESOLUTION: the specification will not specify time-to-live for an endpoint reference, but there could be future or other specs that do specify it

Mark: let’s write up what we decided and send it to the list, if more discussion then fine, otherwise we can close next week

Paco: i will do that

ACTION: Paco to summarize discussion of issue 12 and send out refined proposal. Due 2004-11-10.

Issue 019: WSDL Version Neutrality

Mark: would like to do with issue 019 is switch issue to editorial

Marc: is there general agreement that we want to adopt WSDL 2.0 terminology

Mark: does anyone object to using WSDL 2 terminology

Mark: no objections

RESOLUTION: the specification will adopt WSDL 2.0 terminology when evoking WSDL concepts.

Mark: we’ll wait to see Hugo’s proposal, make some comments, and move forward next up, issue 008 or we could discuss issue 031, wsa:Action

Issue 008: RefProps/RefParams as individual SOAP headers

Glen:See RE: Issue 011. confusion as to why ref props are 1st class soap headers, new message will talk about clarity and safety, putting forth two examples, one with a security header that could result in problems due to layering breakage by dropping ref props into soap headers, client potentially doesn’t really know what it’s asking for by virtue of those being 1st class soap headers, more difficult for an engine to deal with problems there, instead of keeping them encapsulated we can’t specify that there won’t be bad EPRs, not a reason to introduce technologies that create layering problems

Gudge: doesn’t understand example, doesn’t make sense to have a security property there

Mark: need to have a more detailed example

Glen: simple case is i give you an EPR whose ref props don’t make sense as SOAP headers. Ref props are a bag of stuff that want to get echoed back

Paco: if anyone can specify WSDL 2 contract, they can screw it up

Glen: yes, but this is worse

Paco: assumption you’re making is that the client has to make up for the server not making up a reasonable contract

Mark: glen, you said a container would solve this? that’s one possible solution. is the core of the problem that you can’t distinguish between headers and ref prop headers?

Glen: wrapping ref props inside a container or 1st class header prevents other problems

Mark: we should also be open to other solutions

Glen: could think of an attribute that goes on each header, saying it’s a ref prop

Anish: +1 to glen’s security header concern. second, about paco’s comment about soap headers in WSDL, consumer of an EPR isn’t supposed to look inside an EPR, but soap header in wsdl that’s not the case. third, there’s a composability issue, seems like the mapping is designed to cause potential composability problems with other specs that also use headers

Philippe: how is it different from sending an EPR with no ref props, need to trust the client to send back the ref props, for security reasons may not want any properties. nothing prevents the client from looking at the ref props and not following the directive

Glen: i make that point in the mail, feels like a layering violation because you have to look at the ref props and decide what to send, and that list of what i want to send or not send continues to grow. seems to be better ways of doing things that are simpler without giving up qualities of ref props. what is it about the current way of doing things, still haven’t heard why engaging the SOAP processing model is such a good thing

Mark: can Anish take an action item to write up composability problem?

Anish: yes, i can take that.

ACTION: Anish to explain the composibility problem WRT Reference Properties/Parameters (issue 8). Due 2004-11-12.

Gudge: pushing these into WS-Addr introduces layering problems, not solves them. my pipeline processes wsa namespace, second part processes 1st ref prop, third processes 2nd ref prop, etc. i don’t want them all to know about wsa, means i have a different model for processing ref props than that for other soap headers

Glen: why is that a problem? i build the same system, except that some headers introduce slightly more complicated sets of headers, but processors help things down the pipe process abstract headers

Gudge: can’t understand why glen layers it that way

Glen: your way makes no sense to me

<Jonathan> question for Glen: If we’re duplicating the whole SOAP processing model, won’t we have the same problem again (though perhaps on a smaller scale?)

Mark: how do we move forward, people are misunderstand each other’s problems

Glen: this approach opens the door to fairly serious potential problems, by encapsulating it prevents those problems without causing other problems

<Jonathan> Sounds we’re still talking about whether these are "serious". I’m not convinced yet.

Glen: you can follow the rules and end up with something dangerous

Gudge: i either trust the EPR or i don’t. if i trust the receiver, i put the ref props in

Mark: action item for glen is to clarify this

DavidO: i hear gudge saying wants to work at SOAP level, don’t want dispatching software at that level to know about WS-Addr. if i understand correctly, if ref props are spread across multiple soap headers, they now have to be coded up to not only look at soap headers but also inside the ref props container glen proposes. is that right gudge?

Gudge: yes, i think so

DavidO: if i understand glen’s POV, if they add a malicious ref prop that gets turned into a bad or evil header, bad things could happen. if it’s in a container, then that can’t happen. is that right?

Glen: yes

Marc: when we talk about this issue, we talk about not wanting to reproduce the SOAP processing model. what parts do people think we are we having to reinvent?

Gudge: i have not built any systems that add soap attributes to ref props, but i’m not sure i want to preclude it

DavidO: soap processing model of the most interest is that these are header blocks

Mark: we’re out of time. glen mentioned another possible approach adding an attribute to note these are ref props. anyone interested in exploring this?

Glen: thinks there are problems with that solution

DavidO: if glen is writing proposals, he can write that up too

Mark: just wanted to make sure that option was captured that’s all today, same time next Monday

Summary of Action Items

Minutes formatted by David Booth’s scribe.perl 1.95 (CVS log)
$Date: 2004/11/08 23:48:02 $