Web Services Resource Access Working Group Face to Face, Redwood Shores, CA

09 Jun 2009


See also: IRC log


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


<trackbot> Date: 09 June 2009

<asir> Scribe: Asir S Vedamuthu

<asir> ScribeNick: Asir

Agenda Bashing

3-day meeting

Bob: calling for 6 volunteers for 6 different slots
... there are 6 premium slots, calling for tenders
... the first one is already gone

Prasad: prefers Wed PM

Tom: prefers Tue PM

Ashok: Wed AM

Jeff: met for 6 months, discussed the same issue several times, prefers voting

Bob: formed taskforces, F2F is the best time to discuss hard issues

Asir: agree with Bob, we should try and build consensus to the best extent possible, we should build industry consensus not just within this group
... it is important that carry the WG to see adoption
... it is important taht we carry industry consensus to see adoption
... would prefer that we don't get into any premature voting doldrums

Bob: points out the dependencies in the charter
... featured issue of the day is 'mode'
... featured issue for tomorrow is 6413

Asir: will we discuss FO?

Bob: will discuss on day 3

Jeff: WG does not discuss FO, sent to the Director

<jeffm> please add to the log mr. scribe: jeff asked how many many more weeks and months do we have to talk and "try to build consensus" before it is time to actually take a decsion and vote

Yves: WG should try and dispose formal objections

Asir: I would like to echo what Yves mentioned. We should try and avoid formal objections

Bob: keep the discussion on tech merits and professsional

<jeffm> so don't file them when u lose on an issue,

We should work towards avoiding any such formal objections ...


Approval of minutes from the 2009-06-02 distributed meeting

RESOLUTION: 2009-06-02 minutes approved

Task Team Progress

Gil is ready to discuss 6401

Bob: ready to discuss mode proposals


Bob: ready to discuss T and Frags issue

Issue-6956 Enum: server behavior after end of enumeration context

See http://www.w3.org/Bugs/Public/show_bug.cgi?id=6956

<scribe> postponed

Issue 6924 Transfer: behavior unspecified for Put

Gil walks through his high-level proposal

Gil: wants to clarify invalid rep fault

Geoff: there are 3 cases in which Put should be disallowed
... 1. Should PUT be disallowed entirely in this case
... 2. Should the client be able to send a PUT that contains only the elements that can be updated (partial)?
... 3. Should the client send the whole resource, with the read-only values same?

Yves: define a fault

Doug: define a fault and not specify the cases when it should be used
... something wrong with the data

Yves: in the case of partial PUT, use a PATCH like operation
... perhaps, IFMATCH and ETAG style mechanism, similar to HTTP
... this will clearly dilineate fragment style PUT operation

Doug: want to see a PATCH proposal

