Web Services Resource Access Working Group Teleconference -- 11 May 2010

<trackbot> Date: 11 May 2010

<Dug> Yves, you on the sys-req email dist list for w3c?

<Dug> anyone on the phone?

<asoldano> Dug, dialing in again..

<Vikas> Dug, I am on phone.

<Bob> can anyone hear us on the phone?

<Dug> can you hear us?

<asoldano> Dug, no, I can't, can just hear Vikas

<Dug> can you hear bob now?

<asoldano> yep

scribenick Ram

Ram will do May 11, Tom will May 12, and Gil will May 13

The above note is for minute takers for the meetings.

<Dug> Yves, you on the sys-req email dist list for w3c?

<Yves> no

The agenda is approved. No objections.

Minutes of May 4th approved. No objections.

<scribe> New issues

All issues are accepted. No objections.

Discussion on definition of independent implementations

<Bob> "the implementations must be independent and not derived from a common ancestor that implements the specification under test."

<Dug> Yves - do you have any of the sysreq guys on IM or something you can ping quickly? I've lost access to cvs and would like to get it fixed quickly so I can edit the specs.

<Yves> dug: I saw that ted was taking care of this

"the implementations of the specifications features must be independent and not derived from a common ancestor that implements the specification under test."

<Dug> sort of - he "fixed" it so now I can't access it from my old machine either :-)

Correction: "the implementations of the specification features must be independent and not derived from a common ancestor that implements the specification under test."
... "the implementation of the specification features must be independent and not derived from a common ancestor that implements the specification under test."

<Yves> dug, the key I see in there is the one you sent...

<Dug> I need my old key in there too. Not sure why the new key isn't working for the new machine but I'll worry about that later. Right now I'm still on my old machine and I need access for the f2f.

Ram: Should we ask for advice from W3C Team on this matter?

Yves: There is nothing wrong with the WG deciding on the nature of the implementations.

No objections to Bob's proposal as amended by Ram: "the implementation of the specification features must be independent and not derived from a common ancestor that implements the specification under test."

The above will be this WG's guideline for implementation of the specifications.

Issue 9570

<Dug> sent - I hope that's the right one - for some reason I always have trouble with this stuff

<Yves> me dug, can you try now?

Gil describes the proposal.

<Dug> yves - nope still fails

Issue 9570 is RESOLVED.

Issue 9569

Gil: Proposal needs more work. Will get this done by afternoon.

Bob: We will defer this until tomorrow.

Issue 9607

Gil describes the proposal.

<Dug> sent

Dug: I have many concerns about this issue.
... Allowing updates to change EPR seems poor architectural design.
... The client has to communicate any changes to the EPR (cascade effect); this proposal does not address this.
... This notion of the server being able to tell the client "use a different EPR" is not a Transfer specific problem.
... We could think of a seperate specification to work on this, but this is out of scope for this WG.

<Tom_Rutt> If a transfer put induced state change on a resource results it a change of its epr, then that same epr might change due to state changes due to other stimuli associated with the resource.

<Tom_Rutt> In such an environment, I feel strongly that using an event report notification "state change induced EPR change" would be a better solution.

Tom: WS-Man WG can address this issue specific to their domain.
... Don't like this proposal.

Bob: EPR itself contains extension point where other domain specific information could be inserted.

Dug: EPR is more static than a cookie.

Bob: Any objections to close with no action?

Issue 9607 CLOSED WITH NO ACTION.

Bob: Record the response to WS-Man in the bug and respond on the public mailing list.

ACTION Tom to send a response to the WS-Man WG about the disposition of issue 9607.

<trackbot> Created ACTION-148 - Send a response to the WS-Man WG about the disposition of issue 9607. [on Tom Rutt - due 2010-05-18].

Issue 9567

GIl describes the proposal.

Wu: Can i ask for another hour so Li has a chance to check?

Bob: Yes.

Issue 9610

Gil describes the proposal from WS-Man.

Gil describes some enhancements suggested by WS-Man about how to negotiate the heartbeat.

Bob: Some systems may want heartbeat and others may not.

