IRC log of ws-ra on 2009-10-01

Timestamps are in UTC.

07:54:20 [RRSAgent]
RRSAgent has joined #ws-ra
07:54:20 [RRSAgent]
logging to
07:54:22 [trackbot]
RRSAgent, make logs public
07:54:22 [Zakim]
Zakim has joined #ws-ra
07:54:24 [trackbot]
Zakim, this will be WSRA
07:54:24 [Zakim]
ok, trackbot; I see WS_WSRA(F2F)3:30AM scheduled to start 24 minutes ago
07:54:25 [trackbot]
Meeting: Web Services Resource Access Working Group Teleconference
07:54:25 [trackbot]
Date: 01 October 2009
07:58:28 [Zakim]
WS_WSRA(F2F)3:30AM has now started
07:58:35 [Zakim]
+ +39.331.574.aaaa
07:59:03 [Zakim]
+ +
08:01:48 [Bob]
still waiting for folks to show up in Hursley...
08:04:19 [Zakim]
- +
08:04:25 [asoldano]
Bob, ok, I hang up, re-dialing once you're ready in Hursley
08:04:30 [Zakim]
- +39.331.574.aaaa
08:04:31 [Zakim]
WS_WSRA(F2F)3:30AM has ended
08:04:32 [Bob]
we are dialing
08:04:32 [Zakim]
Attendees were +39.331.574.aaaa, +
08:04:38 [Zakim]
WS_WSRA(F2F)3:30AM has now started
08:04:46 [Zakim]
+ +
08:04:50 [Zakim]
- +
08:04:51 [Zakim]
+ +0196281aabb
08:06:15 [Bob]
waiting for the scribe...
08:06:32 [Sreed]
Sreed has joined #ws-ra
08:06:35 [Zakim]
08:06:44 [Zakim]
08:07:04 [Katy]
Katy has joined #ws-ra
08:07:57 [Zakim]
+ +39.331.574.aacc
08:08:49 [gpilz]
gpilz has joined #ws-ra
08:09:21 [dug]
dug has joined #ws-ra
08:10:25 [Wu]
Wu has joined #ws-ra
08:11:54 [Bob]
folks are struggling with internet issues here
08:11:58 [Bob]
08:14:05 [jeffm]
jeffm has joined #ws-ra
08:14:12 [DaveS]
DaveS has joined #ws-ra
08:14:13 [Bob]
scribe: Jeff Mischkinsky
08:14:31 [Bob]
scribenick: Jeffm
08:14:47 [paul]
paul has joined #ws-ra
08:15:08 [Bob]
08:16:09 [dug]
08:16:30 [jeffm]
TOPIC: new issue 7770
08:17:35 [jeffm]
new issue accepted
08:19:06 [scribe]
RESOLUTION: resolved as proposed
08:19:16 [scribe]
TOPIC: new issue 7774
08:19:19 [Bob]
08:20:26 [scribe]
new issue accepted
08:20:29 [asir]
asir has joined #ws-ra
08:20:45 [scribe]
doug: wants a more complete proposal
08:21:00 [scribe]
needs more discussion
08:21:18 [scribe]
and more extensive proposal
08:21:36 [MartinC]
MartinC has joined #ws-ra
08:22:37 [scribe]
TOPIC: Issue-7426 IRI or URI
08:23:11 [Bob]
proposal at
08:23:12 [Yves]
08:23:26 [scribe]
proposal at
08:23:26 [scribe]
08:23:58 [scribe]
bob asks if any objection to accepting the proposal in 103
08:24:19 [scribe]
RESOLUTION: resolved 7426 by adopting proposal
08:24:48 [scribe]
in msg 2009Sep/0103.html
08:25:18 [scribe]
Issue-7588 Enumeration: Expires multiple data types creates interop
08:25:18 [scribe]
TOPIC: issue -Pilz
08:25:45 [MartinC]
08:25:48 [scribe]
problem is same for eventing and enumeration
08:25:48 [Vikas]
Vikas has joined #ws-ra
08:25:52 [MartinC]
08:26:11 [dug]
08:26:12 [Ram]
Ram has joined #ws-ra
08:26:19 [DaveS]
08:26:21 [Ram]
08:26:32 [Zakim]
+ +1.646.361.aadd
08:26:48 [scribe]
gil proposes using duration across the board
08:26:59 [scribe]
gil: makes things simpler
08:27:03 [dug]
08:27:57 [dug]
08:28:06 [scribe]
gil: can be confusion as to what time it is on various systems when using datetime
08:28:58 [Bob]
ack dave
08:29:17 [MartinC]
08:29:22 [scribe]
dave: supports gil's proposal -- impl experience his group had led them to using duration
08:29:37 [asoldano]
I'm in favor of the proposal too
08:30:36 [scribe]
dave: if we have to go back to datetime, we have to mandate utc (or some specific timezone)
08:30:49 [Bob]
ack ram
08:31:09 [scribe]
ram: should require the use of duration
08:31:21 [Yves]
non tz-qualified time are indeed a huge source of interop issue
08:31:55 [scribe]
ram: datetime useful when the devices one is talking to know what they are doing, so leave it as optional
08:32:00 [gpilz]
08:32:09 [scribe]
ram: use policy to indicate datetime support
08:32:36 [Bob]
ack dug
08:32:51 [scribe]
dug: if we keep dt, need to have to use tz
08:33:23 [scribe]
dug: torn on the topic - use case - i want a subscription until midnite tomorrow
08:33:48 [scribe]
dug: time on the source
08:34:34 [scribe]
dug: 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
08:34:53 [scribe]
bob: who specifies the tz- the client or server
08:35:21 [scribe]
dug: always use the source's tz
08:35:54 [MartinC]
08:36:02 [MartinC]
08:36:13 [Bob]
ack martin
08:37:18 [scribe]
martin: in business env dt tends to be used more than duration - e.g. some "business event" finished by 11 pm
08:37:44 [scribe]
martin: regardless there are clock synch issues - no way to know how long msg delivery takes
08:38:47 [scribe]
gil: if u specifiy a duration of 1 hour, and 2 hours u get a response back, u know things are screwed up
08:38:50 [Katy]
08:39:05 [scribe]
martin: no reason to exclude dt
08:39:31 [scribe]
no objection that duration should be required
08:39:51 [scribe]
gil objects to support of dt, even as optional
08:41:56 [scribe]
jeff: suggests that if dt is supported then it must be unambiguously specified
08:42:03 [DaveS]
08:42:19 [Bob]
ack gpi
08:42:28 [asir]
08:43:00 [Bob]
ack kat
08:43:17 [scribe]
katy: you might be in a closed system where u "know"
08:45:39 [scribe]
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
08:48:43 [scribe]
discussion on various ways to make the dt unambig - will be hashed out as part of the proposal
08:48:59 [scribe]
consensus is we don't want to get into clock synchronization issues
08:50:07 [Ram]
08:50:25 [asir]
08:51:02 [scribe]
ram: why do we need to resolve the ambiguity, given that this is optional
08:51:15 [MartinC]
08:51:21 [Bob]
ack dave
08:51:24 [Bob]
ack ram
08:51:25 [scribe]
gil: get interop problem if u don't make it unambig
08:51:28 [Bob]
ack mart
08:51:29 [dug]
08:52:32 [dug]
08:52:39 [scribe]
bob: it is up to the source (the source
08:52:54 [Ram]
08:52:54 [scribe]
(the source's clock) to determine expirty
08:52:58 [scribe]
08:55:07 [Zakim]
- +1.646.361.aadd
08:55:23 [DaveS]
08:55:30 [Zakim]
+ +1.646.361.aaee
08:57:15 [scribe]
bob: an unambig dt must include the date, time AND tz
08:57:22 [Bob]
ack ram
08:57:38 [Bob]
ack dave
08:58:07 [scribe]
dave: discussion makes my case for why we shouldn't do dt -- been down this rathole
08:59:10 [asir]
08:59:57 [Bob]
ack asir
09:04:14 [Bob]
ack asir
09:05:40 [scribe]
ACTION: pilz to produce concrete proposal based on direction for issue 7588
09:05:40 [trackbot]
Created ACTION-113 - Produce concrete proposal based on direction for issue 7588 [on Gilbert Pilz - due 2009-10-08].
09:06:30 [Zakim]
- +39.331.574.aacc
09:07:06 [scribe]
TOPIC: ssue-7553 Eventing: GetStatus Fault messages
09:07:43 [Bob]
proposal at
09:08:04 [Katy]
my ip
09:08:14 [dug]
09:08:25 [Zakim]
09:08:38 [Katy]
09:09:18 [Yves]
that ip is not blacklisted on our side
09:10:15 [Zakim]
+ +
09:10:57 [Zakim]
- +1.646.361.aaee
09:11:26 [Zakim]
+ +1.646.361.aagg
09:11:48 [dug]
09:11:57 [gpilz]
09:12:39 [Bob]
ack dug
09:12:45 [Bob]
ack gp
09:13:59 [scribe]
gil: don't want to require remembering state of expired subscriptions
09:14:37 [dug]
email from katy:
09:14:49 [asir]
q+ to ask a question
09:16:38 [Bob]
ack asir
09:16:38 [Zakim]
asir, you wanted to ask a question
09:17:13 [scribe]
ram: katy's proposal is scoped to the case hwere the subscription mgr is still alive
09:17:35 [scribe]
martin: if subscription mgr is not avail, then can't tell anything :-)
09:19:30 [scribe]
ram: if the subscription has expired or been deleted, then the subscription mgr for that subscription may not be alive
09:19:46 [asir]
09:19:55 [dug]
If the subscription manager is exists but the subscription is not valid, the request MUST fail....
09:20:35 [asir]
what does it mean to say not valid
09:20:53 [asir]
suggest 'unknown'
09:21:00 [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.
09:21:12 [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.
09:21:19 [asir]
suggest replacing not valid with unknown
09:21:42 [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.
09:22:52 [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
09:26:21 [scribe]
discussion evolves into what are the states of subscription
09:27:46 [Bob]
09:27:53 [Ram]
09:27:57 [Bob]
ack asir
09:28:07 [dug]
09:28:10 [Katy]
09:28:13 [Bob]
ack ram
09:30:11 [scribe]
martin: there are really 3 states - expired, unknown, deleted (unsubscribed)
09:30:16 [Ram]
09:30:19 [Bob]
ack udg
09:30:23 [Bob]
ack dug
09:30:29 [Bob]
ack katy
09:31:50 [scribe]
more discussion about existential existence (as opposed to existetial non-existence ;-) of deleted subscriptions
09:32:05 [Bob]
ack ram
09:32:07 [scribe]
katy: need a state diagram
09:32:17 [MartinC]
09:33:05 [Wu]
09:33:12 [Bob]
ack mar
09:34:15 [scribe]
martin: if a getstatus(subscription) is done -- if you have no history, a fault is generated,
09:34:48 [scribe]
martin: if you have a history, and its been deleted, then you don't generate a fault, you return the proper status
09:35:09 [Ram]
09:35:14 [Bob]
ack wu
09:35:15 [DaveS]
Satae suggestion:
09:35:16 [DaveS]
09:35:16 [DaveS]
   - Created
09:35:16 [DaveS]
   - Renewed
09:35:16 [DaveS]
09:35:16 [DaveS]
   - Expired
09:35:18 [DaveS]
   - Cancelled or deleted
09:35:20 [DaveS]
   - Unkonwn
09:35:20 [scribe]
martin: only one fault - unknown subscription - everything else is a known state
09:36:04 [Ram]
How about we change "Valid" to "Active" and "Invalid" to "Inactive".
09:36:07 [scribe]
wu: have a generic fault with sub-fault codes that reflect the state
09:36:31 [Katy]
09:36:58 [scribe]
wu: sub-fault codes are optional
09:37:29 [DaveS]
Status with Ram's suggestion:
09:37:30 [DaveS]
09:37:30 [DaveS]
   - Created
09:37:30 [DaveS]
   - Renewed
09:37:30 [DaveS]
09:37:30 [DaveS]
   - Expired
09:37:32 [DaveS]
   - Cancelled or deleted
09:37:34 [DaveS]
   - Unknown
09:37:37 [DaveS]
GetStatus never faults.
09:38:10 [Ram]
09:39:01 [scribe]
katy: agrees with martin
09:39:10 [Bob]
ack katy
09:39:16 [DaveS]
09:39:51 [Bob]
ack ram
09:40:54 [scribe]
ram: we need to define the "structure" of the get status returns
09:41:02 [asir]
09:42:12 [scribe]
dave: need a form of status which doesn't fault
09:42:15 [scribe]
09:42:17 [scribe]
09:42:21 [scribe]
09:42:34 [scribe]
i'm not +1'ing
09:43:14 [Bob]
ack dave
09:43:18 [Bob]
ack asir
09:43:52 [scribe]
asir: expired and deleted are internal states of the event source
09:44:14 [scribe]
asir: how can this be tested?
09:44:54 [Bob]
ack scri
09:46:02 [scribe]
jeff: what we are really talking about is whether a "bad" subscription faults from get status
09:46:26 [MartinC]
09:46:41 [scribe]
jeff: or it always returns "normally", with a substatus
09:47:31 [scribe]
bob: dave's proposal is unless there is some internal disaster, get status always returns normally
09:48:18 [scribe]
bob: major status returned are "usable"/"unusable", or active/nonactive
09:49:32 [scribe]
bob: try again -- 2 major "uber status": active/unactive and then there is detail info which further elaborates
09:51:01 [asir]
09:51:04 [Katy]
09:51:12 [Bob]
ack martin
09:52:39 [dug]
09:53:05 [asir]
09:53:07 [Ram]
09:53:09 [Bob]
ack asi
09:53:22 [Bob]
ack kat
09:53:30 [scribe]
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
09:53:39 [Bob]
ack dug
09:55:04 [asir]
confused is a possible state as well :-)
09:55:48 [Katy]
09:55:51 [dug]
its a perpetual state
09:56:12 [asir]
09:57:06 [scribe]
bob: should server fault with a bad subscription? 2
09:57:27 [scribe]
bob: should server not fault , but would return as a status "unknwon subscription"
09:58:03 [scribe]
09:59:32 [dug]
10:00:56 [scribe]
10:01:11 [scribe]
confusion reigns
10:05:23 [scribe]
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?
10:07:07 [chad]
chad has joined #ws-ra
10:08:42 [Ram]
10:09:33 [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
10:11:09 [Yves]
10:13:25 [Zakim]
- +
10:22:48 [MartinC]
10:24:08 [Ram]
10:24:09 [Zakim]
10:24:09 [Bob]
thanks, Yves
10:24:23 [Katy]
10:25:25 [dug]
10:25:48 [Bob]
ack ram
10:27:02 [scribe]
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)
10:27:38 [scribe]
ram: question is what to do when the sub mgr is present
10:28:34 [scribe]
ram: a)fault b)send direct response saying deleted, expired, unknown
10:28:57 [dug]
10:29:23 [scribe]
ram: when you do a Transfer.get you don't get a fault (ignoring low level protocol faults), you get back a repsonse
10:31:10 [Bob]
ack martin
10:31:26 [scribe]
martin: conflating sub mgr and the subscription
10:31:38 [asir]
Doug => resource does not exist == subscription manager does not exist
10:32:20 [dug]
not necessarily for all impls - to some a non-existent subscription could still point to a sub mgr
10:32:45 [asir]
That is true from a subscription point of view
10:32:51 [scribe]
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)
10:33:15 [asir]
but from a endpoint point of view, resource does not exist == subscription manager does not exist
10:33:32 [scribe]
bob, dave: no you won't -- there is not necessarily a 1-1 between sub mgr and subscription
10:33:51 [dug]
10:34:00 [asir]
10:34:21 [dug]
there could be on subscription mgr for a ton of subscriptions
10:34:45 [Ram]
10:34:46 [asir]
no disagreements on that piont
10:37:31 [Zakim]
- +1.646.361.aagg
10:41:56 [Bob]
ack dug
10:44:18 [DaveS]
10:44:54 [dug]
Dug: I'd like to discuss the state tables first
10:47:19 [MartinC]
10:48:17 [scribe]
bob: martin raises the issue of the existence of the thing we are trying to query
10:50:07 [scribe]
bob: in other words what is the window of existence?
11:04:16 [MartinC]
11:28:12 [scribe]
After a long discussion, we may agree on the following:
11:28:23 [scribe]
bob: there is only one active state for a subscription
11:33:34 [scribe]
bob: Before that active state exists, the renew req, get_status req, unsubscribe req must fail and may generate the invalid subscription fault.
11:34:50 [scribe]
katy: need definition of subscription in the spec
11:37:04 [scribe]
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)
11:38:54 [scribe]
ACTION: katy to produce a redline proposal consistent with the above principles
11:38:54 [trackbot]
Created ACTION-114 - Produce a redline proposal consistent with the above principles [on Katy Warr - due 2009-10-08].
11:39:48 [Sreed]
Sreed has joined #ws-ra
11:41:06 [jeffm]
reconvene in 1 hour and 5 minutes
12:01:01 [Ashok]
Ashok has joined #ws-ra
12:03:10 [Zakim]
- +0196281aabb
12:03:11 [Zakim]
WS_WSRA(F2F)3:30AM has ended
12:03:12 [Zakim]
Attendees were +, +0196281aabb, Yves, +39.331.574.aacc, +1.646.361.aadd, +1.646.361.aaee, +, +1.646.361.aagg
12:39:02 [Ashok]
Ashok has joined #ws-ra
12:54:25 [Sreed]
Sreed has joined #ws-ra
12:58:56 [Zakim]
WS_WSRA(F2F)3:30AM has now started
12:59:02 [Zakim]
+ +0196281aaaa
13:00:09 [Bob]
we resume...
13:00:40 [Zakim]
+ +39.331.574.aabb
13:03:06 [Bob]
scribe: Katy Warr
13:03:18 [Bob]
scribenick: Katy
13:03:22 [Zakim]
13:04:13 [Bob]
Topic: Issue-7554 Eventing: Unsubscribe Fault
13:04:15 [Bob]
13:05:03 [MartinC]
13:05:34 [Bob]
ack martin
13:05:47 [li]
li has joined #ws-ra
13:06:24 [Zakim]
13:06:46 [Katy]
Katy: This may require updates based on discussions this morning
13:07:48 [Katy]
Martin: Why would this be any different from any other WSDL fault why not return SOAP receiver fault
13:07:58 [Katy]
... This is a generic fault
13:08:48 [asir]
asir has joined #ws-ra
13:09:33 [Katy]
Asir: Why would we need EventSourceUnableToProcess
13:10:01 [Wu]
Wu has joined #ws-ra
13:10:43 [Katy]
Katy: This is already in the spec but specific to Subscribe
13:12:18 [Katy]
Katy: ... it has Retryafter detail
13:12:43 [Katy]
Asir: But Soap receiver fault indicates that you can retry any time after
13:13:05 [li]
are we discussing 7554?
13:13:08 [Katy]
Martin: Should only ave faults for aspects specific to eventing
13:13:18 [Katy]
li - yes
13:14:25 [Katy]
Ram: Invalid receiver fault is when the fault is not due to the content of the message
13:14:34 [li]
13:15:04 [Bob]
ack li
13:15:15 [Katy]
DaveS: Non Soap fault would be useful for additional info too
13:15:26 [Katy]
Doug: Like REtryAfter
13:15:34 [asir]
13:15:34 [dug]
yves - I'm blocked:
13:15:59 [Katy]
Li: Can we use info set with SOAP 1.1?
13:16:19 [Katy]
Asir: Is this a more general concern regarding the use of eventing with soap 1.1?
13:16:28 [Bob]
ack asir
13:16:49 [Zakim]
- +39.331.574.aabb
13:17:05 [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).
13:17:16 [DaveS]
DaveS has joined #ws-ra
13:18:41 [dug]
13:18:54 [Katy]
The question is: Do we ned the SubCode of the EventSourceUnableToProcess
13:19:40 [dug]
I'm being blocked:
13:19:47 [Katy]
Katy: Do we need the RetryAfter?
13:19:53 [dug]
working now
13:19:57 [Katy]
Bob: I think we can use the generic fault
13:20:16 [Katy]
DaveS: Need to step through faults
13:20:29 [Yves]
this ip is not blocked
13:20:37 [dug]
just started to work
13:20:50 [Katy]
InvalidExpirationTime: Keep (don't replace with generic)
13:20:56 [dug]
who is that?
13:21:02 [Yves]
you at the office; 0
13:21:07 [Katy]
UnsupportedExpirationTime: Keep
13:21:16 [Katy]
FilteringNotSupported: Keep
13:21:20 [Yves]
so most probably a proxy
13:21:55 [dug]
no - at IBM hursley
13:22:02 [Katy]
FilteringRequestedUnavailable: Keep
13:22:16 [Katy]
SubscribeRequestInvalid: ?
13:22:35 [Katy]
Martin: What's invalid, if you can't be precise, don't keep it
13:23:07 [Katy]
... This is a candidate for removal I think
13:24:13 [Katy]
EventSourceUnableToProcess: Definitely goes - generic soap fault
13:24:27 [Katy]
UnableToRenew: ?
13:24:51 [Katy]
DaveS: I htink this is the same as EventSourceUnableToProcess so should have same action
13:25:09 [Katy]
... again question is is there genuine value in retry after?
13:25:22 [Katy]
Marting: Can put that in the generic fault
13:25:31 [Katy]
13:26:05 [Katy]
INvalidMessage: Generic SOAP fault
13:26:21 [Katy]
DeliveryFormatRequestUnavailable: Keep
13:27:16 [Katy]
Asir: InvalidMessage adds some value
13:27:44 [Katy]
Doug: This message is not referenced from the spec
13:28:10 [Katy]
... It may have been moved or be added as a generic message
13:28:14 [Sreed]
Sreed has joined #ws-ra
13:29:31 [Katy]
DaveS: InvalidMessage should go
13:29:40 [Ram]
Ram has joined #ws-ra
13:30:37 [Katy]
DeliveryFormatRequestUnavailable and EmptyFilter: Keep
13:31:19 [Katy]
Doug: UnusableEPR is is the EndTo contains something like FTP that's not supported
13:32:31 [Katy]
Ram: Should retain UnusableEPR
13:33:42 [Katy]
Doug: InvalidSubscription should probably be renamed as Unknown as part of 7554
13:34:07 [Katy]
General agreement to this.
13:34:09 [asir]
Consensus: s/InvalidSubscription/UnknownSubscription/
13:34:20 [asir]
Consensus: s/InvalidSubscription/UnknownSubscription/g
13:34:57 [asir]
13:35:13 [asir]
a) s/InvalidSubscription/UnknownSubscription/g
13:35:22 [asir]
b) s/InvalidMessage//
13:36:02 [asir]
c) s/EventSourceUnableToProcess//
13:36:15 [asir]
d) s/UnableToRenew//
13:36:22 [Katy]
RESOLUTION: Combine the above discussion with the 7553. SubscribeRequestInvalid, EventSourceUnableToProcess, UnableToRenew, InvalidMessage become genericsoap fauls
13:37:07 [Katy]
RESOLUTION: InvalidSubscription renamed as above
13:37:33 [Katy]
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
13:38:37 [Katy]
RESOLUTION: Agree above
13:39:47 [dug]
yves - I'm blocked again
13:39:55 [Katy]
TOPIC: Issue
13:40:18 [Katy]
Bob: Subject to action on Gil from earlier
13:40:29 [dug]
13:40:32 [Bob]
13:40:49 [Yves]
this one is not blocked and has never been
13:40:49 [Katy]
13:41:18 [Vikas]
Vikas has joined #ws-ra
13:41:43 [dug]
13:41:45 [Katy]
Gil: Need to define how to compute this URI if it not there
13:42:21 [Yves]
dug, this one is not blocked
13:42:26 [dug]
13:42:42 [dug]
can't get to anything
13:43:58 [Katy]
Gil: 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
13:44:34 [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.
13:45:04 [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.
13:45:16 [dug]
dunno if its caching
13:46:29 [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.
13:47:58 [Katy]
Doug: Will this apply to all bindings?
13:48:52 [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.
13:50:06 [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.
13:50:35 [Katy]
Gil: This saves changing it in both A121 and A122
13:50:59 [Katy]
Asir: Does this address your concern about bindings Doug?
13:51:05 [Katy]
Doug: Yes
13:52:07 [Katy]
RESOLUTION: Text updates as agreed above and also ensure that schema is updated with '?' appropriately
14:11:02 [dug]
14:11:25 [Katy]
TOPIC: Issue 6207
14:11:29 [Bob]
14:11:44 [Katy]
TOPIC: Issue 7207
14:12:19 [Katy]
Li: Need to maintain the semantics of push in the eventing spec
14:12:21 [Bob]
s/TOPIC: Issue 6207//
14:12:31 [Katy]
... it is a very important concept in eventing
14:12:59 [Katy]
... proposal is to add an indication of the type of delivery that is supported by the event source
14:13:19 [Bob]
proposal at
14:13:59 [MartinC]
14:14:27 [Bob]
ack martin
14:14:33 [dug]
14:14:42 [Katy]
Martin: What is the definition of push in this context?
14:15:50 [Katy]
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
14:16:11 [Katy]
Bob: Push is the default way that the spec operates using an EPR
14:16:47 [Katy]
Asir: This is not the default. The NotifyTo is not required in the spec.
14:17:09 [Wu]
14:17:12 [Bob]
ack dug
14:17:17 [Katy]
... What Li is proposing is a way to say that you require the NotifyTo
14:17:21 [MartinC]
14:18:07 [Katy]
Doug: Is this to say event source supports or client requires Push?
14:18:28 [Katy]
li: The former. B.3 is not part of this discussion.
14:18:48 [Katy]
Doug: All you are looking for is a way to say 'I support the NotifyTo'
14:18:56 [Katy]
Li: Yes
14:19:36 [Katy]
Doug: I don't think that the source can fault because it doesn't understand notifyTo
14:19:55 [Katy]
... Definition 4.1 indicates that an EventSource must support notifyTo
14:20:29 [Katy]
... So we don't need a policy to indicate this
14:20:29 [asir]
14:20:49 [Bob]
ack asir
14:21:43 [Wu]
14:21:49 [Katy]
Asir: Looking from the metadata point of view. The text says when NotifyTo is there, receiver must do this.
14:22:23 [Katy]
... As an EventSource, I need a runtime-independent way of indicating support for NotifyTo
14:23:29 [Katy]
... EventSource tells subscribers if you are talking to me then use NotifyTo
14:23:50 [Katy]
Martin: This is a flag to say only NotifyTo is supported
14:23:58 [Katy]
... is my interpretation
14:24:38 [Bob]
14:25:12 [Bob]
ack mar
14:25:46 [DaveS]
14:25:54 [Wu]
14:26:54 [dug]
14:27:15 [Katy]
Asir: We could add a sentence to explicitly state that all eventsources must support notify to
14:27:24 [Bob]
ack david
14:28:24 [Bob]
ack dave
14:29:02 [Ram]
14:29:04 [Katy]
DaveS: Text under 4.1 indicates support. I think that this issue is for the EventSource to indicate that *only* NotifyTo is supported.
14:29:43 [Katy]
Bob: Is the sentence in 4.1 clarity enough to say that NotifyTo must be supported?
14:30:05 [Katy]
... Do we need 'All EventSources must support NotifyTo'
14:30:30 [Katy]
Doug: But we'll need to do that for all optional client behaviours
14:31:30 [Katy]
Martin: The current 4.1 text is unambiguous. If client passes a notify, must send
14:31:35 [MartinC]
14:31:47 [Katy]
Wu: It does not say that it is required
14:32:18 [Katy]
Bob: The first question is: Do we make it clear enough in the spec that the event source must support notifyto?
14:32:53 [Katy]
Wu: I would like a clarifying sentence in 4.1: "EventSource must support NotifyTo"
14:33:50 [Katy]
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
14:34:21 [Katy]
Martin: RFC2119 says should be clarified for sender and receiver
14:35:54 [Katy]
DaveS: We should check each optional/musts
14:37:09 [Katy]
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
14:37:20 [Katy]
Wu: This is a good step forward
14:37:45 [Katy]
Ram: What if I really want a subscriber to send me a NotifyTo
14:38:03 [li]
14:38:39 [dug]
14:38:47 [Ram]
14:38:50 [Katy]
Doug: If in your policy you don't include any other mechanisms for notification then that indicates that only NotifyTo is supported
14:40:20 [Katy]
Ram: What is the fault if the sender does not send a notifyTo when that is required
14:41:05 [Katy]
14:41:07 [Wu]
14:41:48 [Katy]
Bob: Do we have an agreement that we will clarify the conformance section regarding optional sender aspects
14:42:20 [Katy]
Wu: Yes. This will satisfy our first concern
14:44:26 [Katy]
Martin: In response to Asir's question - we need to be clear as to what fault is returned
14:44:51 [Katy]
Bob: What other aspects need to be considered Li?
14:45:02 [Bob]
acl li
14:45:05 [Bob]
ack li
14:45:39 [Wu]
This "OPTIONAL" clarifying is needed, because it beyond the original def of "Optional" as in RFC 2119
14:47:32 [MartinC]
14:47:53 [Katy]
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?
14:49:51 [Katy]
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
14:50:29 [DaveS]
14:50:53 [Katy]
Bob: ... is that written in the spec? My belief is that the spec covers this.
14:52:45 [Katy]
... I believe the question is WHEN is the notification sent. Is this correct Li?
14:52:48 [Bob]
ack mart
14:52:48 [Katy]
Li: yes
14:53:50 [Katy]
Martin: You can't say how long it takes to reply to something.
14:53:56 [gpilz]
14:54:50 [Katy]
Gil: How about filtering or batching? This would take time
14:55:26 [Bob]
ack wu
14:55:39 [Katy]
Bob: I think that Li's issue is regarding the wording of Push
14:55:43 [MartinC]
14:55:48 [dug]
scribe: Dug
14:55:58 [dug]
Wu: missing async unsolicited
14:56:24 [gpilz]
how can in be unsolicited when you asked for it by sending a Subscribe request?
14:56:24 [dug]
Bob: async with respect to what?
14:56:45 [dug]
Wu: async with respect to the event sending behavior
14:56:49 [dug]
scribe: Katy
14:57:39 [Katy]
Bob: When we first looked at the definition of 'Push' we found it undefinable which is why there was support to remove it
14:57:58 [Ram]
14:58:45 [Bob]
ack dave
14:58:50 [Katy]
... 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
14:58:55 [Bob]
ack gpi
14:59:00 [DaveS]
14:59:14 [Bob]
ack mart
14:59:36 [Ram]
15:00:27 [Katy]
Martin: I can't see what other normative text could be added for this behaviour
15:00:47 [dug]
15:02:34 [dug]
15:03:03 [Katy]
Li: As the current spec already implies the behaviour of push, I think this works.
15:04:28 [Katy]
RESOLUTION: Add text to the conformance section to clarify optional sender behaviour means required receiver
15:04:54 [Katy]
ACTION: Doug to come up with proposal across all 4 specs and also to uppercase OPTIONAL
15:04:54 [trackbot]
Created ACTION-115 - Come up with proposal across all 4 specs and also to uppercase OPTIONAL [on Doug Davis - due 2009-10-08].
15:06:50 [Katy]
TOPIC: Issue
15:07:32 [Katy]
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.
15:08:00 [Katy]
RESOLUTION: Resolve 6402 with comment 7 and schema update
15:08:29 [jeffm]
jeffm has joined #ws-ra
15:17:32 [Katy]
TOPIC: Issue 7478
15:18:23 [Katy]
Yves, please could you unblock me? -
15:19:35 [Yves]
katy can you retry?
15:21:04 [dug]
Wu's proposal:
15:22:15 [Katy]
Yves thanks working now
15:22:37 [dug]
Gil's proposal:
15:24:20 [Katy]
Wu: Starting with proposal uses boolean attribute in section 1
15:24:30 [Katy]
... can support existing use of expires
15:24:57 [Katy]
... need to add attribute in schema in 4.1
15:25:18 [MartinC]
15:25:45 [Katy]
... called exact and this optional attribute has value of true then MUST create with the expration time or else fault
15:26:17 [Katy]
... if it has value of FALSE, then expiration time needn't be exact
15:27:48 [Bob]
ack martin
15:27:51 [Katy]
... This ensures that the eventsource must honour expiry if that's required but also gives flexibility if the exact expiry is not required
15:28:19 [Katy]
Martin: If you say exact=false, what does that mean?
15:28:41 [gpilz]
15:28:45 [dug]
15:28:45 [gpilz]
15:28:48 [Ram]
15:28:48 [dug]
15:28:50 [dug]
15:28:52 [Katy]
... I understand the true case
15:29:00 [Wu]
15:29:11 [asir]
suggest that we don't call other participant's use case silly
15:29:27 [dug]
can we call each other silly?
15:29:31 [gpilz]
it's not the use case that is silly, it's the behavior
15:29:43 [dug]
its probably tamer than what we'd like to say :-)
15:29:53 [Bob]
ack li
15:30:01 [Bob]
ack gp
15:30:50 [asir]
15:31:14 [Katy]
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
15:31:30 [Katy]
... a hint is semantically meaningless in this context
15:31:36 [asir]
I would like to ask Gil a clarification question
15:31:36 [MartinC]
15:32:06 [Katy]
... so exact=false is going back to the current behaviour where the client has no say
15:33:02 [Katy]
... A client needs to be able to set a lower limit on what it can live with if the exact=true is not specified
15:33:04 [Bob]
ack ram
15:33:35 [Katy]
Ram: The existing behaviour makes a lot of sense in devises world
15:34:33 [Katy]
... 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
15:35:05 [Katy]
... the client can choose the service that gives the best service. e.g. printer services
15:35:46 [Katy]
... I appreciate that we might need min too but we should make all the use cases work
15:36:14 [Katy]
Gil: But why would I bother to specify an expiration at all if I can just accept what is being given?
15:36:34 [Bob]
15:36:41 [Katy]
Ram: I believe that the proposal allows both behaviours
15:37:04 [DaveS]
15:37:20 [Katy]
... We think we can add sufficient words to clarify what Exact=false means
15:37:32 [Katy]
... If we do this can we make some progress on this issue?
15:37:37 [gpilz]
15:37:39 [Bob]
ack dug
15:38:01 [Katy]
Doug: In the proposal is there a way of saying 'I don't care about the expiry time'
15:38:35 [jeffm]
jeffm has joined #ws-ra
15:39:43 [Katy]
... I wonder whether we should cover all 4 cases 1) Exact time (Exact=true), 2) Indefinite time (no exact specified), 3) Hint (Exact=false) 4) I don't care
15:39:58 [Katy]
Wu: the proposal doesn't cover 4
15:40:09 [dug]
s/exact specified/no expires specified/
15:40:21 [asir]
Ram said that 4) is the same as 3)
15:41:04 [Bob]
ack wu
15:42:54 [Katy]
Wu: Typically a subscriber will ask for the maximum - which we have covered
15:43:53 [Katy]
... 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
15:45:08 [Katy]
Doug: Do we have a use case for 'don't care'?
15:45:12 [Ram]
15:45:43 [Wu]
15:46:48 [Katy]
Gil: 4- If it was so important for you that the subscription succeed that you will accept any expiration
15:47:09 [Katy]
Wu Ram DaveS Bob: Do not see a use case for 4
15:47:20 [Bob]
ack asir
15:47:31 [Bob]
ack martin
15:48:25 [Bob]
ack dave
15:48:27 [Katy]
Martin: The current spec says nothing - the source can pick any time it wants
15:49:27 [Katy]
... I don't understand the use case for a hint
15:49:35 [Bob]
ack gpi
15:49:39 [DaveS]
15:49:53 [Ram]
15:50:10 [MartinC]
15:50:34 [Katy]
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.
15:50:47 [asir]
Martin - why allowing the hint use case is harmful?
15:51:24 [Katy]
Gil's proposal
15:51:39 [Katy]
Gil: This is based on yesterday's discussions
15:51:41 [MartinC]
thr trouble with hints is anything can be given, and some may not be acceptable, so hint is a weak "don't care"
15:51:59 [asir]
k .. is that harmful?
15:52:02 [dug]
15:52:48 [Katy]
... 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 with
15:53:57 [Katy]
... This satisfies the use cases presented and client is clear what is accepable
15:55:11 [Katy]
Ram: Problem is that the event Subscriber doesn't really know what the range is
15:55:42 [Katy]
Gil: then don't constrain with the min attribute
15:55:44 [asir]
I have not heard any rationale as to why the WG should disallow the hint use case
15:56:10 [Katy]
15:56:11 [dug]
<expires> 12pm </expires> == <expires min=0>12pm</expires>
15:56:31 [dug]
old vs gil's
15:57:18 [Katy]
15:57:21 [MartinC]
personlally i think gil's has it wring way i..e 12 is min with an optional max
15:58:56 [Katy]
Doug: <expires min=0>12pm</expires> will give the hint use case in Gil's format
15:59:27 [Bob]
ack ram
15:59:34 [Bob]
ack wu
16:02:18 [Katy]
Wu: We do not think that the min/max duration is a use case because the event source will always honour the minimum duration
16:04:12 [Katy]
Gil: But without the minimum, you could just give any expiry to save resource in the service
16:04:48 [Katy]
Bob: The difference between the proposal is that proposal B places control of the minimum on the client
16:06:03 [Katy]
... If it is the behaviour that the client will alway provide the minimum, the client could specify its minimum as exact=true
16:08:25 [Bob]
16:08:28 [asir2]
asir2 has joined #ws-ra
16:10:36 [Bob]
ack dave
16:11:55 [Katy]
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)
16:12:57 [Ram]
16:13:06 [Wu]
16:13:15 [Katy]
... So Gil's proposal is more complete but Wu's proposal is closer to current behaviour
16:14:03 [Katy]
... So if I was starting from scratch I would go with Gil's proposal but it would mean more impact to current implementations
16:17:51 [Katy]
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
16:20:16 [Katy]
<Expires Exact=boolean | minimum=duration|dateTime> duration|datetime </Expires>
16:20:55 [Katy]
DaveS: How about we start with Gil's proposal but invert the behaviour?
16:22:34 [Katy]
Bob: Replace exact with minimum attribute. If min=expiry time then the exact time is required
16:23:34 [Bob]
ack martin
16:23:36 [Bob]
ack dug
16:24:56 [Katy]
Doug: If this now supports don't care we will be now be changing behaviour as missing expires behaviour will change
16:25:05 [Katy]
We: We don't care about don't care
16:25:17 [Katy]
16:29:39 [gpilz]
gpilz has left #ws-ra
16:30:04 [Katy]
ACTION: DaveS to prepare new proposal for 7478
16:30:04 [trackbot]
Sorry, couldn't find user - DaveS
16:30:20 [Katy]
ACTION: Dave to prepare new proposal for 7478
16:30:20 [trackbot]
Sorry, couldn't find user - Dave
16:30:34 [Katy]
ACTION: DavidS to prepare new proposal for 7478
16:30:34 [trackbot]
Sorry, couldn't find user - DavidS
16:31:06 [MartinC]
MartinC has left #ws-ra
16:31:09 [Katy]
ACTION: Snelling to prepare new proposal for 7478
16:31:09 [trackbot]
Created ACTION-116 - Prepare new proposal for 7478 [on David Snelling - due 2009-10-08].
16:32:04 [Zakim]
16:37:40 [Bob]
rrs, generate minutes
16:37:52 [Bob]
rrsagent, generate minutes
16:37:52 [RRSAgent]
I have made the request to generate Bob
16:38:02 [Yves]
trackbot, end telcon
16:38:02 [trackbot]
Zakim, list attendees
16:38:02 [Zakim]
As of this point the attendees have been +0196281aaaa, +39.331.574.aabb, Yves, li
16:38:03 [trackbot]
RRSAgent, please draft minutes
16:38:03 [RRSAgent]
I have made the request to generate trackbot
16:38:04 [trackbot]
RRSAgent, bye
16:38:04 [RRSAgent]
I see 7 open action items saved in :
16:38:04 [RRSAgent]
ACTION: pilz to produce concrete proposal based on direction for issue 7588 [1]
16:38:04 [RRSAgent]
recorded in
16:38:04 [RRSAgent]
ACTION: katy to produce a redline proposal consistent with the above principles [2]
16:38:04 [RRSAgent]
recorded in
16:38:04 [RRSAgent]
ACTION: Doug to come up with proposal across all 4 specs and also to uppercase OPTIONAL [3]
16:38:04 [RRSAgent]
recorded in
16:38:04 [RRSAgent]
ACTION: DaveS to prepare new proposal for 7478 [4]
16:38:04 [RRSAgent]
recorded in
16:38:04 [RRSAgent]
ACTION: Dave to prepare new proposal for 7478 [5]
16:38:04 [RRSAgent]
recorded in
16:38:04 [RRSAgent]
ACTION: DavidS to prepare new proposal for 7478 [6]
16:38:04 [RRSAgent]
recorded in
16:38:04 [RRSAgent]
ACTION: Snelling to prepare new proposal for 7478 [7]
16:38:04 [RRSAgent]
recorded in