IRC log of ws-addr on 2005-03-01

Timestamps are in UTC.

00:05:54 [pauld]

pauld has joined #ws-addr

14:01:50 [RRSAgent]

RRSAgent has joined #ws-addr

14:01:50 [RRSAgent]

logging to http://www.w3.org/2005/03/01-ws-addr-irc

14:01:56 [mnot]

zakim, this is ws_addrwg

14:01:56 [Zakim]

ok, mnot; that matches WS_AddrWG(TP)9:00AM

14:02:09 [mnot]

Meeting: Web Services Addressing WG Face-to-Face

14:02:12 [mnot]

Chair: Mark Nottingham

14:03:15 [Marsh]

Marsh has joined #ws-addr

14:03:24 [Zakim]

+Bob_Freund

14:04:26 [TonyR]

TonyR has joined #ws-addr

14:04:28 [bob]

zakim, bob is bob_freund

14:04:28 [Zakim]

+bob_freund; got it

14:04:42 [Paco]

Scribe: Paco

14:04:44 [pauld]

pauld has joined #ws-addr

14:04:48 [mnot]

zakim, call QueenMary

14:04:48 [Zakim]

ok, mnot; the call is being made

14:04:50 [Zakim]

+QueenMary

14:04:57 [RebeccaB]

RebeccaB has joined #ws-addr

14:05:09 [mnot]

zakim, call QueenMary/

14:05:09 [Zakim]

I am sorry, mnot; I do not know a number for QueenMary/

14:05:16 [mnot]

zakim, who is on the phone?

14:05:16 [Zakim]

On the phone I see Mark_Peel, bob_freund, QueenMary

14:05:38 [anish]

anish has joined #ws-addr

14:05:55 [umit]

umit has joined #ws-addr

14:06:04 [bob]

zakin, mute me

14:06:14 [bob]

zakim, mute me

14:06:14 [Zakim]

bob_freund should now be muted

14:06:23 [hugo]

Topic: i051

14:06:24 [hugo]

http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0210.html

14:06:30 [Paco]

MarkN: let's pick up isue 51 where we left

14:06:31 [yinleng]

yinleng has joined #ws-addr

14:06:51 [hugo]

Meeting: Web Services Addressing F2F

14:06:55 [hugo]

Chair: MarkN

14:07:56 [dorchard]

dorchard has joined #ws-addr

14:07:57 [dhull]

dhull has joined #ws-addr

14:07:58 [Paco]

Hugo: we discussed mapping of OAPAction and WSA Action

14:08:50 [Paco]

Hugo: proposal is that if SOAPAction (v1.2) is present it must match the value of WSA Action

14:09:32 [Paco]

Hugo: SOAP 1.2 is done deal; SOAP 1.1 is trickier

14:09:56 [cgi-irc]

cgi-irc has joined #ws-addr

14:10:09 [Paco]

SOAP 1.1: there is a third option different from present and absent: ""

14:10:54 [Paco]

Hugo: WS-I BP does not allow empty value

14:11:15 [Paco]

Hugo: I proposed 5 options

14:13:48 [alain]

alain has joined #ws-addr

14:13:53 [Paco]

Hugo: we can align with BP but we'll violate SOAP 1.1

14:14:23 [Paco]

Greg: wasn't BP supposed to clarify SOAP 1.1? I'd rather align with that

14:15:08 [Paco]

Hugo: my option 2 is not acceptable

14:15:18 [Paco]

Hugo: option 3, not allow ""

14:16:59 [Paco]

Umit: in 3, what the required value is?

14:17:06 [Paco]

Hugo: same as wsa Action

14:17:24 [Zakim]

+Prasad_Yendluri

14:17:34 [Paco]

Hugo: Actually, either they match or there is an empty value for SOAPAction

14:18:26 [Paco]

MarkN: Hugo, can you explain the consequences of each option for SOAP 1.1?

14:19:09 [Paco]

Hugo: By BP you always have to specify it; Steve had an idea...

14:19:39 [Paco]

Hugo: either you have a matching value or we define a URI value meaning "empty"

14:20:40 [Paco]

Anish: Had similar discussion with Mark; the URI would mean that wsa action actually provides the value

14:20:59 [Paco]

MarkH: doesn't that violate the aim of SOAPAction?

14:21:31 [dims]

dims has joined #ws-addr

14:21:40 [Paco]

Anish: this cover the case when you don't want to expose the value

14:22:10 [Paco]

Jonathan: this would not work with existing SOAPActino implementations

14:22:58 [Paco]

MarkN: seems people object to semantics in the second case

14:23:29 [jeffm]

jeffm has joined #ws-addr

14:23:40 [Paco]

Glen: are the semantics of both properties actually the same? Since there are so many cases and exceptions

14:23:53 [Paco]

Glen: shouldn't we admit they are different things?

14:24:58 [Paco]

MarkN: we have 7 pending issues; is this one critical?

14:25:22 [umit]

umit has joined #ws-addr

14:25:34 [Paco]

Hugo: SOAP 1.1 says Action describes the intent of the message; SOAP 1.2 is fuzzier

14:25:48 [TomRutt]

TomRutt has joined #ws-addr

14:25:51 [Paco]

Hugo: for SOAP 1.1 they really look like the same thing

14:26:21 [Paco]

Greg: is SOAP action the abstract property or the serialized value of SOAPAction

14:26:53 [Paco]

Greg: the enveloping model means the envelope needs to be able to stand alone

14:27:31 [Paco]

