See also: IRC log
<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.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7204
<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
<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
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7205
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?
All: THERE IS NO DELIVERY ELEMENT IN SubscribeResponse
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