IRC log of ws-addr on 2005-09-28

Timestamps are in UTC.

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