Tom: WSDL tells you what each action needs to be - one could specify different values

14:27:51 [Paco]

Tom: I am starting to agree with Glen

14:29:15 [Paco]

Anish: I'm ok as long as I am not required to specify the http SOAPAction

14:30:21 [Paco]

Anish: how does option 3 works with BP 1.1

14:30:27 [Paco]

Jonathan: it does not

14:30:40 [plh]

plh has joined #ws-addr

14:32:10 [Paco]

Paco: should we decide not to say anything, we may not be really helping

14:32:35 [Paco]

Umit: I disagree, people are going to ask what is the relationsip

14:33:21 [Paco]

Tom: we may want to leave room for profiling

14:33:45 [umit]

i am suggesting we put a recommendation to indicate that they should be the same, but not a MUST

14:33:48 [Paco]

Philippe: we are here to make it work

14:34:04 [Paco]

Tom: but what would be broken?

14:34:43 [Paco]

MarkN: I am surprised no one thought that the BP should change instead of wsa

14:35:00 [swinkler]

swinkler has joined #ws-addr

14:35:10 [Paco]

MarkN: sounds like there are 3 options:

14:35:20 [Paco]

MarkN: Hugo's option 3

14:36:14 [Paco]

keep the status quo

14:36:35 [Paco]

MarkN: second is keep status quo

14:36:54 [Paco]

MarkN: third is change MUST to SHOULD

14:37:46 [Paco]

Greg: are we going to invalidate all existing WSDLs?

14:39:11 [Paco]

MarkH: the binding would tell you what the value is

14:39:32 [Paco]

MarkN: option 4 is the new URI to mean 'empty'

14:39:56 [Paco]

MarkN: there are 2 flavors for #4

14:40:49 [Paco]

Anish: a version of 3 is make no mention of any constraint/recommendation

14:41:21 [Marsh]

zakim, who's on the phone?

14:41:21 [Zakim]

On the phone I see Mark_Peel, bob_freund (muted), QueenMary, Prasad_Yendluri

14:41:34 [bob]

zakim unmute me

14:41:40 [plh]

ack bob

14:43:30 [bob]

+1

14:43:54 [dom]

dom has joined #ws-addr

14:44:21 [Paco]

MarkN: straw poll: 1) 8 in favor, 15 can live with

14:44:33 [dom]

dom has left #ws-addr

14:46:15 [Paco]

Glen: 2 is actually the same as 1, for SOAP 1.1?

14:47:49 [Paco]

Greg: 1 explicitly violates BP 1.1, 2 does not

14:50:24 [Paco]

MarkN: do we understand what 'must be empty" mean?

14:50:51 [Paco]

Hugo: "" is disallowed

14:51:49 [Paco]

Anish: it is not disallow, although is may be weird

14:52:11 [Paco]

MarkN: "" is a relative URI so it defaults to the request URI

14:53:45 [Paco]

MarkN: rewrites #1: contrained the requirement to the header field, not the derived value

14:55:05 [Paco]

Anish: relocating the service changes the derived SOAPAction in the "" case, so you get a mimatch with wsa Action

14:56:05 [timbl]

timbl has joined #ws-addr

14:56:26 [mnot]

Option 2: When issuing a SOAP HTTP Request, the value of the SOAPAction (after "" defaulting) MUST either be equal to the value of the [action] message addressing property, or MUST be empty.

14:56:28 [Paco]

MarkN: should we clarify in #2 that the SOAPAction value compared is the one obtained after defaulting

14:56:49 [Paco]

MarkN: note that now "" is disallowed

14:57:11 [Paco]

MarkN: in option 1

14:57:50 [Paco]

MarkN: voting for option 2) 2 in favor; 12 can live

14:57:57 [cgi-irc]

cgi-irc has joined #ws-addr

14:58:07 [mnot]

Option 1 (revised): When issuing a SOAP HTTP Request, the value of the SOAPAction header field MUST either be equal to the value of the [action] message addressing property, or MUST be empty. ("" disallowed)

14:58:18 [Paco]

MarkN: back to option 1since it changed - posted in IRC

14:58:45 [Paco]

MarkN: vote for #1: 3 in favor; 14 can live

14:59:01 [Paco]

MarkN: does option 3 make sense?

14:59:17 [Paco]

Umit: yes, if you remove the 'must be empty'

15:00:23 [Paco]

MarkN: removes "must be empty", other must becomes a should in option 3

15:01:15 [Paco]

MarkN: vote on #3: 4 in favor, 19 can live

15:02:05 [Paco]

MarkN: option 4: 0 in favor, 20 can live

15:03:04 [Paco]

MarkN: option 5, 7 in favor, 18 can live with

15:03:17 [Zakim]

+??P7

15:05:08 [Paco]

MarkN: negative votes? for #4, who could not live with #4?

15:05:19 [Paco]

Paco: can't live and no are different

15:06:47 [Paco]

MarkN: taking out 4, nobody expressed preference for it; seems like it is either 3 or 5

15:08:31 [Paco]

MarkN: voting 3 or 5: 17 for 3; 3 for #5; abstentions we have missing votes, but clear preference for #3

15:09:24 [Paco]

MarkN: summarizing: we agreed ot ad dfeature, properties and took Hugo's part 3 out

15:09:36 [Paco]

MarkN: we just replaced that by option #3 above

15:10:19 [Paco]

MichaelE: we need to give instructions to the editors about removing SOAP stuff from the core

15:11:05 [Paco]

