See also: IRC log
<trackbot> Date: 11 May 2010
<Dug> anyone on the phone?
<Vikas> Dug, I am on phone.
<Dug> can you hear us?
Ram will do May 11, Tom will May 12, and Gil will May 13
The above note is for minute takers for the meetings.
The agenda is approved. No objections.
Minutes of May 4th approved. No objections.
<scribe> New issues
All new 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."
"the implementations of the specifications features must be independent and not derived from a common ancestor that implements the specification under test."
Correction: "the implementations of
the specification features must be independent and not derived from
a common ancestor that implements the specification under
... "the implementation of the specification features must be independent and not derived from a common ancestor that implements the specification under test."
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."
RESOLUTION: The above will be this WG's guideline for implementation of the specifications.
Gil describes the proposal.
RESOLUTION: Issue 9570 is RESOLVED.
Gil: Proposal needs more work. Will get this done by afternoon.
Bob: We will defer this until tomorrow.
Gil describes the proposal.
Dug: I have many concerns about this
... 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?
RESOLUTION: 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].
GIl describes the proposal.
Wu: Can i ask for another hour so Li has a chance to check?
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
... 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.
Katy explains the 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
... 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.
RESOLUTION: No objections. Issue 9671 RESOLVED as proposed.
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.
RESOLUTION: Issue 9567 RESOLVED with version 4 of proposal.
RESOLUTION: Issue 9569 RESOLVED with proposal 1.
WS-Man folks thought that others may want the batched delivery mechanism.
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
... Any objections to close with no action?
Wu moves to close with no action.
RESOLUTION: 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].
RESOLUTION: Issue 9568 resolved as proposed.
in version 2.
Bob: Why would we need to add XPath Level 2 dialect?
Gil: XPath Level 2 = XPath Level 1 +
... 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
... 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
... 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
RESOLUTION: Issue 9612 CLOSED WITH NO ACTION.
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].
RESOLUTION: Issue 9558 CLOSED WITH NO ACTION.
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
RESOLUTION: Issue 9613 RESOLVED as proposed above.
RESOLUTION: Issue 9655 CLOSED WITH NO ACTION.
Gil explains the proposal.
Dug: What if the enumeration count is
... 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.
RESOLUTION: 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].
Gil: This is an optimization to avoid round-trip.
Dug: I am worried about the implication of this.
Bob: Why not simply do a pull?
Gil: Why not model this as a Transfer resource?
Ram: We need to determine if this has
... 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
... 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
RESOLUTION: Issue 9609 CLOSED WITH NO ACTION.
<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].
<Dug> <!-- Notification WSDL can go here - see Appendix x.y -->
<Dug> <!-- EventDescription Data can go here - see Appenfix x.y -->
<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.
RESOLUTION: Issue 9676 RESOLVED as proposed above.
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 untill tomorrow 9:00 PST