IRC log of ws-addr on 2005-07-18

Timestamps are in UTC.

12:57:06 [RRSAgent]
RRSAgent has joined #ws-addr
12:57:06 [RRSAgent]
logging to http://www.w3.org/2005/07/18-ws-addr-irc
12:57:13 [Zakim]
Zakim has joined #ws-addr
12:57:25 [Marsh]
Zakim, list conferences
12:57:25 [Zakim]
I see MM_DDWG()9:00AM, Team_Comm(Offices)8:00AM active
12:57:26 [Zakim]
also scheduled at this time are Team_SysWeb()8:00AM, SW_Plan()9:00AM, WS_(F2F)9:00AM
12:57:40 [Marsh]
Zakim, this will be WS_(F2F)
12:57:40 [Zakim]
ok, Marsh; I see WS_(F2F)9:00AM scheduled to start in 3 minutes
12:58:26 [GlenD]
GlenD has joined #ws-addr
12:58:35 [GlenD]
dialing in in a few mins
12:58:38 [pauld]
pauld has joined #ws-addr
13:00:32 [TonyR]
TonyR has joined #ws-addr
13:01:12 [Zakim]
WS_(F2F)9:00AM has now started
13:01:19 [Zakim]
+ +1.781.280.aaaa
13:01:21 [prasad]
prasad has joined #ws-addr
13:01:35 [GlenD]
code is WSF2F
13:01:50 [Zakim]
+Prasad_Yendluri
13:01:53 [Zakim]
- +1.781.280.aaaa
13:01:55 [Zakim]
+ +1.781.280.aaaa
13:02:15 [pauld]
pauld has changed the topic to: Web Services Addressing F2F, Progress Software, Bedford MA: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jul/0112
13:02:18 [Zakim]
+ +44.191.243.aabb
13:02:33 [Zakim]
WS_(F2F)9:00AM has been moved to #addr by mnot
13:02:41 [pauld]
who is in blighty?
13:03:17 [RebeccaB]
RebeccaB has joined #ws-addr
13:03:17 [mnot]
mnot has joined #ws-addr
13:03:22 [TRutt]
TRutt has joined #ws-addr
13:03:22 [dhull]
dhull has joined #ws-addr
13:03:23 [pauld]
zakim, aabb is probably mlpeel
13:03:23 [Zakim]
sorry, pauld, I do not understand your question
13:03:27 [GlenD]
zakim, this is ws
13:03:27 [Zakim]
GlenD, WS_(F2F)9:00AM is already associated with an irc channel; use 'move ws to here' if you mean to reassociate the channel
13:03:33 [GlenD]
zakim, move ws to here
13:03:35 [Zakim]
ok, GlenD; that matches WS_(F2F)9:00AM
13:03:35 [pauld]
zakim, aabb is mlpeel
13:03:35 [mnot]
zakim, move ws to here
13:03:37 [Zakim]
+mlpeel; got it
13:03:39 [Zakim]
mnot, this was already WS_(F2F)9:00AM
13:03:43 [Zakim]
ok, mnot; that matches WS_(F2F)9:00AM
13:04:06 [mnot]
Meeting: Web Services Addressing Face-to-Face
13:04:10 [mnot]
Chair: Mark Nottingham
13:04:11 [dhull]
Zakim, What is the velocity of a laden sparrow?
13:04:11 [Zakim]
I don't understand your question, dhull.
13:04:25 [plh]
plh has joined #ws-addr
13:04:30 [mnot]
Agenda: http://www.w3.org/mid/3A124A42-1041-40E2-8FB7-31A3ABDB4B92@bea.com
13:04:33 [Zakim]
+Andreas_Bjarlestam
13:04:38 [marc]
marc has joined #ws-addr
13:04:51 [uyalcina]
uyalcina has joined #ws-addr
13:05:28 [pauld]
some of us have been in this room before: http://www.w3.org/2002/ws/desc/4/06/WSD/full/Bedford.jpg
13:05:31 [plh]
zakim, who's here?
13:05:31 [Zakim]
On the phone I see +1.781.280.aaaa, Prasad_Yendluri, mlpeel, Mark_Peel (muted), Andreas_Bjarlestam
13:05:33 [Zakim]
On IRC I see uyalcina, marc, plh, dhull, TRutt, mnot, RebeccaB, prasad, TonyR, pauld, GlenD, Zakim, RRSAgent, mlpeel, Katy, Marsh, hugo
13:05:53 [plh]
zakim, +1.781 is Sonic
13:05:53 [Zakim]
+Sonic; got it
13:06:23 [Zakim]
+Marsh
13:07:11 [plh]
Zakim, Sonic holds Mark, Paul, David, Tony, Tom, Marc, Steve, Umit, Kathy, Rebecca, Glen, Hugo, Tony, Michael, Paul
13:07:11 [Zakim]
+Mark, Paul, David, Tony, Tom, Marc, Steve, Umit, Kathy, Rebecca, Glen, Hugo, Tony, Michael, Paul; got it
13:07:14 [mnot]
zakim, who is on the phone
13:07:14 [Zakim]
I don't understand 'who is on the phone', mnot
13:07:20 [mnot]
zakim, who's on the phone?
13:07:20 [Zakim]
On the phone I see Sonic, Prasad_Yendluri, mlpeel, Mark_Peel, Andreas_Bjarlestam, Marsh
13:07:22 [Zakim]
Sonic has Mark, Paul, David, Tony, Tom, Marc, Steve, Umit, Kathy, Rebecca, Glen, Hugo, Tony, Michael, Paul
13:07:51 [plh]
Zakim, Sonic holds Mark, Paul, David, Tony, Tom, Marc, Steve, Umit, Kathy, Rebecca, Glen, Hugo, Tony, Michael, PaulK, Jeff, Anish
13:07:51 [Zakim]
Mark was already listed in Sonic, plh
13:07:53 [Zakim]
Paul was already listed in Sonic, plh
13:07:54 [Zakim]
David was already listed in Sonic, plh
13:07:55 [Zakim]
Tony was already listed in Sonic, plh
13:07:57 [Zakim]
Tom was already listed in Sonic, plh
13:07:59 [Zakim]
Marc was already listed in Sonic, plh
13:08:00 [Zakim]
Steve was already listed in Sonic, plh
13:08:01 [Zakim]
Umit was already listed in Sonic, plh
13:08:02 [Zakim]
Kathy was already listed in Sonic, plh
13:08:03 [Zakim]
Rebecca was already listed in Sonic, plh
13:08:05 [Zakim]
Glen was already listed in Sonic, plh
13:08:07 [Zakim]
Hugo was already listed in Sonic, plh
13:08:09 [Zakim]
Tony was already listed in Sonic, plh
13:08:10 [Zakim]
Michael was already listed in Sonic, plh
13:08:11 [Zakim]
+PaulK, Jeff, Anish; got it
13:08:30 [pauld]
zakim, aabb is really Mark_Little
13:08:30 [Zakim]
sorry, pauld, I do not recognize a party named 'aabb'
13:08:42 [TonyR]
scribe: tonyR
13:08:55 [TonyR]
TOPO
13:09:01 [plh]
Zakim, Sonic holds Bob
13:09:01 [Zakim]
+Bob; got it
13:09:10 [TonyR]
TOPIC: selecting scribes
13:10:43 [steve_winkler]
steve_winkler has joined #ws-addr
13:11:51 [yinleng]
yinleng has joined #ws-addr
13:12:17 [TonyR]
TOPIC: Process
13:12:41 [TonyR]
Discussing process of handling formal objections
13:13:28 [Zakim]
+??P12
13:13:30 [PaulKnight]
PaulKnight has joined #ws-addr
13:14:03 [yinleng]
zakim, ??P12 is me
13:14:03 [Zakim]
+yinleng; got it
13:16:19 [TonyR]
JeffM: protesting the method of handling the formal objection as an abuse of process
13:17:07 [TonyR]
Chair: will capture loose ends at the end
13:17:30 [TonyR]
Glen: will want some time to discuss the Async TF results
13:17:56 [TonyR]
Chair: other Administrivia
13:18:15 [TonyR]
Chair: want to take a break in August
13:18:17 [TonyR]
Chair
13:18:39 [TonyR]
Chair: note that one organisation has three representatives on the WG
13:19:23 [TonyR]
Chair: MS has added a third participant (Mark Goodner)
13:19:44 [TonyR]
Chair: note that the charter does not restrict the number of participants
13:20:26 [TonyR]
Chair: note that this does allow organisations to bring their QA people into play to assist with the CR process
13:21:17 [anish]
anish has joined #ws-addr
13:21:31 [Marsh]
q+
13:21:56 [mnot]
ack marsh
13:21:58 [TonyR]
Chair: keeping an eye on the issues relating to good standing rules and the question of weighting straw polls
13:22:24 [TonyR]
Chair: if necessary, will move straw polls to one/organisation
13:23:02 [plh]
zakim, sonic holds Paco
13:23:02 [Zakim]
+Paco; got it
13:23:11 [TonyR]
Marsh: multiple reasons for including an extra person - Gudge may be moving on, and Marsh may have trouble attending
13:23:49 [bob]
bob has joined #ws-addr
13:23:58 [TonyR]
Glen: possible to use the "invited expert" means of involving others
13:24:27 [jeffm]
jeffm has joined #ws-addr
13:24:40 [mnot]
zakim, who is on the phone?
13:24:40 [Zakim]
On the phone I see Sonic, Prasad_Yendluri, mlpeel, Mark_Peel, Andreas_Bjarlestam (muted), Marsh, yinleng
13:24:42 [Zakim]
Sonic has Paco
13:25:07 [TonyR]
Glen: may want to do this to involve someone from Apache
13:25:51 [TonyR]
TOPIC: future face-to-face meetings
13:26:02 [Marsh]
s/multiple reasons/reason/
13:26:20 [Marsh]
s/attending/attending. We want to make sure we maintain active participation./
13:26:25 [TonyR]
Chair: looks like best week will be week of September 26th
13:27:13 [TonyR]
Omnes: rumblings of date clashes
13:28:53 [TonyR]
Chair: still looking for a host
13:30:35 [TonyR]
Looking rather urgently for a host in the Bay Area
13:31:14 [TonyR]
... Tentative dates are 27th and 28th - hope to settle this this week
13:31:52 [TonyR]
Next F2F after this would be November - week of the 7th or 14th
13:32:24 [TonyR]
... Week of the 14th looks problematic - consider the week of the 7th.
13:32:45 [TonyR]
Week of November 7th - any problems?
13:33:10 [TonyR]
Next one after that would be January - week of the 9th or 16th
13:33:37 [TonyR]
And after that is W3C Tech Plenary - end Feb / start of March - pretty much set in stone - in Nice
13:34:21 [TonyR]
January will probably be US east coast
13:34:31 [TonyR]
November is likely to be overseas
13:34:55 [TonyR]
Possibilities for November are: Tokyo, Sweden, and London.
13:35:05 [TonyR]
Omnes: Tokyo looks good!
13:36:38 [TonyR]
Chair: looks like the week of November 7th in Tokyo
13:37:35 [TonyR]
Bob: Hitachi is willing to provide facilities for WSDL as well as WS-Addr
13:38:50 [TonyR]
Chair: looking for a host for January - probably week of 9th of US East Coast
13:39:39 [TonyR]
Chair: willing to consider mid-US
13:39:54 [TonyR]
TOPIC: minutes of last meeting
13:40:05 [TonyR]
Chair: defer consideration to tomorrow
13:40:14 [TonyR]
TOPIC: Action Items
13:40:28 [TonyR]
Chair: done
13:40:41 [TonyR]
TOPIC: LC69 - revisiting
13:41:10 [TonyR]
Chair: response from originator to closure with no action - suggesting changes to language
13:42:14 [TonyR]
Jacek's suggestion is accepted
13:42:27 [TonyR]
ACTION: Mike to respond to Jacek
13:42:51 [TonyR]
TOPIC: LC76
13:43:53 [TonyR]
DaveH: providing a standard means / language for returning a fault - not mandating format, but suggesting things that could be included in the detail element
13:44:59 [TonyR]
... Proposal suggests content to include with any of the four "standard" faults
13:45:17 [TonyR]
... Attach language to the binding in Section 7
13:45:36 [TonyR]
... Minor issue with mechanical details of how to include this.
13:45:58 [TonyR]
... main objective is to make faults more useful / informative
13:46:08 [Marsh]
q+ to ask about MismatchedAction content
13:48:07 [TonyR]
mixed discussion of origin of faults, content
13:50:51 [bob]
q
13:50:51 [bob]
q+
13:50:51 [mnot]
ack Marsh
13:50:51 [Zakim]
Marsh, you wanted to ask about MismatchedAction content
13:52:00 [TonyR]
PaulD: if we mandate these we must test for them. Fair enough to have them as suggestions, but not mandatory
13:52:05 [mnot]
ack bob
13:52:25 [Paco]
Paco has joined #ws-addr
13:53:52 [TonyR]
DaveH: not mandated - just suggestions - if you want to include this information, this is standard way to do it. SHOULD not MUST
13:54:58 [TonyR]
DaveH: there are occasions when one may wish to omit the detail (eg: list of supported actions), hence the SHOULD
13:56:23 [Marsh]
q+ to ask whether we expect interop on the difference between malformed IRI and relative IRI.
13:56:24 [TonyR]
DaveH: most of this goes in the InvalidAddressingHeader - added after the QName that is the standard content of that header
13:56:55 [TonyR]
DaveH: will probably need to wrap the QName
13:57:46 [TonyR]
SteveW: is this an exhaustive list?
13:58:09 [TonyR]
DaveH: fine to add some language which indicates that this is not exhaustive
13:59:28 [TonyR]
PaulD: concerned about putting this into the Core - perhaps it should be published as a Note or Adjunct
13:59:39 [TonyR]
DaveH: Perhaps
13:59:39 [uyalcina]
q+
13:59:40 [Zakim]
-mlpeel
14:00:07 [mnot]
q?
14:01:19 [mnot]
q+ Marc
14:01:30 [steve_winkler]
q+
14:01:53 [dhull]
q+
14:01:57 [mnot]
ack Marsh
14:01:57 [Zakim]
Marsh, you wanted to ask whether we expect interop on the difference between malformed IRI and relative IRI.
14:02:02 [mnot]
ack uyal
14:02:09 [mnot]
q+ Marsh
14:03:04 [pauld]
sees this as a bi-product of writing a test assertions document
14:03:10 [TonyR]
Umit: in favour of this proposal - good to have standard error information format
14:03:14 [mnot]
ack Marc
14:03:29 [mnot]
q+ Marc
14:03:36 [Marsh]
+1 to a bit over the top!
14:03:47 [TonyR]
Marc: concerned that this is a bit too detailed
14:04:35 [TonyR]
Discussion of testing and the need to test all of the error conditions
14:04:53 [TonyR]
PaulD: may need to add error codes as we develop the tests
14:05:21 [TonyR]
Umit: interop depends on standard descriptions of faults / error content
14:05:46 [mnot]
ack steve
14:06:15 [TonyR]
Steve: yes, never finish with errors, but having well-defined errors is helpful
14:06:30 [dims]
dims has joined #ws-addr
14:07:07 [TonyR]
Steve: we can add more errors in an extra document, but let's include the ones we know now
14:07:24 [TonyR]
PaulD: does this mean we have two lists of errors?
14:08:04 [mnot]
q?
14:08:52 [TonyR]
TonyR: but it is not the list of faults we're discussing - the faults are agreed - we are talking about the detail
14:10:04 [TonyR]
DaveH: have never seen an error message that was TOO detailed... Concerned that this isn't fully baked yet
14:10:52 [TonyR]
Chair: can we change a list of errors during CR without kicking back to LC?
14:11:08 [TonyR]
Hugo: probably not count as a substantive change
14:12:11 [TonyR]
... unlikely to violate the rule about "affecting some-one's implementation or review experience"
14:14:14 [yinleng]
abstain
14:14:24 [mlpeel]
abstain
14:14:52 [TonyR]
Straw poll: 11 in favour, 3 against, 3 abstain
14:15:16 [dhull]
q+
14:15:29 [TonyR]
PaulD: likely to change, shouldn't be in the spec
14:15:37 [TonyR]
Marc: it's overkill
14:17:03 [TonyR]
TonyR: asking those against: OK to include faults, but not the detail?
14:17:07 [TonyR]
Marc: yes
14:17:12 [TonyR]
PaulD: yes
14:17:59 [TonyR]
Chair: can we get the proposal "baked" to increase it's acceptability?
14:18:15 [pauld]
seems like accepting this will prevent us being able to vote on leaving CR tomorrow. Expensive "wouldn't it be nice if ..." :-(
14:18:38 [TonyR]
Marsh: prefer to not get this in rather than waste lots of time on it
14:19:11 [TonyR]
Marsh: question on detail of one fault
14:22:19 [pauld]
s/one fault/detecting the difference between relative and malformed IRI/.
14:23:19 [TonyR]
Omnes: perhaps we should drop the "non-absolute IRI" fault - treat it as a malformed IRI
14:23:44 [mnot]
q?
14:23:48 [mnot]
ack dhull
14:23:50 [mnot]
ack Marsh
14:23:53 [TonyR]
... include the non-relative information as a detail information
14:23:53 [mnot]
ack Marc
14:24:23 [Marsh]
q+ to ask about @property
14:24:29 [TonyR]
Marc: should we have a subcode for SOAP 1.2
14:24:38 [TonyR]
s/1.2/1.2?/
14:25:21 [TonyR]
DaveH: good idea - perhaps we should use subcodes for several
14:26:23 [TonyR]
Marc: we already describe detail content for some of the faults - relationship of the existing content to these new contents?
14:26:47 [TonyR]
DaveH: discussing particular cases
14:27:56 [TonyR]
Marc: make the new content siblings to the existing content
14:28:14 [TonyR]
s/existing content/existing content?/
14:29:50 [TonyR]
Marc: the text is rather generic at the moment - we would need to be more specific. This is a reason why this proposal seems "inadequately baked".
14:30:44 [TonyR]
DaveH: that's why I'd prefer to make this an appendix
14:31:27 [TonyR]
Chair: appendix or separate document? Appendix must be included when going to CR; separate document can be published any time
14:32:09 [anish]
q+
14:33:14 [TonyR]
Chair: does moving the details to appendix / sep document affect CR?
14:35:12 [TonyR]
Marc: can have multiple detail elements - perhaps leave current detail content in first detail element, include this new stuff in extra detail elements?
14:37:46 [TonyR]
Omnes: discussion of separate document vs including in spec; discussion of process
14:39:03 [GlenD]
GlenD has joined #ws-addr
14:39:50 [Paco]
Paco has joined #ws-addr
14:41:46 [TonyR]
Omnes: discussing mechanism for including this into the spec
14:42:31 [Zakim]
-Andreas_Bjarlestam
14:43:47 [TonyR]
Chair: need a volunteer to lead a short-lived group to design this proposal - preferably someone other than DaveH - coordinate with Marc to ensure inclusion of his ideas
14:43:55 [TonyR]
Omnes: guilty shuffling
14:44:58 [TonyR]
Chair: we'll convene some people at lunch to attack this problem.
14:46:33 [TonyR]
Marsh: perhaps we can build some of the differences between Faults into the names of the properties, and make things more generic
14:46:43 [TonyR]
DaveH: that makes sense
14:47:07 [TonyR]
Marc: we have some of that already
14:47:50 [TonyR]
Umit: can be issues with using sibling elements
14:48:26 [TonyR]
DaveH: nervous about including this stuff right now because it needs refinement
14:48:39 [Marsh]
ack marsh
14:48:39 [Zakim]
Marsh, you wanted to ask about @property
14:48:46 [TonyR]
Chair: we'll meet at lunch and discuss tomorrow.
14:48:59 [uyalcina]
I would prefer child elements since the parent contains info about the property already
14:49:22 [TonyR]
Chair: break now - back at 11am - will move on to LC20
14:50:24 [Zakim]
-yinleng
14:50:30 [TonyR]
Chair: break REALLY now
14:50:58 [Zakim]
-Marsh
14:51:30 [Zakim]
-Mark_Peel
14:55:26 [Zakim]
-Prasad_Yendluri
15:04:20 [Nilo]
Nilo has joined #ws-addr
15:05:28 [Zakim]
+Nilo_Mitra
15:07:36 [steve_winkler]
steve_winkler has joined #ws-addr
15:09:56 [Zakim]
+Prasad_Yendluri
15:12:17 [TonyR]
Restarting
15:12:21 [TonyR]
TOPIC: LC20
15:12:57 [marc]
marc has joined #ws-addr
15:13:00 [TonyR]
Chair: originally raised by Jonathan - clarifying the semantics of the anonymous URI
15:13:05 [jeffm]
jeffm has joined #ws-addr
15:13:08 [Zakim]
+Marsh
15:13:51 [TonyR]
Proposal by DaveH
15:13:55 [mnot]
http://www.w3.org/mid/42D8778C.9040402@tibco.com
15:14:11 [Katy]
Katy has joined #ws-addr
15:14:15 [Paco]
Paco has joined #ws-addr
15:14:25 [TonyR]
DaveH: introducing the proposal
15:15:17 [TonyR]
... a selection of symbolic URIs - starting with anonymous vs sender
15:15:39 [Marsh]
q+ to note this proposal has little relation to the original comment.
15:16:50 [GlenD]
GlenD has joined #ws-addr
15:16:58 [mnot]
ack Marsh
15:16:58 [Zakim]
Marsh, you wanted to note this proposal has little relation to the original comment.
15:17:34 [TonyR]
Marsh: this does not address the original issue, indeed, it seems this was deliberately NOT the intent
15:18:29 [TonyR]
DaveH: thought the complaint was that anonymous was too vague; introduced sender to address the sending of a message down the back-channel (if any)
15:19:51 [TonyR]
Chair: would it be acceptable to say this is addressed by the binding? Push it to the binding document?
15:20:03 [TonyR]
Marsh: would be happier to close with no action
15:20:24 [TonyR]
DaveH: but then we have no hook to hang the back-channel on
15:20:53 [TonyR]
DaveH: better to have sender to use for this
15:21:21 [TonyR]
Glen: could make this a feature of the underlying binding - HTTP supports this feature
15:21:44 [TonyR]
DaveH: but "sender" can go further
15:22:11 [TonyR]
Paco: the core can specify that the meaning of anonymous is specified by the binding
15:22:51 [Marsh]
+1 to Paco - not gaining much.
15:23:15 [TonyR]
DaveH: but anonymous can be different from sender, defined by binding
15:23:55 [TonyR]
Chair: do more people feel that anonymous should be stated in the core as meaning defined by the binding
15:25:00 [TonyR]
DaveH: problem - anonymous being defined by the binding could change the meaning of an address when moving from one binding to another
15:25:54 [TonyR]
Umit: discussing difference between anonymous meaning "deferred to another spec" and meaning "out-of-band"
15:25:56 [TonyR]
q+
15:26:38 [TonyR]
DaveH: but anonymous is used for "out-of-band" today
15:27:17 [plh]
plh has joined #ws-addr
15:28:02 [Zakim]
-Marsh
15:28:19 [TonyR]
Discussion of current meaning / possible meaning of anonymous
15:28:20 [mnot]
ack anish
15:28:52 [plh]
zakim, sonic holds Dims
15:28:52 [Zakim]
+Dims; got it
15:29:01 [mnot]
ack TonyR
15:31:11 [TonyR]
Lots of discussion of value of "sender"
15:33:58 [TonyR]
Anish: wondering if we should remove the anonymous URI altogether from the core spec, and defer it to the SOAP spec
15:34:27 [Nilo]
I'd like two
15:34:42 [steve_winkler_]
steve_winkler_ has joined #ws-addr
15:34:49 [prasad]
+1 to two
15:35:50 [steve_winkler]
q+
15:36:46 [prasad]
prasad has joined #ws-addr
15:36:46 [TonyR]
Straw poll: Do we need one URI, two URIs? One: 7ish, Two: 5, Abstain: 4ish!
15:36:54 [anish]
q+
15:37:28 [TonyR]
SteveW: should we define just one URI, but allow the definition of more at a later time?
15:37:55 [steve_winkler]
ala our wsa:RelationshipType...
15:37:56 [uyalcina]
q+
15:38:05 [steve_winkler]
q-
15:39:54 [TonyR]
discussion on meaning of anonymous once we have a new "sender"
15:40:21 [TonyR]
Chair: if we do have sender, should ReplyTo / FaultTo default to sender
15:40:25 [TonyR]
Omnes: Yes
15:41:12 [TonyR]
Anish: if we move this to HTTP, and say what it means, what do we lose?
15:41:34 [TonyR]
Marc: we lose ability to default in the core - must move infoset to the SOAP binding
15:42:00 [TonyR]
Paco: so we only care about the SOAP / HTTP case? What about SOAP / TCP?
15:42:28 [TonyR]
... we must define this again in each binding document?
15:42:33 [TonyR]
Anish: yes
15:42:46 [TonyR]
... they are free to define what this means in their case
15:43:16 [mlpeel]
mlpeel has joined #ws-addr
15:43:27 [TonyR]
Umit: the anonymous URI is a forward pointer - must look at the binding document to determine meaning
15:46:30 [TonyR]
SteveW: we should point out that we support multiple IRIs explicitly
15:46:42 [TonyR]
MNot: always thought that was implicit
15:47:27 [TonyR]
JeffM: if we go down this path we must ensure we define the IRI in all the bindings we define
15:49:53 [TonyR]
Marc: we can define anonymous in core / specify its meaning in binding
15:51:11 [TonyR]
Chair: we define one or more URIs in the core, defer semantics to the binding (except for "none" - defined in the core)
15:51:15 [TonyR]
Omnes: yes
15:52:25 [TonyR]
Anish: per underlying transport binding we have a meaning of the IRIs
15:55:41 [TonyR]
Anish: can we have just one, and call it "sender"?
15:56:14 [TonyR]
TonyR: No, because sometimes we want to send the request to "anonymous" - that's not the same as "sender"
15:57:22 [anish]
+1 to one anon URI
15:58:24 [TRutt_]
TRutt_ has joined #ws-addr
16:00:08 [RebeccaB]
Another +1 to one anon URI
16:00:58 [TonyR]
Discussion of whether sender is useful / required / desirable
16:03:39 [TonyR]
TonyR: can we specify in the core that an underlying transport binding must define the Anonymous IRI?
16:05:54 [TonyR]
Anish: cannot require the binding to define the anonymous IRI, because the binding may not permit the use of anonymous - perhaps "the underlying protocol binding must specify the semantics of the anonymous IRI"
16:07:10 [steve_winkler]
q+
16:07:26 [steve_winkler]
q-
16:07:40 [TonyR]
circling discussion - difficult to capture
16:09:50 [TonyR]
TonyR: how do we distinguish symbolic IRIs from real addresses?
16:10:09 [TonyR]
Chair: you require an enumerated list of the symbolic ones
16:12:25 [TonyR]
SteveW: how do we define something like a special IRI for the use case Glen suggested (determine the address from the digital signature) - do we give it a new symbolic name?
16:12:44 [TonyR]
Paco: anonymous can cover that
16:13:21 [TonyR]
Anish: if that travels over HTTP, how do we distinguish these cases?
16:14:06 [steve_winkler]
Slgiht correction: there are two semantics overloaded with current definition of anonymous: out of band and transport specific. Defining a URI for each and making the text more crisp, while illustrating that more URIs could be added, might be a better way to go.
16:20:25 [TonyR]
General discussion reaching almost consensus on returning to Jonathan's proposal
16:20:43 [Nilo]
The IETF makes everything URNs
16:22:00 [TonyR]
Chair: so we need a volunteer to capture a proposal for this
16:22:20 [Nilo]
That was just FYI
16:23:34 [TonyR]
Glen volunteers
16:24:01 [Zakim]
+Marsh
16:26:03 [TonyR]
ACTION: Glen to present a new version of the proposal for LC20 this afternoon
16:27:37 [TonyR]
Lunch break to 1:30 US EDT, may extend depending on progress of subgroups
16:27:48 [Zakim]
-Nilo_Mitra
16:27:56 [Zakim]
-Prasad_Yendluri
16:28:24 [Zakim]
-Marsh
17:00:58 [Zakim]
+Andreas_Bjarlestam
17:17:15 [Zakim]
-Andreas_Bjarlestam
17:18:48 [jeffm]
jeffm has joined #ws-addr
17:27:57 [Zakim]
+Andreas_Bjarlestam
17:29:55 [mnot]
Lunch extended for 15 minutes (possibly more)
17:40:48 [Zakim]
-Andreas_Bjarlestam
17:49:02 [steve_winkler_]
steve_winkler_ has joined #ws-addr
17:49:43 [GlenD]
When the *foo* URI is specified, the underlying transport binding MUST provide a backchannel for the reply message. Any underlying protocol binding supporting the SOAP request-response Message Exchange Pattern (@@uri@@) natively provides such a backchannel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.
17:49:46 [mnot]
zakim, who is on the phone?
17:49:46 [Zakim]
On the phone I see Sonic
17:49:47 [Zakim]
Sonic has Dims
17:49:53 [Paco]
Paco has joined #ws-addr
17:50:07 [anish]
anish has joined #ws-addr
17:50:58 [Zakim]
+Mark_Peel
17:51:10 [steve_winkler]
Scribe: steve_winkler
17:51:27 [Zakim]
+??P2
17:51:32 [steve_winkler]
TOPIC: lc20 continued
17:51:39 [Zakim]
+Marsh
17:51:56 [steve_winkler]
Glen: describes above proposal.
17:52:30 [steve_winkler]
Paco: you're defining the foo URI in the core in the binding?
17:52:43 [steve_winkler]
Glen: No, this means the semantics are defined by the underlying transport.
17:52:59 [steve_winkler]
Paco: That wasn't my understanding of what we were going to do.
17:53:12 [Pete]
Pete has joined #ws-addr
17:53:19 [Zakim]
+Pete_Wenzel
17:53:22 [steve_winkler]
Paco: I think it was clear that we didn't agree on the sender part.
17:53:40 [steve_winkler]
Mark: we kind of came to a place where it was protocol specific.
17:54:21 [steve_winkler]
Paco: It may be transport specific, but it doesn't make the connection that the URI isn't stable/resolvable which is what we have today.
17:54:55 [steve_winkler]
Glen: We could make back channel more specific, by saying that it delivers the reply message to the sender.
17:55:23 [steve_winkler]
Mark: I thought we wanted to be able to use this not only in the ReplyTo but also in the To as a default.
17:55:33 [GlenD]
When the *foo* URI is specified, the underlying transport binding MUST provide a backchannel for the reply message. Any underlying protocol binding supporting the SOAP request-response Message Exchange Pattern (@@uri@@) natively provides such a backchannel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.
17:56:11 [steve_winkler]
Marc: If that URI is in the reply message, does that mean that you have to provide a back channel for a reply message (reply to a reply)?
17:56:20 [steve_winkler]
Glen: Yeah, you have to deal with that anyway.
17:56:38 [steve_winkler]
Glen: One option is to say, don't do that.
17:57:15 [steve_winkler]
Marc: It could just be a DWR (Do What's Right).
17:57:27 [steve_winkler]
Glen: That's hard for interop.
17:57:51 [steve_winkler]
Marc: Just act if it wasn't there. Do what you do anyway.
17:58:04 [steve_winkler]
Glen: That sounds fine if we can say that somehow.
17:58:41 [steve_winkler]
Anish: Aren't we getting into trouble by not defining the context. We define the meaning, but not depenedent on where the URI is found.
17:59:37 [steve_winkler]
Glen and Paco go back and forth. Anish adds his 2 cents...
17:59:54 [bob]
more like to and fro
18:00:09 [Zakim]
+Andreas_Bjarlestam
18:00:22 [steve_winkler]
Paco: We are trying to give a provisional name for something that doesn't have a name.
18:00:25 [dorchard]
dorchard has joined #ws-addr
18:01:00 [steve_winkler]
Anish: I tend to agree, but we are also saying something specific when it's used in ReplyTo
18:01:12 [steve_winkler]
Anish: It seems that we're trying to define it in a more general way.
18:01:44 [steve_winkler]
Anish: In the soap binding all we need to talk to is what is done when this URI appears in the ReplyTo.
18:02:11 [steve_winkler]
Anish: If the same URI appears in To, the SOAP binding has nothing to say about it.
18:02:29 [steve_winkler]
Glen: Because it's the guy on the other end of the binding.
18:02:55 [steve_winkler]
Paco: you can't make it relative. It's absolute within the context of an exchange.
18:03:58 [mnot]
zakim, what is the passcode?
18:03:58 [Zakim]
the conference code is 97323 (tel:+1.617.761.6200), mnot
18:04:37 [Zakim]
+DOrchard
18:04:47 [steve_winkler]
Mark: 3 proposals
18:04:59 [steve_winkler]
Mark: 1 = act as if addressing wasn't here
18:05:12 [steve_winkler]
Mark: 2 = Transport-specific; 'to the unnamed'
18:05:27 [mnot]
When the *foo* URI is specified, the underlying transport binding MUST provide a backchannel for the reply message. Any underlying protocol binding supporting the SOAP request-response Message Exchange Pattern (@@uri@@) natively provides such a backchannel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.
18:05:33 [steve_winkler]
Mark: 3 = Transport-specific; 'use the back channel'
18:05:56 [steve_winkler]
Anish: 4 = Combination of 2 and 3.
18:06:10 [Zakim]
+Nilo
18:06:44 [steve_winkler]
Glen: Any of these MAPs, they only become interesting in the context of an MEP.
18:07:40 [dorchard]
I propose changing "transport" to underlying protocol.
18:09:31 [steve_winkler]
Paco: We want to keep the part about the endpoints for which you can't assign a URI.
18:09:54 [steve_winkler]
Anish: Weren't we going to remove the part about NAT, DHCP, etc?
18:10:14 [steve_winkler]
general nods of agreement by the group.
18:11:32 [steve_winkler]
Glen: This text isn't so bad, it just doesn't say what to do in Req-resp over HTTP.
18:11:49 [steve_winkler]
Glen: We just need to capture that somewhere.
18:12:07 [steve_winkler]
Anish: Why can't we just say that in the SOAP binding?
18:12:39 [steve_winkler]
Glen: Am I allowed to send it somewhere other than up the http resp when anon is in the replyto?
18:12:49 [steve_winkler]
Anish: No. You have to send it back on the back channel.
18:14:10 [steve_winkler]
Glen reads to himself out loud.
18:14:29 [bob]
And the binding said unto the transport I AM THAT I AM: and it said, Thus shalt thou say unto the children of thy message I AM hath sent me unto you.
18:14:39 [steve_winkler]
Mark: Would we put that in the core or the soap binding?
18:14:51 [steve_winkler]
Mark: Do we need something for the to?
18:15:12 [steve_winkler]
Marc: If we do that, we'll need to talk about whether it's an HTTP Req or an HTTP Resp.
18:15:51 [Marsh]
Marsh has joined #ws-addr
18:16:27 [steve_winkler]
Umit: We need to say something in the SOAP binding that relates it back to the anon URI that is defined in the core.
18:18:15 [jeffm]
jeffm has joined #ws-addr
18:19:11 [steve_winkler]
group wordsmithing ensues.
18:20:15 [mnot]
Core: http://www.w3.org/@@@@/@@/addressing/context-specific
18:20:16 [mnot]
Some endpoints cannot be located with a meaningful IRI; this URI is used to allow such endpoints to send and receive messages. The precise meaning of this URI is defined by the context of use; e.g., in a binding of Addressing to a specific protocol.
18:20:16 [mnot]
SOAP Binding:
18:20:16 [mnot]
When (@@URI@@) is specified as the address of the ReplyTo or FaultTo EPR, the underlying SOAP protocol binding provides a channel to the specified endpoint. Any underlying protocol binding supporting the SOAP Request-Response Message Exchange Pattern (@@uri@@) provides such a channel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.
18:21:12 [Marsh]
@@URI@@ is .../context-specific?
18:21:41 [steve_winkler]
Paco: It should still be 'anonymous' and not context specific.
18:22:16 [Marsh]
+1 to anonymous
18:22:41 [steve_winkler]
Anish: Why do we use 'context' instead of transport binding?
18:23:04 [steve_winkler]
Marc: Why can't we say in a protocol to which WS-A is bound?
18:23:29 [prasad]
+1 to anonymous; BTW, where is this text going in the spec?
18:23:58 [mnot]
Core Table 2-1: http://www.w3.org/@@@@/@@/addressing/anonymous
18:23:58 [mnot]
Some endpoints cannot be located with a meaningful IRI; this URI is used to allow such endpoints to send and receive messages. The precise meaning of this URI is defined by the binding of Addressing to a specific protocol.
18:23:58 [mnot]
SOAP Binding:
18:23:59 [mnot]
When (@@URI@@) is specified as the address of the ReplyTo or FaultTo EPR, the underlying SOAP protocol binding provides a channel to the specified endpoint. Any underlying protocol binding supporting the SOAP Request-Response Message Exchange Pattern (@@uri@@) provides such a channel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.
18:24:31 [steve_winkler]
Rebecca: what is the optionality on the word 'provides'?
18:24:59 [steve_winkler]
Glen: In the first sentence, MUST is ok, in the second, it's ok.
18:25:48 [steve_winkler]
DaveO: When it says any underlying protocol that supports SOAP req/resp MEP, this could cause problems...(sorry dave, couldn't quite catch)
18:26:08 [steve_winkler]
DaveO: It doesn't work to use anonymous in that case.
18:26:30 [steve_winkler]
Anish: If you're using WSA to enable that, you'll never use it anyway.
18:26:35 [steve_winkler]
DaveO: That's my point.
18:26:54 [steve_winkler]
Glen: You have to separate your concerns.
18:27:04 [steve_winkler]
Glen: If you try to overload it, it's inappropriate.
18:27:23 [steve_winkler]
Glen: If you want to do something else, that's fine, because it correctly layers under the SOAP MEP.
18:27:41 [steve_winkler]
Anish: If you did overload, your binding would prevent you from doing anonymous.
18:28:08 [steve_winkler]
DaveO: What's the point of the second sentence?
18:28:34 [steve_winkler]
Glen: We're trying to resolve LC20, it's never specified how to send a response for http on the back channel.
18:28:56 [steve_winkler]
Glen: This tells you that the reply message is going to go in the response because of the req/resp MEP.
18:30:20 [steve_winkler]
Glen: For Req/Resp MEP, there exists a back channel for every binding.
18:31:01 [mnot]
Core Table 2-1:
18:31:01 [mnot]
http://www.w3.org/@@@@/@@/addressing/anonymous
18:31:01 [mnot]
Some endpoints cannot be located with a meaningful IRI; this URI is used to allow such endpoints to send and receive messages. The precise meaning of this URI is defined by the binding of Addressing to a specific protocol.
18:31:01 [mnot]
SOAP Binding:
18:31:01 [mnot]
When (@@URI@@) is specified as the address of the ReplyTo or FaultTo EPR, the underlying SOAP protocol binding MUST provide a channel to the specified endpoint. Any underlying protocol binding supporting the SOAP Request-Response Message Exchange Pattern (@@uri@@) provides such a channel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.
18:32:22 [steve_winkler]
Glen: At least this way, we cover all transport bindings...
18:32:43 [steve_winkler]
Umit: One of my concerns is that we have covered SOAP 1.1 and 1.2, and I don't like that to be explicitly called out.
18:33:17 [dorchard]
I wonder about the use of the word "channel". I'm thinking of Umit's "two connection" binding, and whether another http connection is a "channel"
18:34:18 [prasad]
Does the binding need to "define" the precise meaning of the URI?
18:34:41 [steve_winkler]
DaveH: If you're doing req/resp and you switch transports, you're still probably ok.
18:35:18 [Zakim]
-Pete_Wenzel
18:35:35 [Zakim]
+??P4
18:35:50 [yinleng]
zakim, ??P4 is me
18:35:50 [Zakim]
+yinleng; got it
18:37:38 [steve_winkler]
Mark: Can I get a show of hands as to who cares about this distinction.
18:38:10 [steve_winkler]
Mark: result = 3 people. Let's resolve this quickly.
18:38:54 [steve_winkler]
Umit: I just didn't want to tilt it towards SOAP 1.2. With 1.1 there is no definition of MEP.
18:39:44 [steve_winkler]
Glen: describes some crazy cars versus bike transportation analogy.
18:40:32 [steve_winkler]
Mark: straw poll. A, B, don't care.
18:40:43 [dorchard]
I don't see umit b
18:40:46 [mnot]
Core Table 2-1:
18:40:46 [mnot]
http://www.w3.org/@@@@/@@/addressing/anonymous
18:40:46 [mnot]
Some endpoints cannot be located with a meaningful IRI; this URI is used to allow such endpoints to send and receive messages. The precise meaning of this URI is defined by the binding of Addressing to a specific protocol.
18:40:46 [mnot]
SOAP Binding A:
18:40:46 [mnot]
When (@@URI@@) is specified as the address of the ReplyTo or FaultTo EPR, the underlying SOAP protocol binding MUST provide a channel to the specified endpoint. Any underlying protocol binding supporting the SOAP Request-Response Message Exchange Pattern (@@uri@@) provides such a channel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.
18:40:51 [mnot]
SOAP Binding B:
18:40:53 [mnot]
When (@@URI@@) is specified as the address of the ReplyTo or FaultTo EPR, the underlying SOAP protocol binding MUST provide a channel to the specified endpoint. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.
18:41:00 [yinleng]
don't care
18:41:24 [steve_winkler]
A - 6
18:41:32 [steve_winkler]
B - 1
18:41:34 [mlpeel]
don't care
18:41:35 [dorchard]
upon reflection, glen is right about A.. It does work for the 2 connection binding
18:41:40 [Marsh]
don't care
18:41:59 [GlenD]
...as long as the binding correctly implements the req/resp machinery itself
18:42:03 [steve_winkler]
C - 13
18:42:56 [steve_winkler]
Mark: final thoughts? Does anyone object to this as a resolution?
18:43:26 [steve_winkler]
RESOLUTION: Option A is accepted as resolution to LC20.
18:43:39 [steve_winkler]
Jonathan is on the phone and doesn't object.
18:43:43 [Zakim]
+Pete_Wenzel
18:43:46 [hugo]
RRSAgent, where am I?
18:43:46 [RRSAgent]
See http://www.w3.org/2005/07/18-ws-addr-irc#T18-43-46
18:44:02 [hugo]
RRSAgent, make log member
18:44:53 [steve_winkler]
Anyone object to closing I50 (replyTo, FaultTo issue), we needed to reopen that to close LC issues.
18:45:08 [steve_winkler]
Group affirms that I50 is closed.
18:45:28 [steve_winkler]
RESOLUTION: I50 is closed for the same reason that the related LC issues were closed.
18:46:18 [steve_winkler]
TOPIC: LC87 and LC55
18:46:22 [mnot]
http://www.w3.org/mid/012FE7D1-0024-4F98-8849-50ACDE73E524@Sun.COM
18:48:02 [steve_winkler]
Marc: Fixed editorial topics from Hugo. Also put in two versions of the establishing EPR trust.
18:48:43 [steve_winkler]
Marc: Main controversey is whether we should specify normatively how people should determine the trustworthiness of an EPR.
18:49:06 [steve_winkler]
Marc: If we just made it an example, we wouldn't have to test it in CR and we wouldn't have to go into great detail.
18:49:29 [steve_winkler]
Marc: downside is that we don't have a standard way of determining a minimum level of trust and people won't implement it.
18:50:03 [steve_winkler]
Marc: I favor defining it normatively and going into more detail if necessary.
18:50:40 [steve_winkler]
Hugo: I like non-normative because normative requires great level of detail and security expertise and review from the security community.
18:51:20 [steve_winkler]
Hugo: We don't have the necessary expertise in the working group. Rich and Abbie (security experts) agree.
18:51:30 [steve_winkler]
Anish: Do you smell a note?
18:51:41 [steve_winkler]
Hugo: We could make a note.
18:52:01 [steve_winkler]
Anish: The note could provide those details and separate it from the timeline that we have here.
18:52:32 [steve_winkler]
Marc: Someone will end up doing this. We are defining the protocol and should specify how we secure it. If we don't, WS-I or some other group will.
18:52:56 [steve_winkler]
Anish: Do you think we need more details, and if so, should that be in the main spec?
18:53:00 [steve_winkler]
Marc: Yes and yes.
18:53:26 [steve_winkler]
Phillipe: Could it be made into an appendix instead?
18:53:47 [steve_winkler]
Marc: A note would be acceptable. General standards consumer doesn't really differentiate.
18:54:21 [steve_winkler]
Mark: So we have a packaging issue, but you want to have something you can normatively refer to.
18:55:00 [steve_winkler]
Hugo: I would prefer not to have this in the main document. It will have a major impact on the timeline of the main document.
18:55:54 [steve_winkler]
Paul: It would be useful if such a document was produced by CR for testing purposes.
18:56:12 [steve_winkler]
Mark: If we were to decouple, would we want to include the non-normative in the spec and the normative in the note?
18:56:15 [steve_winkler]
Marc: Yep.
18:56:45 [steve_winkler]
Phillipe: We would need to invite other people.
18:57:20 [pauld]
Philippe expresses concern about participation from security experts
18:57:59 [steve_winkler]
Bob: There are many mechanisms, and they're very complicated, so I don't think that the normative version will work in this document.
18:58:38 [steve_winkler]
Marc: I should point out that there is no requirement to implement security.
18:59:07 [steve_winkler]
Bob: I don't think that a normative version can be right or complete for this document.
19:00:10 [dorchard]
q+
19:00:12 [steve_winkler]
Marc: Having something rather than nothing seems valuable. It wouldn't be the only one, but it would be the one defined in the spec.
19:00:42 [steve_winkler]
Mike: The second paragraph, doesn't seem necessary.
19:01:08 [steve_winkler]
Marc: It was there only if we don't do anything else. If we have another note or something, it can go.
19:01:32 [steve_winkler]
Mark: Seems like we're leading towards number 2.
19:02:29 [dorchard]
I would have liked to say something like "If you are going to use ws-security, here's what you must do".
19:02:29 [steve_winkler]
No objections, version 2 becomes basis of discussion.
19:03:12 [steve_winkler]
Mark: To do a note, we'd have to write it and agree to publish it, but we don't need a charter change.
19:03:36 [steve_winkler]
Mark: If we wanted to make it a rec, we would have to consult the team, the group, etc.
19:04:07 [steve_winkler]
Mark: Notes don't fall under the patent policy, but recs do.
19:04:53 [steve_winkler]
Mike: I think we should do a note, and include security, etc. almost like a primer.
19:05:23 [steve_winkler]
Bob: These things will be used in a higher level protocol. Security issues are going to be relevant for these higher level protocols as well.
19:06:04 [steve_winkler]
Marc: Yes, but there are specific things that ws-a introduces.
19:06:28 [plh-bedford]
q?
19:06:50 [mnot]
ack anish
19:06:53 [mnot]
ack uyal
19:07:22 [steve_winkler]
Umit: Why is it only limited to ReplyTo and FaultTo, shouldn't Action or ReferenceParams be included as well.
19:07:31 [Zakim]
-Nilo
19:07:34 [steve_winkler]
Marc: It does.
19:08:12 [mnot]
ack dorch
19:08:25 [steve_winkler]
DaveO: I didn't like mandating security, but I would like to say if you use security, do it this way.
19:08:45 [steve_winkler]
s/security/WS-Security
19:10:06 [steve_winkler]
Marc: Second paragraph is ok, but I won't lie down in the road.
19:10:42 [mlpeel]
I don't have a problem with it
19:11:38 [hugo]
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jul/0115.html
19:11:48 [steve_winkler]
Mark: Are there modifications/suggestions for any other part of Marc's security section proposal?
19:12:56 [steve_winkler]
Hugo: The problem I had was point 2 said that to trust and EPR you need to trust the EPR source and that this source had to have authority over the uri of the EPR.
19:13:19 [steve_winkler]
Hugo: However I may not have authority on the service, but you still might want to trust me, and therefore the EPR.
19:14:17 [steve_winkler]
Hugo: There were 3 aspects for deciding trust (may not be exhaustive): trusted source, epr source has authority, address of epr is a trusted destination.
19:15:21 [steve_winkler]
Tony: I'd be concerned about DOS.
19:15:23 [steve_winkler]
Hugo: as rsalz put it, trust is not black or white.
19:15:53 [steve_winkler]
Paco: How about Refps?
19:16:02 [steve_winkler]
Marc: they're just opaque, right?
19:16:15 [bob]
q+
19:16:33 [steve_winkler]
Paco: When we say the source, this should be the minter, but with refps this may not be the case.
19:17:28 [steve_winkler]
Paco: Isn't a problem to trust the source of the EPR and not care about the source of the runtime message?
19:19:14 [steve_winkler]
Hugo: I always thought there were 3 actors: minter, source, and recipient.
19:20:25 [dhull]
q+
19:20:38 [steve_winkler]
Marc: It's who I'm getting it from that matters.
19:21:34 [steve_winkler]
Bob: All the words around trust here have nothing to do with the application semantics of the message.
19:21:51 [Zakim]
+Nilo
19:21:52 [steve_winkler]
Marc: Not true, we say that the EPRs have to be cryptographically bound to the message.
19:22:09 [mnot]
q?
19:22:17 [mnot]
ack bob
19:22:50 [steve_winkler]
Bob: round the clock trading use case. trust mechanism to authorize trading has dimensions well beyond signature of a particular message.
19:23:05 [steve_winkler]
Bob: We may be conflating the issues of EPR integrity and trustworthiness.
19:23:14 [steve_winkler]
Marc: I don't think so.
19:23:17 [steve_winkler]
Bob: I do.
19:23:32 [Zakim]
-Andreas_Bjarlestam
19:23:59 [steve_winkler]
Bob: Is it proper to be concerned about the potential abuse of the EPRs independent of the security of the message?
19:24:21 [steve_winkler]
Bob: By combining them I think we're having conflicting statements.
19:25:01 [steve_winkler]
Bob: I don't think that we can trust a message just because we trust an endpoint.
19:25:22 [steve_winkler]
Marc: I don't either, and I don't think we're saying that here.
19:25:28 [steve_winkler]
Bob: It needs to be more explicity.
19:25:46 [steve_winkler]
DaveH: Don't attribute to malice what can be explained by stupidity.
19:26:08 [Zakim]
-Mark_Peel
19:26:12 [steve_winkler]
15 minute break. Will reconvene at 3:40
19:26:14 [Zakim]
-yinleng
19:26:24 [Zakim]
-prasad
19:26:30 [Zakim]
-Nilo
19:26:54 [Zakim]
-Pete_Wenzel
19:26:56 [Zakim]
-Marsh
19:27:11 [dhull]
(Meaning, some "security" scenarios can come up through simple mistakes, not just security breaches. E.g., bad code causes an authorized sender to flood the network)
19:30:19 [TRutt]
TRutt has joined #ws-addr
19:30:23 [Marsh]
(But in the name of security, we have to assume the worst...)
19:45:27 [Zakim]
+??P0
19:46:06 [plh-bedford]
[starting again]
19:46:59 [steve_winkler]
Resume discussion of Marc's security proposal
19:48:10 [steve_winkler]
Paco: I'll send minor edits to the list.
19:48:48 [Zakim]
+??P2
19:49:16 [yinleng]
zakim, ??P2 is yinleng
19:49:16 [Zakim]
+yinleng; got it
19:49:18 [steve_winkler]
Bob: The intro has to do with the fact that security implications for applications dealing with one or more protocols go well beyond anything we can state with these elements.
19:49:49 [steve_winkler]
Bob: Essentially it's trying to carve out that this relates not to the complete application or whole protocol stack, but is merely one part of the solution.
19:50:00 [steve_winkler]
Bob: It's kind of a disclamitory intro.
19:50:06 [steve_winkler]
Mark: Any objections to that?
19:50:26 [Zakim]
+Marsh
19:50:30 [steve_winkler]
Mark: Fairly editorial, so Marc and Bob will take care of it.
19:50:32 [Zakim]
+Mark_Peel
19:51:11 [marc]
marc has joined #ws-addr
19:51:32 [prasad]
I am good
19:51:51 [steve_winkler]
Mark: Any objections to accepting the proposal as the resolution to the issue?
19:52:52 [steve_winkler]
Hugo: My comment was substantive, is it included?
19:52:56 [steve_winkler]
Mark: yes.
19:53:56 [steve_winkler]
RESOLUTION: Proposal accepted as resolution to LC 87.
19:55:58 [steve_winkler]
RESOLUTION: Proposal accepted as resolution to LC 55.
19:57:41 [steve_winkler]
TOPIC: LC101 and LC104
19:58:10 [steve_winkler]
Glen walks through proposal.
19:58:28 [steve_winkler]
http://www.w3.org/mid/80A43FC052CE3949A327527DCD5D6B27012975A9@MAIL01.bedford.progress.com
19:58:35 [prasad]
q+
19:58:49 [dhull]
q-
19:59:15 [Zakim]
+Nilo
20:00:19 [mnot]
ack prasad
20:00:34 [Zakim]
-yinleng
20:01:07 [steve_winkler]
Prasad: It's not clear to me that core properties that are already defined can be extended.
20:02:02 [steve_winkler]
Glen: You can extend the existing properties as well as add new ones.
20:02:26 [prasad]
Good for me
20:02:33 [mnot]
An endpoint reference is a collection of abstract properties. This
20:02:34 [mnot]
specification defines a core set of properties, but it is also possible
20:02:34 [mnot]
for other specifications to extend these and/or add other properties. The
20:02:34 [mnot]
semantics and XML Infoset representation (see next section) for any such
20:02:34 [mnot]
extension properties will be described in their defining specifications.
20:02:56 [steve_winkler]
Mark: What about the pseudoschema issue?
20:03:02 [uyalcina]
uyalcina has joined #ws-addr
20:03:06 [steve_winkler]
Glen: Unless there are objections, I'd be happy to let it drop.
20:03:29 [Zakim]
+Pete_Wenzel
20:04:06 [steve_winkler]
A discussion about the pseudo schema ensues.
20:04:41 [steve_winkler]
Jonathan: You end up blowing up your pseudo schema, so I don't think it's the best place to define the extension point.s
20:04:51 [Nilo]
q+
20:05:01 [uyalcina]
q+
20:05:06 [steve_winkler]
Jonathan: pseudo schema should be very constrained
20:06:19 [mnot]
q?
20:06:25 [mnot]
ack Nilo
20:06:41 [anish]
q+
20:07:01 [steve_winkler]
Nilo: Is it necessary to add a cautionary note that any extension should not change the semantics of the core defined here?
20:07:01 [GlenD]
Glen: Can we add something that describes (in the definition of the pseudo-schema) that extensions are omitted for brevity and may exist.
20:07:39 [prasad]
think we allow that no?
20:08:12 [steve_winkler]
Mark: I think the answer is no because we already tell people to be careful about that.
20:09:07 [mnot]
ack uyal
20:09:33 [steve_winkler]
Umit: This proposal is only for 2.1 and about EPR, right? Not about the other MAPs?
20:09:38 [steve_winkler]
Glen: Correct.
20:10:01 [mnot]
ack anish
20:10:47 [steve_winkler]
Anish: I found a pseudo schema related issue: For MAPs we don't express the cardinality, and I thought it would be useful to put it in there.
20:11:02 [Marsh]
Marsh has joined #ws-addr
20:11:22 [steve_winkler]
Anish: Specifically, e.g. Action is one and only, but relatesTo cardinality is defined but not in the pseudoschema.
20:12:19 [steve_winkler]
Anish: My specific proposal was already posted to the list.
20:12:30 [mnot]
LC 101/104
20:12:30 [mnot]
Section 2.1, first sentence - replace with:
20:12:30 [mnot]
An endpoint reference is a collection of abstract properties. This
20:12:30 [mnot]
specification defines a core set of properties, but it is also possible
20:12:30 [mnot]
for other specifications to extend these and/or add other properties. The
20:12:31 [mnot]
semantics and XML Infoset representation (see next section) for any such
20:12:33 [mnot]
extension properties will be described in their defining specifications.
20:12:35 [mnot]
Before example, add:
20:12:37 [mnot]
NOTE: Specifications which describe extension elements or attributes
20:12:39 [mnot]
used to augment the above model will explain any effects those
20:12:41 [mnot]
extensions may have on the abstract properties. They may affect either
20:12:43 [mnot]
the core properties or extension properties as defined in section 2.1.
20:12:45 [mnot]
In Notational Conventions:
20:12:47 [mnot]
Clarify that extensibility is implicit in pseudo-schema
20:15:12 [Zakim]
-Nilo
20:15:24 [mnot]
<wsa:To>xs:anyURI</wsa:To>?
20:15:26 [mnot]
<wsa:To>xs:anyURI</wsa:To>
20:15:43 [mnot]
LC 101/104
20:15:43 [mnot]
Section 2.1, first sentence - replace with:
20:15:43 [mnot]
An endpoint reference is a collection of abstract properties. This
20:15:43 [mnot]
specification defines a core set of properties, but it is also possible
20:15:43 [mnot]
for other specifications to extend these and/or add other properties. The
20:15:44 [mnot]
semantics and XML Infoset representation (see next section) for any such
20:15:46 [mnot]
extension properties will be described in their defining specifications.
20:15:48 [mnot]
Before example, add:
20:15:50 [mnot]
NOTE: Specifications which describe extension elements or attributes
20:15:52 [mnot]
used to augment the above model will explain any effects those
20:15:54 [mnot]
extensions may have on the abstract properties. They may affect either
20:15:56 [mnot]
the core properties or extension properties as defined in section 2.1.
20:15:58 [mnot]
Section 3.2 example:
20:15:59 [Marsh]
q?
20:16:00 [mnot]
add cardinality to pseudo-schema
20:16:02 [Marsh]
q+
20:16:02 [mnot]
In Notational Conventions:
20:16:04 [mnot]
Clarify that extensibility is implicit in pseudo-schema
20:16:37 [mnot]
ack Marsh
20:17:00 [steve_winkler]
Jonathan: I thought we had a link to the notational conventions in the WSDL spec.
20:17:23 [steve_winkler]
Marc: It says to use BNF conventions
20:17:50 [steve_winkler]
Umit: W3C should spit out a pseudoschema spec.
20:18:24 [mnot]
ACTION: Jonathan to coordinate w/ WSDL to make sure notationalo conventions are synced
20:18:27 [uyalcina]
uyalcina has joined #ws-addr
20:19:55 [steve_winkler]
Anish: In my opinion if you write a spec that claims it is extensible, then you have to show how it should be extended.
20:20:09 [steve_winkler]
Glen: I wouldn't be averse to adding some kind of example.
20:20:36 [steve_winkler]
Glen: The issue for providing a framework is a separate one that is already closed.
20:20:47 [steve_winkler]
Anish: I have a problem with how you can do extensibility with infoset.
20:21:00 [steve_winkler]
Anish: I don't know how to map that to abstract properties.
20:21:04 [Zakim]
+Nilo
20:21:17 [steve_winkler]
Glen: This just says that whoever extends the spec needs to tell you how to do it.
20:21:40 [steve_winkler]
Anish: But you're making it someone else's problem.
20:21:53 [steve_winkler]
Glen: But it has to be someone else's problem.
20:22:15 [Marsh]
+1 to Glen. Extensions are by definition someone else's problem.
20:22:49 [steve_winkler]
Mark: Does anyone object to the resolution?
20:24:14 [steve_winkler]
Anish objects.
20:24:19 [steve_winkler]
Roll call vote ensues.
20:25:31 [mnot]
zakim, who is on the phone?
20:25:31 [Zakim]
On the phone I see Sonic, DOrchard, prasad, Marsh, Mark_Peel, Pete_Wenzel, Nilo
20:25:33 [Zakim]
Sonic has Dims
20:25:49 [uyalcina]
yep
20:27:07 [steve_winkler]
18 Yess
20:27:12 [steve_winkler]
s/Yess/yes
20:27:15 [steve_winkler]
1 No
20:27:38 [hugo]
the No vote is Oracle
20:27:51 [steve_winkler]
RESOLUTION: LC 101 and 104 closed with the proposed resolution.
20:28:57 [steve_winkler]
TOPIC: LC5
20:29:58 [steve_winkler]
Mark: Several people mentioned that there were use cases around this property and removing it could be considered a substantive change.
20:30:24 [steve_winkler]
Mark: To remove it we still need to vote, but this kind of gives us an out.
20:30:57 [steve_winkler]
Mark: My opinion as chair is to mark it as a feature at risk so that we don't knock ourselves back to working draft.
20:31:21 [steve_winkler]
Marc: Colleagues at liberty alliance are planning on using it.
20:31:50 [steve_winkler]
Mark: We could mark it so, and get comments later that there will be formal objections if it's removed.
20:32:50 [steve_winkler]
Mark: The only argument against would be that we don't internally define any use for it.
20:33:29 [steve_winkler]
Marc: True, but we do that for others as well. I'm just saying that we know it's necessary, why take that step.
20:34:31 [Marsh]
+1 to mark at risk. We prefer to drop it, but not at the expense of the schedule. Marking at risk should flush out the constituency, or show it doesn't have one...
20:36:48 [Marsh]
Proxy to Paco again. Back in 45 min, but you might be done by then...
20:36:53 [Zakim]
-Marsh
20:36:59 [steve_winkler]
Bob: There is a potential security use there.
20:37:09 [prasad]
Wonder what action we would take if there is in act an objection to removing the source endpoint
20:37:26 [prasad]
s/act/fact
20:37:31 [steve_winkler]
Marc: In liberty, they want to use the metadata bucket to add information about who the message was from.
20:38:03 [dorchard]
+1 to "do something"
20:38:04 [Nilo]
did he say comfortable or UNcomfortable?
20:38:16 [Nilo]
i'd like to leave it in
20:40:28 [hugo]
Previous discussion at http://www.w3.org/2002/ws/addr/4/dec-f2f-minutes.html#item20
20:41:43 [chad]
chad has joined #ws-addr
20:41:49 [pauld]
chad, new poll
20:41:49 [chad]
new poll
20:42:08 [pauld]
chad, option 1: Flesh it out
20:42:18 [pauld]
chad, option 2: Mark at risk
20:42:30 [pauld]
chad, option 3: drop it
20:42:41 [pauld]
chad, option 4: Status Quo
20:43:08 [pauld]
chad, question: options for LC5
20:43:15 [pauld]
chad, question?
20:43:26 [pauld]
chad, options?
20:45:02 [RebeccaB]
vote: 4,2,3,1
20:45:07 [mlpeel]
vote: 2, 1
20:45:11 [marc]
vote: 4
20:45:12 [dorchard]
vote: 1, 2,3
20:45:15 [prasad]
vote: 1,2,3
20:45:20 [TonyR]
vote: 2, 4, 1, 3
20:45:24 [hugo]
vote: 2, 4, 1, 3
20:45:24 [dims]
dims has joined #ws-addr
20:45:25 [Nilo]
vote: 4, 1, 2
20:45:30 [steve_winkler]
vote: 2, 1, 4
20:45:33 [TRutt]
vote: 2,3,4,1
20:45:40 [dhull]
vote: 1, 3, 2
20:45:46 [GlenD]
vote: 2,1
20:45:47 [PaulKnight]
vote: 2,1,3,4
20:46:10 [pauld]
vote: 4, 2
20:46:20 [jeffm]
vote: 1, 2
20:46:37 [Paco]
2 4 3 1
20:47:03 [anish]
vote: michael: 2, 4
20:47:07 [bob]
vote: 1,2,4,3
20:47:21 [Paco]
vote: 2, 4, 3, 1
20:47:38 [pauld]
chad, count
20:47:38 [chad]
Question: options for LC5
20:47:38 [chad]
Option 1: Flesh it out (5)
20:47:38 [chad]
Option 2: Mark at risk (9)
20:47:38 [chad]
Option 3: drop it (0)
20:47:38 [chad]
Option 4: Status Quo (4)
20:47:39 [chad]
18 voters: bob (1, 2, 4, 3) , dhull (1, 3, 2) , dorchard (1, 2, 3) , GlenD (2, 1) , hugo (2, 4, 1, 3) , jeffm (1, 2) , marc (4) , michael (2, 4) , mlpeel (2, 1) , Nilo (4, 1, 2) , Paco (2, 4, 3, 1) , pauld (4, 2) , PaulKnight (2, 1, 3, 4) , prasad (1, 2, 3) , RebeccaB (4, 2, 3, 1) , steve_winkler (2, 1, 4) , TonyR (2, 4, 1, 3) , TRutt (2, 3, 4, 1)
20:47:44 [chad]
Round 1: Count of first place rankings.
20:47:46 [chad]
Round 2: First elimination round.
20:47:47 [steve_winkler]
vote: 2, 4, 1
20:47:48 [chad]
Eliminating candidadates without any votes.
20:47:50 [chad]
Eliminating candidate 3.
20:47:52 [chad]
Round 3: Eliminating candidate 4.
20:47:54 [chad]
Candidate 2 is elected.
20:47:56 [chad]
Winner is option 2 - Mark at risk
20:48:12 [pauld]
chad, details?
20:50:18 [steve_winkler]
RESOLUTION: LC5 is closed by marking the source endpoint and all associated machinery at risk.
20:53:21 [steve_winkler]
Mark: Please come tomorrow prepared to wrap up any loose ends.
20:53:43 [Zakim]
-Nilo
20:54:35 [steve_winkler]
Mark: We'll target final spec on Thursday, people can look at it and we can vote to go to CR on Monday.
20:56:19 [steve_winkler]
Hugo: When we decided to use XML Schema and whether it would be normative or not, and limited ourselves to XML 1.0, because XMLP did the same.
20:57:02 [steve_winkler]
Hugo: There has been push back. This would mean changing a couple of sentences in the core to say that we use XML 1.1.
20:57:33 [steve_winkler]
Hugo: Our schema isn't as complex as say WSDL 2.0, we could just say that it's 1.1 and leave it.
20:57:47 [steve_winkler]
Mark: This is the W3C looking at the overall stack.
20:57:54 [anish]
q+
20:58:36 [steve_winkler]
Hugo: The pushback, we have linked certain versions of tech to certain versions of other tech and there's a cascading effect that is a problem.
20:59:05 [steve_winkler]
Hugo: At an abstract level there is no reason to constrain to a particular version, but at a binding level certain specifics may want to be included.
21:00:03 [steve_winkler]
Paul: We've cited versions for WSDL and SOAP, but not XML.
21:00:38 [Zakim]
-Pete_Wenzel
21:02:31 [Zakim]
-DOrchard
21:03:37 [Zakim]
-Mark_Peel
21:04:59 [Zakim]
-prasad
21:05:21 [steve_winkler]
meeting recessed
21:05:40 [bob]
bob has left #ws-addr
21:05:49 [mnot]
rrsagent, generate the minutes
21:05:49 [RRSAgent]
I'm logging. I don't understand 'generate the minutes', mnot. Try /msg RRSAgent help
21:05:55 [mnot]
rrsagent, I hate you
21:05:55 [RRSAgent]
I'm logging. I don't understand 'I hate you', mnot. Try /msg RRSAgent help
21:06:06 [mnot]
rrsagent, please generate the minutes
21:06:06 [RRSAgent]
I'm logging. I don't understand 'please generate the minutes', mnot. Try /msg RRSAgent help
21:06:22 [mnot]
rrsagent, draft minutes
21:06:22 [RRSAgent]
I have made the request to generate http://www.w3.org/2005/07/18-ws-addr-minutes.html mnot
21:06:36 [TRutt]
TRutt has left #ws-addr
21:06:39 [mnot]
you pedantic freak
21:07:31 [yinleng]
yinleng has left #ws-addr
21:10:00 [Zakim]
disconnecting the lone participant, Sonic, in WS_(F2F)9:00AM
21:10:01 [Zakim]
WS_(F2F)9:00AM has ended
21:10:04 [Zakim]
Attendees were +1.781.280.aaaa, Prasad_Yendluri, +44.191.243.aabb, Mark_Peel, mlpeel, Andreas_Bjarlestam, Marsh, Mark, Paul, David, Tony, Tom, Marc, Steve, Umit, Kathy, Rebecca,
21:10:06 [Zakim]
... Glen, Hugo, Michael, PaulK, Jeff, Anish, Bob, yinleng, Paco, Nilo_Mitra, Dims, prasad, Pete_Wenzel, DOrchard, Nilo
21:34:41 [dhull]
dhull has joined #ws-addr
23:43:16 [dims]
dims has joined #ws-addr