Hugo: part of issue 51 may be related ot Mark Baker's issue

15:11:38 [MSEder]

MSEder has joined #ws-addr

15:11:53 [Paco]

MarkN: I spoke to him, seems there is no SOAP destination property that creates a conflict

15:12:23 [Paco]

MarkN: it may come up again when we talk about logical addresses

15:13:09 [Paco]

MarkN: can we close issue 51 with the proposal as described?

15:14:20 [mnot]

Option 3 as accepted: When issuing a SOAP HTTP Request, the value of the SOAPAction (after "" defaulting) SHOULD be equal to the value of the [action] message addressing property.

15:14:46 [Zakim]

-??P7

15:15:00 [Paco]

MarkN: we close issue 51, moving on to issue 7; Hugo had an action

15:15:10 [Paco]

Hugo: think so

15:15:14 [Zakim]

+ +44.191.243.aaaa

15:15:15 [mnot]

Topic: Issue 007

15:15:27 [MSEder]

Add to the core document some basic guidance regarding how to handle this issue if the what Addressing is bound to has an action.

15:15:30 [hugo]

http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0186.html

15:15:39 [hugo]

http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0187.html

15:15:56 [Paco]

Hugo: proposal had a bug, sent amendment, check 2nd url

15:16:54 [Paco]

Hugo: my proposal talks about sending, receiving messages, not intermediaries

15:17:53 [Paco]

Hugo: spec only talks about to and ref. params, not other properties; does not talk about receiving messages

15:19:12 [Paco]

Hugo: core spec is missing infoset serialization for ref. params in message

15:20:05 [Paco]

Hugo: and put this in the core

15:20:39 [Paco]

Hugo: when receiving message, do inverse - properties take values from serialized infoset

15:21:16 [Zakim]

-Prasad_Yendluri

15:21:42 [Zakim]

-Mark_Peel

15:21:53 [Paco]

Glen: we should alter the syntax of wsa:type now that we don't have ref. properties

15:22:43 [Zakim]

- +44.191.243.aaaa

15:23:02 [Paco]

Hugo: I proposed 3 rules but there is a problem with #1; intermediaries would then have to forward all headers

15:23:08 [Paco]

Hugo: not remove them

15:23:19 [mnot]

Modified Proposal: http://www.w3.org/mid/20050224134944.GK16108@w3.org

15:24:33 [Paco]

Glen: we can solve it saying that it is one's chioce whether to forward properties

15:27:13 [Paco]

Anish: if ref. param is targeted at intermediary it should be removed

15:28:28 [Paco]

Anish: abstract properties can be populated before or after soap headers are processed

15:28:29 [Paco]

Glen

15:28:50 [Paco]

Glen: the result of the processing is precisely populating those properties

15:29:14 [Paco]

Geln: intermediary processing model is unclear

15:30:36 [Paco]

Glen intermediary can decide what to do; header is in abstract bag and available to be sent again or not

15:31:17 [Paco]

MarkH: get rid of point 2 in the proposal

15:32:15 [Paco]

MarkH: let the intermediary do its SOAP processing , what else is needed?

15:32:30 [Paco]

Glen: that is why we put the wsa:type property in the first place

15:32:56 [mnot]

zakim, who is on the phone?

15:32:56 [Zakim]

On the phone I see bob_freund, QueenMary

15:34:09 [Paco]

Paco: we sould not go on defining how people use the type attribute, thatis application specific

15:35:05 [Paco]

Mark: add 'targeted at the node' in point 2

15:35:11 [Paco]

Glen: that is implied

15:35:18 [Paco]

Umit: no, it is not

15:37:35 [Paco]

Paco: minter of the EPR knows processing model of intermediaries, intermediaries need not be aware of anything else

15:37:36 [timbl]

timbl has joined #ws-addr

15:37:58 [Paco]

Glen: intermediary will see wsa:type attribute and needs to know what to do

15:38:50 [Paco]

MarkN: break at 10:40, back at 11

15:39:18 [Zakim]

-bob_freund

16:00:37 [Zakim]

+bob_freund

16:01:24 [hugo]

i007 new proposal for discussion: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0002.html

16:01:50 [pauld]

pauld has joined #ws-addr

16:02:25 [TomRutt]

TomRutt has left #ws-addr

16:02:59 [TomRutt]

TomRutt has joined #ws-addr

16:04:13 [Paco]

MarkN: Hugo sent an updated proposal

16:04:55 [Paco]

Hugo: updated the syntax of wsa:type attribute

16:05:07 [Paco]

Hugo: did not change sending the message part

16:06:15 [Paco]

Hugo: populating abstract properties is not an issue really: implementation make choices of whether to expose the properties or not

16:06:40 [Paco]

Hugo: so implementations can ignore #2

16:07:09 [Paco]

Glen: the issue is when a second spec depends on abstract properties, and needs access to the right values

16:08:26 [Paco]

Hugo: in point 2, wsa:type enables to to populate ref. param values

16:08:56 [Paco]

Hugo: in 3, just do standard SOAP processing on headers

16:09:07 [Paco]

Glen: disagrees

16:09:37 [Paco]

Glen: it is unnecessary, unless you mean process ref. params as normal

16:10:01 [Paco]

Glen: but you could decide not to... so remove #3

16:10:44 [Paco]

MarkH: this looks like an extension of the SOAP binding, not a straight application of the SOAP proc. model

16:11:10 [umit]

umit has joined #ws-addr

16:11:23 [anish]

q+ to ask a question about was:type

16:11:30 [Paco]

