See also: IRC log
<trackbot> Date: 09 June 2009
<asir> Scribe: Asir S Vedamuthu
<asir> ScribeNick: Asir
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 ...
RESOLUTION: 2009-06-02 minutes approved
Gil is ready to discuss 6401
Bob: ready to discuss mode proposals
Yes
Bob: ready to discuss T and Frags issue
See http://www.w3.org/Bugs/Public/show_bug.cgi?id=6956
<scribe> postponed
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
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
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6975
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
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6712
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
re-stating
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
<Bob> http://www.w3.org/2002/ws/ra/wiki/
http://www.w3.org/2002/ws/ra/wiki/Proposals_for_6692
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
Subscribe
NotifyTo
scribe:
EndTo
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
Dug:
<subscribe>
<notifyTo>
</notifyTo>
<Pull/>
</Subscribe>
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:
<Pull>
<Queue />
</Pull>
<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:
<subscribe>
<notifyTo> </notifyTo>
<push_with-proxy/>
</subscribe>
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
Gil:
<subscribe>
<notifyTo> </notifyTo> (changed from <Delivery/>
<endTo> </endTo>?
<Filter/>?
<Format/>?
<Extension/>
</subscribe>
why is this more difficult?
Bob:
<subscribe>
<notifyTo> </notifyTo> (changed from <Delivery/>
<endTo> </endTo>?
<Filter/>?
<Format/>?
<mode uri= />
</subscribe>
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