<scribe> ACTION: Yves to open an issue to solve versioning and partial PUT in Transfer AND provide a proposal [recorded in http://www.w3.org/2009/06/09-ws-ra-minutes.html#action01]

<trackbot> Created ACTION-67 - Open an issue to solve versioning and partial PUT in Transfer AND provide a proposal [on Yves Lafon - due 2009-06-16].

Asir: when you mentioned PATCH, are you thinking of a new operation for fragment PUT

Yves: yes

Doug: sounds like a fragment-like feature, nice to have feature for tomorrow's discussion

Yves: will prepare some material for tomorrow's discussion

pop the stack

Issue-6956 Enum: server behavior after end of enumeration context

Geoff walk through the proposal

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

Doug: SHOULD should be a MUST
... in section 3.2
... applies to both request and response
... MUST fail and MUST generate

Geoff: not sure yet
... you have to look at the proposal in context, let's look at the spec

Ashok: have two options: send another end of sequence or send an invalid context. Why don't we say that?

Geoff: if it is going to gen then the system should gen an invalid context, sometimes the system may generate a perfectly valid message, end of seq

Doug: hurts, hurts
... perhaps, we need to introduce more changes to cover what Geoff is asking for

Geoff: will re-work the proposal to include enum context as well

<scribe> ACTION: Geoff to re-work the proposal for issue 6956, due tomorrow! [recorded in http://www.w3.org/2009/06/09-ws-ra-minutes.html#action02]

<trackbot> Could not create new action - please contact sysreq with the details of what happened.

<trackbot> Could not create new action - please contact sysreq with the details of what happened.

Bob: temporarily disposed 6924 and 6956

Issue-6975 WS-Transfer needs to define the term 'literal resource


Gil: not hard to do!
... means XML as is

Bob: related to 6712
... would a def for lit rep move forward 6712?

Geoff: IFF 6712 outcome is no dialect, then high-level def is sufficient
... IFF 6712 outcome is - use dialect, then lit rep should be clearly defined

Bob: should we record a dependency?

<jeffm> http://news.bbc.co.uk/2/hi/business/7490346.stm

<jeffm> http://www.guardian.co.uk/commentisfree/2009/may/22/pringles-potato-crisp

<scribe> ACTION: Gil to provide a draft definition for lit rep, issue 6975 [recorded in http://www.w3.org/2009/06/09-ws-ra-minutes.html#action03]

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

Issue-6712 Transfer: Create is ambiguous


Doug: sent out a revised proposal

Geoff: two kinds of areas that are unclear
... 1. concept of DB example, service acting like a DB, taking a stream, creating something in a DB

<gpilz> ?

Geoff: transfer spec does not, transfer talks about a resource, it is upto a resource to decide what to do
... DB service, will deal with things as it always it used to
... will take string, xml, instruction
... it is upto the DB to figure out how to handle classes of things
... it is upto the DB to figure out different classes of things
... as they say in Aus, Bob is your uncle!
... it is upto the service to decide what to do
... walks through an example, say an issue client
... 2. it is not easy to define what is a literal rep
... have not seen any answers to questions that I posted to the WG
... walks through a priority rep example
... so, no need to intro any new attributes
... we could follow Bob's suggestion of using the term 'payload'

Dug: will go with the assumption: authors had some smarts and introduced instruction
... moving to payload = removing functionality
... service can figure out by letting client to indicate
... but this is one-off and not interoperable
... transfer does not have any mechanism to tell the client what is the shape of the resource
... very simple to clear this ambiguity
... not comfortable to remove the functionality

Bob: why did the authors not provide a mechanism to indicate

Doug: guessing

Gil: authors were on a schedule and did not have sufficient time to think thru
... is it instruction or is it literal
... does the service need to be aware
... supports doug's proposal

Asir wants to point of that Transfer Member Submission says

"Implementations should provide metadata which describes the use of the representation and how it relates to the resource which is created, but such mechanisms are beyond the scope of this specification."

It is upto the service to tell the world what is the shape of a resource

Geoff: what is the actual interop scenario?

<gpilz> how come nothing I said got in the minutes?

Please add it Gil

<gpilz> the crux of this issue is dualities

<gpilz> sometimes you want the service to interpret the contents, sometimes you don't

<gpilz> neither the client nor the service is "the absolute master"

<gpilz> they need to interact

<gpilz> "isResource" is a means for the client to hint to the service what is intended

<gpilz> obviously the service may or may not honor that hint

<gpilz> finally, denigrating other peoples use cases is non-productive (unless a use case is non-implementable, etc.)

Doug: service can tell the client to include a header
... wants a transfer-level mechanism for a client to tell the diff

Geoff: for the issue processing example, would you, as a client, have said the attribute is a resource or instruction?

Doug: in the example, you are storing an example
... it may not matter
... there is no ambiguity
... my proposal will not impact existing impl
... this is a fringe usecase
... default is the status quo

Ashok: you actually started with an attribute as an URI
... URI gives you a bigger scope, different values (rather than binary
... what did you change from URI to boolean?

Doug: wants to know if this is raw data or instruction

Asir: transfer does not spell out any mechanism to tell the client what is the shape of a resource
... [quoted material from the transfer spec]

<dug> HTTP+HEAD IMO gives the metadata the client needs

Asir: And the create operation says that the contents of the create operation are service specific
... it could be many things
... the spec talks about a few possibilities
... why is an instruction treated specially?
... all you need is an URI and service-specific contents
... this is similar to HTTP specification

Yves: in HTTP, it is upto the server (implementation of a resource) to figure out what to do with the contents
... and the implementation of a resource can vary in nano seconds

Bob: I received a request from Hemal Shah to present his views on some of WS-RA issues
... he is a member of the DMTF/WS-Man WG

<gpilz> as are Bob, Doug, Tom, Jeff, and myself

<gpilz> (members of the WS-MAN WG)

Bob: walks through the principle of robustness
... if you are making a statement about modeling after something, we should be cognizant of how much of those underlying stuff are used
... summarizing ...
... we have this thing called transfer
... we are talking about creation
... want something to be created
... it could be a lit rep, instruction or something else
... authors didn't define any further
... this means
... disambiguation is totally out of the hands of the Transfer spec
... it is upto some other specs to define what the rep or something else
... if we go along the lines of let's annotate using a boolean to disambiguate
... I am worried that we are narrowing our use to a smaller scope
... just lit rep and instruction
... or here is another language that i dev to provide instructions
... if we were to get on the route then I am worried

Doug: now prefers a URI

Bob: we are talking about a vague thing, contraining to any small set is premature
... that leaves us with three alternatives
... a) if you want to tag a content, we will give you one that is optional
... b) nothing is necessary, these are service-specific, defer to services
... c) Recommend other mechanisms to get metadata or providing a place holder for client-server negotiation
... practically boils down to a and b

Ram: noticed that there is a struggle between what belongs to the protocol versus app layer
... what is sent by the client could be data, instruction or both
... how am I going to negotiate with the service?

Ashok: perhaps, a negotiation mechanism

Bob: may be some rough analogy to media type

Wu: there are umpteen possibilities, there is no reason for us to define these possibilities, I am more inclined to leave this to service-specific

<dug> Wu - this isn't a new feature - the transfer spec already talks about doing this - we're just clearing up an ambiguity

Gil: we have an open thing here to define a policy for transfer, we don't need to know that now to decide on this issue

Ram: both parties seem to make good points, you don't know what the payload is going to be, range of values - data, instruction, both or something else
... a proposal to indicate using a mechanism
... why not specify in the spec that payload could be anything, state that anyone could define the payload, use extensions for servers to figure out the nature of the payload

Geoff: use some wording to articulate clearly in the spec would help

Doug: opinion, you are removing a feature

Ashok: adding only a attribute, you do not have to use it
... optional attribute
... HTTP is not a good example
... people are constantly inventing new protocols rather than using HTTP

Gil: Ram said that app can extend, Doug mentioned that is an interop issue, Geoff said that we could clarify

Geoff: you may say that the attribute is optional ... but it is not
... not actually optional
... if the client gets confused then this will confuse the client
... what if I use it and what if I don't use it
... this is the point that Wu mentioned
... this is shifting the ball from service-specific to client-specific

Bob wants to hear from Tom

Bob: can you argue for both sides?

Tom: prefers strong typing, so prefers an extra flag
... how can I defend for the other side
... it is upto the app side to figure out

Bob: there are two options
... a) add an optional xs:anyURI
... b) close with no action
... c) provide guidance to implementers on how to extend the protocol for indicating content