Glen: when there are ref. params then the base model is not enough

16:13:20 [Paco]

MarkH: SOAP proce. model implies thatthe processing can be derived from the headers themselves

16:14:00 [Paco]

Hugo: difference is really stylistic

16:15:07 [Paco]

MarkH: need to write wsa as an active intermediary - which is why I said it is at the binding

16:15:25 [Paco]

Hugo: question is what triggers all those rules

16:16:07 [Paco]

Glen: is Action targeted at intermediaries as well?

16:16:33 [Paco]

MarkH: we haven't discussed this at all

16:17:05 [Paco]

Glen: it is ok to say that if you are wsa compliant this is hwat you do

16:18:15 [Paco]

and if we end up saying that wsa action is always targeted at internediaries then we can say that is what triggers processing

16:20:06 [anish]

http://ezine.nitroexpress.com/200412/bigcat.wmv

16:21:02 [Paco]

Anish: do we say anythign about what wsa-ignorant SOAP modules do when a header has wsa:type

16:21:12 [Paco]

Glen: no we don't

16:21:56 [Paco]

MarkN: this was decided when closing issue 8; we chose not to require people to understand

16:23:16 [Paco]

Glen: replace "not in the general case" for "do not necessarily"

16:23:43 [Paco]

Jonathan: is there an implication that all ref.ps make it to this level to be extracted?

16:23:59 [Paco]

Hugo: we should say "targeted at the node" at #2

16:25:39 [Paco]

Jonathan: why are we doing this?

16:25:57 [Paco]

Paco: what are the interop consequences, I think none.

16:26:16 [rsalz]

rsalz has joined #ws-addr

16:26:21 [vinoski]

vinoski has joined #ws-addr

16:27:18 [Paco]

Glen: there are implications if other specs rely on wsa

16:27:30 [Paco]

Paco: this is implementation, not visible behavior on the wire

16:27:43 [Paco]

Greg: it is architecture, no interop consequences

16:28:46 [mlpeel]

mlpeel has joined #ws-addr

16:28:53 [Paco]

Glen: I want to be able to write code that accesses and refers to those properties so we need to provide access to them

16:29:16 [Zakim]

+Mark_Peel

16:29:58 [Paco]

Hugo: allows one to be very concrete about what the properties are when you receive them

16:30:22 [Paco]

Jonathan: we should not do it

16:30:38 [Paco]

Glen: it is debatable if this has interop consequences

16:31:23 [dorchard]

dorchard has joined #ws-addr

16:31:29 [Paco]

MarkN: Anish, Hugo, Glen, Mark are you ok with the modifications proposed here?

16:36:59 [Paco]

Jonathan: I support the proposal is we strike 4.2

16:37:31 [Paco]

MarkH: there is an issue of whether in 4.2 the property is actually the same as in 3 (when sending the message)

16:37:47 [Paco]

MarkN: Anything else we need to cnsider?

16:37:54 [Paco]

MarkH: yes, targeting?

16:38:12 [Paco]

Jonathan: since we don;t have a proposal that will not happen today.

16:38:58 [Paco]

Hugo: I won't object if we decide to strike 4.2 even if there are reasons to do it

16:40:17 [Paco]

MarkN: straw poll about removing 4.2 from proposal

16:40:35 [Paco]

MarkH: this makes this property a sender's only property

16:40:44 [dorchard]

darn, I'm missing something here...

16:40:50 [Paco]

Anish: you can tell what params survived

16:41:24 [Paco]

Jonathan: you may not come ou twith the same properties that you started because intermediaries may consume them

16:42:21 [Paco]

MarkN: prefer to remove 4.2: 10; prefer to keep: 3; abstain: 8

16:42:58 [Paco]

MarkN: actualy 9 abstentions (one on the phone); clear desire to remove

16:43:48 [Paco]

MarkN: targeting headers - we already can target ref ps, do we provide guidance to targte the other headers?

16:44:11 [Paco]

Glen: I sent a proposal: can add attribute on the EPR to indicate where to target headers

16:44:45 [Paco]

Jonathan: I thought we decided not to add mechanisms to target EPRs, but we don;t preclude ref. ps from being targeted

16:45:19 [Paco]

MarkH: if you process Action do you need to reinserted

16:45:55 [Paco]

MarkN: spec says the aim to target end-to-end

16:46:17 [Paco]

MarkH: not just the EPR but all MAP

16:46:57 [Paco]

MarkH: we don;t say anything and this means ultimate receiver; we may prefer to explicitly allow targeting

16:47:22 [Paco]

Anish: othe option is target to next and relay=true

16:47:43 [Paco]

Anish: in that case the semantics is to reinsert

16:48:24 [Paco]

Glen: we should allow multiple To headers

16:48:49 [Paco]

Glen: I don't want to define message path but I want to allow routing on top of wsa

16:49:15 [Paco]

MarkH: you target mail to ultimate destination

16:50:06 [Paco]

MarkN: 3 options: target to ultimate receiver; 2 provide mechanism to target to others;

16:50:23 [Paco]

MarkN: target to ultimate r but allow change sin the future;

16:50:56 [Paco]

Anish: 4 is next+relay: if you understand and process you reinsert

16:51:54 [Paco]

Jonathan: 3 could be that the epr has an indicatio to target to other nodes

16:53:00 [Paco]

MarkN: 3 is like 2 but we don't do the job

16:53:21 [Paco]

MarkN: got rid of option 1; renumber accordingly

16:54:05 [Paco]