Wu: There is many wrinkles when you dig deeper about heart beats. The frequency of the heart beat need to be specified. The event source may become overloaded with heart beat pseudo events.
... If the client cannot be reached, what should the event source do? Delete subscription, etc?
... It is a whole new protocol.
... This should be outside the general WS-Eventing spec.
... Event subscribers could use GetStatus to probe the event source. Using a heart beat is out of scope.

Gil: About the delivery frequency of heart beats, we need a mechanism to negotiate that.
... I think using the existing mechanisms such as subscription expiration we can work it out.
... I don't see why we cannot define heart beats and leave the details to individual implementations.

Bob: It occurs to me that heart beats are inherently less scalable in terms of network capacity.
... Don't know how big the bag of clients are who receive heart beat notifications.
... A pull mechanism such as GetStatus is better.
... A client can automatically back off, etc.

Gil: Your point about load is well taken. But an event source is not required to support heart beats.
... The WS-Man folks use heart beat only in low client counts.
... Hence, network load is not a concern. The GetStatus may not actually work since the entity who receives the heart beat notification and the entity that sends GetStatus may be different.

Bob: I prefer an event ping instead of a heart beat.
... That is sufficient to handle the use case.
... Using a fault to negotiate a capability is not a reliable way to do things; since faults need not be transmitted.

Wu: I second Bob's opinion. Heart beat can be issue of capacity and waste of bandwidth.
... If a subscriber subscribes to multiple subscriptions, the question arises whether the source sends single or multiple heart beats.

Gil: The heart beat is on a per subscription basis.

Wu: That means a subscriber gets many heart beats from the same event source?

Gil: Yes. But I don't see a concern.

Bob: Would a single heart beat such a ping satisfy?

Gil: Need to explore this with WS-Man.

Dug: What is the difference between GetStatus and synthetic ping from the event sink to the Subscription Manager to send a heart beat?

Gil explains on white board.

<gpilz> "Verify" is a good name for this operation

Dug: Is GetStatus is synchronous the reason why it cannot be used?

Gil: No, the event source and sink may be disconnected.

Dug: Event source is a conceptual object.

<Yves> if the heartbeat is not received, you also don't know if it was not generated, or not transmitted, or lost in an outgoing proxy somewhere

<Yves> (in the heartbeat case)

<Bob> +1 to Yves

Dug: I like to better understand what sort of problems/use cases this addresses. I am having trouble distinguishing between asynchronous replyTo on a GetStatus seems sufficient.

Ram echoes the same sentiment as Dug.

Wu: I agree with Ram and Doug.

There is some debate about why can't GetStatus/GetStatusResponse serve the same function of a "Verify" ping message followed by a Verify response from event source.

Break until 10:30AM PT.

Meeting about to resume

Issue 9671

<li> aaee is li

Katy explains the proposal.

<Dug> http://www.w3.org/Bugs/Public/attachment.cgi?id=868

<Dug> proposal

Ram points to a minor editorial correction.

<Dug> there are other editorial things too :-)

<Dug> but they're minor

Gil: If the metadata is updated to say for example WS-MakeConnection is supported, it creates metadata that is out of sync with the service.
... Is this a configuration mechanism?

It is a remote configuration mechanism, yes.

Katy: It is no different from an administrative mechanism to update an endpoint's configuration metadata.

Dug: There are two types of metadata out there. Metadata that is manipulable by the service and that which cannot be manipulable by the service's configuration. That is where remote configuration comes to being.

Gil: There are two faces to metadata.
... One which the service project outward for all/otheres to see.
... Another is about configuration metadata.
... WS-Policy is not well suited for configuration metadata.

Katy: I don't fully agree.

Bob: This seems to be reiteration of 6411 i suppose.

No objections. Issue 9671 RESOLVED as proposed.

Back to Issue 9610.

ACTION Gil to come back with a proposal for this issue before end of this F2F

<trackbot> Sorry, couldn't find user - Gil

ACTION gpilz to come back with a proposal for this issue before end of this F2F

<trackbot> Created ACTION-149 - Come back with a proposal for this issue before end of this F2F [on Gilbert Pilz - due 2010-05-18].

