See also: IRC log
<trackbot> Date: 28 July 2009
<Bob> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0060.html
<Bob> Scribe: Sreedhara Narayanaswamy
<Bob> scribenick: Sreed
Bob: Agenda accepted
RESOLUTION: Minutes of 2009-07-21 accepted w/o
<Bob> http://www.w3.org/2002/ws/ra/tracker/actions/open
Bob: Issue 6917 was the result of an
external comment
... We need to address this issue and at least reach a directional
agreement pretty soon
... Discussion of 6917 will be scheduled for the F2F
Li: Let's discuss the agenda of publication at the F2F
Bob: How are we doing on the frag proposal?
Geoff: Working on it will send it over the week
Bob: Need by Thursday for folks to
see it before the meeting
... Any other items for the F2F?
Tom Rutt: Notification defintion discussing about the mechanism would be required
Tom Rutt: Proposed solution require Notification defintion which is the application content of the defintion, need discussion on this
RESOLUTON: Accepting New issue 7127 & Tom Rutt will be taking the ownership
gpilz: 6401 reference parameters information trying to work which is specific - the way description
Geoff: Joint proposal - discussion
IBM & Microsoft had which is based on the last F2F
... push mode is not currently specified in the spec, delivery
element is still exists - original spec when push mode is
undefined. Wording changes push/make connections which will be
handled 6432
Dug: Notifications can be delivered
gpliz: It is not clear what asynchronous means
Bob: Asynchronous is a difficult term without a description of what it is asynchronous with respect to
<dug> I can live w/o "async" - same end result
<Bob> proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/att-0057/wseventing-6692-10.doc
Bob: Any objection to accepting the proposal?
<dug> here are the sentences in the spec that use "asynchronous"
<dug> "This specification defines only an asynchronous method of delivery for notifications from the event source to event sink. "
<dug> "The absence of any extensions to the wse:Delivery or wse:NotifyTo elements indicates that notifications should be asynchronously sent as SOAP messages to the endpoint described in lines (21-28). "
<dug> "When present this element indicates that notifications MUST be asynchronously sent to the EndpointReference identified by this element."
<dug> This specification defines only one method of delivery for notifications from the event source to event sink.
<dug> ??
<dug> This specification a method of delivery for notifications from the event source to the event sink.
<dug> This specification defines a method of delivery for notifications from the event source to the event sink.
<gpilz> This specification defines a method for delivering notifications from the event source to the event sink.
li: define is reference to the event - async some kind of i/p
<gpilz> This specification defines a method for transmitting notifications from the event source to the event sink.
<dug> maybe we should delete this sentence??
<dug> :-)
<Wu> This specification defines a subscribe/notify method ...
Bob: Wu what text you propose?
<dug> "This specification defines a method for transmitting notifications from the event source to the event sink through the inclusion of the wse:NotifyTo EPR."
<Wu> This specification defines a subscribe/notify method for transmitting notifications from the event source to the event sink.
<dug> "This specification defines a method for transmitting notifications from the event source to the event sink through the use of the wse:NotifyTo element."
dug: how we actually do it
<Geoff> +1 for doug
<Bob> "This specification defines a method for transmitting notifications from the event source to the event sink through the use of the wse:NotifyTo element."
<Bob> no objections
Bob: any objections to striking the word "asynchronous" in the other two sentences?
<Bob> no objections to the removal of asynchronously in the other two places
<asir> Vow!!
<asir> Certainly progress!
RESOLUTION: Resolve Issue-6692 as proposed in bugzilla with the amendments related to asynchronous above
<Bob> AI: chair to add modifications to bugzilla reflecting the three agreements above
Bob: new proposal is in the bugzilla
<gpilz> +1
Wu: suggest wording changes
<Ram> Proposal for 6432: "When the wse:NotifyTo element is used within the Delivery element it specifies the endpoint to which Notifications are sent. For delivery to addressable endpoints this is sufficient. However, for non-addressable endpoints some additional mechanisms are needed. A subscriber can choose to leverage the WS-MakeConnection] specification to enable delivery of Notifications to non-addressable endpoints."
Bob: Ram are you suggesting specific
changes to the text in the proposal?
... Wu Are you supporting Ram's text?
... we might have to discuss and resolve this at the F2F
<Ram> Bob says: There needs to be two implementations for optional features. If not, those features will need to be marked at risk.
Asir: might not to test anything at all
Bob: We can discuss this next week
<Bob> N.B. both Oracle and IBM mentioned that they would be able to demonstrate implementations of eventing composed with MC during CR
<li> geoff: where is the link to the proposal?
Geoff: Information with the subscription currently in the spec. Complexity of having two models how we can differentiate it.
Geoff
<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0079.html
dug: might be re-inventing transfer in this