MarkH: difference between 2 and 3 (new #s) is that in 3 each intermediary by defaults get the headers; not in 2

16:54:23 [Paco]

Dave): you support 3 if you like routing

16:55:02 [Paco]

Glen: 3 does not support source routing

16:55:51 [Paco]

Anish: how does 3 works for SOAP 1.1

16:56:10 [Paco]

MarkH: there is still the problem of understanding but not processing

16:57:12 [Paco]

MarkN: no difference in 1 and 2 for 1.1 and 1.2

16:58:19 [Zakim]

+??P0

16:58:24 [Paco]

MarkN: we need wsa:To mustUnderstadn=

16:58:34 [Paco]

MarkN true

16:58:59 [Paco]

MarkN: in 1.1 you ave actor=next, mU=true

16:59:28 [Paco]

DaveO: if you have an intermediary and you want the message to relay you need ot upgrade your intermediary

16:59:54 [Paco]

JeffM: if you don;t want to go to SOAP 1.2 you need to do something else to make 3 work

17:01:41 [Paco]

MarkN: new option 4 is to default to #2 in case of soap 1.1; in option 3 we specify forwarding semantics and mU=true

17:02:50 [Paco]

Hugo: concerned with having different approaches for different protocols

17:05:44 [Paco]

MarkN: poll: option 1, 0 in favor, 3 can live; #2 13 in favor, 22; #3 1 in favor, 13 can live with

17:06:47 [Paco]

MarkN #4, 3 in favor, 17 can live with.

17:07:50 [Paco]

MarkN: choice is betwee 2 and 4; vote again: 13 for #2, 4 for #4, 5 abstain

17:08:23 [Paco]

MarkN: seems everyone can live with #2

17:08:35 [Paco]

MarkN: that takes care of the targeting

17:09:04 [TonyR]

TonyR has joined #ws-addr

17:09:29 [Paco]

MarkN: does Hugo's edited proposal plus the targting approach just accepted constitute an acceptable resolution of the issue?

17:09:38 [Paco]

Anish: do we need point 5 anymore?

17:10:07 [Paco]

Glen: there is no harm in leaving it there

17:10:25 [Paco]

Anish: does this say anythig beyond soap processing model

17:10:33 [Paco]

Glen: yes

17:11:45 [Paco]

Anish: soap processing defines what is processed regardless of any extensions; rules are clear for intermediaries

17:12:30 [Paco]

Glen: just because you populate the abstract model you don't process or forward all those headers

17:12:54 [Paco]

Jonathan: how important is this?

17:13:11 [Paco]

Anish: I am ok if Glen really wants it

17:13:31 [Paco]

MarkN: so we have a proposal to close issue 7; any objections?

17:13:54 [Paco]

Glen: yes, 4.2 should not have been removed

17:14:28 [Paco]

Glen: record I am not happy - done

17:16:58 [Paco]

MarkN: talk for a few minutes about issue 22 before lunch

17:17:39 [Paco]

MarkN: some people believe we needed a module; others that it is necessary to describe in detail the behavior implied by wsa

17:17:59 [Paco]

MarkN: Is there another aspect that would need to be addressed?

17:18:28 [Paco]

Greg: I want to understand how things map to WSDL, SOAP, transport

17:18:36 [Zakim]

+Pete_Wenzel

17:18:48 [Pete]

Pete has joined #ws-addr

17:18:59 [Paco]

MarkN: we need to know what are the requirements on MEPs and use patterns

17:19:31 [Paco]

Anish: do we need to address DaveO's proposal to close thi issue?

17:19:34 [pauld_]

pauld_ has joined #ws-addr

17:19:58 [dhull_]

dhull_ has joined #ws-addr

17:20:27 [Paco]

Jonathan: we need to decide if there is anything that we can do to our documents to close this issue

17:21:13 [Paco]

MarkN: goes over remaining issues in the agenda that are posisble blocks ot last call

17:22:02 [Paco]

MarkN: maybe we can have a last call next or following week

17:22:23 [Paco]

MarkN: if MarkH can incorporate all issues by then; review and vote

17:23:57 [Zakim]

-bob_freund

17:24:00 [Zakim]

-Mark_Peel

17:24:02 [Paco]

MarkN: break for lunch, back at 1:20

17:25:07 [Zakim]

-Pete_Wenzel

17:26:11 [MSEder]

MSEder has left #ws-addr

17:29:26 [dhull_]

dhull_ has joined #ws-addr

17:36:40 [bob_]

bob_ has joined #ws-addr

17:40:02 [Zakim]

-??P0

17:49:40 [pauld_]

pauld_ has joined #ws-addr

18:18:35 [timbl]

timbl has joined #ws-addr

18:19:15 [timbl]

timbl has joined #ws-addr

18:23:41 [swinkler]

swinkler has joined #ws-addr

18:26:45 [RebeccaB]

RebeccaB has joined #ws-addr

18:27:14 [Pete]

Pete has joined #ws-addr

18:27:51 [Zakim]

+Pete_Wenzel

18:29:50 [Zakim]

+Mark_Peel

18:29:53 [mnot]

mnot has joined #ws-addr

18:29:57 [mnot]

zakim, who is here?

18:29:57 [Zakim]

On the phone I see QueenMary, Pete_Wenzel, Mark_Peel

18:29:58 [Zakim]

On IRC I see mnot, Pete, RebeccaB, swinkler, timbl, bob_, dorchard, mlpeel, rsalz, plh, jeffm, anish, RRSAgent, Zakim, hugo

