00:00:22 markn: option 1 would close issue 8 00:00:52 jeffm: result is a tie between 1 and 3 00:03:20 tom: difficulty is a difference in requirements. i voted for 2 as i'd like to target multiiple intermediaries. 00:05:20 markn: formal vote for option 1 or 3 00:06:00 microsoft 3 00:06:32 zakim, unmute me 00:06:32 MSEder should no longer be muted 00:06:33 W3C: 1 00:06:42 Mark: 3 00:06:54 mlpeel has joined #ws-addr 00:06:59 Novell: option 3 00:07:30 mike, we can't here you 00:07:38 s/here/hear 00:07:46 Nokia: abstains 00:08:34 HP: abstain 00:08:37 zakim. mute me 00:08:42 IBM: 3 00:08:46 zakim, mute me 00:08:46 MSEder should now be muted 00:08:48 SAP: 3 00:09:00 Hitachi: 3 00:09:05 Fujitsu: 1 00:09:46 Oracle: 1 00:09:49 BEA: 3 00:09:53 Sun: 1 00:09:57 BT: 3 00:09:59 W3C: 1 00:10:04 Novell: 3 00:10:12 Nokia: abstains 00:10:29 option 3 - 7 00:10:32 option 1 - 4 00:10:41 2 abstained 00:11:00 RESOLUTION: close issue 8 with proposal #3 00:11:17 Topic: i004 security model 00:11:30 gudge: will send mail about security considerations 00:11:33 marc: i'll help 00:14:15 discussion of what namespaces can be added to a header by refps 00:14:41 schema retricts ##other but there are other namespaces XOP, MTOM, etc .. 00:14:54 dorchard has joined #ws-addr 00:16:22 Topic: Issue 1 00:17:06 markn: time constrained discussion of this issue. 45 mins, lunch then 45 mins afterwards. 00:18:55 daveo: i'm now with paco after discussion of state in an EPR interaction. there are two types of EPR statefull (v) stateless. in all cases they're just an data echoing mechanism. 00:21:23 ... we don't need to tell the client about the identity of what is being identified. in all cases we tend to wrap data in an element. in any of the specs where a client needs compare identitiy, there is a wrapper. we don't need to say anything in addressing about EPR identifier. 00:22:02 ... state is a separate discussion. EPRs are about echoing data, not identification. 00:22:31 ... propose remove text about identification in addressing. EPRs are not always identifiers. 00:23:05 anish: what's the difference between refprops and refparams. why 2 different mechanisms? 00:23:52 -MSEder 00:24:36 +MSEder 00:25:04 2 00:25:08 zakim mute me 00:25:15 zakim,mute me 00:25:15 MSEder should now be muted 00:25:15 paco: you can separate this discussion. there are use-cases without identifiers and use-cases with EPRs as an identitifier and use-cases with state. 00:26:28 zakim, who is on the call? 00:26:28 On the phone I see Hugo.Haas, Melbourne, PeteWenzel, Mark_Peel, MSEder (muted) 00:26:49 q? 00:27:43 marc: was with the argument until he heard paco. unhappy about maintaining distinction between params and props. 00:29:13 paco: address + the state is like URI and a cookie. 00:29:55 paco: how does state effect an interaction: 1000's of ways. policy just raises one area of concern. 00:30:24 marc: more than just state. you're talking about a different thing. it's hiding behind words. 00:31:16 jeffm: we're playing semantic games here. how can you talk about state without identity? state implies an entitiy. it's got to be the state of something. 00:31:31 marc: discussion is not just about state but also about diff EPRS accepting diff messages and having diff policies 00:31:34 lost audio 00:32:07 -Melbourne 00:32:13 +Hugo 00:33:17 -Hugo 00:33:22 +Hugo 00:33:54 daveo: what led me to thinking ERPs are an identifier + state, was the lack of a comparison of EPRs in other specs. 00:34:28 zakim, mute me 00:34:28 MSEder was already muted, MSEder 00:34:45 zakim, unmute me 00:34:45 MSEder should no longer be muted 00:34:52 zakim, mute me 00:34:52 MSEder should now be muted 00:35:15 ... in the specs we have which use EPRs, RM, pub-sub, etc layer comparison on top 00:35:31 s/in the/the/ 00:36:11 tony: you don't cache EPRs! 00:36:17 jeffm: oh yes you do! 00:36:59 markn: warns that a spec you can't abuse is a very high bae 00:37:04 s/bae/bar/ 00:39:39 hugo: in the direction we're going, there isn't much difference between props and params. if we need two bags, what is the difference? one of them is still likely to be identifying something 00:44:04 changing state doesn't mean that a service suddenly accepts a new set of messages. it may affect the result you get for particular messages (e.g. a 'getmybankbalance' message may return a fault unless i previously sent an 'authenticateme' message). its still the same service with the same identity 00:44:28 tom: raises formal identifiers (v) URIs .. specs like WS-RF and RM want to use refps to distinguish what you're talking about 00:44:34 paco seems to suggest that refps chnage the service 00:46:08 paco: i can't prevent you using refps as identifiers.you can always hang yourself 00:47:45 daveo: i'm ok with collapsing refprops and params. under what situation would you get state in a refprop as opposed to a refparam and do something differently? we need to understand this to go forward. 00:48:14 +1 to why we need both 00:48:43 +1 to not needing both 00:49:00 greg: benefits in optimisation when policy can be attached. 00:50:18 greg: (answering markn) 20,000 blade servers could have their own EPR. 00:50:30 marc: then they're an identifier 00:51:01 anish: if you're talking about two different 'things' then they're identifiers 00:51:36 paco: if everything the same apart from the policy, then are we really talking about a different thing? 00:52:20 anish: if two EPRs can point to the same thing, then we're not talking about identifiers 00:53:14 markn: what's the use-case for refprops? 00:54:02 glen: difference of opinion as to "what is a Web service?" is the problem here 00:55:20 ... what we need to do is pick the 80/20 cases. EPR should point you at the same thing a WSDL points you at. 00:55:32 paco: world doesn't turn around WSDL 00:56:01 which chicken and egg. came first, the WSDL or the Web service? 00:56:44 paco: don't use WSDL as a staight jacket. 00:57:00 s/staight/straight/ 00:57:40 glen: it's dangerous to change services mid-stream 00:58:37 paco: in very long running services, things such as policy may change. 00:59:37 tom: it's good that EPRs aren't identifiers - they're references. i think we should collapse refps. we don't want them to be identifiers 01:00:15 markn: lunch is looming .. distinction between refprops and params 01:01:06 markn: our charter only requires us to consider (not resolve) this issue. 01:01:07 -PeteWenzel 01:01:09 -MSEder 01:01:13 -Mark_Peel 01:01:20 -Hugo 01:01:20 markn: lunch! 01:01:21 -Hugo.Haas 01:01:23 WS_DescWG(f2f)4:00PM has ended 01:01:24 Attendees were Hugo.Haas, Mark_Peel, Umit_Yalcinalp, MSEder, Melbourne, PeteWenzel, Hugo 01:24:36 umit has left #ws-addr 01:34:53 mlpeel has joined #ws-addr 01:48:14 Zakim, this will be WS_Desc 01:48:14 ok, hugo; I see WS_DescWG(f2f)4:00PM scheduled to start 288 minutes ago 01:56:34 WS_DescWG(f2f)4:00PM has now started 01:56:40 +MSEder 01:56:41 mlpeel has joined #ws-addr 01:59:21 +Hugo.Haas 01:59:42 +Hugo 02:00:33 -Hugo 02:00:47 Zakim, this will be WS_Desc 02:00:47 ok, hugo, I see WS_DescWG(f2f)4:00PM already started 02:00:52 zakim, mute me 02:00:52 +Hugo 02:00:54 MSEder should now be muted 02:01:52 -Hugo 02:02:07 zakim, unmute me 02:02:07 MSEder should no longer be muted 02:02:18 +Mark_Peel 02:05:04 PLEASE PUT A MESSAGE ON IRC WHEN YOU START 02:05:24 zakim, mute me 02:05:24 MSEder should now be muted 02:10:56 zakim, unmute me 02:10:56 MSEder should no longer be muted 02:11:29 pauld has joined #ws-addr 02:11:48 +Hugo 02:11:52 zakim, mute me 02:11:52 MSEder should now be muted 02:12:38 Zakim, Hugo is Melbourne 02:12:38 +Melbourne; got it 02:12:43 marc has joined #ws-addr 02:15:11 stevewinkler has joined #ws-addr 02:15:21 zakim, unmute me 02:15:21 MSEder should no longer be muted 02:15:32 Taking over as scribe. 02:15:41 zakim, mute me 02:15:41 MSEder should now be muted 02:15:51 Constrained discussion until 2 about issue i001 02:15:55 Scribe: stevewinkler 02:18:06 Gudge: describes management system as impetus for ref props. 02:18:52 Mark: what is the value of refProps? 02:20:02 Gudge: single entry point into a system, and then use the refprops to go from there. 02:20:15 test, my irc is dying. 02:22:29 steve has joined #ws-addr 02:22:53 Ok, I'm back. 02:23:07 The web client died... 02:24:01 this stems from two different architectural views of the world: message (v) resource oriented. one isn't better than the other for all cases. 02:24:42 Gudge describes chart from his previous action item 02:25:14 Paco: params and properties are used for state. 02:25:24 marc: that's not what the spec says. 02:25:30 paco: but that's how it's used. 02:26:13 daveo: that was then, this is now. we'll remove identifier terms and add in the part about state. 02:26:52 gudge: The question is, why are there two buckets? 02:27:18 Marsh has joined #ws-addr 02:27:24 gudge: it seems that we'll use this answer to inform the decision of i001, what is an identifier. 02:27:31 Scribe: steve 02:29:10 glen: my preference is to simplfy addressing, allow the other use to be layered on top. 02:29:34 marc: so you would say that the management app would define a param. 02:29:43 glen: I would define an EPR extension. 02:30:03 gudge's diagram from Redmond: http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0084.html 02:30:21 paco: so waht you're saying is that an EPR applies to a specific service, if the service changes you need a new EPR. Is the reverse true? 02:30:57 paco: if an EPR changes, do you have to assume that the metadata has changed. 02:33:03 paco: there's a difference between the description of the interaction and the interaction itself. 02:35:32 paco: you're assuming the client is aware of how the policy changes. 02:36:59 back and forth between paco and glen... 02:40:42 paco: we're trying to get away from defining this. We're never going to do it, so let's get away from this. 02:40:58 glen: yes, so what's the point of having refps indicate different metadata? 02:42:12 glen: the interesting thing about an epr is that some piece of code doesn't need to change to talk to it. 02:42:32 paco: yes, but if you see that they're different, then it MAY have changed. 02:43:29 mnot has joined #ws-addr 02:43:59 paco: refparams are data, not metadata. 02:44:27 glen: why are we talking about the connection between an EPR and metadata at all? 02:44:50 paco: the rationale for having 2 buckets, is that the relationship to the metadata is different. 02:45:38 paco: a client gets an EPR that is differrent in params, you don't have to refresh your (policy?) side, but if props are different you do have to do the refresh (not cache). 02:46:55 mark: why are we using props to do this, instead of just params with a string that defines the metadata context? 02:47:48 glen: there is an unbounded way to figure out that information, why are we talking about it. It shouldn't be in the spec... 02:48:54 Mark: 3 options: 0 status quo, 1 remove refprops (i.e. collapse), 2 reword 02:49:48 reword means clarify 02:54:37 ack hugo 02:54:37 hugo, you wanted to give his view about i001 closure 02:56:22 daveo: the web is not aligned with the web architecture. 02:59:57 Hugo: I think that option 1 would close i001, and that options 0 and 2 would required us to justify our choice with something like the comparison that we started with, and consider a QName to URI mapping 03:00:29 marc: the fact that webarch was written retrospectively, gives it weight, and indicates that they know how to build the types of systems we want to build. 03:01:48 jeff: there's a big difference between observing how others have done their implementations and codifying it in a foundational spec. 03:06:53 Paco has joined #ws-addr 03:07:00 ack hugo 03:07:00 hugo, you wanted to disagree 03:07:51 marc: I see the removal of refprops as a necessary precursor to rewording the spec wrt to identification. 03:14:14 straw poll: 03:14:28 option 0 gets 0 votes and has been erased. 03:14:55 Zakim, who's on the phone? 03:14:55 On the phone I see MSEder (muted), Hugo.Haas, Melbourne, Mark_Peel 03:14:57 zakim, unmute me 03:14:57 MSEder should no longer be muted 03:15:40 option 1 gets 10 votes 03:16:11 option 2 gets 6 votes 03:16:25 zakim,mute me 03:16:25 MSEder should now be muted 03:17:10 1 abstention 03:19:21 zakim, unmute me 03:19:21 MSEder should no longer be muted 03:20:40 zakim, unmute me 03:20:40 MSEder was not muted, MSEder 03:20:47 zakim,mute me 03:20:47 MSEder should now be muted 03:21:03 vote for adoption of proposal 1: 03:21:12 2 abstentions 03:21:24 zakim. unmute me 03:21:30 yes: 7 03:21:33 No: 4 03:21:44 zakim, mute me 03:21:44 MSEder was already muted, MSEder 03:21:52 can you go home' 03:21:53 Issue 1 closed with the removal of refprops. 03:24:05 -MSEder 03:24:32 -Mark_Peel 03:25:57 EderMike has joined #ws-addr 03:30:50 RESOLUTION: Issue 1 closed with the removal of refprops. 03:30:57 MSEder has joined #ws-addr 03:32:12 -Melbourne 03:34:00 zakim, who is on the call 03:34:01 I don't understand 'who is on the call', MSEder 03:34:11 zakim,who is on the call? 03:34:11 On the phone I see Hugo.Haas 03:43:26 +MSEder 03:43:42 zakim, mute me 03:43:42 MSEder should now be muted 03:43:44 +Hugo 03:44:03 zakim, unmute me 03:44:03 MSEder should no longer be muted 03:44:15 zakim, who is on the call? 03:44:15 On the phone I see Hugo.Haas, MSEder, Hugo 03:44:34 zakim, mute me 03:44:34 MSEder should now be muted 03:45:48 marc has joined #ws-addr 03:47:48 For the record, issue 1 votes: HP=Y, MSFT=N, IBM=N, SAP=ABS, HIT=Y, FUJ=Y, ORCL=Y, BEA=Y, SUN=Y, BT=Y, W3C=ABS, NOK=N, NOV=N 03:52:30 TOPIC: i020 03:52:55 Anish describes the motivation for the issue. 03:58:54 ? 03:59:06 RESOLUTION: change 'will be used instead of' to 'can be used' in section 2 of the WSDL binding. Editors to make the change right right now. 04:00:01 section: http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html#_Toc77464317 04:00:07 WRT WSDL binding, section 2 2nd paragraph. 04:00:27 Here is what the amended text from Section 2 of the WSDL binding now says: 04:00:27 To support these scenarios, we define a lightweight and extensible mechanism to 04:00:28 dynamically identify and describe service endpoints and instances. Endpoint references 04:00:28 logically extend the WSDL description model (e.g., portTypes, bindings, etc.), but 04:00:28 do not replace it. Endpoint references can be used in the following cases: 04:00:42 the issue is at this email: http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0168.html 04:02:10 1st subissue resolved. 04:02:21 anish is willing to drop the 2nd subissue. 04:04:43 anish describes subissues 3 and 4. 04:13:17 ACTION: Anish to propose text for resolving i020 subissue 4. 04:20:30 ACTION: Anish to start discussion on i020 subissue 4, what are we talking about when we say endpoint reference. 04:20:53 ACTION: Anish to restate description of issue i020. 04:21:18 ACTION 1=Anish to propose text for resolving i020 subissue 3 (what is the relationshiop between wsdl endpoint and wsa:address if a service Qname/port is present in an EPR) 04:21:26 TOPIC: i009 04:24:40 pauld describes the motivation for the issue. 04:28:33 jonathon: we already have all the mechanisms in place to do this now, we don't need to provide extensibility for extensibility. 04:28:41 glen: +1 04:29:00 glen: if you want to do other things you introduce new headers. 04:30:19 dorchard: if we allow multiple To's a subsequent version of the spec could provide some meaning, but if we don't provide it now, then we don't enable future versions to be compatible using those QNames. 04:32:06 jonathon: dave wants to evolve the namespace and paul wants to evolve the functionality. 04:34:12 glen: I don't see a compatible change worth defining. 04:35:35 going from request-response to request-respond-to-one-of-a-list 04:38:15 marc: an example - v1 says pick one, v2 says pick one but do so in this ordering. 04:38:45 I guess I don't understand why we wouldn't just leverage the way SOAP works to do v2 04:39:04 We define new QNames for new headers in v2 04:39:24 if the sender doesn't mark them mu='true', then v1 receivers can ignore them 04:39:45 why does our spec need to say anything? 04:39:54 GregT has joined #ws-addr 04:40:07 Marsh: can we just say 'ignore stuff not in our namespace'? 04:41:58 pauld: discussion has been hijacked, issue is about cardinality, not versioning. 05:00:22 I'm having trouble following it as the scribe. 05:00:38 jeffm has joined #ws-addr 05:02:02 I'm trying to sift through the content and summarize, and in doing so got lost. I'll just start blindly typing what I hear. 05:03:23 mnot: straw poll on where everyone sits. 05:03:30 option 1: status quo 05:04:10 zakim, unmute me 05:04:10 MSEder should no longer be muted 05:04:39 1. Status Quo 05:04:45 option 2: constrain in the soap binding, open in core and wsdl 05:04:50 2. Constrain in SOAP binding, open in core/wsdl 05:04:52 option 3: open everywhere 05:05:01 zakim, mute me 05:05:01 MSEder should now be muted 05:05:02 4. constrain in WSDL, open in core/soap 05:05:14 option 4: constrain in wsdl binding, open in core and soap. 05:05:25 option 1: 13 votes 05:05:34 option 2: 0 votes 05:05:52 option 3: skipped 05:05:57 zakim, mute me 05:05:57 MSEder was already muted, MSEder 05:06:03 option 4: 5 05:07:13 mnot: would anyone object to closing issue with no action (accept the status quo)? 05:08:07 marc: it seems like we're limiting ourselves. 05:09:29 glen: I'd rather have a clear first spec, and then later on we can amend it for new scenarios in version 2, or allow other specs to add new headers. 05:10:23 GregT has left #ws-addr 05:13:09 marc: I'm surprised that people are comfortable with the wsdl binding that allows extensions (e.g. wsa:from optional) and doesn't say how it works, but they're not comfortable with this. 05:17:30 http://www.wallaceandgromit.com/images/gallery/gdoGal8Large.jpg 05:18:32 RESOLUTION: issue i009 closed with the status quo. 05:21:35 meeting adjourned. 05:21:42 RRSAgent, draft minutes 05:21:51 Zakim, draft minutes 05:21:51 I don't understand 'draft minutes', hugo 05:21:56 RRSAgent, draft minutes 05:22:12 Says it's forbidden :-( 05:22:15 zakim, make me a nice cup of tea, please 05:22:15 I don't understand 'make me a nice cup of tea', pauld 05:23:04 bob has left #ws-addr 05:23:15 yinleng has left #ws-addr 05:23:20 s/Scribe: paul/Scribe: pauld/ 05:23:35 RRSAgent, draft minutes 05:23:37 MSEder has left #ws-addr 05:24:19 -MSEder 05:24:28 -Hugo.Haas 05:24:30 -Hugo 05:24:32 WS_DescWG(f2f)4:00PM has ended 05:24:33 Attendees were MSEder, Hugo.Haas, Mark_Peel, Melbourne, Hugo 05:24:53 pauld_ has joined #ws-addr 05:27:06 mnot, I am sending email with all the minutes 05:27:11 http://www.rbg.vic.gov.au/__data/page/59/newmap_web.pdf 05:30:02 http://www.rbg.vic.gov.au/visitorinfo/maps 05:30:24 bigger map: http://www.rbg.vic.gov.au/__data/page/59/newmap_web.pdf 09:30:13 Zakim has left #ws-addr 22:01:49 RRSAgent has joined #ws-addr 22:01:49 is logging to http://www.w3.org/2005/01/18-ws-addr-irc 22:01:58 GlenD has joined #ws-addr 22:02:33 jeffm has joined #ws-addr 22:02:53 Gudge has joined #ws-addr 22:03:11 yinleng has joined #ws-addr 22:03:21 GregT has joined #ws-addr 22:04:39 marc has joined #ws-addr 22:04:43 MSEder has joined #ws-addr 22:04:47 Meeting: WS-Addressing F2F, Melbourne, Australia 22:04:54 Chair: Mark Nottingham 22:05:01 Scribe: Glen Daniels 22:05:16 +Michael_Eder 22:05:51 zakim, mute me 22:05:51 sorry, MSEder, I do not see a party named 'MSEder' 22:06:01 zakim, michael_eder is me 22:06:01 +MSEder; got it 22:06:08 zakim, mute me 22:06:08 MSEder should now be muted 22:06:19 Agenda: http://www.w3.org/2002/02/mid/B8E1BF9A-6546-11D9-9332-000A95BD86C0@bea.com;list=public-ws-addressing 22:06:28 Topic: Issue 6 22:06:36 Marsh has joined #ws-addr 22:07:42 http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0084.html 22:08:24 Make optional, default value of Destination property to anonymous URI 22:09:53 Jonathan: Cases where you don't want to omit (signing, etc), but that should be OK 22:10:47 Paul: When does this get used? How often? 22:11:08 Marc: Every time we send an HTTP sync response, for instance 22:11:47 straw poll : Who'd like to see this in the spec? 22:11:53 Zakim, who's on the phone? 22:11:56 On the phone I see Hugo.Haas, Mark_Peel, Hugo, MSEder (muted) 22:11:56 zakim, unmute me 22:11:56 MSEder should no longer be muted 22:11:56 8 for 22:12:39 zakim, please mute me 22:12:39 MSEder should now be muted 22:12:40 please speak up for the benefit of those of us on the phone 22:13:00 Jonathan: It's natural to look at the header to indicate the presence of WSA... can still look at , but... 22:13:21 Paco: Seems simpler to have less optionality 22:13:46 mnot has joined #ws-addr 22:15:24 (discussion of cellphone use-cases) 22:16:52 Tom: We really care about optimizations, so I feel strongly that we should accept this. Seems simple. 22:17:08 Tony: Do we want to explicitly say the empty address is not the same thing? 22:17:14 Marc: Should talk about XML base 22:17:22 Jeff: We need to do that in general 22:17:43 ACTION: Marc to characterize the issues regarding XML base and the addressing headers - start discussion 22:17:50 zakim, who is on the call? 22:17:50 On the phone I see Hugo.Haas, Mark_Peel, Hugo, MSEder (muted) 22:18:40 Greg: Is this primarily for replies? 22:18:56 Marc: Reply is the obvious common usage, but not necessarily limited to that 22:21:59 Jonathan: Would slightly prefer an empty to an omission 22:22:43 (discussion of whether "" could be a schema-valid encoding of a URI - conclusion == yes, although it's not a valid absolute URI at the application level) 22:24:03 Glen: Seems like we could profitably state that "" is equivalent to omission, and that the URI is absolute not relative to make things more complete. 22:25:07 Jonathan: URIs should be absolute in general for us - action, MessageID, relationship.... this connects to the issue of how you compare/absolutize URIs 22:25:53 Mark: Any objections to accepting this proposal? 22:26:03 No objections. 22:26:58 RESOLUTION: We will accept Marc's proposal (http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0084.html) 22:27:57 NOTE: Microsoft indicates some discomfort with this resolution 22:28:37 TOPIC: i013 - Serialising metadata into messages 22:28:59 http://www.w3.org/2002/ws/addr/wd-issues/#i013 22:29:22 Anish explains the issue 22:29:47 GregT has joined #ws-addr 22:29:47 bob has joined #ws-addr 22:29:48 pauld has joined #ws-addr 22:29:49 Marsh has joined #ws-addr 22:30:00 Gudge has joined #ws-addr 22:33:21 (Discussion of a standard way to echo back the service QName in the EPR to the EPR's destination) 22:34:30 Greg: Isn't this just an implementation detail? If you want it back, use a RefP... 22:35:52 Paco: WSDL doesn't specify that this stuff appear in the message, so why should Addressing need it? 22:36:59 Anish: Hokay, RefPs seem to do the trick 22:37:43 RESOLUTION: Close issue 13 with no action, since ReferencePs allow the service to request arbitrary echoed data including things like service/port QNames 22:38:02 TOPIC: Issue 15 22:38:04 http://www.w3.org/2002/ws/addr/wd-issues/#i015 22:38:48 Marc describes the issue 22:39:13 No standard way to update EPRs 22:41:03 zakem, mute me 22:41:17 zakim, mute me 22:41:17 MSEder was already muted, MSEder 22:42:22 yinleng has joined #ws-addr 22:43:04 Marc: This is already "almost there" in that we say it's optional to put a in a reply - we just don't say what to do with it 22:45:19 Paco: There seem to be a lot of potential little issues around this and if we don't solve them all it might not be good enough 22:46:06 Jeff: Would this be a hint (you may use this new one) or a requirement (you must use this new one)? 22:47:21 Marc: This seems like something extra that we could do, but isn't strongly in scope either 22:48:00 Marc: Do people think this should be explored/fleshed out? 22:49:12 (some interest from 3-4 folks) 22:50:15 woops, those last two "Marc"s were "Mark"s :( 22:51:19 Jonathan: This sounds interesting, but feels like feature creep (should be in other spec(s)) 22:52:04 Marc: Are people really against this? If not, I may pull it together as a real proposal... 22:52:29 Gudge: Layered spec seems right - do it after we've checkpointed/resolved our big stuff 22:55:08 TOPIC: Issue 18 22:55:10 http://www.w3.org/2002/ws/addr/wd-issues/#i018 22:58:46 (pause for test of the emergency intercom system) 22:59:45 Anish: This means an instance of an EPR is not really abstract, it's tied to a particular protocol, etc 22:59:56 Glen: right, I think that's the intent (although I might prefer otherwise) 23:00:38 Anish: Abstract properties (which exist outside particular bindings) have to contain non-abstract markup 23:01:15 umit has joined #ws-addr 23:02:34 s/Marc: Do people think/Mark: Do people think/ 23:02:59 Paco: Refp's don't have to contain those attributes, they just might 23:03:02 q? 23:03:56 Anish: Impression you get from reading core is that a single abstract EPR can be used with multiple bindings - if you need proto-specific markup, this isnt really true... 23:04:17 BREAK - return at 10:24:35 23:04:25 (AM, Melbourne time) 23:04:28 -MSEder 23:29:07 uno momento - we'll let you know when ready 23:29:14 -Hugo 23:29:22 +Hugo 23:29:25 oh, we did :) 23:30:03 +Umit_Yalcinalp 23:31:21 RESTART 23:32:29 (discussion of potential editorial change to indicate that an EPR isn't really "abstract", since RefP infosets might need to know about the binding) 23:35:12 If this is multi-protocol (per Steve Vinoski's issue), then this might matter 23:38:27 +MSEder 23:38:47 zakim, mute me 23:38:47 MSEder should now be muted 23:41:46 ACTION: Anish to identify which parts of the specifications give an impression that EPRs are more abstract than they actually are 23:42:54 Back to issue 15 briefly 23:43:18 ACTION: Marc to make a concrete proposal for issue 15 (redirection/EPR updating) 23:44:04 ...due 2005-01-26 23:44:10 ACTION 3 = Marc to make a concrete proposal for issue 15 (redirection/EPR updating). Due 2005-01-26 23:44:41 TOPIC: Issue 25 23:44:55 http://www.w3.org/2002/ws/addr/wd-issues/#i025 23:45:18 do we have concrete use cases for enabling multiple Actions? 23:46:11 Paco has joined #ws-addr 23:47:19 TOPIC: Issue 40 23:47:30 http://www.w3.org/2002/ws/addr/wd-issues/#i040 23:50:36 Proposal is to strike all but first sentence in section 3 (Faults) 23:51:06 (with the idea of not repeating ourselves) 23:51:49 RESOLUTION: Delete all but first sentence of section 3, paragraph 1, in the SOAP binding doc. 23:54:27 TOPIC: Issue 22 23:54:52 Marc: Do we have a dependency on the new HTTP binding/SOAP MEP that David is working on for the SOAP binding doc? 23:55:39 (mumblings "yes") 23:55:59 TOPIC: Issue 17 23:56:25 Anish: Didn't we say that we're waiting for the WSDL group? 23:56:42 Mark: Yes, we'll discuss this afternoon