Web Services Resource Access Working Group Face to Face

05 Aug 2009


See also: IRC log


Ashok Malhotra, Oracle Corp.
Asir Vedamuthu, Microsoft Corp.
Bob Freund, Hitachi, Ltd.
David Snelling, Fujitsu, Ltd.
Doug Davis, IBM
Geoff Bullen, Microsoft Corp.
Gilbert Pilz, Oracle Corp.
Jeff Mischkinsky, Oracle Corp.
Li Li, Avaya Communications
Ram Jeyaraman, Microsoft Corp.
Sreedhara Narayanaswamy, CA
Tom Rutt, Fujitsu, Ltd.
Vikas Varma, Software AG
Wu Chou, Avaya Communications
Yves Lafon, W3C/ERCIM
Bob Natale, MITRE Corp.
Fred Maciel, Hitachi, Ltd.
Katy Warr, IBM
Mark Little, Red Hat
Orit Levin, Microsoft Corp.
Paul Fremantle, WSO2
Paul Nolan, IBM
Prasad Yendluri, Software AG
Bob Freund, Hitachi, Ltd.
Ram Jeyaraman, Gilbert Pilz


<trackbot> Date: 05 August 2009

<Bob> scribe: Ram

<Bob> scribenick: Ram

scribe ram

Bob: I have sent a re-ordered agenda for the rest of the meeting.

Re-ordered agenda is accepted.


Bob explains the issue and the progression so far.

Ram posted a link http://www.w3.org/Bugs/Public/show_bug.cgi?id=6432

Bob says: Add the word 'the' after the phrase "such as".

<Bob> Yves: Suggest that the capital MAY be changed to a "may"

<li> where is the header in previous text?

<li> ram: header is important and it should be defined in mc itself

Dave: Change the MAY to may.
... This would make it clearly non-normative.

<li> agree with 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.

<Geoff> change to ...A subscription manager MAY choose mechanisms,..

<Yves> well, in order to communicate, they will have to do something. the MAY is really unnecessary

<Geoff> change to ...A subscription manager MAY choose to support mechanisms,..

<Yves> after that if they have to use WS-MC, then so be it, I have nothing against it :)

For revised proposal for 6432 see comment #8 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6432

Wu: Need a way to indicate MC is used in NotifyTo.