18:29:59 [dhull]

dhull has joined #ws-addr

18:31:20 [timbl]

timbl has left #ws-addr

18:32:58 [pauld_]

pauld_ has joined #ws-addr

18:33:40 [rsalz]

scribe: rsalz

18:33:48 [mnot]

Topic: i022

18:34:13 [Zakim]

+bob_freund

18:34:23 [umit]

umit has joined #ws-addr

18:34:24 [rsalz]

mnot: fait accompli we're going to describe a soap module.

18:35:04 [rsalz]

mnot: okay to leave it for the editors?

18:35:11 [GregT]

GregT has joined #ws-addr

18:35:36 [rsalz]

hugo: yes, but we should give a URI to the soap1.1 extension

18:35:48 [vinoski]

vinoski has joined #ws-addr

18:37:50 [TRutt_]

TRutt_ has joined #ws-addr

18:39:22 [rsalz]

mnot: do anything for soap1.1? if so, re-use the 1.2 uri?

18:39:42 [rsalz]

hugo: don't re-use uri

18:40:02 [rsalz]

mhadley: does that mean we define them in separate sections, duplicate the wording, etc?

18:40:09 [rsalz]

hugo: we're going to have to separate them anyway

18:40:39 [rsalz]

dorchard: document default behavior and separate them?

18:41:28 [rsalz]

mnot: anyone other than hugo feel need for two uri's?

18:42:06 [rsalz]

hugo: he can live with just one uri

18:42:26 [rsalz]

glen: single uri has two sets of semantics.

18:42:44 [rsalz]

mnot: anyone object to this as partial resolution to i022?

18:42:57 [rsalz]

nobody objects, mnot will send email to list with revised proposal

18:44:49 [rsalz]

topic: asynchronous task force

18:45:15 [hugo]

s/topic/Topic/

18:46:25 [rsalz]

glen: will summarize TF and enumerate the questions they came up with.

18:47:11 [rsalz]

glen: focus of discussion was on use cases; how do people want to use this spec?

18:47:37 [rsalz]

For example, WSDL has a one-way MEP, but no way to bind that to SOAP.

18:48:27 [rsalz]

Using ReplyTo could be a one-way. How can you look at WSDL and see that that's supported?

18:48:47 [rsalz]

s/For/glen: For/

18:48:54 [rsalz]

s/Using/glen: Using/

18:50:06 [PaulKnight]

PaulKnight has joined #ws-addr

18:50:14 [rsalz]

glen: Much of this stuff really "belongs" in WSDL or SOAP group, although we can help out. That is, it won't hold us up (not our job), but the community needs this done.

18:50:27 [PaulKnight]

PaulKnight has left #ws-addr

18:51:25 [rsalz]

See http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0001.html for list of questions.

18:52:00 [Paco]

Paco has joined #ws-addr

19:04:15 [rsalz]

glen: This discussion will continue in WSDL WG; some chat with SOAP WG, too.

19:04:51 [rsalz]

glen: There doesn't seem to be any work for WS-A to do in order to enable this; burden seems to be on the other WG's.

19:05:30 [rsalz]

Anish: Could define multiple bindings (HTTP, SMTP/response) which has combinatorial issues.

19:06:02 [rsalz]

Glen: If you define a "floating" (composable, run-time), that id's markers in the message for transport.

19:08:30 [rsalz]

Identified a question: can you express it in WSDL 1.1 (does it have enough/the right) extensibility points?

19:10:22 [GregT]

Anish - we have decisions wrt. who should do what... there are things that XMLP could do.. or WSD can do.. or things that WSA can do. Question is... if we find out that there are things that can be done wrt. SOAP or WSDL 1.1, is this the working group that would do it?

19:10:46 [GregT]

Mark - it's just as much in scope of XMLP.... We are kind of drifiting into this discussion.

19:11:02 [GregT]

Paco - Anish's point is specific to WSDL 1.1

19:11:16 [GregT]

Mark - was there any discussion in the TF about parity, and equivalent discussion?

19:11:28 [GregT]

Glen - there was concern at the beginning, but no discussion on this

19:11:32 [noah]

noah has joined #ws-addr

19:11:41 [GregT]

Anish - WSA is the only group that has SOAP 1.1 and WSDL 1.1 in itls charter...

19:12:02 [pauld_]

pauld_ has joined #ws-addr

19:12:16 [GregT]

DavidO - his point is that WSA, wrt WSDL 1.1,is in the scope of this group... it's not to do the errata.

19:12:37 [GregT]

Anish - I'm now saying it's in the charter... if we really wanted something wrt. WSDL 1.1., the best chance is to have this group to do something about it

19:12:59 [GregT]

Jonathon - I don't think I agree w/that.

19:13:06 [GregT]

Glen - I would like to see the TF to remain and act as a facitlator to this discussion

19:13:50 [rsalz]

TF already has members of XMLP, WSDL, WS-A

19:14:39 [rsalz]

glen: More people than just the TF members have opinions.

19:14:50 [rsalz]

glen: Want non-TF folks in each WG to get involved.

19:16:09 [rsalz]

hugo: There's nothing on critical path for last call; some annoying things (e.g., one-way binding) that will come up during CR stage.

19:16:27 [rsalz]

Nobody disagrees.

19:18:06 [rsalz]

Dicussion of closing i022 now; is leaving i021 open enough for now?

19:19:52 [rsalz]

Discussion of considering another deliverable, a collection of usage scenarios and how to use WS-A to achieve them.

