See also: IRC log
<trackbot> Date: 01 October 2009
<Bob> still waiting for folks to show up in Hursley...
<Bob> scribe: Jeff Mischkinsky
<Bob> scribenick: Jeffm
<scribe> new issue accepted
RESOLUTION: resolved 7770 as proposed
RESOLUTION: new issue 7774 opened
doug: wants a more complete proposal
needs more discussion
and more extensive proposal
bob asks if any objection to accepting the proposal in 103
RESOLUTION: resolved 7426 by adopting proposal
in msg 2009Sep/0103.html
Issue-7588 Enumeration: Expires multiple data types creates interop
problem is same for eventing and enumeration
gil proposes using duration across the board
gil: makes things simpler
... can be confusion as to what time it is on various systems when using datetime
dave: supports gil's proposal -- impl experience his group had led them to using duration
<asoldano> I'm in favor of the proposal too
dave: if we have to go back to datetime, we have to mandate utc (or some specific timezone)
ram: should require the use of duration
<Yves> non tz-qualified time are indeed a huge source of interop issue
ram: datetime useful when the devices
one is talking to know what they are doing, so leave it as
... use policy to indicate datetime support
dug: if we keep dt, need to have to
... torn on the topic - use case - i want a subscription until midnite tomorrow
... time on the source
... not sure if we absolutely have to support the use case, but we should be aware that we will not be able to support it w/ duration only
bob: who specifies the tz- the client or server
dug: always use the source's tz
martin: in business env dt tends to
be used more than duration - e.g. some "business event" finished by
... regardless there are clock synch issues - no way to know how long msg delivery takes
gil: if u specifiy a duration of 1 hour, and 2 hours u get a response back, u know things are screwed up
martin: no reason to exclude dt
no objection that duration should be required
gil objects to support of dt, even as optional
jeff: suggests that if dt is supported then it must be unambiguously specified
katy: you might be in a closed system where u "know"
Directional Resolution: 1. implementation of duration is mandatory. 2. impl of dt is optional, 3. dt specified must be unambigous 4, must be policy mechanism to say if dt is supported
discussion on various ways to make the dt unambig - will be hashed out as part of the proposal
consensus is we don't want to get into clock synchronization issues
ram: why do we need to resolve the ambiguity, given that this is optional
gil: get interop problem if u don't make it unambig
bob: it is up to the source (the source
(the source's clock) to determine expirty
bob: an unambig dt must include the date, time AND tz
dave: discussion makes my case for why we shouldn't do dt -- been down this rathole
<scribe> ACTION: pilz to produce concrete proposal based on direction for issue 7588 [recorded in http://www.w3.org/2009/10/01-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-113 - Produce concrete proposal based on direction for issue 7588 [on Gilbert Pilz - due 2009-10-08].
gil: don't want to require remembering state of expired subscriptions
<dug> email from katy: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0066.html
ram: katy's proposal is scoped to the case hwere the subscription mgr is still alive
martin: if subscription mgr is not avail, then can't tell anything :-)
ram: if the subscription has expired or been deleted, then the subscription mgr for that subscription may not be alive
<dug> If the subscription manager is exists but the subscription is not valid, the request MUST fail....
<asir> what does it mean to say not valid
<asir> suggest 'unknown'
<dug> If the subscription manager exists but the subscription is not valid, the request MUST fail and the subscription manager MUST generate a wse:InvalidSubscription fault.
<dug> If the subscription manager exists and the subscription is not valid, the request MUST fail and the subscription manager MUST generate awse:InvalidSubscript ion fault.
<asir> suggest replacing not valid with unknown
<dug> If the subscription manager exists and the subscription is not valid, the request MUST fail and the subscription manager MUST generate a wse:InvalidSubscription fault.
<asir> If the subscription manager exists and the subscription does not exists, the request MUST fail and the subscription manager MUST generate awse:SubcriptionDoesNotExist fault
discussion evolves into what are the states of subscription
martin: there are really 3 states - expired, unknown, deleted (unsubscribed)
more discussion about existential existence (as opposed to existetial non-existence ;-) of deleted subscriptions
katy: need a state diagram
martin: if a getstatus(subscription)
is done -- if you have no history, a fault is generated,
... if you have a history, and its been deleted, then you don't generate a fault, you return the proper status
<DaveS> Satae suggestion:
<DaveS> - Created
<DaveS> - Renewed
<DaveS> - Expired
<DaveS> - Cancelled or deleted
<DaveS> - Unkonwn
martin: only one fault - unknown subscription - everything else is a known state
<Ram> How about we change "Valid" to "Active" and "Invalid" to "Inactive".
wu: have a generic fault with
sub-fault codes that reflect the state
... sub-fault codes are optional
<DaveS> Status with Ram's suggestion:
<DaveS> - Created
<DaveS> - Renewed
<DaveS> - Expired
<DaveS> - Cancelled or deleted
<DaveS> - Unknown
<DaveS> GetStatus never faults.
katy: agrees with martin
ram: we need to define the "structure" of the get status returns
dave: need a form of status which doesn't fault
asir: expired and deleted are
internal states of the event source
... how can this be tested?
jeff: what we are really talking
about is whether a "bad" subscription faults from get status
... or it always returns "normally", with a substatus
bob: dave's proposal is unless there
is some internal disaster, get status always returns normally
... major status returned are "usable"/"unusable", or active/nonactive
... try again -- 2 major "uber status": active/unactive and then there is detail info which further elaborates
discussion ensues -- on what is the difference between not knowing of a particular subscription and knowing that it existed in the past and has been expired/deleted
<asir> confused is a possible state as well :-)
<dug> its a perpetual state
bob: should server fault with a bad
... should server not fault , but would return as a status "unknwon subscription"
bob: if a subscription which is the subject of a get status op is not known (for whatever reason) should the operation a)fault or b)return info?
<Yves> to me a) and b) are fine... it's basically a style issue. However we should be consistent across specs when we encounter that kind of case
<Bob> thanks, Yves
ram: at highest level - is the
subscription manager present - if it is not, then all bets are off
(outside of the scope of the WG)
... question is what to do when the sub mgr is present
... a)fault b)send direct response saying deleted, expired, unknown
... when you do a Transfer.get you don't get a fault (ignoring low level protocol faults), you get back a repsonse
martin: conflating sub mgr and the subscription
<asir> Doug => resource does not exist == subscription manager does not exist
<dug> not necessarily for all impls - to some a non-existent subscription could still point to a sub mgr
<asir> That is true from a subscription point of view
martin: if get_status request gets to the subscription mgr, by definition the subscription is not unknown (otherwise it wouldn't have got to the subscription mgr)
<asir> but from a endpoint point of view, resource does not exist == subscription manager does not exist
bob, dave: no you won't -- there is not necessarily a 1-1 between sub mgr and subscription
<dug> there could be on subscription mgr for a ton of subscriptions
<asir> no disagreements on that piont
<dug> Dug: I'd like to discuss the state tables first
bob: martin raises the issue of the
existence of the thing we are trying to query
... in other words what is the window of existence?
After a long discussion, we may agree on the following:
bob: there is only one active state
for a subscription
... Before that active state exists, the renew req, get_status req, unsubscribe req must fail and may generate the invalid subscription fault.
katy: need definition of subscription in the spec
bob: need to tidy the language in get_status operation that seems to indicate that there is a distinction between invalid and expired (i.e. collapse them)
<scribe> ACTION: katy to produce a redline proposal consistent with the above principles [recorded in http://www.w3.org/2009/10/01-ws-ra-minutes.html#action02]
<trackbot> Created ACTION-114 - Produce a redline proposal consistent with the above principles [on Katy Warr - due 2009-10-08].
<Bob> scribe: Katy Warr
<Bob> scribenick: Katy
Katy: This may require updates based on discussions this morning
Martin: Why would this be any
different from any other WSDL fault why not return SOAP receiver
... This is a generic fault
Asir: Why would we need EventSourceUnableToProcess
Katy: This is already in the spec but
specific to Subscribe
... ... it has Retryafter detail
Asir: But Soap receiver fault indicates that you can retry any time after
<li> are we discussing 7554?
Martin: Should only ave faults for aspects specific to eventing
li - yes
Ram: Invalid receiver fault is when the fault is not due to the content of the message
DaveS: Non Soap fault would be useful for additional info too
Doug: Like REtryAfter
<dug> yves - I'm blocked: 188.8.131.52
Li: Can we use info set with SOAP 1.1?
Asir: Is this a more general concern regarding the use of eventing with soap 1.1?
<asir> Receiver The message could not be processed for reasons attributable to the processing of the message rather than to the contents of the message itself. For example, processing could include communicating with an upstream SOAP node, which did not respond. The message could succeed if resent at a later point in time (see also 5.4 SOAP Fault for a description of the SOAP fault detail sub-element).
The question is: Do we ned the SubCode of the EventSourceUnableToProcess
<dug> I'm being blocked: 184.108.40.206
Katy: Do we need the RetryAfter?
<dug> working now
Bob: I think we can use the generic fault
DaveS: Need to step through faults
<Yves> this ip is not blocked
<dug> just started to work
InvalidExpirationTime: Keep (don't replace with generic)
<dug> who is that?
<Yves> you at the office; 0
<Yves> so most probably a proxy
<dug> no - at IBM hursley
Martin: What's invalid, if you can't
be precise, don't keep it
... This is a candidate for removal I think
EventSourceUnableToProcess: Definitely goes - generic soap fault
DaveS: I htink this is the same as
EventSourceUnableToProcess so should have same action
... again question is is there genuine value in retry after?
Martin: Can put that in the generic fault
INvalidMessage: Generic SOAP fault
Asir: InvalidMessage adds some value
Doug: This message is not referenced
from the spec
... It may have been moved or be added as a generic message
DaveS: InvalidMessage should go
DeliveryFormatRequestUnavailable and EmptyFilter: Keep
Doug: UnusableEPR is is the EndTo contains something like FTP that's not supported
Ram: Should retain UnusableEPR
Doug: InvalidSubscription should probably be renamed as Unknown as part of 7554
General agreement to this.
<asir> Consensus: s/InvalidSubscription/UnknownSubscription/
<asir> Consensus: s/InvalidSubscription/UnknownSubscription/g
<asir> a) s/InvalidSubscription/UnknownSubscription/g
<asir> b) s/InvalidMessage//
<asir> c) s/EventSourceUnableToProcess//
<asir> d) s/UnableToRenew//
RESOLUTION: Combine the
above discussion with the 7553. SubscribeRequestInvalid,
EventSourceUnableToProcess, UnableToRenew, InvalidMessage become
... InvalidSubscription renamed as above
Doug: Should make it clear where to put the retry in the generic fault - i.e. that it can be used in the detail space
RESOLUTION: Agree above
<dug> yves - I'm blocked again
Bob: Subject to action on Gil from earlier
Gil: Need to define how to compute
this URI if it not there
... A.1.2.1 and A.1.2.2 require text describing how to compute the ActionURI if it is not present in the event description
<gpilz> The [Action] property of the Notification has the value of the actionURI attribute of the wse:eventType element corresponding to the type of the Event being transmitted.
<gpilz> The [Action] property of the Notification has the value of the actionURI attribute, if present, of the wse:eventType element corresponding to the type of the Event being transmitted.
<gpilz> If the actionURI is not present, this property has a value that is the concatentation of the wse:EventDescriptions targetNamespace attribute and the wse:eventType name attribute separated by the '/' character.
Doug: Will this apply to all bindings?
<gpilz> This attribute provides a value for the various 'action' properties and attributes which, depending upon the format of the Notification used to transmit the Event, serve as a potential aide to identifying the semantics implied by the message.
<gpilz> This optional attribute provides a value for the various 'action' properties and attributes which, depending upon the format of the Notification used to transmit the Event, serve as a potential aide to identifying the semantics implied by the message. When not present the implied value of this attribute is the concatentation of the wse:EventDescriptions targetNamespace attribute and the wse:eventType name attribute separated by the '/' character.
Gil: This saves changing it in both A121 and A122
Asir: Does this address your concern about bindings Doug?
RESOLUTION: Text updates as agreed above and also ensure that schema is updated with '?' appropriately
Li: Need to maintain the semantics of
push in the eventing spec
... it is a very important concept in eventing
... proposal is to add an indication of the type of delivery that is supported by the event source
Martin: What is the definition of push in this context?
Li: The event delivery is initiated by the event source so there is no dependency on messages from the event sink for the delivery of events
Bob: Push is the default way that the spec operates using an EPR
Asir: This is not the default. The
NotifyTo is not required in the spec.
... What Li is proposing is a way to say that you require the NotifyTo
Doug: Is this to say event source supports or client requires Push?
li: The former. B.3 is not part of this discussion.
Doug: All you are looking for is a way to say 'I support the NotifyTo'
Doug: I don't think that the source
can fault because it doesn't understand notifyTo
... Definition 4.1 indicates that an EventSource must support notifyTo
... So we don't need a policy to indicate this
Asir: Looking from the metadata point
of view. The text says when NotifyTo is there, receiver must do
... As an EventSource, I need a runtime-independent way of indicating support for NotifyTo
... EventSource tells subscribers if you are talking to me then use NotifyTo
Martin: This is a flag to say only
NotifyTo is supported
... is my interpretation
Asir: We could add a sentence to explicitly state that all eventsources must support notify to
DaveS: Text under 4.1 indicates support. I think that this issue is for the EventSource to indicate that *only* NotifyTo is supported.
Bob: Is the sentence in 4.1 clarity
enough to say that NotifyTo must be supported?
... Do we need 'All EventSources must support NotifyTo'
Doug: But we'll need to do that for all optional client behaviours
Martin: The current 4.1 text is unambiguous. If client passes a notify, must send
Wu: It does not say that it is required
Bob: The first question is: Do we make it clear enough in the spec that the event source must support notifyto?
Wu: I would like a clarifying sentence in 4.1: "EventSource must support NotifyTo"
Doug: If we really want to do this, we should clarify in the compliance section to say that optional client behaviour by default means required service behaviour
Martin: RFC2119 says should be clarified for sender and receiver
DaveS: We should check each optional/musts
Bob: Would this be sufficient to clarify that for all of the sender optional things described, receipt of these optional aspects is required by the receiver
Wu: This is a good step forward
Ram: What if I really want a subscriber to send me a NotifyTo
Doug: If in your policy you don't include any other mechanisms for notification then that indicates that only NotifyTo is supported
Asir: What is the fault if the sender does not send a notifyTo when that is required
Bob: Do we have an agreement that we will clarify the conformance section regarding optional sender aspects
Wu: Yes. This will satisfy our first concern
Martin: In response to Asir's question - we need to be clear as to what fault is returned
Bob: What other aspects need to be considered Li?
<Wu> This "OPTIONAL" clarifying is needed, because it beyond the original def of "Optional" as in RFC 2119
Li: If you want to do Push from the EventSource, how does the EventSource know that there's nothing more than the EPR required to send to the sink?
Bob: Li, is your question the
EventSource requires no further stimulus other than the occurence
of an event to send a notification to an EPR
... ... is that written in the spec? My belief is that the spec covers this.
... I believe the question is WHEN is the notification sent. Is this correct Li?
Martin: You can't say how long it takes to reply to something.
Gil: How about filtering or batching? This would take time
Bob: I think that Li's issue is regarding the wording of Push
<dug> scribe: Dug
Wu: missing async unsolicited
<gpilz> how can in be unsolicited when you asked for it by sending a Subscribe request?
Bob: async with respect to what?
Wu: async with respect to the event sending behavior
<scribe> scribe: Katy
Bob: When we first looked at the
definition of 'Push' we found it undefinable which is why there was
support to remove it
... The current spec uses an EPR and there is nothing that the source needs to do other than send the messages. The spec is clear now
Martin: I can't see what other normative text could be added for this behaviour
Li: As the current spec already implies the behaviour of push, I think this works.
RESOLUTION: Add text to the conformance section to clarify optional sender behaviour means required receiver
<scribe> ACTION: Doug to come up with proposal across all 4 specs and also to uppercase OPTIONAL [recorded in http://www.w3.org/2009/10/01-ws-ra-minutes.html#action03]
<trackbot> Created ACTION-115 - Come up with proposal across all 4 specs and also to uppercase OPTIONAL [on Doug Davis - due 2009-10-08].
Wu: We are happy with this direction and think it's a good step forward. We may propose additional augmentation as new issue if required.
RESOLUTION: Resolve 6402 with comment 7 and schema update
Yves, please could you unblock me? - 220.127.116.11
<Yves> katy can you retry?
Yves thanks working now
<dug> Gil's proposal: http://www.w3.org/Bugs/Public/attachment.cgi?id=760
Wu: Starting with proposal uses
boolean attribute in section 1
... can support existing use of expires
... need to add attribute in schema in 4.1
... called exact and this optional attribute has value of true then MUST create with the expration time or else fault
... if it has value of FALSE, then expiration time needn't be exact
... This ensures that the eventsource must honour expiry if that's required but also gives flexibility if the exact expiry is not required
Martin: If you say exact=false, what
does that mean?
... I understand the true case
<asir> suggest that we don't call other participant's use case silly
<dug> can we call each other silly?
<gpilz> it's not the use case that is silly, it's the behavior
<dug> its probably tamer than what we'd like to say :-)
Gil: A problem is that there's
nothing to say that the eventsource will give a close value if the
exact flag is not specified
... a hint is semantically meaningless in this context
<asir> I would like to ask Gil a clarification question
Gil: so exact=false is going back to
the current behaviour where the client has no say
... A client needs to be able to set a lower limit on what it can live with if the exact=true is not specified
Ram: The existing behaviour makes a
lot of sense in devises world
... In that environment it makes sense for the client to request a time, but if that's not possible then the service offers what it can
... the client can choose the service that gives the best service. e.g. printer services
... I appreciate that we might need min too but we should make all the use cases work
Gil: But why would I bother to specify an expiration at all if I can just accept what is being given?
Ram: I believe that the proposal
allows both behaviours
... We think we can add sufficient words to clarify what Exact=false means
... If we do this can we make some progress on this issue?
Doug: In the proposal is there a way
of saying 'I don't care about the expiry time'
... I wonder whether we should cover all 4 cases 1) Exact time (Exact=true), 2) Indefinite time (no no expires specified), 3) Hint (Exact=false) 4) I don't care
Wu: the proposal doesn't cover 4
<asir> Ram said that 4) is the same as 3)
Wu: Typically a subscriber will ask
for the maximum - which we have covered
... When Li and I went through use cases there is no real benefit to specifying a minimum time because a server will always choose the minimum time in order to save its resources
Doug: Do we have a use case for 'don't care'?
Gil: 4- If it was so important for you that the subscription succeed that you will accept any expiration
Wu Ram DaveS Bob: Do not see a use case for 4
Martin: The current spec says nothing
- the source can pick any time it wants
... I don't understand the use case for a hint
Gil: The use case for a non-hint is that I would like to specify boundaries to the expiration time and hint does not give me this. I'd prefer to say fault the subscription if you can't do min expires.
<asir> Martin - why allowing the hint use case is harmful?
Gil's proposal http://www.w3.org/Bugs/Public/attachment.cgi?id=760
Gil: This is based on yesterday's discussions
<MartinC> thr trouble with hints is anything can be given, and some may not be acceptable, so hint is a weak "don't care"
<asir> k .. is that harmful?
Gil: 1) Leave expires element out =
accept anything, 2) Expires says = this is what I want 3) Expires
with min attribute = specify expires but this is what I can live
... This satisfies the use cases presented and client is clear what is accepable
Ram: Problem is that the event Subscriber doesn't really know what the range is
Gil: then don't constrain with the min attribute
<asir> I have not heard any rationale as to why the WG should disallow the hint use case
<dug> <expires> 12pm </expires> == <expires min=0>12pm</expires>
<dug> old vs gil's
<MartinC> personlally i think gil's has it wring way i..e 12 is min with an optional max
Doug: <expires min=0>12pm</expires> will give the hint use case in Gil's format
Wu: Wu do not think that the min/max duration is a use case because the event source will always honour the minimum duration
Gil: But without the minimum, you could just give any expiry to save resource in the service
Bob: The difference between the
proposal is that proposal B places control of the minimum on the
... If it is the behaviour that the client will alway provide the minimum, the client could specify its minimum as exact=true
DaveS: I have identified 5 use cases
1) Exact (Both proposals) 2) Best Effort (Both) 3)
Infinite/Indefinite (Both) 4) I don't care (Gil's but could be
added to Wu's) 5) Range (Gil's only)
... So Gil's proposal is more complete but Wu's proposal is closer to current behaviour
... So if I was starting from scratch I would go with Gil's proposal but it would mean more impact to current implementations
Ram: What if we accommodated min/max in Wu's behaviour so we get (5) above but without inverting current behaviour so minimum impact to current spec
<Expires Exact=boolean | minimum=duration|dateTime> duration|datetime </Expires>
DaveS: How about we start with Gil's proposal but invert the behaviour?
Bob: Replace exact with minimum attribute. If min=expiry time then the exact time is required
Doug: If this now supports don't care we will be now be changing behaviour as missing expires behaviour will change
We: We don't care about don't care
<scribe> ACTION: DaveS to prepare new proposal for 7478 [recorded in http://www.w3.org/2009/10/01-ws-ra-minutes.html#action04]
<trackbot> Sorry, couldn't find user - DaveS
<scribe> ACTION: Dave to prepare new proposal for 7478 [recorded in http://www.w3.org/2009/10/01-ws-ra-minutes.html#action05]
<trackbot> Sorry, couldn't find user - Dave
<scribe> ACTION: DavidS to prepare new proposal for 7478 [recorded in http://www.w3.org/2009/10/01-ws-ra-minutes.html#action06]
<trackbot> Sorry, couldn't find user - DavidS
<scribe> ACTION: Snelling to prepare new proposal for 7478 [recorded in http://www.w3.org/2009/10/01-ws-ra-minutes.html#action07]
<trackbot> Created ACTION-116 - Prepare new proposal for 7478 [on David Snelling - due 2009-10-08].
<Bob> rrs, generate minutes
<Yves> trackbot, end telcon