Ram: c) is all about setting expectations and providing guidance

Asir: points out how to build consensus

<gpilz> Asir moves to delay with additional, undefined proposals

<gpilz> as far as consensus goes, I have not interest in an attribute that is "optional to understand"

Bob: what does a) mean? If I am the creator of the message, it would pass schema validation. If I were a receiver of it I could not understand, I could not support that URI

<gpilz> it totally undoes the intent of the original proposal

Bob: it is

Bob's option a) is a hint that is ignorable

Bob is looking at one of Doug's proposal

<gpilz> doug refers to the issue description for his original proposal

Folks on the phone - whiteboard discussion in-progress

Transcribing white board

a) OPTIONAL Hint that describes the content, CONTENT DESCRIPTION

b) Close with no action

Adding more stuff to option a)

a) OPTIONAL Hint that describes the content, CONTENT DESCRIPTION. If the service cares then faults if the URI is not known. If the service does not need the hint, then ignrores

restating option a)

a) OPTIONAL Hint that describes the content, CONTENT DESCRIPTION. If the service needs a hint and the CONTENT DESCRIPTION is not known, then service MUST generate fault. If the service does not require a hint then may ignore the CONTENT DESCRIPTION. Type(CONTENT DESCRIPTION) = xs:anyURI

b) Close with no action

<dug> a) includes defining a fault

OPTIONAL Hint that describes the content, CONTENT DESCRIPTION. If the service needs a hint and the CONTENT DESCRIPTION is not known, then service MUST generate fault. If the service does not need a hint then may ignore the CONTENT DESCRIPTION and will NOT generate a fault. Type(CONTENT DESCRIPTION) = xs:anyURI