19:20:11 [rsalz]

A set of recipes, similar to dorchard's examples.

19:22:45 [rsalz]

dorchard: If there were a WS architecture group, they could own the primer, but it seems that WS-A should own it.

19:23:26 [rsalz]

s/recipes/, or a primer/

19:23:48 [rsalz]

s/, or a primer/recipes, or a primer/

19:26:08 [rsalz]

Is it a non-normative primer, or a document with MUSTs, etc., that say how something *is* to be done

19:29:36 [rsalz]

mnot: Straw poll -- Who thinks that delivering something like this (details TBD) is important for the success of WS-Addressing?

19:30:22 [dorchard]

dorchard has joined #ws-addr

19:30:58 [rsalz]

Results are 21 yes, 2 no, 1 abstain

19:33:08 [rsalz]

mnot: Straw poll -- is having something like this critical for exiting CR?

19:33:30 [rsalz]

glen and jef clarify the question to explain that this is part of the QA/interop testing

19:33:40 [rsalz]

s/jef/jeffm/

19:36:12 [rsalz]

mnot: Is "this work" important enough to hold up at least one document from exiting CR?

19:37:00 [rsalz]

Results are 17 yes, 4 no, 2 abstain

19:38:28 [Zakim]

-Pete_Wenzel

19:38:48 [rsalz]

dorchard: Test suites and scenarios are targeted to different audiences

19:41:02 [rsalz]

mnot: A WG Note is the next level of document type and seems appropriate for "this work". A WG Note isn't by default part of the patent policy

19:42:07 [rsalz]

Would have to resolve patent policy issues if we go this way>

19:42:23 [rsalz]

s/>//

19:42:48 [rsalz]

mnot: An official recommendation from the WG would probably require a charter change.

19:44:54 [cgi-irc]

cgi-irc has joined #ws-addr

19:47:06 [rsalz]

jeffm: want scope of new doc resolved before going to last call

19:47:19 [rsalz]

phillipe: want scope resolved before exiting last call

19:48:42 [rsalz]

mnot: with my chairman hat on, i want the async-tf to continue

19:49:21 [rsalz]

glen: will coordinate the work, but not be decision-maker. izzat cool with all?

19:50:53 [rsalz]

paco points out that dependency on wsdl and xmlp is important

19:51:22 [rsalz]

mnot and glen point out that we have to decide if that's important to us before we enter CR

19:53:41 [yinleng]

yinleng has joined #ws-addr

19:54:30 [rsalz]

mnot: issue i022 is a poor proxy for the dependency concerns. can we close i022 with the module proposal? no dissent, i022 closed.

19:55:00 [rsalz]

Topic: issue i004

19:55:40 [mlpeel]

mlpeel has joined #ws-addr

19:59:53 [pauld]

http://dictionary.reference.com/search?q=entropy

19:59:55 [rsalz]

hugo: Took Gudge's text, Paco's amendment, current text and wrote a new security considerations proposal.

20:00:45 [rsalz]

dhull: question about where the trust relationship holds?

20:03:39 [rsalz]

Added revised wording from jmarsh about message-id and need for other data to address reply issues

20:04:49 [rsalz]

paco: if epr has a replyto sending to a third place, make sure that you can trust the info to send to it

20:11:05 [rsalz]

more discussion about trust; details not captured as scribe was involved. :)

20:33:35 [rsalz]

<<break>>

20:33:53 [rsalz]

s@<break>@break/@

20:34:36 [rsalz]

dhull: subscription request use-case as another example, particularly where determining trust is determined very late in the game.

20:36:02 [TonyR]

TonyR has joined #ws-addr

20:38:22 [rsalz]

Much group wordsmithing of the security considerations proposal.

20:40:53 [rsalz]

dicussion of hugo's proposal for the SOAP binding security considerations text

20:57:58 [kyley]

kyley has joined #ws-addr

20:58:39 [rsalz]

mhadley wants to see a concrete example of signed/secured EPR

20:59:06 [rsalz]

dorchard says that wouldn't necessarily force us to re-start LC

20:59:42 [rsalz]

mnot: w3team agrees this is a feasible LC call issue; mhadley agrees to do so at that time

21:00:57 [rsalz]

mnot: formal vote: accept proposed text to close issue i004

21:01:04 [Zakim]

-bob_freund

21:03:21 [rsalz]

results 12 yes 2 no 4 abstain

21:04:08 [rsalz]

mnot: issue i004 is closed

21:06:09 [rsalz]

mnot: less than an hour left; issues to address i049 i050 i052 i020. will do status-check at 5pm

21:07:00 [rsalz]

Topic: i049, default default action uri for fault messages

21:07:19 [rsalz]

issue and proposal at http://w3.org/2002/ws/addr/wd-issues/#i049

21:09:09 [rsalz]

