IRC log of ws-ra on 2009-08-05

Timestamps are in UTC.

15:55:57 [RRSAgent]
RRSAgent has joined #ws-ra
15:55:57 [RRSAgent]
logging to
15:55:59 [trackbot]
RRSAgent, make logs public
15:55:59 [Zakim]
Zakim has joined #ws-ra
15:56:01 [trackbot]
Zakim, this will be WSRA
15:56:01 [Zakim]
ok, trackbot; I see WS_WSRA(F2F)11:30AM scheduled to start 26 minutes ago
15:56:02 [trackbot]
Meeting: Web Services Resource Access Working Group Teleconference
15:56:02 [trackbot]
Date: 05 August 2009
15:56:20 [Bob]
rrsagent, this meeting spans midnight
15:57:35 [Zakim]
WS_WSRA(F2F)11:30AM has now started
15:57:43 [Zakim]
15:58:37 [Vikas]
Vikas has joined #ws-ra
15:59:45 [Zakim]
15:59:46 [Zakim]
16:01:30 [li]
li has joined #ws-ra
16:02:13 [Zakim]
16:02:40 [Ram]
Ram has joined #ws-ra
16:07:10 [Bob]
scribe: Ram
16:07:17 [dug]
dug has joined #ws-ra
16:07:18 [Bob]
scribenick: Ram
16:08:25 [Bob]
16:08:34 [dug]
16:09:31 [Bob]
ack dug
16:10:23 [dug]
16:10:36 [Wu]
Wu has joined #ws-ra
16:10:49 [Ram]
scribe ram
16:11:05 [Ram]
Bob: I have sent a re-ordered agenda for the rest of the meeting.
16:13:41 [Ram]
Re-ordered agenda is accepted.
16:13:54 [Geoff]
Geoff has joined #ws-ra
16:14:07 [asir]
asir has joined #ws-ra
16:14:21 [Ram]
Issue 6432
16:14:37 [Sreed]
Sreed has joined #ws-ra
16:14:52 [DaveS]
DaveS has joined #ws-ra
16:14:54 [Tom_Rutt]
Tom_Rutt has joined #ws-ra
16:15:45 [Ram]
Bob explains the issue and the progression so far.
16:16:20 [Ram]
Ram posted a link
16:19:14 [li]
16:19:15 [Ram]
Bob says: Add the word 'the' in front of the phrase "such as".
16:20:05 [Bob]
s/in front of/after
16:20:23 [Bob]
ack li
16:20:48 [DaveS]
16:20:51 [Bob]
Yves: Suggest that eh capital MAY be changed to a "may"
16:21:03 [Bob]
s/eh /the /
16:21:52 [gpilz]
gpilz has joined #ws-ra
16:22:02 [Bob]
ack dave
16:23:30 [li]
where is the header in previous text?
16:24:22 [li]
ram: header is important and it should be defined in mc itself
16:24:46 [Ram]
Dave: Change the MAY to may.
16:24:58 [Ram]
Dave: This would make it clearly non-normative.
16:25:21 [li]
agree with ram
16:25:28 [Geoff]
16:26:59 [Bob]
ack geo
16:28:08 [Wu]
16:29:40 [Ram]
Ram: It is sufficient to note that the proposal uses a non-normative reference to WS-MakeConnection. No need to test. If companies are willing to test this that is fine but it is not necessary to pass CR.
16:30:08 [Bob]
ack yves
16:30:39 [Geoff]
change to ...A subscription manager MAY choose mechanisms,..
16:32:27 [Yves]
well, in order to communicate, they will have to do something. the MAY is really unneccessary
16:32:30 [Ashok]
Ashok has joined #ws-ra
16:32:35 [Yves]
16:32:42 [Geoff]
change to ...A subscription manager MAY choose to support mechanisms,..
16:32:51 [Bob]
ack wu
16:33:14 [Yves]
after that if they have to use WS-MC, then so be it, I have nothing against it :)
16:35:40 [Ram]
For revised proposal for 6432 see comment #8
16:35:41 [DaveS]
16:38:12 [Ram]
Wu: Need a way to indicate MC is used in NotifyTo.
16:39:03 [Bob]
ack dave
16:39:05 [dug]
16:39:14 [dug]
16:40:06 [Ram]
Wu and Yves are fine with the latest revised proposal (comment #8).
16:40:26 [Ram]
Dave: Fine with the latest edits.
16:41:01 [Ram]
Bob: Are members OK with proposal. Any objections?
16:41:15 [Ram]
No objections. Issue resolved.
16:41:23 [Ram]
Issue 6432 resolved.
16:42:33 [Ram]
Issue 6724 discussion.
16:44:11 [Ram]
Geoff: There is a proposal from Doug (comment #4) in the bug report. I have a subsequent proposal as well in the bug report.
16:44:41 [dug]
16:45:13 [Ram]
Geoff: The general question here is if there is value in creating an explicit resource representation of a subscription. No need to have two ways of doing the same thing. Since we have gone down the route of using explicit operations, we should continue to use it.
16:46:25 [DaveS]
16:46:47 [Ram]
Geoff: No need to define a Transfer resource representation for a subscription manager.
16:47:43 [Bob]
ack dug
16:48:38 [Ram]
Doug: Geoff' proposal does not address many problems. It is possible to take Geoff's proposal and address those problems.
16:49:42 [Ram]
Doug: If we choose NOT to use WS-Transfer operations, we need to add explicit operations to address the gaps.
16:49:58 [Ram]
Doug: However, there are some caveats.
16:50:19 [gpilz]
16:50:22 [Ram]
Doug: We need to find a way to get statistical information such as number of subscriptions, etc.
16:50:22 [Bob]
16:51:36 [Ram]
Geoff: The extensibility mechanism can allow for such statistical queries.
16:52:21 [Ram]
Geoff: Would it be acceptable to get past this point by agreeing to some generic getMetrics() operations?
16:52:40 [Ram]
Doug: It probably may work. I need to think a bit more.
16:52:47 [Bob]
ack dave
16:53:34 [Ram]
Dave: There is nothing in the spec that prevents us from composing with WS-Transfer. WS-Eventing is a targeted 80/20 use case. The getStatus() does that. The addition of more operations or linkage to WS-Transfer complicates this.
16:57:08 [Ram]
Dave: No need to have two ways to do the same thing. It is hard to make drastic changes.
16:57:18 [Bob]
ack gpi
16:57:32 [Ram]
Gil: Dave said most of what I wanted to say.
16:58:05 [Ram]
Gil: Do you need to add new operations to WS-Eventing and WS-Enumeration and so on?
16:58:25 [Bob]
16:58:55 [Geoff]
16:59:27 [Bob]
ack bob
17:00:05 [Ram]
Bob: I am speaking as Hitachi rep not as a chair. First off, optionality begets profilidity.
17:00:39 [Ram]
Bob: We have got frankly an organization (Hitachi) a bit schizophrenic with the issue of optionality.
17:01:00 [Ram]
Bob: The device people are of the feeling that if it is optional they would not do it.
17:01:21 [Ram]
Bob: They do not want new features.
17:01:37 [Ram]
Bob: They are so concerned about message size.
17:03:46 [Ram]
Bob: The large systems people are concerned about consistency / coherency of data as retrieved by queries.
17:04:17 [Ram]
The large systems people have no problems with policy.
17:05:12 [Wu]
17:05:15 [Ram]
Bob: The devices and large systems people do not want any get operations.
17:05:28 [Ram]
Bob: I propose to close this issue with no action.
17:05:54 [dug]
17:05:59 [Bob]
ack geo
17:06:34 [Bob]
ack wu
17:06:36 [li]
+1 bob
17:06:51 [Bob]
ack dug
17:07:17 [asir]
+1 bob
17:08:03 [Ram]
Doug: I don't agree.
17:08:53 [Bob]
ack yves
17:09:18 [Ram]
Doug: I would like to explore a possible proposal with Geoff and come back to this. There are some genuine reasons why people want this.
17:09:45 [Ram]
Yves: There are some security concerns. I understand that you may want to do such things, but it may be better to do this on the receiving side.
17:09:56 [Ram]
Yves: I prefer to have a constrained approach for security reasons.
17:12:42 [DaveS]
17:12:51 [Bob]
ack dave
17:13:04 [Ram]
Bob: Is there an interest to pursue the option of Doug and Geoff working together to propose a revised proposal.
17:16:44 [Ram]
Bob: Straw poll to close with no action or delay and produce a proposal.
17:17:22 [jeffm]
jeffm has joined #ws-ra
17:17:53 [Ram]
Close with no action: Microsoft, Avaya, CA, Fujitsu, Hitachi.
17:18:28 [Ram]
Delay: Oracle.
17:18:40 [Ram]
Add W3C to Close with no action.
17:19:15 [Zakim]
17:19:21 [Ram]
Action: Doug to come back witth a new proposal for 6724 before next meeting.
17:19:21 [trackbot]
Created ACTION-88 - Come back witth a new proposal for 6724 before next meeting. [on Doug Davis - due 2009-08-12].
17:27:37 [Ram]
Corrections to straw poll results on 6724.
17:27:53 [Ram]
Close with no action: Microsoft, Avaya, CA, Fujitsu, Hitachi, W3C.
17:28:02 [Ram]
Delay: IBM, Oracle.
17:29:22 [Ram]
Dave: I am willing to wait to see a proposal if it can be turned around quickly.
17:35:32 [Bob]
action: Doug to define a new proposal for 6724 for consideration on 2009-08-18
17:35:32 [trackbot]
Created ACTION-89 - Define a new proposal for 6724 for consideration on 2009-08-18 [on Doug Davis - due 2009-08-12].
17:36:21 [Ram]
Issue 7159 discussion.
17:37:39 [gpilz]
17:38:24 [DaveS]
17:38:36 [Geoff]
17:38:49 [Bob]
ack gp
17:38:53 [Ram]
Doug: No need to repeat what is said in WS-Addressing.
17:39:00 [Ram]
Gil: +1
17:39:21 [Bob]
ack dave
17:39:42 [Bob]
ack geo
17:39:52 [Ram]
Dave: We can drop the referred to text.
17:40:02 [Ram]
Geoff: Can we simply say what Transfer spec says?
17:40:12 [Ram]
Bob: Any objections to Geoff's proposal.
17:40:26 [Ram]
7159 resolved with wording in Transfer.
17:41:01 [asir]
17:41:35 [Ram]
6917 issue discussion.
17:44:01 [Bob]
proposal at
17:44:12 [Bob]
17:44:22 [Bob]
17:44:44 [Ram]
Gil explains his prposal.
17:46:19 [Ram]
Gil: There is a description and runtime aspect to the problem.
17:46:52 [Ram]
Gil: What do I filter based on multiple tags?
17:47:01 [Ashok]
17:47:43 [li]
17:47:53 [Ashok]
17:47:55 [Ram]
Ashok: Let us leave it as something we need to talk about.
17:49:13 [Ram]
Gil: These tags need to be disambiguated.
17:51:24 [Geoff]
17:52:11 [Bob]
ack li
17:53:29 [Ram]
Li: I like to treat these problem in two aspects. One is do we need to compose with WS-Topic. This is the source of this issue. The performance issue is with content based filtering.
17:53:58 [Ram]
Li: The other aspect is open-ended. Do we need to create another filtering mechanism besides WS-Topic.
17:54:45 [li]
17:55:35 [Ram]
Li: Option 1 is do nothing. WS-Topic can compose with WS-Eventing.
17:55:45 [Ram]
Li: Option 2. WS-Eventing can profile WS-Topic.
17:56:10 [Ram]
Li: Option 3: WS-Eventing says something such as WS-Topic can be used for content filtering.
17:56:18 [Ashok]
17:56:22 [Bob]
<windReport rdf:about="wind">...
17:56:42 [Wu]
+1 Li
17:57:47 [Ram]
Geoff: Question for Gil. It seems that event tags are static for each event. Is it true?
17:58:12 [DaveS]
17:58:16 [li]
we need to answer two questions 1) if and how to compose ws-topic; 2) another filtering mechanism
17:58:18 [Bob]
ack geo
17:58:19 [Ram]
Geoff: I would like to understand if WS-Eventing can compose with WS-Topic?
17:59:13 [Ram]
Gil: The question about whether the event tags are static is a bit complicated. It could be static and dynamic.
18:01:31 [li]
18:03:50 [Bob]
ack ashok
18:05:22 [Ram]
Ashok: Why can't the tags be part of the data content. Close this issue with no action.
18:05:39 [Ram]
Doug: Think of the tags are metadata.
18:05:42 [Wu]
18:07:54 [Bob]
ack dave
18:09:08 [Ram]
Dave: WS-Topic is infested with references to WS-Notification. While it is possible to compose WS-Topic with WS-Eventing, it is not so as it is. One may need to profile WS-Topic to make it composable with WS-Eventing.
18:10:17 [Ram]
Dave: I would not recommend using WS-Topic in WS-Eventing. We could use the event description tags (part of 6401 issue proposal) and describe how to use the WS-Topic tags.
18:11:13 [Bob]
ack li
18:11:41 [Ram]
Li: We talked about tagging. There is a W3C Recommendation SAWSDL.
18:12:14 [Geoff]
18:12:34 [Ashok]
18:14:18 [Ram]
Bob: Do you have an idea of what it would take to make SAWSDL compose with WS-Eventing?
18:14:29 [Yves]
18:15:08 [Yves]
18:15:14 [Yves]
(external annotations)
18:15:38 [DaveS]
18:15:41 [Ashok]
yves, RDF annotations, correct?
18:15:46 [Yves]
18:16:22 [Bob]
18:16:34 [Ram]
Wu: If we want to tag, we should use SAWSDL.
18:16:38 [Ashok]
18:17:02 [Ram]
Wu: But there is complexity involved in that process.
18:17:20 [Bob]
ack geo
18:17:20 [Ram]
Wu: A better way is to extend the specification for tagging purposes.
18:17:50 [Ram]
Geoff: There are a whole lot of approaches here. There is also complexity.
18:18:18 [Ram]
Geoff: I am getting concerned that this will end up being a long pole.
18:18:24 [li]
18:18:29 [asir]
actually, SAWZALL
18:18:31 [Bob]
18:18:58 [Ram]
Geoff: If this purely a performance thing and NOT a functional thing, can't we address this via some guidance on composition?
18:19:03 [Bob]
ack dave
18:19:27 [Wu]
We just need to say WS-E can be extended, e.g. through tagging using SAWSDL, to allow fast filtering
18:19:37 [Bob]
ack wu
18:19:55 [Ram]
Dave: We do have an interoperable way if not the performant way.
18:20:30 [Ram]
Dave: My inclination is to do the right thing - close this with no action. Put some guidance in the primer.
18:21:51 [Ram]
Bob: Does anyone have any objections?
18:22:03 [Ram]
Bob: We need to send a note to the issue submitter.
18:22:34 [Ram]
Dave: I volunteer to send the note to the issue submitter and mention about how we intend to discuss this in the primer.
18:24:05 [Ashok]
18:24:37 [Bob]
ack li
18:25:10 [Ram]
Bob: Issue closed with no action.
18:25:49 [li]
18:26:17 [Ram]
Issue-7204 Eventing: Delivery policy for delivery mode extension
18:28:51 [Ram]
18:29:54 [Wu]
18:30:25 [gpilz]
18:32:58 [Ram]
Wu explains his proposal.
18:37:21 [Ram]
Ashok: Typically, we do not have policy on a message. We only have policy on endpoints.
18:37:25 [DaveS]
18:37:30 [Bob]
ack dave
18:38:01 [Ram]
Dave: This is a question. Is this similar to how RMPolicy works?
18:38:05 [Ram]
Asir: No.
18:38:13 [Ram]
Ashok: Why not?
18:39:38 [Ram]
Wu: The idea is to decorate the Delivery element with the options you would support.
18:40:18 [Bob]
18:40:29 [DaveS]
18:41:16 [Tom_Rutt]
18:41:42 [Bob]
ack bob
18:42:47 [Ram]
Bob: WS-Policy is used to advertise a bunch of capabilities.
18:43:27 [Ram]
Bob: at the WSDL level.
18:44:58 [Ram]
Bob: What is the need to use policy in an atypical way?
18:45:25 [Ram]
Wu: The problem is with QNames and how to interpret them.
18:46:50 [Ram]
Wu: Policy allows composition and clear semantics.
18:47:27 [Ram]
Bob: Why not use the typical WSDL policy attachments and do it upfront?
18:48:07 [Bob]
18:49:06 [Bob]
ack dave
18:49:37 [Ram]
Dave: Close with No action.
18:50:11 [gpilz]
gpilz has joined #ws-ra
18:50:20 [dug]
Bob - I'd like to have some time after lunch to talk about the incorporation for 7159 - just 5 mins
18:50:37 [Ram]
Dave: The sink needs to know what it wants and should get the WSDL that it desires. No need to invent a poilcy framework since everything I need is in WSDL.
18:50:58 [Ram]
Dave: The WSDL definition for the sink has all the necessary information.
18:52:47 [dug]
18:53:13 [Ram]
Wu: What in policy prevents using push and pull together.
18:54:21 [dug]
18:55:19 [Tom_Rutt]
How would wu’s proposal would allow the following type of delivery extension:
18:55:21 [Tom_Rutt]
Add an extension to provide an alternateNotifyTo epr element. If an element of this QName is present in the delivery element, the semantics of the extension are that the event source can use the epr in the alternateNotifyTo element child of the deliveryElement to send the event delivery operation to if the primary NotifyTo address is unavailable for any reason.
18:55:23 [Tom_Rutt]
I do not understand how wu'sr proposal could handle such an extension, since I do not where the alternate epr would be carried in the subscribe request.
18:55:26 [Bob]
ack tom
18:57:18 [Ram]
Ashok: SHould the EPR goes into the policy assertion?
18:57:35 [Ram]
Doug: Shouldn't NotifyTo EPR also go into policy assertion?
18:58:19 [Ram]
Bob: Let us wrap up this discussion. Who feels this proposal is accepable?
18:58:47 [Ram]
Who feels that this issue be closed with no action.
18:58:55 [gpilz1]
gpilz1 has joined #ws-ra
18:59:01 [Ram]
Oracle, Fujitsu and IBM say close with no action.
18:59:40 [Ram]
Microsoft needs more time.
19:00:00 [Ram]
Bob: Would Aug 18th work?
19:00:10 [Ram]
Asir: Let us revisit after lunch time,.
19:00:19 [Ram]
Lunch break.
19:00:38 [Ram]
Break until 1pm Pacific Time.
19:00:42 [Zakim]
19:01:28 [Zakim]
20:04:14 [Zakim]
20:06:11 [dug]
20:06:28 [gpilz1]
scribenick: gpilz1
20:06:39 [gpilz1]
TOPIC: 7159
20:06:48 [DaveS]
DaveS has joined #ws-ra
20:06:54 [dug]
20:07:01 [gpilz1]
Doug: issue about cleaning up fault language around WS-Addr
20:07:16 [gpilz1]
... text is inconsistent across all specs
20:07:26 [gpilz1]
... first section should be boilerplate
20:07:32 [gpilz1]
... some had slightly different text
20:07:50 [gpilz1]
... WS-T doesn't even describe mapping of faul infoset to XML
20:08:35 [gpilz1]
... WS-Enum says MUST include fault action URI, WS-T says should, others (?) don't say anything
20:09:06 [gpilz1]
... would like to start out with consistent language across all specs (with MUST) and raise an issue, if necessary, if people disagree with the MUST
20:09:24 [gpilz1]
Bob: comments?
20:09:43 [gpilz1]
DaveS: we can raise a separate issue for separate specs if need be
20:10:04 [gpilz1]
RESOLVED: Doug to make fault text consistent across all specs
20:10:40 [gpilz1]
TOPIC: 7205
20:10:54 [Zakim]
20:11:13 [gpilz1]
20:11:18 [Zakim]
20:11:22 [gpilz1]
Wu: (reviews issue)
20:12:17 [Zakim]
20:13:51 [Ashok]
Ashok has joined #ws-ra
20:13:53 [gpilz1]
Bob: questions?
20:13:55 [Bob]
20:13:55 [Geoff]
20:14:02 [Bob]
ack geo
20:14:22 [gpilz1]
Geoff: the submission spec had a fault that returned the set of supported Modes
20:15:02 [gpilz1]
... we've now got a set of QNames in wse:Delivery, you could get a case (e.g. Push/Pull) that doesn't make sense
20:15:31 [gpilz1]
... first question is: did the submission spec do this as a simple means of negotiation?
20:15:46 [gpilz1]
... do we still think that is a relevant thing to do?
20:15:52 [gpilz1]
... is it useful?
20:16:07 [gpilz1]
... if we do think it is useful, we need to figure out what to return
20:16:58 [gpilz1]
Bob: in the submission version, the element that held detailed info on supported Modes was optional
20:17:16 [gpilz1]
... I have previously expressed my reservations about extension negotiation using faults
20:17:43 [gpilz1]
... if we need a negotiation mechanism, is WS-Policy enough?
20:18:03 [gpilz1]
... if we don't do that, a more reliable mechanism would be to return something in SubscribeResponse
20:18:53 [gpilz1]
... (speaking not as a chair for the above and the following)
20:19:12 [gpilz1]
... in previous specs, using faults to carry important information is not a good idea
20:19:24 [gpilz1]
Wu: if we have Policy we don't need to worry about the fault codes
20:20:33 [gpilz1]
Bob: you think there is a need to have an active mechanism to negotiate extensions built into the protocol?
20:20:41 [gpilz1]
Wu: yes, we should use Policy
20:20:50 [gpilz1]
... that way we don't need to invent anything
20:21:16 [gpilz1]
DaveS: you are saying that, if we use Policy we won't need this?
20:21:19 [gpilz1]
Wu: yes
20:21:34 [gpilz1]
Tom: Policy doesn't have a negotiation framework, how would that work?
20:22:04 [gpilz1]
Doug: I think that, when Wu says "use Policy" he means "use my proposal for using Policy to negotiatie extensions"
20:22:19 [gpilz1]
Wu: correct, I am profiling WS-Policy to meet a specific need
20:22:42 [gpilz1]
Geoff: isn't it kind of sufficient if the Source advertises it's Policy in the Event Source WSDL?
20:23:02 [gpilz1]
... we've already noted that we need to define an assertion that indicates "I support WS-Eventing"
20:23:30 [gpilz1]
... I'm assuming this would support things like Delivery extensions as well as support Formats, Filters, etc.
20:23:44 [gpilz1]
... If we did that, would that satisfy your requirements Wu?
20:25:18 [gpilz1]
Wu: (agrees that WS-Policy is optional)
20:25:51 [gpilz1]
... if you only specify the QName sequence in the Delivery wrapper, how do you separate them?
20:26:03 [gpilz1]
Geoff: I want to separate this issue from the first one
20:26:17 [gpilz1]
... Want to figure out what, if anything, needs to be returned in "the fault"
20:26:25 [DaveS]
20:26:34 [gpilz1]
... Policy is optional so you may not have Policy when you do the Subscribe
20:26:44 [gpilz1]
... and you may not send anything back on a fault
20:26:48 [gpilz1]
... and that could be OK
20:27:06 [Bob]
ack dave
20:27:25 [gpilz1]
DaveS: this model of "try something and, if it doesn't work, tell me what I can use" is there a default that always works?
20:27:31 [gpilz1]
All: (yes)
20:27:36 [gpilz1]
DaveS: then we don't need this
20:28:02 [gpilz1]
... You can always fall back to what you know works. This idea of tell you what works when you try something that doesn't work is a duplication of effort.
20:28:24 [gpilz1]
Wu: what happens if client does not support Policy and an extension isn't accepted
20:28:38 [gpilz1]
DaveS: then the client should fall back to what is known to work
20:28:43 [gpilz1]
Wu: there is one complication
20:29:06 [gpilz1]
... under the current spec, we have these default mechanism where there is nothing inside wse:Delivery
20:29:17 [gpilz1]
Geoff: incorrect, you have to have at least one element
20:29:26 [gpilz1]
Wu: is that specified in WS-Eventing?
20:29:32 [gpilz1]
All: (yes)
20:29:45 [gpilz1]
Geoff: there is a subtelty here - there is no default
20:29:57 [gpilz1]
... you have to have something in wse:Delivery
20:30:16 [gpilz1]
... but you could have an Event Source that didn't support NotifyTo but instead support "From"
20:30:37 [gpilz1]
DaveS: but there is no "must support" attached to NotifyTo?
20:30:40 [gpilz1]
Geoff: yes
20:30:43 [gpilz1]
DaveS: ouch
20:30:50 [gpilz1]
... not sure I like the strategy for this
20:31:11 [gpilz1]
... if there isn't a default solution that we know is going to work (from reading the spec)
20:31:42 [gpilz1]
... then it is a little unfair to developers/clients not to provide a default which is known to work in all cases
20:31:57 [gpilz1]
Doug: I'm not sure you can do that
20:32:16 [gpilz1]
... we can't require WS-Policy, we can't require people to support NotifyTo, etc.
20:32:23 [gpilz1]
... we don't have any alternatives
20:32:50 [gpilz1]
Geoff: we need to figure out the simplest, poor mans approach to providing a default that is known to work in all cases
20:33:09 [gpilz1]
DaveS: we don't have to provide something, but it is good spec ettiquite
20:33:40 [gpilz1]
Doug: another constraint - I would have to have the "poor man thing" be radically different than the "rich man thing"
20:33:54 [gpilz1]
... two completely different mechanisms is untenable
20:34:04 [Bob]
20:34:13 [gpilz1]
... if there is a poor man/rich man, the rich man needs to be an extension of the poor mans scheme
20:34:31 [gpilz1]
Geoff: does this lead to WS-Policy in extension negotiation
20:34:44 [gpilz1]
Doug: not necessarily
20:35:12 [gpilz1]
... if you want to find out what the Event Source supports you need to look at its WSDL and see what WS-Policies are advertised there
20:35:24 [gpilz1]
... to do something else is to invent a new policy language
20:35:43 [gpilz1]
Bob: I think we need to retain a fault that needs to be generated if there is "some nonsense"
20:36:00 [gpilz1]
... the detail element needs to say "the source of the nonsense is *this*"
20:36:01 [dug]
20:36:17 [gpilz1]
... that faulting mechanism already exists
20:37:23 [gpilz1]
... extension writers are going to write their extensions any way they want
20:37:46 [gpilz1]
Geoff: device people may create a fault that contains important info in the fault detail
20:37:50 [gpilz1]
... we can't stop them
20:38:00 [gpilz1]
Bob: (?)
20:38:16 [gpilz1]
Geoff: if we are going to specify something, it shouldn't be in the fault it should be in SubscribeRespone
20:38:25 [gpilz1]
Bob: or some kind of "probe" mechanism
20:38:35 [gpilz1]
Asir: but that doesn't exist today
20:38:40 [gpilz1]
Bob: no, it doesn't
20:38:49 [Wu]
20:38:59 [Bob]
ack dug
20:39:01 [gpilz1]
Geoff: MEX exists but, in this case, MEX would return policy
20:39:10 [gpilz1]
Doug: trying to figure out where we are
20:39:23 [gpilz1]
... we have a fault in Section 6.6 that says
20:39:31 [dug]
This fault is sent when the event source is not capable of fulfilling a Subscribe request for local reasons unrelated to the specific request.
20:39:54 [gpilz1]
... maybe we should remove the "for local reasons unrelated to the specific request" part
20:40:14 [gpilz1]
... we have 2 different types of faults here; one is similar to a mustUnderstand fault
20:40:30 [Geoff]
20:40:44 [gpilz1]
... if you detect a QName that you don't recognize and you choose not to ignore it - you can generate this fault
20:40:46 [gpilz1]
20:40:56 [Bob]
ack geoff
20:42:17 [gpilz1]
Geoff: there is a subtetly here; the is the mU header fault, there is "this one" (internal fault), then there is the case where you specify an arbitrary set of extensions that I understand, but their combo doesn't make any sense
20:43:20 [gpilz1]
Doug: I understand the extension - I think we should merge the "internal processing error" and the "you sent me wierd data" - but I could live with separate faults
20:43:37 [gpilz1]
Geoff: I like having the disctinction
20:43:55 [gpilz1]
Bob: one is "I'm sick" and the other is "I don't understand your jive"
20:44:07 [Bob]
ack gpi
20:44:41 [Wu]
20:45:00 [asir]
actually, it is 'I don't like your jive'!
20:46:53 [gpilz1]
Gil: (blathers on about something - basically agrees with Geoff but thinks fault shouldn't be overly specific)
20:47:13 [gpilz1]
Geoff: how far do we support people that don't use WS-Policy
20:48:31 [DaveS]
20:48:31 [gpilz1]
Bob (as geek not chair): there is an old technique where I try to create a connection
20:48:57 [gpilz1]
... I usually start with my most preferred alternative (full duplex, 56K/sec)
20:49:11 [gpilz1]
.. and I gradually back off through my prefered alternatives
20:49:34 [gpilz1]
... the only thing you need is some way of determining if the connection is successful
20:49:37 [gpilz1]
20:50:08 [gpilz1]
... w/regards to the multiplicity of extensions, etc. you can use multiple NotifyTo's
20:50:50 [gpilz1]
Geoff: sounds like you are saying "specify the fault and be done with it"
20:51:07 [Bob]
ack wu
20:51:10 [gpilz1]
Bob: point is that the client may never see the fault, but it needs to know if the Subscribe succeeded
20:51:25 [gpilz1]
Wu: "jive fault" should be grounding
20:51:33 [gpilz1]
Bob: anybody object to "jive fault"
20:51:46 [gpilz1]
DaveS: I'll make my comment, then answer
20:52:39 [gpilz1]
Wu: whether you "use Policy" (to decorate WSDL) or not, you should use this fault
20:52:45 [gpilz1]
... this is another grounding point
20:53:01 [gpilz1]
... we could also allow, optionally, in the fault message, the allowed alternatives
20:53:24 [gpilz1]
Geoff: what would that format look like, Policy?
20:53:27 [Bob]
q+ to spit the dummy on optional detail element content
20:53:53 [gpilz1]
Wu: up to the event source what the format of the detail is
20:53:58 [Bob]
ack dave
20:54:17 [gpilz1]
DaveS: I think I'm ok with "I'm sick" and "I don't understand your jive" as separate faults
20:54:32 [gpilz1]
... but we shouldn't drill down to far on the "I don't understand your jive" fault
20:55:04 [gpilz1]
... (???) has 12 different faults that all describe variations of "I don't understand your jive"
20:55:20 [Geoff]
20:55:27 [Bob]
acl gpi
20:55:40 [Bob]
20:55:45 [Bob]
ack gil
20:55:51 [Bob]
ack gpi
20:56:43 [Bob]
ack bob
20:56:43 [Zakim]
Bob, you wanted to spit the dummy on optional detail element content
20:56:54 [gpilz1]
Gil: cautions against optimizing for the case of detecting incompatible extensions
20:57:21 [gpilz1]
Bob (as geek): the point about optional detail on the jive fault is that it won't be processed by a machine
20:57:39 [gpilz1]
... you can't count on it for negotiation because ultimately a human being is going to process it
20:57:56 [gpilz1]
... and it might be expressed in a large number of ways
20:58:35 [gpilz1]
... perfectly happy with "jive fault" and "sick fault" and leave it up to the impl what it in the detail
20:58:55 [gpilz1]
... putting critical information in a fault that may never be received by the client seem foolhardy
20:59:06 [gpilz1]
... my preference: 2 faults with impl-dependent details
20:59:28 [gpilz1]
... if we still need something like a probing mechanism we can do that independently of the faulting mechanism
20:59:30 [DaveS]
+1 to Bob's suggestion.
21:00:03 [gpilz1]
Bob: propose that "this" is how we deal with faulting extensions
21:00:44 [gpilz1]
Doug: (clarifies) two faults: an "internal error" fault and an "there is something wrong with your request" fault
21:00:53 [gpilz1]
Geoff: (further clarifies)
21:01:42 [Bob]
proposed resolution:
21:01:43 [gpilz1]
AI: Bob to write a proposal the codifies the above
21:03:02 [Bob]
There are two faults defined. The current fault that indicates internal error, and a fault that replaces the invalidmode fault that indicates subscribeRequestInvalid
21:03:21 [Bob]
the detail elements of both of these fault would be implementation dependent
21:03:42 [Bob]
both faullts are "generated" and not necessarilly "transmitted"
21:19:25 [Zakim]
21:21:31 [dug]
[Detail] <wse:RetryAfter> ? (Optional)
21:21:39 [dug]
21:22:33 [dug]
21:22:50 [Bob]
ack geo
21:22:54 [Bob]
ack dug
21:23:42 [Wu]
21:25:21 [Wu]
21:26:37 [Bob]
There are two faults defined. The current fault that indicates internal error, and a fault that replaces the invalidmode fault that indicatessubscribeRequestInva lid the detail elements of both of these fault would be implementation dependent
21:26:39 [Bob]
both faullts are "generated" and not necessarilly "transmitted". The <wse:RetryAfter> element would be retained.
21:28:29 [Zakim]
21:29:49 [Bob]
There are two faults defined. The current fault that indicates internal error, and a fault that replaces the invalidmode fault that indicates subscribeRequestInvalid the detail elements of both of these fault would be implementation dependent both faullts are "generated" and not necessarilly "transmitted". The <wse:RetryAfter> element would be retained. Text that describes the generation of...
21:29:51 [Bob]
...these faults in the body of the spec will need to be adjusted accordingly.
21:31:27 [Bob]
RESOLUTION: Issue-7205 resolved with the proposal above
21:32:09 [Wu]
21:32:20 [Bob]
Topic: Issue-7206
21:35:27 [Tom_Rutt]
21:35:39 [dug]
21:35:51 [Bob]
ack tom
21:36:25 [Bob]
ack dug
21:37:03 [Geoff]
21:38:48 [gpilz]
gpilz has joined #ws-ra
21:39:28 [gpilz]
All: (discussion of above issue)
21:43:02 [Wu]
21:44:02 [Bob]
ack geo
21:46:12 [gpilz]
Bob: WS-Eventing operates in accordance to the rules of the SOAP processing model
21:46:25 [gpilz]
... according to that model, extensions can be ignored
21:46:49 [gpilz]
... if is important for the service to understand it, you can use mU
21:47:10 [gpilz]
... you can use extensions w/out mU and you can use extensions to the response to indicate acceptance
21:47:38 [gpilz]
... non-understood mU will generate a fault
21:47:40 [gpilz]
21:48:05 [gpilz]
... you have all the tools you need in this model to do what you need to do
21:48:19 [gpilz]
... one way to determine what is supported and what is not is to use mU to generate faults
21:48:35 [gpilz]
All: very simple negotiation
21:48:59 [gpilz]
Geoff: I'm not sure that is the actual problem
21:49:26 [gpilz]
... the problem is I can ignore things and you can't tell what I ignored and what I didn't ignore (for all those thing in which there was no mU)
21:49:52 [DaveS]
21:50:17 [gpilz]
Bob: the microbit that is not support according to the SOAP processing model is that I'd like to request an extens w/out mU but I'd like to know if it is ignored
21:50:46 [gpilz]
Geoff: if I send Subscribe with NotifyTo and Pull and no mU headers, I need to understand what was enabled
21:51:01 [li]
21:51:29 [gpilz]
... it seems to be usefull to indicate which extensions were honored
21:53:04 [Bob]
ack wu
21:53:35 [gpilz]
Wu: if I want to have an extension to Subscribe where I can either deliver to my office or my home
21:53:55 [gpilz]
... I need to know, in the Subscribe response, where the Notifications will be sent
21:54:01 [Bob]
ack gp
21:54:31 [DaveS]
21:54:36 [DaveS]
What gil said.
21:56:05 [li]
21:57:05 [gpilz]
Gil: there is no issue here becase SubscribeResponse has an extension point that extension authors can use to indicate acceptance of/agreeement to the request extension(s)
21:57:49 [gpilz]
Bob: need section in the primer on this subject: SubscribeRespone provides an extension point that (see above)
21:58:00 [asir]
q+ to ask Wu a question
21:58:07 [dug]
21:59:10 [dug]
21:59:19 [Bob]
ack asir
21:59:19 [Zakim]
asir, you wanted to ask Wu a question
21:59:42 [gpilz]
Asir: perhaps it would be easier to use your earlier example that . . . .
22:00:28 [gpilz]
... perhaps you and Gil are saying the same thing
22:00:33 [gpilz]
Wu: (explain use case)
22:00:43 [dug]
22:02:32 [Wu]
22:07:13 [gpilz]
Wu: problem arises when you specify a choice of policy alternatives on Subscribe, you need to know which one was picked for that Subscription
22:07:38 [gpilz]
Asir: you can use the extension point of SubscribeResponse to indicate which alternative was chosen
22:07:55 [gpilz]
Wu: when you echo back, you have to attach this response to the Delivery element
22:08:12 [gpilz]
Asir: you want a Delivery element on SubscribeResponse?
22:08:40 [gpilz]
... Wu wants a place to put the acknowledgement extension
22:09:14 [Bob]
ack dug
22:09:19 [gpilz]
Doug: how closely tied is this issue to your other issues?
22:09:28 [gpilz]
... do you see something other than what Bob wants?
22:09:51 [gpilz]
Wu: if you allow extension developers to pick QNames, it acts as an alternative to WS-Policy
22:10:11 [gpilz]
Doug: let's say the Subscribe request can be extended by QNames (no Policy)
22:10:30 [gpilz]
... if we say that extension authors can use the xs:any of SubscribeResponse, is that ok?
22:10:33 [gpilz]
Wu: in Delivery?
22:10:49 [gpilz]
22:11:11 [gpilz]
Doug: is this only need for the extensions-are-WS-Policy or in the general case?
22:11:16 [gpilz]
Wu: general case
22:11:44 [gpilz]
Doug: you are assuming that QName can appear either in Delivery and outside Delivery
22:12:21 [gpilz]
... so the semantics of inside and outside Delivery are so distinct that you need a Delivery element in SubscribeResponse to indicate that different things have been accepted
22:12:36 [gpilz]
... and it wouldn't be better just to use 2 different QNames?
22:13:38 [gpilz]
Wu: (need Delivery element)
22:14:39 [gpilz]
All: (general discussion ensues)
22:15:09 [Bob]
22:16:18 [Bob]
ack wu
22:17:34 [gpilz]
Bob: we put in the appropriate place (where we talk about extensions - 3.2) "extension authors are delegated the task of extending response message to indicate the understanding of and acceptance of the extension in the request"
22:17:49 [dug]
22:18:12 [asir]
is this the exact text or direction?
22:19:17 [Geoff]
22:20:18 [gpilz]
AI: Gil to write up proposal for above text
22:20:26 [gpilz]
Doug: I want to put this everywhere
22:21:06 [gpilz]
Bob: sprinkle on all specification liberally
22:21:13 [Bob]
ack dug
22:21:18 [Bob]
ack geo
22:21:18 [gpilz]
Geoff: oh d*mn!
22:21:30 [gpilz]
... we have one element that we actually define "NotifyTo"
22:21:42 [gpilz]
... we have no "NotifyTo" in the SubscribeResponse
22:21:55 [gpilz]
... we probably need to define one?
22:21:59 [gpilz]
Doug: don't think so
22:22:09 [gpilz]
Bob: NotifyTo is our very first extension
22:22:58 [gpilz]
All: (general discussion ensues)
22:25:10 [dug]
22:26:13 [Bob]
directional resolution agreed.
22:26:16 [gpilz]
RESOLUTION: (directional) Gil to write up text (AI above)
22:49:03 [gpilz]
TOPIC: issue 6642
22:50:57 [Bob]
22:55:55 [asir]
22:58:49 [Bob]
ack asir
22:59:13 [gpilz]
Asir: we need a way to address the explicit/implicit operation problem before we can talk about this
22:59:30 [gpilz]
... when a Subscriber subscribes he gets back a Subscription Manager EPR
22:59:57 [gpilz]
... there needs to be a way to get from the Subscription Manager EPR to the metadata that applies to the Subscription Manager
23:00:20 [gpilz]
... its up to the Event Source to use the "Metadata" bucket of the SubMgr EPR to include MEX
23:00:30 [gpilz]
... or you can use HTTP GET ....?wsdl
23:00:37 [gpilz]
... or pick up the phone
23:00:46 [gpilz]
... or perhaps a manual
23:01:13 [gpilz]
Ashok: but you are telling us that this Subscription Manager is populated with its policy
23:01:18 [gpilz]
Wu: that's an option
23:01:28 [gpilz]
Ashok: once that occurs you can do whatever you want
23:02:01 [gpilz]
... I think you are telling us that the Subscription Manager has it's policy in EPR, and then you can access that somehow
23:02:07 [gpilz]
... yes
23:02:25 [gpilz]
23:05:47 [gpilz]
TOPIC: issue 6694
23:06:44 [gpilz]
Doug: (describes issue)
23:08:25 [gpilz]
23:09:09 [asir]
23:09:31 [Bob]
ack gp
23:09:42 [li]
23:11:21 [Wu]
23:11:35 [Bob]
ack asir
23:11:51 [gpilz]
Asir: still trying to collect data to better understand the problem
23:12:53 [gpilz]
... Gil says it causes the unnecessary stubs
23:13:02 [gpilz]
Gil: its not just stubs, it is the programming model
23:13:07 [asir]
23:13:16 [Bob]
ack li
23:13:25 [gpilz]
Li: I have a question for these implicit operations
23:14:09 [gpilz]
... implicit operations means if I have an application service that wants to use eventing or mex, by doing implicit operations I would hide the operations for eventing or mex from the application WSDL
23:14:23 [gpilz]
... the application service would not define the bindings for those operations
23:14:45 [gpilz]
... as a client, if I want to send a subscribe message, where do I get the binding
23:14:53 [gpilz]
Asir: (reiterates)
23:15:13 [gpilz]
Doug: look at how other specs to implicit specs like WS-RM
23:15:27 [gpilz]
... the binding is declared in the WSDL included in the WS-RM spec
23:15:41 [gpilz]
Li: I think Asir understands me correctly
23:15:51 [gpilz]
... the client needs the whole WSDL to generate the code
23:15:59 [gpilz]
... at the same time the WSDL is hidden from the client
23:16:24 [gpilz]
23:16:47 [gpilz]
Doug: if operations are implicit there is no "client side" to be generated, it's part of the SOAP stack
23:17:17 [gpilz]
Li: if I need to communicate to the service where the operation is hidden, I need to download a library?
23:17:43 [Zakim]
23:18:02 [gpilz]
Gil: there is a WSDL for the client to look at - its in the spec
23:18:03 [Bob]
ack wu
23:18:07 [dug]
23:18:08 [gpilz]
Wu: I share these concerns
23:18:18 [gpilz]
... Eventing is very rich
23:18:41 [gpilz]
... I'm am concerned that, given all the optionality in Eventing, it can be used properly with implicit operations
23:18:48 [Bob]
ack asir
23:19:00 [li]
dug: you would need both client and server side intrastructure code to work
23:19:03 [gpilz]
Asir: two concerns have been expressed
23:19:17 [asir]
23:19:19 [gpilz]
... I would like to have a firm understanding of what is meant by implicit
23:19:22 [Bob]
ack gp
23:27:19 [li]
but authentication alglorithms have different strength
23:30:12 [Bob]
ack gpi
23:30:21 [Bob]
ack dug
23:31:06 [gpilz]
Doug: depending upon what the policy assertion means, implicit behind that is a definition of the operations that will be supported by that endpoint
23:32:20 [gpilz]
... are there use cases in which the individual operations require separate policy?
23:32:36 [gpilz]
... even if there are, its not a given that you must make the operations explicit
23:32:38 [Wu]
23:33:06 [gpilz]
... there are other ways to relate policy to implicit operations that don't require making the operations explicit
23:33:10 [Bob]
ack asir
23:33:17 [gpilz]
Asir: I haven't heard any new concerns
23:33:30 [gpilz]
... I understand this issue well enough for now
23:33:52 [gpilz]
... I suggest we think in pieces before we try and put it all together
23:34:02 [gpilz]
... one person is implementing an eventing stack
23:34:10 [gpilz]
... another is an eventing application programmer
23:36:42 [gpilz]
... (mentions WS-Trust as another example of an infrastructure spec)
23:40:02 [gpilz]
All: (discussion ensues)
23:40:03 [gpilz]
23:41:18 [dug]
23:41:48 [li]
23:42:51 [gpilz]
Wu: in this implicit scenario, how do I know what kind of Events will be omitted by the port?
23:43:32 [li]
23:44:42 [Bob]
ack wu
23:45:21 [gpilz]
Asir: presence of the wsem:Eventing policy indicates that you can do a MEX GetMetadata and retrieve either EventDescriptions or Notification WSDL
23:45:28 [Bob]
ack dug
23:46:02 [gpilz]
Doug: I'm OK with everything being implicit
23:46:27 [gpilz]
... but if the solution for different QoS on different protocols (eventing, enum) is to split my endpoint up, I don't like it
23:47:11 [gpilz]
... if we want to support different QoS either at the spec level or for operations within the specs, I can't live with a solution that requires the implementer to split their port up
23:47:45 [gpilz]
Asir: let's say you have another assertion for Transfer (E - for Eventing, T - for Transfer)
23:48:10 [gpilz]
... so you build a policy expression with two alternatives, E and a bunch of stuff and T and a bunch of stuff
23:48:24 [gpilz]
... if you talk 'E' you get all the stuff that shares an alternative with E
23:48:39 [gpilz]
... if you talk 'T' you get all the stuff that shares an alternative with T
23:50:03 [gpilz]
Doug: this still leaves the problem of per-operation policies within the same spec
23:56:36 [dug]
23:56:54 [Bob]
ack dug
00:01:14 [dug]
00:01:24 [Bob]
00:02:27 [Bob]
ack dug
00:04:19 [li]
00:05:18 [dug]
This WSDL describes the WS-MC protocol from the point of view of the endpoint that receives the MakeConnection message.
00:05:20 [dug]
Also note that this WSDL is intended to describe the internal structure of the WS-MC protocol, and will not generally appear in a description of a WS-MC-capable Web service. See section 3.4 Policy for a higher-level mechanism to indicate that WS-MC is supported.
00:05:21 [gpilz]
RESOLUTION: (directional) everything is implicitly defined with WS-Policy assertions, optionality of operations to be indicated by sub-assertions or some other appropriate WS-Policy mechanism
00:06:09 [asir]
00:06:27 [jeffm]
jeffm has joined #ws-ra
00:06:37 [Bob]
ack li
00:07:43 [Wu]
00:08:11 [Bob]
ack asir
00:08:26 [gpilz]
00:08:55 [Wu]
It is too narrow if every evening implementation must be implicit.
00:09:02 [Bob]
ack wu
00:09:08 [gpilz]
there is no "MUST" in the above sentence
00:09:19 [gpilz]
it says "will not generally appear"
00:09:27 [dug]
This WSDL is intended to describe the internal structure of the XXX protocol, and will not generally appear in a description of a XXX capable Web service. See section xxx for a higher-level mechanism to indicate that XXX is supported.
00:09:40 [dug]
00:10:07 [Wu]
00:10:09 [li]
we should not mandate everybody to hide implicit opreations, we give them choices
00:11:08 [Bob]
ack gpi
00:14:04 [asir]
this is generally a blog/wiki/primer material
00:14:28 [Bob]
ack dug
00:14:57 [asir]
00:15:20 [Bob]
ack asir
00:16:17 [Wu]
00:16:40 [jeffm]
00:18:34 [Bob]
ack jeff
00:19:15 [li]
00:21:20 [Bob]
ack li
00:22:27 [Bob]
RESOLUTION: (directional) everything is implicitly defined with WS-Policy assertions, optionality of operations to be indicated by sub-assertions or some other appropriate WS-Policy mechanism
00:23:12 [Wu]
00:23:19 [asir]
00:24:07 [li]
+1 wu
00:25:07 [Bob]
RESOLUTION: (directional) everything is implicitly defined with WS-Policy assertions, optionality of operations to be indicated by assertions or some other appropriate WS-Policy mechanism. In addition the wsdl will be in the specs
00:25:43 [Wu]
It should be "If things are defined implicitly, it should be defined through WS-policy
00:30:16 [li]
+1 asir
00:31:54 [asir]
If a WS-RA behavior is represented using one or more policy assertions, operations corresponding to the behavarior are implicitly defined. The WS-RA protocol specs will define WSDLs and XML Schemas.
00:32:11 [dug]
This WSDL is intended to describe the internal structure of the XXX protocol, and MUST NOT appear in a description of a XXX capable Web service. See section xxx for a higher-level mechanism to indicate that XXX is supported.
00:34:54 [Bob]
RESOLUTION: (directional) everything is implicitly defined with WS-Policy assertions, optionality of operations to be indicated by assertions or some other appropriate WS-Policy mechanism. In addition the wsdl will be in the specs
00:36:03 [gpilz]
RESOLVED: motion carries
00:37:18 [Wu]
We are very concerned that "everything is implicitly defined with WS-Policy assertions"
00:37:39 [Bob]
rrsagent, generate minutes
00:37:39 [RRSAgent]
I have made the request to generate Bob
00:37:58 [Bob]
resolution carries 1 to lots
00:38:03 [Bob]
rrsagent, generate minutes
00:38:03 [RRSAgent]
I have made the request to generate Bob
00:41:02 [li]
msg geoff good luck!
00:41:48 [Zakim]
00:42:19 [Zakim]
00:42:20 [Zakim]
WS_WSRA(F2F)11:30AM has ended
00:42:21 [Zakim]
Attendees were [Microsoft], Yves, Vikas, li
00:54:20 [gpilz]
gpilz has left #ws-ra