Dug: The proposal we are thinking about to resolve this issue is quite radical. It is not clear if WS-Man WG would agree to this radical approach. We can close this issue with no action and ask the WS-Man WG to consider the radical approach; if there is an uptake we can reopen the issue.

<gpilz> Katy, are you still there?

<gpilz> I just realized that I don't know what fault an endpoint should generate if it simply doesn't support PutMetadata

Dug: We need to explain the reasons for closing with no action.

Gil: If we close with no action, then we may loose the option to re-open it later since we may go on to CR soon.

Dug: Why don't we wait until tomorrow when WS-Man gets a chance to discuss?

There is general consensus.

Back to issue 9567

Issue 9567 RESOLVED with version 4 of proposal.

Issue 9569

Issue 9569 RESOLVED with proposal 1.

Issue 9611

WS-Man folks thought that others may want the batched delivery mechanism.

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

Li: The batched delivery mode is covered by the wrapped delivery format already.

Wu: WS-Eventing as it is already meets the requirements of the issue.
... In short, WS-Eventing alreadys supports the batching mode.

Dug: Clarification: The wrapped delivery does not necessary support this since this has only a single action URI.

Gil: The strawman proposal is underspecified. If this WG is interested in batched mode, we can work on it. Otherwise, why spend the effort?

The current model in WS-Man does not work adequately. It only says you can batching without exceeding a certain number or seconds. That is a weak constraint.

Wu: If we want to do this, we need to do this in a way this works.

Bob: First off, i view batching as a significant overhead for resource-constrained environments. It may be best to leave it to specific domains to do this right.

<li> +1 bob

Gil: I like to address the underlying use case without taking on an obligation to take it on.
... This may be a pre-mature optimization.

Dug: I am torn on this one. It is a nice optimization for example like in WS-Notification. At the same time, when batching was attempted (with SOAP messages, etc), there are issues such as transactionality, etc. It really is a can of worms. It is best to leave it to the domain experts to deal with this.

Wu: I second Dug's comment.

Gil: There are ordering issues with batching as well.

Tom: How does one do filtering with batching?

Dug: Specification already says that filtering happens before formatting.

Bob: Any one in favor of proposal?
... Any objections to close with no action?

Wu agrees.

Wu moves to close with no action.

No objections.

Issue 9611 CLOSED WITH NO ACTION.

ACTION Wu to prepare a response for 9611.

<trackbot> Created ACTION-150 - Prepare a response for 9611. [on wu chou - due 2010-05-18].

Issue 9568

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

Issue 9568 resolved as proposed.

in version 2.

Lunch break until 12:50pm PT.

The conference call will restart @ 12:50pm PT.

<Bob> we are re-starting

Issue 9612

Bob: Why would we need to add XPath Level 2 dialect?

Gil: XPath Level 2 = XPath Level 1 + extra operators
... WS-Man wants to see if the XPath dialects have generic applicability.

Bob: It is not clear how WS-RA can determine if a particular subset of XPath is acceptable to other WGs?
... Different communities are going to want different level of subsetting of XPath.
... Should WS-RA be the one defining all the various flavors of XPath?

<Yves> as long as we have a way for people to define and use their own flavor, we should only define what we need (and do only minor stuff to help others)

Gil: Yeah. It is sufficient to define the base framework that allows use of various dialect.

Bob: Feel a bit uncomfortable about taking on something that we do not care that much.

Dug: Since we do not have people clamoring for this, don't see a need to do this.

Bob: We should define Dialect URI for XPath 2.0.
... Since it is a W3C Recommendation.

Dug: We should do a separate issue.

Bob will open a new issue.

Is there an alternate solution?

Dug: If we were to send XPath Level 1 to WS-Security WG, then we send XPath Level 2 to them as well.

Bob: I hear a consensus to close with no action.

No objections. Issue 9612

Issue 9612 CLOSED WITH NO ACTION.

Issue 9558

Tom: If we take on developing XPath levels / profiles, then we will have to be open to taking on many different such level and profiles. Are we ready for that?