mnot reminds jmarsh that WG polled and gave mhadley AI to write his proposal (#3 at url above)

21:10:30 [Zakim]

+bob_freund

21:10:30 [rsalz]

paco and jmarsh discuss mhadley vs jmarsh proposal

21:14:15 [rsalz]

mnot: straw poll of three options: mhadley, jmarsh (remove the "messaging" URI and text from mhadley), or abstain.

21:16:11 [rsalz]

both 11, just-faults 6, abstain 5

21:16:53 [anish]

anish has joined #ws-addr

21:17:24 [rsalz]

mnot: straw poll do both or do nothing

21:18:27 [rsalz]

results do both 9 do nothing 7 abstain 8

21:20:50 [rsalz]

mnot: formal vote close i049 by accepting mhadley's proposal

21:23:42 [rsalz]

results 6 yes 7 no 5 abstain

21:24:42 [rsalz]

decision: issue i049 closed with no change.

21:25:29 [rsalz]

Topic: issue i050; see http://w3.org/2002/ws/addr/wd-issues/#i050

21:26:45 [rsalz]

hugo: Walked through his proposal; see http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0101.html

21:29:57 [rsalz]

jmarsh: propose amendment "if faultto is absent, send to replyto if present"

21:33:17 [Paco]

Paco has joined #ws-addr

21:33:30 [rsalz]

umit raises issue of WSDL 2.0 rules for faults and MEPs

21:34:35 [rsalz]

dhull: don't specify too much and thereby preclude bindings

21:36:58 [rsalz]

paco: keep replyto mandatory. faults are unexpected, which is justfication for asymmetry of handling.

21:38:54 [mnot]

mnot has joined #ws-addr

21:41:52 [rsalz]

seem to have consensus to accept jmarsh's amendment

21:43:45 [rsalz]

hugo: for classic http-based MEP, replyto isn't needed.

21:44:37 [dims]

dims has joined #ws-addr

21:45:45 [rsalz]

paco says there are two issues: clarification (he thinks it's needed), and asymmetry (he thinks it's fine)

21:47:04 [rsalz]

mnot: straw poll in favor of #3 ? 12 yes, 8 no 1 abstain

21:49:35 [rsalz]

ACTION: jmarsh to propose concrete text for proposal 3 to close i049

21:50:02 [rsalz]

Topic: i052, what is a logical address?

21:50:18 [rsalz]

See http://w3.org/2002/ws/addr/wd-issues/#i052

21:50:42 [pauld]

i blogged on this: http://blog.whatfettle.com/archives/000244.html

21:52:09 [rsalz]

paco: has alternative proposal to remove the second proposal

21:52:41 [rsalz]

umit: agree with paco. avoid dangerous waters

21:53:37 [rsalz]

anish: motivation was confusion (for non-wg members) about difference between logical and network address

21:54:29 [rsalz]

anish: i could be okay with paco's proposal, but prefer my clarification of the current intent

21:56:08 [rsalz]

paco: it's just a uri; what value do we add by the description?

21:56:44 [rsalz]

anish: previous versions of the spec say it *was* dereferencable; this makes it clear that it's not (now)

21:58:43 [rsalz]

dorchard: we have a thing called an address, but we're avoiding saying what it is

21:59:24 [rsalz]

mnot: straw poll anish's proposal, paco's proposal, or abstain

22:00:46 [Zakim]

-bob_freund

22:01:41 [rsalz]

results anish 4 paco 11 abstain 7 (includes neither one is acceptable)

22:02:23 [rsalz]

closed issue i052

22:02:48 [rsalz]

ACTION: mhadley recorded text of paco's proposal

22:03:26 [rsalz]

s/recorded/to make sure that he recorded/

22:03:59 [dims|away]

dims|away has joined #ws-addr

22:05:25 [bob_]

bob_ has left #ws-addr

22:06:42 [dims]

dims has joined #ws-addr

22:07:38 [Zakim]

-Mark_Peel

22:10:12 [umit]

umit has left #ws-addr

22:10:12 [Zakim]

-QueenMary

22:10:13 [Zakim]

WS_AddrWG(TP)9:00AM has ended

22:10:14 [Zakim]

Attendees were Mark_Peel, Bob_Freund, QueenMary, Prasad_Yendluri, +44.191.243.aaaa, Pete_Wenzel

22:11:06 [yinleng]

yinleng has left #ws-addr

22:19:01 [dhull]

dhull has joined #ws-addr

22:21:30 [mnot]

rrsagent, generate logs

22:21:30 [RRSAgent]

I'm logging. I don't understand 'generate logs', mnot. Try /msg RRSAgent help

22:21:36 [mnot]

rrsagent, make logs

22:21:36 [RRSAgent]

I'm logging. I don't understand 'make logs', mnot. Try /msg RRSAgent help

22:21:42 [mnot]

rrsagent, help

22:21:50 [mnot]

rrsagent, make logs

22:21:50 [RRSAgent]

I'm logging. I don't understand 'make logs', mnot. Try /msg RRSAgent help

22:22:24 [mnot]

zakim, generate minutes

22:22:24 [Zakim]

I don't understand 'generate minutes', mnot

22:22:33 [mnot]

rrsagent, generate minutes

22:22:33 [RRSAgent]

I have made the request to generate http://www.w3.org/2005/03/01-ws-addr-minutes mnot

22:23:37 [mnot]

rrsagent, make logs world-visible

22:23:44 [mnot]

rrsagent, pointer

22:23:44 [RRSAgent]

See http://www.w3.org/2005/03/01-ws-addr-irc#T22-23-44

22:23:51 [mnot]

rrsagent, generate logs

22:23:51 [RRSAgent]

I'm logging. I don't understand 'generate logs', mnot. Try /msg RRSAgent help

22:23:58 [mnot]

rrsagent, generate minutes

22:23:58 [RRSAgent]

I have made the request to generate http://www.w3.org/2005/03/01-ws-addr-minutes mnot

22:50:27 [pauld_]

pauld_ has joined #ws-addr

22:51:58 [pauld__]

pauld__ has joined #ws-addr

23:14:10 [pauld__]

pauld__ has joined #ws-addr