a) OPTIONAL Hint that describes the content, CONTENT DESCRIPTION. If the service needs a hint and the CONTENT DESCRIPTION is not known, then service MUST generate a fault (to be defined). If the service does not need a hint then may ignore the CONTENT DESCRIPTION and MAY NOT generate a fault. Type(CONTENT DESCRIPTION) = xs:anyURI

b) Close with no action

Bob: a) is only a direction not a concrete proposal, editors will need to prep a concrete proposal

RESOLUTION: consensus on a) as the directional proposal

Issue is still open

<scribe> ACTION: Doug to prep a concrete proposal based on directional proposal a) for issue 6712 [recorded in http://www.w3.org/2009/06/09-ws-ra-minutes.html#action04]

<trackbot> Created ACTION-68 - Prep a concrete proposal based on directional proposal a) for issue 6712 [on Doug Davis - due 2009-06-16].

<gpilz> http://www.w3.org/2002/ws/ra/edcopies/wst.html isn't working

<gpilz> scribin - ur doin it wrong

<Bob> scribe: Tom Rutt

<Bob> scribenick: TomRutt

Issue 6692 (Mode)

<Bob> http://www.w3.org/2002/ws/ra/wiki/


Gil: I suggest that we are familiar with all the proposals, and suggest we move this to CHAD. Is there anyone whose opinion will change with further review of the proposals?

No support for Proposal A indicated

Some support for Proposal B

Some support for Proposal C

Some support for Proposal D

Bob: lets do a single vote per company STV.

Proposal B. remove wse:Delivery element and all it's sub-elements Proposal C. close with no action Proposal D. Add new mode

Bob: B handles policy centric world well, C does not service it, D provides a way to indicate use of policy. In terms of charter, C and D are stronger

Geoff: Can we separate the proposals, remove delivery element, ws only remove mode attribute of delivery element?

<dug> Delivery element's purpose can be achieved using the EPR element instead.

Geoff: there has not been a lot of discussion on delivery item itself

<Wu> There are things in Delivery that are not good for EPR, see examples

<Wu> in Li's cases

<dug> those are properties of the subscription and would go outside of the Delivery element.

Geoff: delivery element allows for containment of life cycle

<dug> And Li's example is a perfect example of the problem with Mode. How do you compose those two new modes with your Proxy example? Who will define those new modes?

Asir: It seems premature to stop working for consensus. Implementers have spoken, we need to consider their views for adoption purposes

Bob: can someone speak why D is not appropriate?

Dug: Proposal D does not do anything for interop or composability. Keeping Mode in any shape or fashion encourages bad behaviour.

Asir: I do not agree Mode is being used as a replacment for RM or Security.

Bob: Push with Ack in ws-man is not an adequate replacement for ws-rm, it is mainly a flow control mechanism.

Gil: while mode push with ack is not an adequate replacment for WS-RM there is a lot of functional overlap

Bob: I am concerned that Mode conflates characteristics of format, protocol behaviour, network characteristics and jumbles them into a single URI value
... Dug's argument is that the Mode mechanism is not consistent with other extension mechanisms commonly used in ws-* specs
... I am not hearing new concerns on the use of Mode.
... my device implementers could accept an alternative which is a qname check, however if a policy intersection engine like thing is required, they would balk.
... is eventing a device spec, a large system spec (possibliy uncomfortable for devices) or for both?

Asir: I believe it has to work for both types of system
... I suggest we have a set of guidelines for the proper use of the Mode mechanism. We can have an example of one or two modes, to set the precident for the rest of the world to use.

Bob: I am not sure the big system guys would be happy unless there as a policy friendly approach to use

<asir> I also added that we should do it in a way that big system vendors adopts them too

Wu: option C does not disallow use of policy, however it maintains mode for small devices

<asir> Actually, option C composes with the use of WS-Policy

<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0016.html

<asir> if there is a perceived composition issue that should be addressed

<asir> no doubts

Dug: mode is a fundamentally broken feature, it not only does not compose with ws-* world, it also does not even work with its own suggested uses. Some of the examples (e.g., mode with proxy) do not work

<Wu> There is clear value for a light solution in mode. And delivery element is critical seamtics in WS-E (See section 2.2)

