See also: IRC log
<Bob> scribe: Sumeet Vij
<Bob> scribenick: Sumeet
RESOLUTION: minutes of f2f last week approved without objection
Bob: Any objections to accepting new issues and assigning them to their reporters?
RESOLUTION: All new issues are accepted and will be assigned to their reporters w/o
Tom: asked Doug to clarify AbstractProperties
<dug> http://www.w3.org/2002/ws/ra/edcopies/wsrt.html#get
<gpilz> this also resolves 6681
RESOLUTION: 6666 resolved with the proposal contained in the description w/o
Gill: Issue 6681 might be resolved with the Resolution to 6666
<Bob> Use InfoPath style notation
<dug> +1
<Bob> as in Issue-6666
<dug> [Body]/wse:Subscribe/wse:EndTo
<Bob> Geoff: This looks like an issue with the "*"
<dug> that's my understanding as well
<Bob> ... the idea is to expand all of the *'s with what they should be
<asir> what does [Body] mean? Infoset or XML Element?
<dug> its an abstract proprety
Asir: Wants clarification on the square brackets
<dug> http://www.w3.org/2002/ws/ra/edcopies/wsrt.html#conven
<Bob> Use pseudo-InfoPath style notation as in Issue-6666
<Bob> expand all of the *'s with what they should be
RESOLUTION: Issue 6681 resolved by using pseudo-InfoPath style notation as in Issue-6666 w/o
<Bob> proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0081.html
Li: added clarifications for issue 6431
Geoff: Need more time to go over the
proposal
... Wants clarification about Pause and Resume
<Bob> Geoff: Is queuing part of transport or is it part of eventing?
<Geoff> not sure we should add optional features to base spec
<Geoff> is it not something that should be in a higher level spec
<Wu> Wu: pause/resume is to control event delivery, not about queue
<Geoff> we are talking about composing with other specs, this seems to be another example of that
Ashok: Policy might be required to determine whether the endpoint supports it or not
<dug> +1 to that! (bob's comment)
Gill: Pause/Resume pertains more to queuing
<gpilz> pause/resume has two parts (a) an optimization of cancel/subscribe and (b) the idea that you have access to the Notifications that were transmitted inbetween the Pause/Resume
<gpilz> (b) starts to wander into queuing
<gpilz> (a) is premature
<gpilz> one could easily extend Subscribe/SubscribeResponse to indicate that additional Pause/Resume operations were in effect
<svij> Bob: Are folks proposing to close with no action?
<svij> Geoff: General sentiment is that the base level spec should be kept simple
<Bob> scribenick: svij
Wu: Pause/Resume as an option
<asir> :-)
<gpilz> +1 to Doug
<Bob> Dug: Folks questioned as to need for functionality at this time or considered it a premature optimisation
Doug: Whether this functionality is required, maybe this could be added later in a compasable fashion
<dug> its not about multiple specs, rather its more of a statement about whether this function is needed at this time
<Geoff> +1 to Bob about hating optionality
<Wu> We are fine with pause/resume as optional feature or put into Appendix to clearly indicate it.
<dug> LOL we should remove all xs:any's :-)
<Geoff> that is extensibility...
<Geoff> vey different
<Geoff> very
<asir> Different nation
<Wu> pause/resume has its critical applications, e.g. presence services, location servies, etc.
Bob: Straw poll on adding pause/resume functionality
Wu: In favor
<Ashok> We could mark it vNext
<gpilz> let's try to just answer the question that the Chair asked
<dug> There is a "LATER" field in bugzilla
Microsoft: Not in favor of adding this functionality to the base spec
Nobody else in favor of adding this now
<Geoff> if wu wants to work on a part 2 we are OK with that
Wu: Sees advantage in Pause/Resume functionality
<Geoff> we do not believe that at any time it implied that functionality like p/r would be in the base Eventing spec
<gpilz> if some organizations really need this, they should join this WG and make their opinions known
<Geoff> it was always envisaged that it would be part of a higher level spec
Bob: Asked whether this is a premature decision
Geoff: Is there a consensus on whether we need a Higher level specification
Bob: New Specifications should not be
taken lightly
... What would be our definition of "later" mean? Effectively
pushing the feature to "time indefinite"
... Suggests we should close with no action if the feature is not
to apear in this spec
... We should take a vote on whether will "close with no
action"
Asir: Bugzilla supports certain keywords like "futureConsideration"
<asir> it is "futureConsideration"
MSFT: abstain
<gpilz> Oracle: yes
Fujitsu: Yes
IBM: abstain
Avaya: No
SoftwareAG: abstain
<marklittle> Red Hat: Yes
RESOLUTION: Issue-6431 Closed with no action 4-Yes 1-No 3-Abstentions
Bob: I have marked the issue with futureConsideration
RESOLUTION: Resolve Issue-6687 with proposal contained in Bugzilla w/o
<Bob> proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0154.html
<asir> 6594 is only about Transfer
<Bob> Geoff: * adds the posibility of nothing + means there is at least one
<DaveS> +1
<Bob> ACTION: Dug to describe the text the covers the empty case in issue-6594 [recorded in http://www.w3.org/2009/03/17-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-52 - Describe the text the covers the empty case in issue-6594 [on Doug Davis - due 2009-03-24].
<Geoff> we want to be clear that acceptance of a way forwards on this issue does not mean we accept transfer wrappers
Geoff: Implications of policy implicitly defining WSDL
<asir> Tom ... i think we just started discussing here
<dug> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6403
<asir> there is a nested policy assertion
Tom: Raised a query about sub-assertions based on experience with WS-Addressing
dug: Enumeration operations are optional
Bob: Please check IRC now and make
corrections/comments
... Adjourned