16:01:05 RRSAgent has joined #ws-addr 16:01:05 logging to http://www.w3.org/2005/09/28-ws-addr-irc 16:01:14 Meeting: Web Services Addressing Face-to-Face 16:01:17 pauld has joined #ws-addr 16:01:17 Chair: Mark Nottingham 16:01:49 Agenda: http://www.w3.org/mid/D98ACD86-AAC1-405F-BD05-3CE8D3B63980@bea.com 16:01:52 bob has joined #ws-addr 16:02:05 prasad has joined #ws-addr 16:03:59 GlenD has joined #ws-addr 16:04:14 zakim, I haven't seen you in ages! 16:04:14 I don't understand 'I haven't seen you in ages!', GlenD 16:04:19 zakim, this is WS_ADDRWG 16:04:19 sorry, mnot, I do not see a conference named 'WS_ADDRWG' in progress or scheduled at this time 16:04:27 zakim, this is wsf2f 16:04:27 ok, mnot; that matches WS_(F2F)12:00PM 16:04:35 zakim, who is here? 16:04:35 On the phone I see Roland_Merrick, Mark_Peel, [TIBCO], Prasad_Yendluri 16:04:37 On IRC I see GlenD, prasad, bob, pauld, RRSAgent, Zakim, mnot, TonyR, Arun, mlpeel, David 16:04:44 TRutt has joined #ws-addr 16:04:47 RebeccaB has joined #ws-addr 16:04:58 hugo has joined #ws-addr 16:05:00 I will not be able to join via phone or in person today but will be available on IRC 16:05:32 Marsh has joined #ws-addr 16:05:37 dhull has joined #ws-addr 16:07:46 dorchard has joined #ws-addr 16:08:52 chad has joined #ws-addr 16:08:55 Paco has joined #ws-addr 16:09:04 chad, hi you paperless beast 16:11:02 scribe: dorchard 16:11:53 Meeting: WS-Addressing Face-to-Face, September 28, 2005 16:12:00 Chair: Mark Nottingham 16:14:18 BEA proposes dinner and rides at BEAWorld's rental of Great America Park 16:15:33 Hitachi follows up with a stunning plan for Gordon Moore talk at ?? tomorrow night 16:16:33 Bob solicits Wednesday evening and weekend before. Perhaps saturday/sunday leaf viewing 16:16:43 also proposes kamakura 16:18:24 andreas has joined #ws-addr 16:19:25 AI review 16:19:55 paco i61 done 16:20:46 umit i56 done 16:21:16 swinkler has joined #ws-addr 16:21:36 vikas has joined #ws-addr 16:21:37 Gil has joined #ws-addr 16:21:56 approve minutes sep 19th 16:22:29 web services i18n comment 16:23:12 mail of 1th sept which requests feedback. 16:23:49 mail of 15th sept which requests feedback 16:24:01 bob has joined #ws-addr 16:24:16 hugo: closer to xmlp or ws-desc than to ws-a. 16:25:21 WG takes no action 16:26:18 topic: issue i61 16:26:34 RRSAgent, where am I? 16:26:34 See http://www.w3.org/2005/09/28-ws-addr-irc#T16-26-34 16:26:52 RRSAgent, make log public 16:26:54 Gil has joined #ws-addr 16:27:12 Paco runs through his proposal. 16:27:43 http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0037.html 16:28:50 -Roland_Merrick 16:31:05 paco: the wsaw:action attribute does not mandate ws-addressing 16:32:15 Gil has left #ws-addr 16:32:45 paco: if required="false" and wsaw:usingAddressing is set, the message must have the complete set of wsa header blocks. 16:32:57 DavidH: for example, can't have message with messageId but no action 16:33:47 Gil has joined #ws-addr 16:34:19 anish has joined #ws-addr 16:35:20 general approval of the first paragraqph 16:37:17 discussion of 2nd paragraph 16:38:14 anish: may be ws-a binding for udp 16:39:07 rebecca: what does "this" refer to 16:39:13 paco: the latter 16:41:57 markn: add [core, applicable ws-addressing protocol bindings (e.g., SOAP)] after sentence fragment "senders MUST use all header blocks mandated by 16:43:33 UsingAddressing present, required = true ==> MUST follow rules in core and other applicable bindings. In particular, MUST include wsa:Action 16:43:41 usingAddressing present, required = false (or missing) ==> MUST follow rules in core and other applicable bindings, if *any* MAP header is present 16:43:45 some discussion about "which response" messages following initial messages. 16:44:14 If usingAddressing is missing, no constraints on WSA 16:44:34 paco: what is the scope 16:44:52 anish: this text will go in wsdl doc, and this doc would say the requirements. 16:45:39 paco: meps are a natural scope, but not the only one. 16:46:24 paco: could scope be all operations in same interface? 16:47:59 anish: say one operation that is req/respon using ws-addressing. then get response with ws-addresssing. Should another request without ws-a to same operation be ok? 16:48:26 jeffm has joined #ws-addr 16:48:34 anish: this should be ok for wsdl:required="false" 16:50:26 davidh: agrees 16:50:42 uyalcina has joined #ws-addr 16:50:50 paco: may be other scopes. 16:51:01 chad has joined #ws-addr 16:51:56 paco: may want to say whole portType. 16:52:04 umit: putting on binding is an oxymoron. 16:52:12 anish: even per invocation. 16:54:03 paco: is the change something like change "related" to any message sent within same instance of an mep. 16:55:48 markn: "any subsequent messages in that exchange pattern"? 16:56:15 andreas has joined #ws-addr 16:56:40 davidh: suggests putting into bullets 16:58:33 paco: we should replace "header blocks" with something non soap specific. 17:01:15 scribe loses scribe ability for a bit. 17:01:42 paco: need a clear way to say whether properties are required 17:02:50 davidh: when you have message addressing properties present, then header blocks will be in the soap messages 17:04:43 anish: what about defaulting if ws-addressing not fully engaged, say mU="false" on partial. 17:05:25 paco: mU isn't part of it at all. 17:06:41 in either mU=" * *" or wsdl:required=" * ", it doesn't matter. Receiver will honour Addressing. 17:08:30 anish: if mU="false", receiver has already said that by "usingAddressing" marker, receiver will honour. 17:09:36 q+ 17:09:42 Glen make sstunning point about how many non-soap bindings we have. 17:10:10 davidh: we should talk about properties, not header blocks. 17:10:27 paco: it's binding dependent on how to determine if ws-a is present. 17:11:24 paco: this is a binary decision. 17:11:53 davidh: if I get this kind of soap message, the set of meps will be x... 17:12:21 paco/davidh get into whether ws-a enabled is binary decision or what the scope is. 17:13:08 ack uya 17:13:22 would there be engaging that is different on different bindings? 17:15:15 i would prefer somewhere in this text, esp if we were not to remove the wording about "headers", we should include language to indicate mU value is not relevant. It does not come across clearly. 17:16:03 davidh: this should be independent of the wsdl port type (interface) definition 17:18:10 davidh: the soap and whatever binding figure out what properties are present. 17:19:33 glen: could say usingAddressing is specific to ws-a soap and wsdl bindings, some other binding could define it's own usingAddressing and semantics. 17:19:57 markn: 1 path: specific to soap, etc. 2nd path: be more generic 17:20:40 TonyR: IIUC, the presents of any property switches on ws-a, but does that really mean "any non defaulted property". 17:22:02 mark tries to guage room's interest. 17:26:07 mark: maybe usingAddressing is too simplistic. 17:27:20 anish: need an additional flag, not only addressing is supported/required, and it is possible to have another soap binding how to indicate... 17:28:21 davidh: all we need to do is say explicitly if there are no soap header blocks present then no soap properties.. 17:29:03 glen: axis2 twigs of properties that are always there in messages, even without ws-a. 17:30:55 tonyr: all this is putting a different face on the flag. This is pretending there's no flag. 17:34:37 davido: could tonyR live with "if non-defaulted WS-Addressing properties"? 17:35:33 mark: change to say "if [the WS-Addressing protocol binding is engaged], the use of the Message Addressing Properties MUST be..." 17:36:00 mark: more cleanup. (should he be an editor?) 17:48:17 tonyr: given an endpoint that takes both non-wsa and wsa, if you take an endpoint that only takes wsa then it.. (scribe lost rest) 17:50:04 doesn't find it useful to discuss non-soap bindings for this issue 17:50:23 I want to separate the idea of WS-Addressing being engaged from the idea of MAPs being in the message 17:50:59 markn: proposes we just have to fix the text within the [] in proposed text. 17:52:07 Sounds good 17:52:08 I was suggesting that the SOAP binding may CHOOSE to set the notional "WS Addressing is engaged" flag based on the presence of a WS Addressing SOAP header 17:54:16 jeffm: is this context free determination of ws-addressing engaged? 17:54:39 glen: if it's soap and actual header blocks are present then... 17:55:32 -Mark_Peel 17:55:51 No - not context free - absolutely not - the decision is made by the protocol 17:57:09 -Prasad_Yendluri 17:57:45 +??P0 18:17:38 Paramount's Great America: http://www.pgathrills.com/ 18:22:11 topic: issue 56 18:22:59 http://lists.w3.org/Archives/Public/public-ws-addressing/2005Apr/0062.html 18:23:30 anish: not defaulting makes sense if endpoint/o port not specified. 18:27:50 zakim, who is on the phone? 18:27:51 On the phone I see [TIBCO], prasad 18:27:58 umit wants to remove item #4. 18:28:56 bob has joined #ws-addr 18:30:34 I can't scribe umit's comments 18:31:17 umit: need a motivation for which parts of EPR would need to be in endpoint 18:32:11 markn: paraphrasing umit, close 57 with no action then 18:32:50 jonathan: relationship to destination and http location is important 18:33:34 jonathan: also relationship between wsa:endpoint references's address and endpoint's address. 18:34:12 Arun has joined #ws-addr 18:36:06 jonathan: maybe change endpoint address to be "generated endpoint address" which takes into account http:location 18:36:15 jonathan: or another alternative. 18:36:43 jonathan:endpoint ref address with endpoint address then add http location 18:37:27 uyalcina has joined #ws-addr 18:37:54 anish: we don't need eprs to solve this..? 18:38:52 markn: 57 is about placing ref params in wsdl. 18:39:57 paco: want to be able to place ref params in wsdl. 18:42:19 davido: eprs in wsdl doesn't make sense because metadata is covered in other areas and ref params should be dealt with in part of wsoap:header mechanism. 18:42:57 anish: destination value could be common across ports and want to indicate that. 18:43:28 anish: if 10 different ports and same thing, then have single epr? (not sure if I got it) 18:44:16 anish: a wsdl 11 service element with a port, soap:address foo, another with soap:address bar. 18:45:14 anish: if we have epr, the rules are really clear. 18:45:40 order of human concerns: 1) food, 2) sex, 3-487) (other stuff), 488) web services specifications 18:46:43 anish: wsa:destination could be different than address. 18:47:10 glen: wsa:to could have more dispatch. 18:47:21 could have wsa:to different than http location. 18:48:15 Glen, there is nothing in the specification that allows you to do this today, so the assumption does not hold as the specs are written 18:49:02 q+ 18:49:17 anish: bullet 4 allows distinction between endpoint address and endpoint/port address. 18:50:16 anish: wsa:desination has to match the wsa:to, but not wsa:endpoint address. 18:52:04 wouldn't that require you to use an EPR always to use WS-A? 18:52:24 jonathan: If you make epr and endpoint/port address orthogonal, then when you add wsa:endpoint reference then does the MAP property. This means wsdl:address isn't MAP property 18:53:41 q+ 18:54:00 anish: slightly different. Didn't mean to say completely different, was pointing out bullet #4 has a problem wr earlier discussions. Given a wsdl and wsaddressing is being used, how do you figure out destination property. 18:54:54 anish: there is also the case where creator of service creates wsdl but not epr, the value of destination is the value is the thing in the port/endpoint address. Then there is a problem when EPR is added. 18:55:02 anish: wants to delete bullet 4. 18:56:49 gil: need to explain when endpointreference and endpoint/port are different. 18:57:01 q+ 18:57:33 q- 18:59:08 yinleng has joined #ws-addr 18:59:19 it seems to me that all we wanted to avoid physical/logical destination, but this proposal requires you to define the relationship of destination and the actual WSDL endpoint address and would require you to treat destination as a more nebulus concept. Today we don't go there. 18:59:22 dorchard: against setting reference parameters in epr. 18:59:55 dorchard: against setting soap header blocks by using EPR when we already have wsdl 1.1 and wsdl 2.0 constructs for header blocks. 19:00:43 +??P3 19:00:53 anish: dave, you for setting destination using wsoap:header? 19:01:00 zakim, ??P3 is me 19:01:00 +yinleng; got it 19:01:26 markn: 1. No EPR; 2. EPR aligned w/destination. 3. EPR "loose". 19:02:22 rebecca: we added metadata into EPR. If EPR not going to destination does it disallow? 19:02:51 umit: the WSDL has all the policy/metadata stuff. 19:03:10 +1 to umit 19:04:03 markn: option 2 is keep statement 4, option 3 is remove statement 4 19:04:13 -yinleng 19:04:22 -prasad 19:44:20 +Mark_Peel/Katy_Warr 19:45:16 pauld has joined #ws-addr 19:45:35 Katy has joined #ws-addr 19:59:29 swinkler has joined #ws-addr 19:59:35 zakim, who is on the phone? 19:59:35 On the phone I see [TIBCO], Mark_Peel/Katy_Warr 20:02:16 scribe: pauld 20:02:30 Straw Poll: options for i056 20:02:57 option 1: No EPR (5) 20:03:10 options 2: EPR Algned w/dest (4) 20:03:30 +??P1 20:03:34 option 3: EPR "Loose" (5) 20:03:43 s/options/option/ 20:03:57 s/Algn/Aligned/ 20:05:21 objections to options 2 (daveo, hugo, glen, others) 20:05:31 s/options/option/ 20:05:56 umit: prefers option 2 to 3 20:06:23 chad has joined #ws-addr 20:06:28 chad, hi 20:06:44 chad, question: options for i056 20:06:59 chad, option 1: No EPR 20:07:14 chad, option 2: EPR Aligned w/dest 20:07:26 chad, option 3: EPR "Loose" 20:07:39 vote: 3 20:07:45 vote: 3 20:07:46 vote 3, 1 20:07:47 vote: 3, 1 20:07:48 vote: 1 20:07:48 vote: 3, 1 20:07:53 vote: 1 20:07:55 vote: 3 20:07:56 vote: 3, 1 20:08:08 vote: 1 20:08:18 vote: 1 20:08:23 3 20:08:25 vote: umit:2,1 20:08:33 vote 3 20:08:35 vote: trutt: 3 20:08:38 vote: 3 20:09:05 chad, votes? 20:09:14 vote: 1, 2, 3 20:09:35 chad, trutt: abstains 20:09:44 chad, trutt abstains 20:09:52 chad, vote: trutt: abstains 20:09:57 chad, trutt: vote: 0 20:10:00 vote: trutt: abstains 20:10:04 trutt: vote: 0 20:10:20 vote: 3, 1, 2 20:10:32 vote: bob: 1, 3 20:10:37 vote: 1, 3 20:10:50 chad, options? 20:10:56 chad: votes? 20:10:57 chad, votes? 20:11:35 vote: abstain 20:12:19 chad, count 20:12:19 Question: options for i056 20:12:19 Option 1: No EPR (7) 20:12:19 Option 2: EPR Aligned w/dest (1) 20:12:19 Option 3: EPR "Loose" (7) 20:12:19 17 voters: andreas (1) , anish () , bob (1, 3) , dhull (3, 1) , dorchard (1) , GlenD (3, 1) , hugo (3, 1) , jeffm (3) , Marsh (1, 2, 3) , Paco (3, 1, 2) , pauld (1) , prasad (1, 3) , RebeccaB (3) , trutt () , TRutt (3) , umit (2, 1) , vikas (1) 20:12:22 Round 1: Count of first place rankings. 20:12:24 Round 2: Eliminating candidate 2. 20:12:26 Candidate 1 is elected. 20:12:28 Winner is option 1 - No EPR 20:12:37 chad: details 20:12:42 chad, details 20:13:39 Arun has joined #ws-addr 20:14:31 mnot: so, that covers i56 and i57, but we will still need text to cover how to infer the destination 20:15:32 marsh: we need to consider when address and the EPR differ 20:15:53 daveo: setting wsaddressing is on the binding, not on the endpoint 20:16:36 daveo: how is eching a refparam different to a fixed value in schema? 20:16:45 s/eching/echoing/ 20:17:58 mnot: lets see if we have a use-case for describing refps in wsdl before designing it 20:18:32 daveo: service may provide a supplier or sessionid 20:19:02 marsh: routing headers could be constant, not ephemeral 20:19:31 paco: we have to consider WSDL 1.1 as well as WSDL 2.0 20:19:39 +??P2 20:19:57 anish: you fix it in schema, not WSDL, but how do you specify a fixed value on an endpoint basis 20:19:58 zakim, ??P2 is me 20:19:58 +yinleng; got it 20:20:38 marsh: part of my concern is it's harder to create a *structure* which may happen to have fixed values 20:21:09 mnot: we seem to agree there is functional requirement, it's the style where we differ 20:21:54 .. if we allow an EPR, then we're done. it's the not allowing case where we have more work 20:22:11 +Mark_Peel.a 20:22:14 q+ 20:22:37 daveo: wsdl 1.1 and 2.0 allow you to set SOAP headers. allowing EPRs introduces potential collision 20:23:18 mnot: straw poll revealed slight leaning to not allowing an EPR. Can people who voted 3 explain their position 20:23:44 anish: ERP destination may be different to the WSDL port value 20:24:11 .. this issue is about how to figure the value of the output MEP 20:25:09 glen: the case where you don't specify the relationship toAddress ..] 20:25:40 tom: raises physical (v) logical address distinction 20:26:28 marsh: all addresses in WSDL are logical, though in the case where you don't have a map, dereferencing the logical is a good option 20:28:30 discussion of mapping between mapping between addresses or if the To address can be used as a second layer 20:29:26 glen: imagine a world where wsdl endpoint was the addressing endpoint, much as i like 3, 2 is my preference 20:29:58 another point would be what about combining policies of EPR and WSDL. 20:30:02 room moving towards 2, though virtually noone voted for it 20:30:51 hmmm.. I'm still firmly astride #1. 20:31:15 swinkler has joined #ws-addr 20:32:14 mnot: restates our charter requirement "providing the mechanisms for defining Web Services Addressing property values in WSDL 1.1 and WSDL 2.0 service descriptions;" 20:32:29 hmmm... I'm leaning away from #1 towards #2, just because refPs are simpler and direct. 20:33:59 umit: 1 is preferable - given we have metadata section in an EPR, we would need to make the WSDL and the EPR consistant which is difficult 20:34:34 anish: solving i56 is more interesting to me than including refps in a description 20:36:10 number of people interested in setting a To message addressing property not in the WSDL 20:36:25 I think it was around 5 people interested. 20:37:55 anish: anyone can define extensions which conflict, it's a generic problem, not specific to the EPR in WSDL proposal 20:38:07 marsh: what would this pseudo destination be? 20:38:20 mnot: cross that bridge when we get there 20:38:22 uyalcina has joined #ws-addr 20:39:15 anish: we're defining the WSDL binding for addressing, EPRs is a big part of addressing. I could do this with extensibility, but that wouldn't be good enough 20:39:53 marsh: i the question wherer we EPRs in wsdl at all? 20:40:05 mnot: i'm exploring the functionality required 20:40:16 .. also is this testible? 20:40:39 anish: i believe so 20:42:09 discussion of info required for test data (essentially out of band) 20:42:23 mnot: what about this as an optional extension? 20:43:29 marsh: sounds like we're talking about a broker - send it here first, then dispatch, if so is one level going to be enough 20:43:49 pauld: reminds me of source routing 20:45:26 glen: this is essentially about multiple possible destinations within a single node 20:45:40 marsh: this reminds me of multiple to's 20:49:45 anish: i have a multi-protocol use-case, multiple ports in wsdl, and i want to tell clients sending over different paths to use the same To value 20:50:04 discussion spirals into identity / physical address death spin 20:51:03 anish: we need to reexplore why we have two different things - EPRs / endpoints 20:51:24 umit: we can solve your problem with the machinary we already have 20:52:13 paco: this is why in the broker model refps are more interesting than To 20:52:57 mnot: interested to see if this discussion has changed people's opinions 20:53:06 +1 to Paco 20:53:36 staw poll: do we need to have a separate WSDL address to Addressing property? 20:54:01 yes: 7 20:54:18 I vote yes 20:54:32 no: 6 20:55:13 marsh: is our address the same as the WSDL endpoint address is the question? 20:55:26 glen: they should be the same thing, it's not just syntax 20:56:07 daveo: i don't understand the way you voted (no) 20:56:28 s/no)/no), glen/ 20:57:13 marsh: if the stuff coming from WSDL is different, how do i now represent that in SOAP headers, it's a new thing 20:58:01 mnot: wants a proposal for option 1 20:59:56 daveo: maybe we could make the infosets the same even though WSDL 1.1, 2.0 and EPRs serialisations differ .. 21:01:21 .. heard glen says he wants them to be the same thing, but thinks making the serialisations the same isn't realistic 21:02:38 glen: so we could have an xslt to go between them 21:02:52 anish: asserts they aren't the same thing 21:06:20 DavidO's Proposal for i056: The [destination] property is taken from the endpoint or port address - 21:06:20 derived address (WSDL 2.0) or the applicable WSDL 1.1 extension (for 21:06:21 SOAP it is taken from soap:address/@location). 21:07:13 chad, new poll 21:07:13 new poll 21:07:27 chad, options for i56 21:07:35 chad, question: options for i56 21:10:37 daveo: explores difference between setting values at the endpoint and the binding level. My supplier id use-case makes sense at the binding level .. 21:10:50 paco: WSDL bindings are reusable, but endpoints aren't 21:13:36 review of anish's proposals for i57: http://www.w3.org/2002/ws/addr/wd-issues/#i057 21:14:20 daveo: ws-addressing can reuse WSDL constructs in ways they weren't expecting 21:14:30 marsh: not sure the schema allows that 21:15:39 mnot: agreement that this would be a top level extension, not a sibling of usingAddressing 21:17:14 discussion of WSDL providing WSDL SOAP headers in the endpoint or refparams in the endpoint 21:19:15 daveo: volunteers to write two proposals for expressing refparams in WSDL 21:19:27 mnot: do we need to keep i56 open? 21:20:07 marsh: functionality daveo is proposing is good, however option 2 does this, which tells me it's a clear winner :-) 21:20:35 s/which tells/which received the least votes and / 21:22:45 poll again 21:22:50 option 1: 5 21:22:59 option 2: 2 21:23:08 s/1: 5/1: 7/ 21:23:13 option 3: 5 21:23:34 mnot: whuptish (to daveo) 21:23:47 .. your proposals are going to help here 21:24:15 sound of a whip 21:24:17 Topic: i064 - Migration of @Action 21:25:30 marsh: outlines difficulty of migrating from addressing member submission to our rec in area of wsa:action 21:25:59 http://www.w3.org/2002/ws/addr/wd-issues/#i064 21:26:10 paco: this is a rec for wsdl authors? 21:26:24 marsh: yes, it's how to keep your actions aligned 21:28:02 .. in many cases they'll be the same, which is fine, but it would be nice to ensure that someone dipsatching on action knows how to exhibit the same behaviour across the two specs 21:28:58 .. if people following this advice, it will enable vendors to easily support the migration 21:29:18 anish: advice is don't use defaults in the submission case if the values match 21:30:06 paco and marsh discuss a service which sends two different action values in a single message 21:31:24 hugo: seems like primer material 21:31:34 mnot: or even a note or a document 21:31:45 marsh: asking for higher visibility 21:32:17 hugo: seems like we're highlighting bug fixes and what's changed 21:33:01 pauld: seems like it could help adoption by demonstraing how to migrate 21:33:28 marsh: communicates to current users of WSE how to plan for W3C WS-Addressing 21:34:31 anish: explores how this helps in migration 21:36:12 .. wonders what' special about action, other machinary is required to process our messages beyond the member subission - we have defaults for To, etc 21:39:57 anish: still needs to understand if this really helps in migration 21:40:16 marsh: walks through proposal 21:40:28 .. again 21:41:00 mnot: would be concerned this baloons to an entire migration guide 21:42:02 hugo: this is essentially my discomfort. It sees motherhood and apple pie. Wierd to pick on this and put it in the main document 21:42:21 marsh: but what else would you call out - have a complete table:? 21:45:06 -Mark_Peel/Katy_Warr 21:45:28 discussion of what's so special about action 21:45:42 zakim, who is on the phone? 21:45:42 On the phone I see [TIBCO], prasad, yinleng, Mark_Peel.a 21:46:38 hugo: concerned about the word "recommend" 21:46:59 jeffm: we could use "suggest" 21:47:20 -Mark_Peel.a 21:47:28 -yinleng 21:50:28 RRSAgent, where am I? 21:50:28 See http://www.w3.org/2005/09/28-ws-addr-irc#T21-50-28 22:01:55 +Mark_Peel 22:13:03 daveo: presents his proposals for i057: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0039.html 22:14:02 +YinLeng 22:14:30 umit: worries that having a type for refps makes them no longer opaque 22:14:56 daveo: the meaning of the content is still opaque 22:15:19 glen: potentially duplicate incompatible type definitions for a single element 22:15:38 paco: don't think you can do the redefine in schema 22:19:45 daveo: you have the same issues with refparms not matching a schema held locally 22:19:47 uyalcina has joined #ws-addr 22:20:15 daveo: you could use 'redefine' 22:21:37 paco: schema defines types, but this is about instances 22:22:37 daveo: wanted to express the complexity of using EPR in WSDL in option #5 22:22:49 .. option #6 is for completeness 22:23:06 daveo: option #3 is best 22:23:18 I prefer #3 22:23:33 mnot: preferences between option #3 and #4? 22:24:14 option 3: 10 22:24:27 option 4: 1 22:24:33 s/3: 10/3: 11/ 22:26:56 daveo: you can refer to an endpoint via a static WSDL or dynamic EPR, and we seem to be striving for harminisation 22:28:09 .. we'd like to be able to add SOAP headers into a static WSDL, there isn't much else in an EPR: address, refp, metadata 22:28:20 anish: there is an extensibility point 22:28:47 s/daveo:/dhull:/ 22:29:40 daveo: i'm pro 3^H 1 22:29:48 s/daveo:/dhull:/ 22:32:04 anish: if you have an EPR extension, you also need to think about expressing it in an endpoint in WSDL 22:32:35 rebecca: so the only thing we need to worry about are refps 22:32:58 glen: bangs the "why cant and endpoint be the same as an EPR" drum 22:34:05 andreas: explores the need to replicate the refp to SOAP header echoing 22:35:20 glen: surprised we only describe how to formuate a reply message, not a request 22:37:00 rebecca: worries that EPR in WSDL would make EPRs static 22:37:28 omnes: that's not a risk as the EPR can override any information in the WSDL 22:39:38 daveo: a design point of WSDL is the reuse of bindings, etc, but there seems to be an argument for having them all in one place (inside the EPR metadata section) 22:39:59 s/argument/argument here/ 22:40:17 daveo: why would you want to flatten the WSDL model? 22:40:46 q+ 22:40:53 vikas: why are we putting dynamic information in a WSDL 22:41:10 glen: WSDLs can be minted on a per-customer version 22:41:18 s/version/basis/ 22:41:43 vikas: sees any content inside EPRs being dynamic 22:42:09 daveo: some of the constructs may not be so dynamic, you seem to be arguing against that 22:42:13 vikas: yes 22:43:35 straw poll, again 22:45:26 chad, new poll 22:45:26 new poll 22:45:45 one vote per company? 22:45:56 vote: tibco: 1, 3 22:46:03 chad, question: options for i056 22:46:10 option 1: no EPR 22:46:17 vote: 1 22:46:26 option 2: EPR Aligned 22:46:26 vote: 3 22:46:43 option 3: EPR "Loose" 22:46:51 vote: tibco: 1, 3 22:46:52 vote: 3 22:46:54 vote: 1 22:47:00 vote: becky: 3 22:47:01 vote: 3 22:47:14 vote: option 2, option 1 22:47:19 chad, options 22:47:24 chad, thou art confused 22:47:27 vote: option 1 22:47:28 yes I know. 22:47:33 chad, option 1: no EPR 22:47:41 chad, option 3: EPR "Loose" 22:47:45 chad, options? 22:47:57 chad, option 2: EPR Aligned 22:48:00 chad, options? 22:48:01 vote: 3 22:48:05 vote:1 22:48:06 vote: tibco: 1, 3 22:48:07 vote: 1 22:48:07 vote: 3 22:48:07 vote:becky:3 22:48:08 vote: 2, 1 22:48:08 vote: abstain 22:48:10 vote: 2, 1 22:48:12 vote: 1 22:48:12 vote: 1 22:48:12 vote: 1 22:48:13 vote: 3,1 22:48:16 vote: 1 22:48:20 vote:3,1 22:48:21 vote: 2, 1 22:48:25 bob: 1 22:48:45 vote: bob: 1 22:48:58 chad, count 22:48:59 Question: options for i056 22:48:59 Option 1: no EPR (8) 22:48:59 Option 2: EPR Aligned (3) 22:48:59 Option 3: EPR "Loose" (5) 22:48:59 17 voters: andreas (1) , anish (3) , becky (3) , bob (1) , dorchard (1) , GlenD (1) , hugo (3, 1) , Marsh (2, 1) , mlpeel (1) , Paco (1) , pauld (2, 1) , tibco (1, 3) , TonyR () , TRutt (3) , uyalcina (2, 1) , vikas (1) , yinleng (3, 1) 22:49:02 Round 1: Count of first place rankings. 22:49:04 Round 2: Eliminating candidate 2. 22:49:06 Candidate 1 is elected. 22:49:08 Winner is option 1 - no EPR 22:49:28 RebeccaB has joined #ws-addr 22:49:30 chad, details 22:55:18 anish: unhappy at this decision, not reflecting all the EPR in the WSDL could be short sighted 22:55:53 .. 2 is my prefence, 3 i could live with 22:56:12 who would lie down in the road for 2? 22:56:23 NONE! 22:56:35 who would lie down in the road for 3? 22:56:38 4 22:57:06 rebecca: also unhappy with 1 22:57:40 discussion of how near the middle of the road those thinking about lying down are 22:58:41 glen: explores anish's concerns about pulling an EPR apart 23:01:08 anish: i may have an extension in a MAP, e.g. the contents of an EPR could change the behaviour of an MAP. I could also add new MAPs 23:02:34 hugo: understand why you perfer 2, but the issue for i56 could be resolved by 1 and 3? 23:04:22 marsh: I started thinking like anish, which is why i preferred 2 over 1. Once you consider extensions of extensions, 1 flattens that problem - it's either an extension of WSDL or extension of an EPR 23:04:50 there may be some extensions which only make sense at runtime and don't at design time 23:05:15 marsh: unlikely to get automatic behaviour here, you're going to have to say something about how an extension may work 23:06:57 rebecca: argues for using EPRs as a template 23:07:24 umit: 1 and 2 aren't identical to each other 23:07:38 glen: just in resepct to the destination address 23:07:55 umit: use-case for 3 can be handled by extensibility 23:08:07 mnot: we seem to be heading towards a formal vote 23:09:53 is 2 a point of consensus, who can't live with 2? 23:10:01 glen: i'd object to 2 23:11:22 .. i can't have a generic EPR processor without specific code for when EPR info occurs in WSDL 23:13:02 dhull: 23:13:11 anish: the processing of EPR wrt to populating the MAPs is unchanged as to whether the EPR occurs in WSDL or somewhere else 23:13:39 dhull: what is the motivation for 3, how do you deal with conflicts? 23:13:44 anish: EPR does not specify all the MAPs but it does specify [destination] and [ref params] and possible extensions to MAPs 23:14:25 anish: the only thing that you have to do wrt to extra stuff when the EPR is in WSDL is -- check that the port address and wsa:Address is the same (if both occur) 23:15:28 rebecca: cites multiple protocols to a single endpoint 23:15:56 dhull: how do i interpret the multiple ports 23:16:12 rebecca: if you don't understand the options, ignore them 23:17:33 i'm begining to like davido's option #6 :-) 23:18:06 dhull: implementing multiple ports in the metadata seems almost to work by accident as opposed to explicitly expressing multiple endpoints 23:18:32 discussion heads off into the woods 23:20:41 paco: recursive metadata ... 23:21:19 marsh: as a leading proponent of #2 i'm willing to drop it to get a binary vote 23:22:21 paco: WSDL inside metadata inside an EPR inside WSDL is something we should rule out 23:23:01 marsh: expect comments on this, we should explain why we say nothing 23:23:17 glen: doesn't like 2 architecturaly 23:23:26 +1 to Glen 23:23:31 paco: can live with 2 if we rule out recursion 23:24:48 zakim, who is making smells? 23:24:48 I don't understand your question, pauld. 23:26:04 glen: don't repeat yourself principle serves us well 23:26:10 anish: then vote for 3! 23:27:07 mnot revises option 2 on the board to specify "Semantics of WSDL-related metadata (...) are undefined in such EPRs" 23:27:42 andreas: 2 and 3 seem very complex with caveats which many people will have to understand 23:29:18 dhull: 1 and 2 don't seem antithetical 23:29:20 i agree with andreas. It is too complicated that we can not seem to agree in this room even what these options would mean. 23:30:51 RebeccaB has joined #ws-addr 23:31:26 anish: having the same EPR in multiple places allows another spec to define how to compare them. splitting them up precludes that 23:31:38 marsh: is option 3 still on the table? 23:32:01 hugo: i may object to either 1 or 2 23:33:23 .. we don't prevent people distinguishing between physical and logical address, but 1 and 2 could do this 23:34:03 Formal Vote 23:34:22 s/Formal Vote/ 23:34:26 s/Formal Vote// 23:35:27 mnot: does anyone object to accepting option 2? 23:35:31 yes, 3 23:36:04 i056+i057 23:36:04 option 1: 23:36:04 The [destination] property is taken from the endpoint or port address - 23:36:04 derived address (WSDL 2.0) or the applicable WSDL 1.1 extension (for 23:36:04 SOAP it is taken from soap:address/@location). wsa:ReferenceParameters can be a child element of a wsdl20 endpoint or a wsdl 11 port. 23:36:06 option 2: 23:36:08 a) Allow a wsa:EndpointReference element to be included as a child of 23:36:10 wsdl20:endpoint or wsdl11:port. 23:36:12 b) When a wsa:EndpointReference element is present as a child of a 23:36:14 wsdl20:endpoint/wsdl11:port the usual WS-Addressing/binding rules apply 23:36:16 [destination]=wsa:EndpointReference/wsa:Address. Semantics of WSDL-related metadata (e.g., WSDL namespace metadata, wsdl-related MAPs) are undefined in such EPRs. 23:36:19 c) When there is no wsa:EndpointReference child element, the 23:36:21 [destination] property is taken from the endpoint or port address - 23:36:23 endpoint/@address (WSDL 2.0) or the applicable WSDL 1.1 extension (for 23:36:25 abstain 23:36:25 SOAP it is taken from soap:address/@location). 23:36:27 d) If there is both a wsa:EndpointReference and an endpoint/port address 23:36:29 then they must have the same value. 23:36:31 option 3: 23:36:33 option 2 - d 23:37:48 Formal Vote: Accept Option 2 for i056 and i057 23:38:47 BEA - N 23:38:51 BT - Y 23:39:10 CA -abs 23:39:42 Ericsson - N 23:39:48 Fujitsu - N 23:39:52 Hitachi - N 23:39:55 HP - abs 23:40:00 IBM - Y 23:40:07 IONA - Y 23:40:13 Microsoft - abs 23:40:35 Novell - N 23:40:39 Oracle - Y 23:40:43 SAP - abs 23:40:47 Sonic - N 23:41:13 Tibco - N 23:41:17 W3C - N 23:41:24 WebMethods - abs 23:41:49 No 9, Yes 4, Abstain 5 23:42:26 Formal Vote:Option 1 or 3 for i056 and i057 23:42:33 BEA - 1 23:42:37 BT - 1 23:42:44 CA - abs 23:43:23 Ericsson - 1 23:43:30 Fujitsu - 3 23:43:39 Hitachi - 1 23:43:44 HP - abs 23:43:48 IBM -1 23:43:51 IONA - 3 23:44:01 Microsoft - 1 23:44:07 Novell - 1 23:44:15 Oracle - 3 23:44:18 SAP - 1 23:44:21 Sonic - 1 23:44:32 SONOA - 1 23:44:38 TIBCO - 1 23:44:42 W3C - 3 23:44:48 WebMethods - 1 23:45:16 Option 1 - 12, Option 3 - 4, abstain - 2 23:45:49 -Mark_Peel 23:46:11 any objections to adopting option 1 for i56 and i57 23:46:17 anish: i don't know 23:46:21 -YinLeng 23:46:35 RESOLUTION: i56 and i57 closed by adopting option 1 23:47:48 s/Sonic - N/Sonic - N, SONOA - N/ 23:48:38 Topic: i064 - reprise 23:48:55 http://www.w3.org/2002/ws/addr/wd-issues/#i064 23:49:29 anish: there seems to be other issues for migration, eg defaulting of other MAPs including To 23:50:08 .. this addresses a particular issue Microsoft has, but there may be other issues we should address in this area 23:50:18 marsh: then raise them as separate issues 23:51:20 pauld: mirrors our experience in migration 23:52:47 marsh: for me it's orthogonal if there are other migration issues, this is something I'd like to see adopted, but it doesn't preclude other migration issues being added 23:53:38 anish: maybe a separate migration note, or Primer would be better, but then this in a separate section would be OK if we can add other issues 23:54:14 hugo: would like to see the other migration issues before deciding where it should all go 23:54:22 i'm not suggesting a separate note or primer 23:55:30 marsh: doesn't want to tie this to a bigger boat that might not float 23:57:10 pauld: one other area which will trip people up is the loss of refprops 23:58:05 .. but explaining the reasons behind *why* we made descisions isn't usual in specifications 23:59:43 anish: would accept this if it was a part of a list of each change made, possibly with one or two minor changes