Dug: what is missing is a way for event source to tell synch what it supports. A middle ground proposal is to give equivalent to mode, with a single uri check, but use a policy reference.

bob: the smallest device implementers will only support "push" mode.

Dug: we can define a mechanism to advertise which policy URIs are supported. This allows the best of both worlds.
... a source can provide metadata to describe which policy can be placed within the subscribe.

Asir: it is qname not uri.

Dug: You could use a policy ref URI
... mode is not extendable. You cannot add tweaks to an existing mode without creating a new mode URI.

Geoff: I recommend that we live with mode, and decide the best way to organize to move forward to give both sides what they need (not fracture market)

Bob: At smallest end they do not think of protocol layers, they implement a state machine which minimally ensures the protocol will work within their particular constraints. They want a simple qname, or URI attribute which they can do a comparison to.
... On the other side, the system guys state mode is unacceptable. All behaviour is in extension specs, such as ws-man. You are not implementing eventing, but ws-man eventing.
... this makes it difficult to extend in an incremental manner.
... the small device guys want to know where to look for the value which they can do a quick check on.

Yves: with regard to proposal D being "ugly". We have two user views, use policy, use a single value. Proposal D was not meant to be beautiful, but was meant to allow both user views. What is blocking factor in the use of proposal D? We have a wider community than WS-Man on both sides of these views

Dug: D promotes an extensibility point which is not useful in anything other than the simplest cases. I see it as fundamentally broken. Alllowing use of full blown policy or use of policy refs allows a solution which can work for the small and large systmes.

Bob: does example 1 of proposal b provide a mechanism for small system side? 1. This first one uses a PolicyReference to refer to a predefined policy assertion
... is a policy ref uri a functional replacement for Mode?

<asir> Policy Reference URI does not carry any semantics

<asir> it is just a reference

Wu: I do not think so, since mode has defined fault messages.

bob: the fault is optional.

Gil: the fault as policy negotiaion at run time is way too late for me. There is a need to know ahead of time what is supported.

Wu: the policy reference does not satisfy the negotiation allowd by the mode with its faulting behaviour.

Dug: we could define a fault to use with the policy reference approach.

<asir> We are not convinced that policy reference URI is a functional replacement for mode

Dug: we can define a fault which is just as informative if the value of the policy reference URI is not acceptable, including the policy refs which are supported in the fault information

Bob: this approach is reducable to the minimal case for mode behaviour, but is extensible to more full use of policy.
... we could state "resource constained systems should only use policy reference URI".

Geoff: By doing this we are missing the distinction of two life cycles by deleting delivery element. Â You cannot stick everything you want into NotifyTo, you have lost differentiation.

Bob: back to the original question, can the policy ref (where it is placed can be discussed further) value serve as a functional equivalent to mode?

Geoff: this would require further discussion before answering.

Asir: while I agree a uri value can be used, it is a different question as to whether that uri can be a policy reference. The policy ref is defined elsewhere.

Ashok: would you be happier with a policy expression being used rather than a policy ref?

Asir: that has concerns for the small device implementers. Also who would define the policy assertion for "push"

Ashok: this spec could define such a policy assertion type.

Asir: that would require a complete proposal to evaluate.
... using full policy expression would not help the small device implementers.

Ashok: the use of policy is not a problem, it seems to be the full policy intersection which is troublesome for implementers of small systems.

Li: how about an option E: there are several modes listed in the Wiki. There is a hierarchy of things, push vs pull, then other features (ack or not), interval or not, and the combination may not be suitable for one uri. A compromise is to keep mode as element, and separate out the push vs pull indication. This would allow multiple refinements to do combinations. For those which do not support refinements, we still have push vs pull

bob: mode element with multiple possible children as refinement elements. One might be push, another ack. then push with acks would be adding both children.

Li: no I would prefere a mode element with name "push" allowing refinements such as "acks" or "intervals"

Bob: I see this as having some of the characteristics of ws-policy.

Gil: the ws world has ws-policy, which is a general purpose framework for dealing with such issues. Why do we need to have a concept of mode?
... do not see need for additiona wrapper element, such as delivery, to deal with extensions. WS-man mode has functions which are outside of semantics of delivery element. The semantics of extension tell you what they are for, and can be kept as extension to subscribe element.

Bob: I hear Li's proposal as a way to express the semantics of current uses of mode, using a mechanism which is similar to the policy expression.
... are you suggesting to put this new mode element within the deliver element, as an alternative to a mode attribute?