Bob: Do we care about XPath Level 1 in WS-Fragment?

No one expresses a strong interest.

Bob: Any objections to removing XPath Level 1 from WS-Fragment?

Dug: This means that the serialization rules in the specification need to retained.

Bob: We can respond to XML Security WG that they need to define their own XPath Level.

Gil: Is the response that WS-RA is getting out of the business of defining XPath dialects?

<Dug> All: yes that's the answer

Proposal: Remove XPath level 1 from WS-Fragment AND respond to XML Security WG that WS-RA is getting out of the business of defining XPath levels.

ACTION Bob to respond to Frederick / XML Security WG.

<trackbot> Created ACTION-151 - Respond to Frederick / XML Security WG. [on Bob Natale - due 2010-05-18].

ACTION gpilz to respond to WS-Man about WS-RA's position on XPath level support.

<trackbot> Created ACTION-152 - Respond to WS-Man about WS-RA's position on XPath level support. [on Gilbert Pilz - due 2010-05-18].

Issue 9558 CLOSED WITH NO ACTION.

Issue 9613

Gil: WS-Man manages a farm of little devices that go through power cycles, etc. It is difficult to keep it going if the subscriptions are transient.
... Hence, they have this feature called persistent subscriptions.

Wu: The intention is good, but there are issues here. We think QoS is a complex mechanism and should be a separate description.
... What does it mean to say a subscription is persistent.
... What about caching, etc?

Gil: There is no notion of caching. WS-Man has a different model for dropped events.

Dug: If we define a persistent flag, we need to define all the various aspects such as caching, etc.

Wu: This is a feature that qualifies for a separate QoS spec. Hence, close with no action.

Bob, Dug: WS-Eventing events can be persistent as it is today; it is not precluded.

Gil: Nothing in our specs says delivery is guranteed, it is best effort.
... It would be useful to know which devices in a farm can and cannot support persistent subscriptions.

<Tom_Rutt> How would one of these small devices behave if there was an EndTo EPR in the subscribe request. would the have enough "smarts" to be able to send the SubscriptionEnd message before it goes down, or at its reboot?

<Tom_Rutt> So would this small device also not be able to accept EndTo EPRs in the subscription?

Gil: There are a number of QoS in WS-Man specs such as delivery mode (push with ack), etc. It is domain specific.

Dug: I am sensing that we are heading towards close with no action.
... Subscription expiry and persistence have some relation.

<gpilz> A subscription can become invalid for any reason including:

<gpilz> Subscription deleted (via Unsubscribe)

<gpilz> Subscription expired

<gpilz> Subscription ended (via SubscriptionEnd)In addition, the Event Source/Subscription Manager MAY cancel a subscription at any time, as necessary.

Gil: Section 4 of WS-Eventing clarifies this that the source makes a best effort.

<Tom_Rutt> The management workstation should be able to determine the kind of kit is is dealing with, and have a table in its own state to know whether the event source has persistence of subscriptions. They seem to be asking that the subscribe operation exchage, itself, have a way for the management station to obtain this knowledge.

Gil: There is out-of-band knowledge that is necessary here.

Tom: An event source that does not have the ability for persistence better not accept a subscription with an EndTo.
... If the systems goes down abruptly, is it out of scope of the spec.

Gil: We need some clarity about abortive shutdown case.

Dug: The spec already says best effort.

Proposed response to WS-Man WG: Persistence is a difficult topic. After due consideration, we have decided that this is domain specific and outside the scope of the WS-RA work. However, your issue has caused us to add "if possible" to the description of SubscriptionEnd message.

The above clarification would help deal with abortive shutdown cases.

<Dug> ... via a SubscriptionEnd message if an EndTo was present in the Subscribe message.

Dug: In addition, add the above.

<Dug> to end of 2nd para in section 4

<Dug> bye !

See you.

Issue 9613 RESOLVED as proposed above.

Issue 9655

Issue 9655 CLOSED WITH NO ACTION.

Issue 9608

Gil explains the proposal.