Wu and Yves are fine with the latest revised proposal (comment #8).

Dave: Fine with the latest edits.

Bob: Are members OK with proposal. Any objections?

No objections. Issue resolved.

RESOLUTION: Issue 6432 resolved with comment #8.


Geoff: There is a proposal from Doug (comment #4) in the bug report. I have a subsequent proposal as well in the bug report.
... 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.
... No need to define a Transfer resource representation for a subscription manager.

Doug: Geoff' proposal does not address many problems. It is possible to take Geoff's proposal and address those problems.
... If we choose NOT to use WS-Transfer operations, we need to add explicit operations to address the gaps.
... However, there are some caveats.
... We need to find a way to get statistical information such as number of subscriptions, etc.

Geoff: The extensibility mechanism can allow for such statistical queries.
... Would it be acceptable to get past this point by agreeing to some generic getMetrics() operations?

Doug: It probably may work. I need to think a bit more.

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.
... No need to have two ways to do the same thing. It is hard to make drastic changes.

Gil: Dave said most of what I wanted to say.
... Do you need to add new operations to WS-Eventing and WS-Enumeration and so on?

Bob: I am speaking as Hitachi rep not as a chair. First off, optionality begets profilidity.
... We have got frankly an organization (Hitachi) a bit schizophrenic with the issue of optionality.
... The device people are of the feeling that if it is optional they would not do it.
... They do not want new features.
... They are so concerned about message size.
... The large systems people are concerned about consistency / coherency of data as retrieved by queries.

The large systems people have no problems with policy.

Bob: The devices and large systems people do not want any get operations.
... I propose to close this issue with no action.

<li> +1 bob

<asir> +1 bob

Doug: I don't agree.
... I would like to explore a possible proposal with Geoff and come back to this. There are some genuine reasons why people want this.

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.
... I prefer to have a constrained approach for security reasons.

Bob: Is there an interest to pursue the option of Doug and Geoff working together to propose a revised proposal.
... Straw poll to close with no action or delay and produce a proposal.

Close with no ACTION: Microsoft, Avaya, CA, Fujitsu, Hitachi.

Delay: Oracle.

Add W3C to Close with no action.

<scribe> ACTION: Doug to come back witth a new proposal for 6724 before next meeting. [recorded in http://www.w3.org/2009/08/05-ws-ra-minutes.html#action01]

Corrections to straw poll results on 6724.

Close with no ACTION: Microsoft, Avaya, CA, Fujitsu, Hitachi, W3C.

Delay: IBM, Oracle.

Dave: I am willing to wait to see a proposal if it can be turned around quickly.

<Bob> ACTION: Doug to define a new proposal for 6724 for consideration on 2009-08-18 [recorded in http://www.w3.org/2009/08/05-ws-ra-minutes.html#action02]

<trackbot> Created ACTION-89 - Define a new proposal for 6724 for consideration on 2009-08-18 [on Doug Davis - due 2009-08-12].


Doug: No need to repeat what is said in WS-Addressing.

Gil: +1

Dave: We can drop the referred to text.

Geoff: Can we simply say what Transfer spec says?

Bob: Any objections to Geoff's proposal.

RESOLUTION: Resolve Issue-7159 with the wording used in Transfer.

<asir> cool


<Bob> proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0093.html

<Bob> and http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0094.html

<Bob> and http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0095.html

Gil explains his prposal.

Gil: There is a description and runtime aspect to the problem.
... What do I filter based on multiple tags?

Ashok: Let us leave it as something we need to talk about.

Gil: These tags need to be disambiguated.

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.
... The other aspect is open-ended. Do we need to create another filtering mechanism besides WS-Topic.

<li> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009May/0176.html

Li: Option 1 is do nothing. WS-Topic can compose with WS-Eventing.
... Option 2. WS-Eventing can profile WS-Topic.
... Option 3: WS-Eventing says something such as WS-Topic can be used for content filtering.

<Bob> <windReport rdf:about="wind">...

<Wu> +1 Li

Geoff: Question for Gil. It seems that event tags are static for each event. Is it true?

<li> we need to answer two questions 1) if and how to compose ws-topic; 2) another filtering mechanism

Geoff: I would like to understand if WS-Eventing can compose with WS-Topic?

Gil: The question about whether the event tags are static is a bit complicated. It could be static and dynamic.

Ashok: Why can't the tags be part of the data content. Close this issue with no action.

Doug: Think of the tags are metadata.

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.
... 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.

Li: We talked about tagging. There is a W3C Recommendation SAWSDL.

<Ashok> SAWSDL

Bob: Do you have an idea of what it would take to make SAWSDL compose with WS-Eventing?

<Yves> http://www.w3.org/TR/sawsdl/

<Yves> http://www.w3.org/TR/sawsdl/#external

<Yves> (external annotations)

<Ashok> yves, RDF annotations, correct?

<Yves> yes

<Bob> http://www.milwaukeeconnect.com/webapp/wcs/stores/servlet/product_27_40028_-1_747354_201248_192137

Wu: If we want to tag, we should use SAWSDL.
... But there is complexity involved in that process.
... A better way is to extend the specification for tagging purposes.

Geoff: There are a whole lot of approaches here. There is also complexity.
... I am getting concerned that this will end up being a long pull.

<asir> actually, SAWZALL

Geoff: If this purely a performance thing and NOT a functional thing, can't we address this via some guidance on composition?

<Wu> We just need to say WS-E can be extended, e.g. through tagging using SAWSDL, to allow fast filtering

Dave: We do have an interoperable way if not the performant way.
... My inclination is to do the right thing - close this with no action. Put some guidance in the primer.

Bob: Does anyone have any objections?
... We need to send a note to the issue submitter.

Dave: I volunteer to send the note to the issue submitter and mention about how we intend to discuss this in the primer.

RESOLUTION: Close Issue-6917 with no action.

Issue-7204 Eventing: Delivery policy for delivery mode extension


<Wu> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0050.html

Wu explains his proposal.

Ashok: Typically, we do not have policy on a message. We only have policy on endpoints.

Dave: This is a question. Is this similar to how RMPolicy works?

Asir: No.

Ashok: Why not?

Wu: The idea is to decorate the Delivery element with the options you would support.

Bob: WS-Policy is used to advertise a bunch of capabilities.
... at the WSDL level.
... What is the need to use policy in an atypical way?

Wu: The problem is with QNames and how to interpret them.
... Policy allows composition and clear semantics.

Bob: Why not use the typical WSDL policy attachments and do it upfront?

Dave: Close with No action.

<dug> Bob - I'd like to have some time after lunch to talk about the incorporation for 7159 - just 5 mins

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.
... The WSDL definition for the sink has all the necessary information.

Wu: What in policy prevents using push and pull together.

<Tom_Rutt> How would wuÕs proposal would allow the following type of delivery extension:

<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.

<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.

Ashok: SHould the EPR goes into the policy assertion?

Doug: Shouldn't NotifyTo EPR also go into policy assertion?

Bob: Let us wrap up this discussion. Who feels this proposal is accepable?

Who feels that this issue be closed with no action.

Oracle, Fujitsu and IBM say close with no action.

Microsoft needs more time.

Bob: Would Aug 18th work?

Asir: Let us revisit after lunch time,.

Lunch break.

Break until 1pm Pacific Time.

<dug> http://www.w3.org/2002/ws/ra/edcopies/wsenum.html#Faults

<gpilz1> scribenick: gpilz1

Issue-7159 editorial revisitation

<dug> http://www.w3.org/2002/ws/ra/edcopies/wsenum.html#Faults

Doug: issue about cleaning up fault language around WS-Addr
... text is inconsistent across all specs
... first section should be boilerplate
... some had slightly different text
... WS-T doesn't even describe mapping of faul infoset to XML
... WS-Enum says MUST include fault action URI, WS-T says should, others (?) don't say anything
... 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

Bob: comments?

DaveS: we can raise a separate issue for separate specs if need be

RESOLUTION: Doug to make fault text consistent across all specs



Wu: (reviews issue)

Bob: questions?

Geoff: the submission spec had a fault that returned the set of supported Modes
... 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
... first question is: did the submission spec do this as a simple means of negotiation?
... do we still think that is a relevant thing to do?
... is it useful?
... if we do think it is useful, we need to figure out what to return

Bob: in the submission version, the element that held detailed info on supported Modes was optional
... I have previously expressed my reservations about extension negotiation using faults
... if we need a negotiation mechanism, is WS-Policy enough?
... if we don't do that, a more reliable mechanism would be to return something in SubscribeResponse
... (speaking not as a chair for the above and the following)
... in previous specs, using faults to carry important information is not a good idea

Wu: if we have Policy we don't need to worry about the fault codes

Bob: you think there is a need to have an active mechanism to negotiate extensions built into the protocol?

Wu: yes, we should use Policy
... that way we don't need to invent anything

DaveS: you are saying that, if we use Policy we won't need this?

Wu: yes

Tom: Policy doesn't have a negotiation framework, how would that work?

Doug: I think that, when Wu says "use Policy" he means "use my proposal for using Policy to negotiatie extensions"

Wu: correct, I am profiling WS-Policy to meet a specific need

Geoff: isn't it kind of sufficient if the Source advertises it's Policy in the Event Source WSDL?
... we've already noted that we need to define an assertion that indicates "I support WS-Eventing"
... I'm assuming this would support things like Delivery extensions as well as support Formats, Filters, etc.
... If we did that, would that satisfy your requirements Wu?

Wu: (agrees that WS-Policy is optional)
... if you only specify the QName sequence in the Delivery wrapper, how do you separate them?

Geoff: I want to separate this issue from the first one
... Want to figure out what, if anything, needs to be returned in "the fault"
... Policy is optional so you may not have Policy when you do the Subscribe
... and you may not send anything back on a fault
... and that could be OK

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?

All: (yes)

DaveS: then we don't need this
... 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.

Wu: what happens if client does not support Policy and an extension isn't accepted

DaveS: then the client should fall back to what is known to work

Wu: there is one complication
... under the current spec, we have these default mechanism where there is nothing inside wse:Delivery

Geoff: incorrect, you have to have at least one element

Wu: is that specified in WS-Eventing?

All: (yes)

Geoff: there is a subtelty here - there is no default
... you have to have something in wse:Delivery
... but you could have an Event Source that didn't support NotifyTo but instead support "From"

DaveS: but there is no "must support" attached to NotifyTo?

Geoff: yes

DaveS: ouch
... not sure I like the strategy for this
... if there isn't a default solution that we know is going to work (from reading the spec)
... then it is a little unfair to developers/clients not to provide a default which is known to work in all cases

Doug: I'm not sure you can do that
... we can't require WS-Policy, we can't require people to support NotifyTo, etc.
... we don't have any alternatives

Geoff: we need to figure out the simplest, poor mans approach to providing a default that is known to work in all cases

DaveS: we don't have to provide something, but it is good spec ettiquite

Doug: another constraint - I would have to have the "poor man thing" be radically different than the "rich man thing"
... two completely different mechanisms is untenable
... if there is a poor man/rich man, the rich man needs to be an extension of the poor mans scheme

Geoff: does this lead to WS-Policy in extension negotiation

Doug: not necessarily
... 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
... to do something else is to invent a new policy language

Bob: I think we need to retain a fault that needs to be generated if there is "some nonsense"
... the detail element needs to say "the source of the nonsense is *this*"
... that faulting mechanism already exists
... extension writers are going to write their extensions any way they want

Geoff: device people may create a fault that contains important info in the fault detail
... we can't stop them

Bob: (?)

Geoff: if we are going to specify something, it shouldn't be in the fault it should be in SubscribeRespone

Bob: or some kind of "probe" mechanism

Asir: but that doesn't exist today

Bob: no, it doesn't

<Wu> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0050.html

Geoff: MEX exists but, in this case, MEX would return policy

Doug: trying to figure out where we are
... we have a fault in Section 6.6 that says

<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.

Doug: maybe we should remove the "for local reasons unrelated to the specific request" part
... we have 2 different types of faults here; one is similar to a mustUnderstand fault
... if you detect a QName that you don't recognize and you choose not to ignore it - you can generate this fault

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

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

Geoff: I like having the disctinction

Bob: one is "I'm sick" and the other is "I don't understand your jive"

<asir> actually, it is 'I don't like your jive'!

Gil: (blathers on about something - basically agrees with Geoff but thinks fault shouldn't be overly specific)

Geoff: how far do we support people that don't use WS-Policy

Bob (as geek not chair): there is an old technique where I try to create a connection

scribe: I usually start with my most preferred alternative (full duplex, 56K/sec)
... and I gradually back off through my prefered alternatives
... the only thing you need is some way of determining if the connection is successful
... w/regards to the multiplicity of extensions, etc. you can use multiple NotifyTo's

Geoff: sounds like you are saying "specify the fault and be done with it"

Bob: point is that the client may never see the fault, but it needs to know if the Subscribe succeeded

Wu: "jive fault" should be grounding

Bob: anybody object to "jive fault"

DaveS: I'll make my comment, then answer

Wu: whether you "use Policy" (to decorate WSDL) or not, you should use this fault
... this is another grounding point
... we could also allow, optionally, in the fault message, the allowed alternatives

Geoff: what would that format look like, Policy?

Wu: up to the event source what the format of the detail is

DaveS: I think I'm ok with "I'm sick" and "I don't understand your jive" as separate faults
... but we shouldn't drill down to far on the "I don't understand your jive" fault
... (???) has 12 different faults that all describe variations of "I don't understand your jive"

<Zakim> Bob, you wanted to spit the dummy on optional detail element content

Gil: cautions against optimizing for the case of detecting incompatible extensions

Bob (as geek): the point about optional detail on the jive fault is that it won't be processed by a machine

scribe: you can't count on it for negotiation because ultimately a human being is going to process it
... and it might be expressed in a large number of ways
... perfectly happy with "jive fault" and "sick fault" and leave it up to the impl what it in the detail
... putting critical information in a fault that may never be received by the client seem foolhardy
... my preference: 2 faults with impl-dependent details
... if we still need something like a probing mechanism we can do that independently of the faulting mechanism

<DaveS> +1 to Bob's suggestion.

Bob: propose that "this" is how we deal with faulting extensions

Doug: (clarifies) two faults: an "internal error" fault and an "there is something wrong with your request" fault

Geoff: (further clarifies)

AI: Bob to write a proposal the codifies the above

<Bob> proposed resolution:

<Bob> There are two faults defined. The current fault that indicates internal error, and a fault that replaces the invalidmode fault that indicates subscribeRequestInvalid

<Bob> the detail elements of both of these fault would be implementation dependent

<Bob> both faullts are "generated" and not necessarilly "transmitted"

<dug> [Detail] <wse:RetryAfter> ? (Optional)

<dug> EventSourceUnableToProcess

<Bob> scribenick: 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

both faullts are "generated" and not necessarilly "transmitted". The <wse:RetryAfter> element would be retained.

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...

scribe: these faults in the body of the spec will need to be adjusted accordingly.

RESOLUTION: Issue-7205 resolved with the proposal above

<Wu> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7206


<scribe> Scribenick: gpilz

All: (discussion of above issue)

Bob: WS-Eventing operates in accordance to the rules of the SOAP processing model
... according to that model, extensions can be ignored
... if is important for the service to understand it, you can use mU
... you can use extensions w/out mU and you can use extensions to the response to indicate acceptance
... non-understood mU will generate a fault
... you have all the tools you need in this model to do what you need to do
... one way to determine what is supported and what is not is to use mU to generate faults

All: very simple negotiation

Geoff: I'm not sure that is the actual problem
... 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)

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

Geoff: if I send Subscribe with NotifyTo and Pull and no mU headers, I need to understand what was enabled
... it seems to be usefull to indicate which extensions were honored

Wu: if I want to have an extension to Subscribe where I can either deliver to my office or my home
... I need to know, in the Subscribe response, where the Notifications will be sent

<DaveS> What gil said.

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)

Bob: need section in the primer on this subject: SubscribeRespone provides an extension point that (see above)

<Zakim> asir, you wanted to ask Wu a question

Asir: perhaps it would be easier to use your earlier example that . . . .
... perhaps you and Gil are saying the same thing

Wu: (explain use case)
... problem arises when you specify a choice of policy alternatives on Subscribe, you need to know which one was picked for that Subscription

Asir: you can use the extension point of SubscribeResponse to indicate which alternative was chosen

Wu: when you echo back, you have to attach this response to the Delivery element

Asir: you want a Delivery element on SubscribeResponse?
... Wu wants a place to put the acknowledgement extension

Doug: how closely tied is this issue to your other issues?
... do you see something other than what Bob wants?

Wu: if you allow extension developers to pick QNames, it acts as an alternative to WS-Policy

Doug: let's say the Subscribe request can be extended by QNames (no Policy)
... if we say that extension authors can use the xs:any of SubscribeResponse, is that ok?

Wu: in Delivery?


Doug: is this only need for the extensions-are-WS-Policy or in the general case?

Wu: general case

Doug: you are assuming that QName can appear either in Delivery and outside Delivery
... 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
... and it wouldn't be better just to use 2 different QNames?

Wu: (need Delivery element)

All: (general discussion ensues)

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"

<asir> is this the exact text or direction?

AI: Gil to write up proposal for above text

Doug: I want to put this everywhere

Bob: sprinkle on all specification liberally

Geoff: oh d*mn!
... we have one element that we actually define "NotifyTo"
... we have no "NotifyTo" in the SubscribeResponse
... we probably need to define one?

Doug: don't think so

Bob: NotifyTo is our very first extension

All: (general discussion ensues)

<dug> ouch!

<Bob> directional resolution agreed.

RESOLUTION: (directional) Gil to write up text (AI above)


<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6642

Asir: we need a way to address the explicit/implicit operation problem before we can talk about this
... when a Subscriber subscribes he gets back a Subscription Manager EPR
... there needs to be a way to get from the Subscription Manager EPR to the metadata that applies to the Subscription Manager
... its up to the Event Source to use the "Metadata" bucket of the SubMgr EPR to include MEX
... or you can use HTTP GET ....?wsdl
... or pick up the phone
... or perhaps a manual

Ashok: but you are telling us that this Subscription Manager is populated with its policy

Wu: that's an option

Ashok: once that occurs you can do whatever you want
... I think you are telling us that the Subscription Manager has it's policy in EPR, and then you can access that somehow
... yes

RESOLUTION: Close Issue-6642 with no action


Doug: (describes issue)

Asir: still trying to collect data to better understand the problem
... Gil says it causes the unnecessary stubs

Gil: its not just stubs, it is the programming model

Li: I have a question for these implicit operations
... 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
... the application service would not define the bindings for those operations
... as a client, if I want to send a subscribe message, where do I get the binding

Asir: (reiterates)

Doug: look at how other specs to implicit specs like WS-RM
... the binding is declared in the WSDL included in the WS-RM spec

Li: I think Asir understands me correctly
... the client needs the whole WSDL to generate the code
... at the same time the WSDL is hidden from the client

Doug: if operations are implicit there is no "client side" to be generated, it's part of the SOAP stack

Li: if I need to communicate to the service where the operation is hidden, I need to download a library?

Gil: there is a WSDL for the client to look at - its in the spec

Wu: I share these concerns
... Eventing is very rich
... I'm am concerned that, given all the optionality in Eventing, it can be used properly with implicit operations

<li> dug: you would need both client and server side intrastructure code to work

Asir: two concerns have been expressed
... I would like to have a firm understanding of what is meant by implicit

<li> but authentication alglorithms have different strength

Doug: depending upon what the policy assertion means, implicit behind that is a definition of the operations that will be supported by that endpoint
... are there use cases in which the individual operations require separate policy?
... even if there are, its not a given that you must make the operations explicit
... there are other ways to relate policy to implicit operations that don't require making the operations explicit

Asir: I haven't heard any new concerns
... I understand this issue well enough for now
... I suggest we think in pieces before we try and put it all together
... one person is implementing an eventing stack
... another is an eventing application programmer
... (mentions WS-Trust as another example of an infrastructure spec)

All: (discussion ensues)

Wu: in this implicit scenario, how do I know what kind of Events will be omitted by the port?

Asir: presence of the wsem:Eventing policy indicates that you can do a MEX GetMetadata and retrieve either EventDescriptions or Notification WSDL

Doug: I'm OK with everything being implicit
... but if the solution for different QoS on different protocols (eventing, enum) is to split my endpoint up, I don't like it
... 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

Asir: let's say you have another assertion for Transfer (E - for Eventing, T - for Transfer)
... so you build a policy expression with two alternatives, E and a bunch of stuff and T and a bunch of stuff
... if you talk 'E' you get all the stuff that shares an alternative with E
... if you talk 'T' you get all the stuff that shares an alternative with T

Doug: this still leaves the problem of per-operation policies within the same spec

<Bob> dug

<dug> This WSDL describes the WS-MC protocol from the point of view of the endpoint that receives the MakeConnection message.

<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.

proposed 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

<Wu> It is too narrow if every evening implementation must be implicit.

there is no "MUST" in the above sentence

it says "will not generally appear"

<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.

<li> we should not mandate everybody to hide implicit opreations, we give them choices

<asir> this is generally a blog/wiki/primer material

<li> +1 wu

<Bob> proposed 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

<Wu> It should be "If things are defined implicitly, it should be defined through WS-policy

<li> +1 asir

<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.

<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.

<Bob> resolution carries 1 to lots

<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

<Wu> We are very concerned that "everything is implicitly defined with WS-Policy assertions"

<Bob> recessed until tomorrow

Summary of Action Items

[NEW] ACTION: Doug to come back witth a new proposal for 6724 before next meeting. [recorded in http://www.w3.org/2009/08/05-ws-ra-minutes.html#action01]
[NEW] ACTION: Doug to define a new proposal for 6724 for consideration on 2009-08-18 [recorded in http://www.w3.org/2009/08/05-ws-ra-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/08/19 15:17:38 $