Li: yes that is my proposal.

<dug> Gil: given a nested structure, such as

<dug> Subscribe

<dug> Delivery

<dug> Mode

<dug> PolicyURI

<dug> NotifyTo

<dug> EndTo

<dug> Would a policy on notifyTo and EndTo require its own child policy like element.

<Bob> scribenick: Tom_Rutt

Bob: the fundamental issue on mode as a single URI , regarding the combinatorial effect is helped by the list of behaviour elements, which makes it look more like the use of ws-policy
... if we did have such a new "mode" element allowing a list of behaviour subElements, where would it be placed
... I would like to understand why the delivery element would place this new mode element

Geoff: Mode as originally defined was to define lifecycle of notifications. If one was to replace mode with something like policy, this is a general concept which is broader than delivery aspects.

Gil: extension is extension, with its own semantics. All we need is an any extension, which if not understood is ignored. You can also add a header element to indicate its use is required or in use.

<gpilz> wsman:ContentEncoding, wsman:SendBookmarks both exist outside of wse:Delivery, yet apply to the lifecycle of the notifications

Dug: lifecycle of notification seems no different than lifecycle of any message. We already have an extension inside of EPR. both Notify To and End To have different semantics, but both could have a new feature which needs to be turned on. I see no need for having a new "endTo:@Mode" when epr extension could be used.
... I see three extensions for:

Properties of notifications (notifyTo epr)

Properties of end to message (endTo epr)

Properties of subscription itself (xs any of subscribe)

dug: what do you need to do for a notification delivery that you do not have to do for end to and notify to
... would it not be better to use a solution mechanism which can be used in other places for ws-*

Geoff: All the things which have been done with mode so far are eventing specific. I would have to think about (given eventing is one-way construct) mechanisms which are more general

Dug: the push vs pull example is concrete and might be a reason to keep mode. However we have ways to solve this without mode (e.g. make connection). RM has an acksTo epr which can work in push and pull environment without using something like the eventing delivery mode attribute

Geoff: it is not clear to me that make connection is a complete solution for pull mode of eventing. It is the limitations of eventing that has me saying that the concept of doing eventing is different than just passing around messages

Dug: to keep mode there needs to be concrete examples as to why eventing is different. I need to understand why an EPR is not good enough to satisfy those needs. Most examples I have heard could be handled using an EPR. It seems to keep coming back to "that is the way we implemented it already"

Wu: having a delivery mode attribute gives a single place to add delivery extensions. I do not see a problem of keeping mode, and also allowing more general policy mechanisms

Gil: experience shows that people to not stay within the model of having delivery extension only be in the mode attribute. The idea that wse:delivery is a magical envelope to constrain all extensions does not work. For example, WS-Man has extensions that are not handled by delivery mode

Wu: I see value in delivery element, it is there and should not be removed

Dug: delivery does harm, since we have to explain how to use it and when to use it. We have to define what goes into subsribe, the delivery element, and the eprs. I see two extensibility points, say the subsribe and the notifyTo epr. Why is sending out notifications different than sending any other message. There are two lifecles, one for the subscription, the other for the message...
... (notification). I do not see how we have an additional lifecycle between those two.
... given structure





scribe: ...

I see no need for anything between these two. NotifyTo gives all that is required for delivery.

Asir: if you take away push and pull this could be true

<asir> I am afraid that Doug wasn't around when Eventing was designed

<asir> Interesting rationale

Dug: eventing did not do a mode for endTo.

<li> where is time machine?

Wu: that is because endTo has only push way.

<asir> i wish we had one .. so we could put doug in and roll him back

dug: why is push the only way to deliver endTo?

Li: Dug says epr alone can indicate if I can do push or pull. What about anonymous address, this does not give enough information for push and pull.
... ws addressing has "anonymous" and "none" as address.

bob: Li is saying: with epr I can do push and pull mode with epr. How do I tell to do pull mode with EPR. I cannot send message to anonymous or none? How do I send pull message.

dug: you can pass in a makeConnection uri instead of an anonymous URI, that states the make connection is used to pull the message

<asir> Li drives home the point that an EPR is not enough

Li: if you have to extend EPR why is it not acceptable to just use Mode, rather than define a new extension for epr?

<Bob> Li now understands that the epr could be a container for more information

