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
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
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
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
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
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
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
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.
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
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