Dug: What if the enumeration count is dynamic?
... I am just worried that it is an estimate and there are no guarantees; but if there are no guarantees how is it useful?
... It seems too specific to a particular use case.

Bob: What if EnumerateResponse has an optional element that indicates total count at that point in time.

Dug: Calculating size could be expensive.

Bob: What shall we do?

Gil: Close with no action.
... This seems domain specific.
... The addition of this extra information does not seem useful in the general case.

Issue 9608 CLOSED WITH NO ACTION.

ACTION Dug to write up response to 9608.

<trackbot> Created ACTION-153 - Write up response to 9608. [on Doug Davis - due 2010-05-18].

Issue 9609

Gil: This is an optimization to avoid round-trip.

Dug: I am worried about the implication of this.

<li> bye

<Dug> bye

Gil: Agrees.

Bob: Why not simply do a pull?

Gil: Why not model this as a Transfer resource?

Ram: We need to determine if this has generic usefulness.
... We need to make sure before collapsing Enumerate and Pull if implementations do special initializations during Enumerate.

ACTION gpilz to work on a proposal for 9608

<trackbot> Created ACTION-154 - Work on a proposal for 9608 [on Gilbert Pilz - due 2010-05-18].

Ram: Since there doesn't seem any interest in this optimization, suggest close this with no action.
... Since there does not seem a generic applicability of this optimization.

<Tom_Rutt> rationale: the cost in terms of spec and implementation complexity outweighs the potential benefits of saving a round trip of network exchange for a minority of use cases

No objections.

Issue 9609 CLOSED WITH NO ACTION.

Issue 9699

<Dug> "All messages defined by this specification MUST be sent to a Web service that is addressable by an EPR."

<Dug> "All messages defined by this specification MUST be sent to a Web service that is addressable by an EPR, and be sent with WS-Addressing 1.0 engaged."

<gpilz> "All messages defined by this specification MUST be sent with WS-Addressing 1.0 engaged.

<gpilz> "All messages defined by this specification MUST be sent with WS-Addressing 1.0 engaged and sent to a Web service that is addressable by an EPR."

<Dug> All messages defined by this specification MUST be sent to a Web service that is addressable by an EPR (see [WS-Addressing]).

<Dug> All messages defined by this specification MUST conform to the WS-Addressing specification and sent to a Web service thatis addressable by an EPR.

<gpilz> "All messages defined by this specification MUST be sent with the headers required by the WS-Addressing 1.0 specification"

<Dug> All messages defined by this specification MUST conform to the WS-Addressing specification and be sent to a Web service thatis addressable by an EPR.

<Dug> All messages defined by this specification MUST conform to the WS-Addressing specification and be sent to a Web service that is addressable by an EPR.

<Dug> All messages defined by this specification MUST conform to the WS-Addressing specification and be sent to a Web service that is addressable by an EPR ( see [WS-Address]).

<Dug> All messages defined by this specification MUST conform to the WS-Addressing specification and be sent to a Web service that is addressable by an EPR ( see [WS-Addressing]).

<Dug> All messages defined by this specification MUST conform to the WS-Addressing specification and be sent to a Web service that is addressable by an EPR ( see [WS-Addressing 1.0 SOAP Binding]).

<Dug> All messages defined by this specification MUST conform to the WS-Addressing specifications and be sent to a Web service that is addressable by an EPR ( see [WS-Addressing]).

Issue 9699 is RESOLVED as proposed with the latest proposal above.

ACTION Dug to respond to comment submitter on 9699.

<trackbot> Created ACTION-155 - Respond to comment submitter on 9699. [on Doug Davis - due 2010-05-18].

Issue 9676

<Dug> If the Event Source advertises Notification WSDL then it MUST appear as a child of the FormatName element. and do this for EVD data too.

Issue 9676 RESOLVED as proposed above.

Issue 9675

ACTION Dug to add examples for Notification WSDL.

<trackbot> Created ACTION-156 - Add examples for Notification WSDL. [on Doug Davis - due 2010-05-18].

<Bob> recessed

- DRAFT -

Web Services Resource Access Working Group Teleconference

11 May 2010

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output