Geoff: If we put everything in an extension to notifyTo epr, I do not see how this could handle things such as queuing

Dug: priority mechanisms could apply to both push and pull. Those types of things would be properties of subscription, and thus would be outside notifyTo EPR.

Geoff: epr is to decide mechanism to send the information. However eventing has subscription mechanism to define how to send the information, not associated with mechanism used to send notification

Dug: we cannot remove extensibility inside the eprs, we need extensibility inside subscribe, I see not need for also having extensibility inside delivery element

Bob: regarding push and pull, we need a queuing mechanism for pull. If we need different qos for separate queues, this is not part of delivery but is part of the subscription. We could define a queuing behind a push (higher priority send first). It might be better to define in a general subscription bucket a way for defining extensions pertaining to the subscription. Some specs have put...
... such extensions into the delivery mode, but they are not really associated with delivery endpoints
... having a flexible way to place extensibility points in different buckets seems good. Slicing the current aspects associate with current uses of mode into their more appropriate locations would be good. The concern seems to remain about evolution from current implementations.

Gil: putting policy in subscribe message itself is not how I see it. If I want to request that this subscription is pausable, I would put in an extension element for pause. Where policy comes in is for the event source to state whether it supports such an extension

Bob: If we use policy as general mechanism to govern operation of eventing for large systems, and retain the mode stuff for small systems, the large systems would not use such a mode extension unless they were implementing the specific spec which uses mode (e.g. ws-man)

Li: the mode could have an attribute at a high level (e.g, pull or push) Then its children could have more specific behaviour identifiers within the context of the higher level mode







Why is this not good enough for such an extension

<dug> <subscribe>

<dug> <notifyTo> ... </notifyTo>

<dug> <pull/>

<dug> <queue foo=true|false/>

<dug> </subscribe>

<li> should <queue> be inside <pull>?

<dug> it can be - gil just moved it there :-)

gill: or could do:


<Queue />


<li> ok, something like that

If queue is defined as part of pull extension

<li> or the root could be <mode name="push|pull" >

Geoff: Gil's proposal has always been: 1) use basic extensions to add new features, 2) use new headers to indicate feature must be understood, 3) use policy to advertise what is supported

Dug: another example:


<notifyTo> </notifyTo>



Dug: this is just as easy to check. The qname can be seached for in the subscribe message

Geoff: this approach allows many things to be added. How do you find the extensions

Dug: same problem exists for a mode element with multiple children

Gil: there is nothing that can be done with a uri that cannot be done with a qName extension

as particpant rather than scribe: Any way to get around the combinatorial limitations of the mode attribute (such as Li’s proposal to allow a smaller number of high level mode names, e.g., push or pull, with a nested list of further detail elements, e.g, use ack) will require current ws eventing extensions to change theirimplementations to evolve. I am now even more of the opinion that using the...

scribe: extensions with qNames will not be more difficult to implement than these other proposed hacks to retain the mode attribute



<notifyTo> </notifyTo> (changed from <Delivery/>

<endTo> </endTo>?





why is this more difficult?



<notifyTo> </notifyTo> (changed from <Delivery/>

<endTo> </endTo>?



<mode uri= />


Bob: we could define a predefined extension called mode with the proposal above
... as an alternative could put the mode extension into the notifyTo EPR, or any other EPR you need to extend
... currently there is no way to describe mode for endTo

<li> it didn't die but was murdered

<gpilz> it couldn't live with its own lameness

<Bob> recessed until tomorrow

<Bob> ashok tomorrow am, Prasad tomorrow pm

Summary of Action Items

[NEW] ACTION: Doug to prep a concrete proposal based on directional proposal a) for issue 6712 [recorded in http://www.w3.org/2009/06/09-ws-ra-minutes.html#action04]
[NEW] ACTION: Geoff to re-work the proposal for issue 6956, due tomorrow! [recorded in http://www.w3.org/2009/06/09-ws-ra-minutes.html#action02]
[NEW] ACTION: Gil to provide a draft definition for lit rep, issue 6975 [recorded in http://www.w3.org/2009/06/09-ws-ra-minutes.html#action03]
[NEW] ACTION: Yves to open an issue to solve versioning and partial PUT in Transfer AND provide a proposal [recorded in http://www.w3.org/2009/06/09-ws-ra-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/06/29 16:37:56 $