07:54:20 RRSAgent has joined #ws-ra 07:54:20 logging to http://www.w3.org/2009/10/01-ws-ra-irc 07:54:22 RRSAgent, make logs public 07:54:22 Zakim has joined #ws-ra 07:54:24 Zakim, this will be WSRA 07:54:24 ok, trackbot; I see WS_WSRA(F2F)3:30AM scheduled to start 24 minutes ago 07:54:25 Meeting: Web Services Resource Access Working Group Teleconference 07:54:25 Date: 01 October 2009 07:58:28 WS_WSRA(F2F)3:30AM has now started 07:58:35 + +39.331.574.aaaa 07:59:03 + +91.40.66.29.aabb 08:01:48 still waiting for folks to show up in Hursley... 08:04:19 - +91.40.66.29.aabb 08:04:25 Bob, ok, I hang up, re-dialing once you're ready in Hursley 08:04:30 - +39.331.574.aaaa 08:04:31 WS_WSRA(F2F)3:30AM has ended 08:04:32 we are dialing 08:04:32 Attendees were +39.331.574.aaaa, +91.40.66.29.aabb 08:04:38 WS_WSRA(F2F)3:30AM has now started 08:04:46 + +91.98.49.99.aaaa 08:04:50 - +91.98.49.99.aaaa 08:04:51 + +0196281aabb 08:06:15 waiting for the scribe... 08:06:32 Sreed has joined #ws-ra 08:06:35 +??P0 08:06:44 +Yves 08:07:04 Katy has joined #ws-ra 08:07:57 + +39.331.574.aacc 08:08:49 gpilz has joined #ws-ra 08:09:21 dug has joined #ws-ra 08:10:25 Wu has joined #ws-ra 08:11:54 folks are struggling with internet issues here 08:11:58 agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Oct/ 08:14:05 jeffm has joined #ws-ra 08:14:12 DaveS has joined #ws-ra 08:14:13 scribe: Jeff Mischkinsky 08:14:31 scribenick: Jeffm 08:14:47 paul has joined #ws-ra 08:15:08 agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Oct/0000.html 08:16:09 http://www.w3.org/Bugs/Public/show_bug.cgi?id=7770 08:16:30 TOPIC: new issue 7770 08:17:35 new issue accepted 08:19:06 RESOLUTION: resolved as proposed 08:19:16 TOPIC: new issue 7774 08:19:19 http://www.w3.org/Bugs/Public/show_bug.cgi?id=7774 08:20:26 new issue accepted 08:20:29 asir has joined #ws-ra 08:20:45 doug: wants a more complete proposal 08:21:00 needs more discussion 08:21:18 and more extensive proposal 08:21:36 MartinC has joined #ws-ra 08:22:37 TOPIC: Issue-7426 IRI or URI http://www.w3.org/Bugs/Public/show_bug.cgi?id=7426 08:23:11 proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0103.html 08:23:12 http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/att-0103/uri-to-iri.txt 08:23:26 proposal at 08:23:26 http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0103.html 08:23:58 bob asks if any objection to accepting the proposal in 103 08:24:19 RESOLUTION: resolved 7426 by adopting proposal 08:24:48 in msg 2009Sep/0103.html 08:25:18 Issue-7588 Enumeration: Expires multiple data types creates interop 08:25:18 TOPIC: issue http://www.w3.org/Bugs/Public/show_bug.cgi?id=7588 -Pilz 08:25:45 q+ 08:25:48 problem is same for eventing and enumeration 08:25:48 Vikas has joined #ws-ra 08:25:52 q- 08:26:11 q+ 08:26:12 Ram has joined #ws-ra 08:26:19 q+ 08:26:21 q+ 08:26:32 + +1.646.361.aadd 08:26:48 gil proposes using duration across the board 08:26:59 gil: makes things simpler 08:27:03 q- 08:27:57 q+ 08:28:06 gil: can be confusion as to what time it is on various systems when using datetime 08:28:58 ack dave 08:29:17 q+ 08:29:22 dave: supports gil's proposal -- impl experience his group had led them to using duration 08:29:37 I'm in favor of the proposal too 08:30:36 dave: if we have to go back to datetime, we have to mandate utc (or some specific timezone) 08:30:49 ack ram 08:31:09 ram: should require the use of duration 08:31:21 non tz-qualified time are indeed a huge source of interop issue 08:31:55 ram: datetime useful when the devices one is talking to know what they are doing, so leave it as optional 08:32:00 q+ 08:32:09 ram: use policy to indicate datetime support 08:32:36 ack dug 08:32:51 dug: if we keep dt, need to have to use tz 08:33:23 dug: torn on the topic - use case - i want a subscription until midnite tomorrow 08:33:48 dug: time on the source 08:34:34 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 bob: who specifies the tz- the client or server 08:35:21 dug: always use the source's tz 08:35:54 q 08:36:02 q? 08:36:13 ack martin 08:37:18 martin: in business env dt tends to be used more than duration - e.g. some "business event" finished by 11 pm 08:37:44 martin: regardless there are clock synch issues - no way to know how long msg delivery takes 08:38:47 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 q+ 08:39:05 martin: no reason to exclude dt 08:39:31 no objection that duration should be required 08:39:51 gil objects to support of dt, even as optional 08:41:56 jeff: suggests that if dt is supported then it must be unambiguously specified 08:42:03 q+ 08:42:19 ack gpi 08:42:28 q+ 08:43:00 ack kat 08:43:17 katy: you might be in a closed system where u "know" 08:45:39 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 discussion on various ways to make the dt unambig - will be hashed out as part of the proposal 08:48:59 consensus is we don't want to get into clock synchronization issues 08:50:07 q+ 08:50:25 q- 08:51:02 ram: why do we need to resolve the ambiguity, given that this is optional 08:51:15 q+ 08:51:21 ack dave 08:51:24 ack ram 08:51:25 gil: get interop problem if u don't make it unambig 08:51:28 ack mart 08:51:29 q+ 08:52:32 q- 08:52:39 bob: it is up to the source (the source 08:52:54 q+ 08:52:54 (the source's clock) to determine expirty 08:52:58 expirey 08:55:07 - +1.646.361.aadd 08:55:23 q+ 08:55:30 + +1.646.361.aaee 08:57:15 bob: an unambig dt must include the date, time AND tz 08:57:22 ack ram 08:57:38 ack dave 08:58:07 dave: discussion makes my case for why we shouldn't do dt -- been down this rathole 08:59:10 q+ 08:59:57 ack asir 09:04:14 ack asir 09:05:40 ACTION: pilz to produce concrete proposal based on direction for issue 7588 09:05:40 Created ACTION-113 - Produce concrete proposal based on direction for issue 7588 [on Gilbert Pilz - due 2009-10-08]. 09:06:30 - +39.331.574.aacc 09:07:06 TOPIC: ssue-7553 Eventing: GetStatus Fault messages http://www.w3.org/Bugs/Public/show_bug.cgi?id=7553 09:07:43 proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0103.html 09:08:04 my ip 09:08:14 test 09:08:25 -??P0 09:08:38 195.212.29.83 09:09:18 that ip is not blacklisted on our side 09:10:15 + +91.40.66.29.aaff 09:10:57 - +1.646.361.aaee 09:11:26 + +1.646.361.aagg 09:11:48 q+ 09:11:57 q+ 09:12:39 ack dug 09:12:45 ack gp 09:13:59 gil: don't want to require remembering state of expired subscriptions 09:14:37 email from katy: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0066.html 09:14:49 q+ to ask a question 09:16:38 ack asir 09:16:38 asir, you wanted to ask a question 09:17:13 ram: katy's proposal is scoped to the case hwere the subscription mgr is still alive 09:17:35 martin: if subscription mgr is not avail, then can't tell anything :-) 09:19:30 ram: if the subscription has expired or been deleted, then the subscription mgr for that subscription may not be alive 09:19:46 q+ 09:19:55 If the subscription manager is exists but the subscription is not valid, the request MUST fail.... 09:20:35 what does it mean to say not valid 09:20:53 suggest 'unknown' 09:21:00 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 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 suggest replacing not valid with unknown 09:21:42 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 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 discussion evolves into what are the states of subscription 09:27:46 q? 09:27:53 q+ 09:27:57 ack asir 09:28:07 q+ 09:28:10 q+ 09:28:13 ack ram 09:30:11 martin: there are really 3 states - expired, unknown, deleted (unsubscribed) 09:30:16 q+ 09:30:19 ack udg 09:30:23 ack dug 09:30:29 ack katy 09:31:50 more discussion about existential existence (as opposed to existetial non-existence ;-) of deleted subscriptions 09:32:05 ack ram 09:32:07 katy: need a state diagram 09:32:17 q+ 09:33:05 q+ 09:33:12 ack mar 09:34:15 martin: if a getstatus(subscription) is done -- if you have no history, a fault is generated, 09:34:48 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 q+ 09:35:14 ack wu 09:35:15 Satae suggestion: 09:35:16 Valid: 09:35:16 - Created 09:35:16 - Renewed 09:35:16 Notvalid 09:35:16 - Expired 09:35:18 - Cancelled or deleted 09:35:20 - Unkonwn 09:35:20 martin: only one fault - unknown subscription - everything else is a known state 09:36:04 How about we change "Valid" to "Active" and "Invalid" to "Inactive". 09:36:07 wu: have a generic fault with sub-fault codes that reflect the state 09:36:31 q+ 09:36:58 wu: sub-fault codes are optional 09:37:29 Status with Ram's suggestion: 09:37:30 Active: 09:37:30 - Created 09:37:30 - Renewed 09:37:30 Inactive: 09:37:30 - Expired 09:37:32 - Cancelled or deleted 09:37:34 - Unknown 09:37:37 GetStatus never faults. 09:38:10 q+ 09:39:01 katy: agrees with martin 09:39:10 ack katy 09:39:16 q+ 09:39:51 ack ram 09:40:54 ram: we need to define the "structure" of the get status returns 09:41:02 q+ 09:42:12 dave: need a form of status which doesn't fault 09:42:15 +1 09:42:17 +1 09:42:21 +q 09:42:34 i'm not +1'ing 09:43:14 ack dave 09:43:18 ack asir 09:43:52 asir: expired and deleted are internal states of the event source 09:44:14 asir: how can this be tested? 09:44:54 ack scri 09:46:02 jeff: what we are really talking about is whether a "bad" subscription faults from get status 09:46:26 q+ 09:46:41 jeff: or it always returns "normally", with a substatus 09:47:31 bob: dave's proposal is unless there is some internal disaster, get status always returns normally 09:48:18 bob: major status returned are "usable"/"unusable", or active/nonactive 09:49:32 bob: try again -- 2 major "uber status": active/unactive and then there is detail info which further elaborates 09:51:01 q+ 09:51:04 q+ 09:51:12 ack martin 09:52:39 q+ 09:53:05 q- 09:53:07 q+ 09:53:09 ack asi 09:53:22 ack kat 09:53:30 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 ack dug 09:55:04 confused is a possible state as well :-) 09:55:48 q+ 09:55:51 its a perpetual state 09:56:12 :-) 09:57:06 bob: should server fault with a bad subscription? 2 09:57:27 bob: should server not fault , but would return as a status "unknwon subscription" 09:58:03 5 09:59:32 q+ 10:00:56 redo 10:01:11 confusion reigns 10:05:23 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 has joined #ws-ra 10:08:42 q+ 10:09:33 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 chad? 10:13:25 - +91.40.66.29.aaff 10:22:48 q+ 10:24:08 q+ 10:24:09 -Yves 10:24:09 thanks, Yves 10:24:23 q- 10:25:25 q- 10:25:48 ack ram 10:27:02 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 ram: question is what to do when the sub mgr is present 10:28:34 ram: a)fault b)send direct response saying deleted, expired, unknown 10:28:57 q+ 10:29:23 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 ack martin 10:31:26 martin: conflating sub mgr and the subscription 10:31:38 Doug => resource does not exist == subscription manager does not exist 10:32:20 not necessarily for all impls - to some a non-existent subscription could still point to a sub mgr 10:32:45 That is true from a subscription point of view 10:32:51 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 but from a endpoint point of view, resource does not exist == subscription manager does not exist 10:33:32 bob, dave: no you won't -- there is not necessarily a 1-1 between sub mgr and subscription 10:33:51 nope 10:34:00 why? 10:34:21 there could be on subscription mgr for a ton of subscriptions 10:34:45 q+ 10:34:46 no disagreements on that piont 10:37:31 - +1.646.361.aagg 10:41:56 ack dug 10:44:18 q+ 10:44:54 Dug: I'd like to discuss the state tables first 10:47:19 q+ 10:48:17 bob: martin raises the issue of the existence of the thing we are trying to query 10:50:07 bob: in other words what is the window of existence? 11:04:16 q- 11:28:12 After a long discussion, we may agree on the following: 11:28:23 bob: there is only one active state for a subscription 11:33:34 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 katy: need definition of subscription in the spec 11:37:04 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 ACTION: katy to produce a redline proposal consistent with the above principles 11:38:54 Created ACTION-114 - Produce a redline proposal consistent with the above principles [on Katy Warr - due 2009-10-08]. 11:39:48 Sreed has joined #ws-ra 11:41:06 reconvene in 1 hour and 5 minutes 12:01:01 Ashok has joined #ws-ra 12:03:10 - +0196281aabb 12:03:11 WS_WSRA(F2F)3:30AM has ended 12:03:12 Attendees were +91.98.49.99.aaaa, +0196281aabb, Yves, +39.331.574.aacc, +1.646.361.aadd, +1.646.361.aaee, +91.40.66.29.aaff, +1.646.361.aagg 12:39:02 Ashok has joined #ws-ra 12:54:25 Sreed has joined #ws-ra 12:58:56 WS_WSRA(F2F)3:30AM has now started 12:59:02 + +0196281aaaa 13:00:09 we resume... 13:00:40 + +39.331.574.aabb 13:03:06 scribe: Katy Warr 13:03:18 scribenick: Katy 13:03:22 +Yves 13:04:13 Topic: Issue-7554 Eventing: Unsubscribe Fault http://www.w3.org/Bugs/Public/show_bug.cgi?id=7554 13:04:15 - 13:05:03 q+ 13:05:34 ack martin 13:05:47

li has joined #ws-ra 13:06:24 +li 13:06:46 Katy: This may require updates based on discussions this morning 13:07:48 Martin: Why would this be any different from any other WSDL fault why not return SOAP receiver fault 13:07:58 ... This is a generic fault 13:08:48 asir has joined #ws-ra 13:09:33 Asir: Why would we need EventSourceUnableToProcess 13:10:01 Wu has joined #ws-ra 13:10:43 Katy: This is already in the spec but specific to Subscribe 13:12:18 Katy: ... it has Retryafter detail 13:12:43 Asir: But Soap receiver fault indicates that you can retry any time after 13:13:05

are we discussing 7554? 13:13:08 Martin: Should only ave faults for aspects specific to eventing 13:13:18 li - yes 13:14:25 Ram: Invalid receiver fault is when the fault is not due to the content of the message 13:14:34

q+ 13:15:04 ack li 13:15:15 DaveS: Non Soap fault would be useful for additional info too 13:15:26 Doug: Like REtryAfter 13:15:34 q+ 13:15:34 yves - I'm blocked: 195.212.29.75 13:15:59 Li: Can we use info set with SOAP 1.1? 13:16:19 Asir: Is this a more general concern regarding the use of eventing with soap 1.1? 13:16:28 ack asir 13:16:49 - +39.331.574.aabb 13:17:05 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 has joined #ws-ra 13:18:41 yves?? 13:18:54 The question is: Do we ned the SubCode of the EventSourceUnableToProcess 13:19:40 I'm being blocked: 195.212.29.75 13:19:47 Katy: Do we need the RetryAfter? 13:19:53 working now 13:19:57 Bob: I think we can use the generic fault 13:20:16 DaveS: Need to step through faults 13:20:29 this ip is not blocked 13:20:37 just started to work 13:20:50 InvalidExpirationTime: Keep (don't replace with generic) 13:20:56 who is that? 13:21:02 you at the office; 0 13:21:07 UnsupportedExpirationTime: Keep 13:21:16 FilteringNotSupported: Keep 13:21:20 so most probably a proxy 13:21:55 no - at IBM hursley 13:22:02 FilteringRequestedUnavailable: Keep 13:22:16 SubscribeRequestInvalid: ? 13:22:35 Martin: What's invalid, if you can't be precise, don't keep it 13:23:07 ... This is a candidate for removal I think 13:24:13 EventSourceUnableToProcess: Definitely goes - generic soap fault 13:24:27 UnableToRenew: ? 13:24:51 DaveS: I htink this is the same as EventSourceUnableToProcess so should have same action 13:25:09 ... again question is is there genuine value in retry after? 13:25:22 Marting: Can put that in the generic fault 13:25:31 s/Marting/Martin 13:26:05 INvalidMessage: Generic SOAP fault 13:26:21 DeliveryFormatRequestUnavailable: Keep 13:27:16 Asir: InvalidMessage adds some value 13:27:44 Doug: This message is not referenced from the spec 13:28:10 ... It may have been moved or be added as a generic message 13:28:14 Sreed has joined #ws-ra 13:29:31 DaveS: InvalidMessage should go 13:29:40 Ram has joined #ws-ra 13:30:37 DeliveryFormatRequestUnavailable and EmptyFilter: Keep 13:31:19 Doug: UnusableEPR is is the EndTo contains something like FTP that's not supported 13:32:31 Ram: Should retain UnusableEPR 13:33:42 Doug: InvalidSubscription should probably be renamed as Unknown as part of 7554 13:34:07 General agreement to this. 13:34:09 Consensus: s/InvalidSubscription/UnknownSubscription/ 13:34:20 Consensus: s/InvalidSubscription/UnknownSubscription/g 13:34:57 Summary: 13:35:13 a) s/InvalidSubscription/UnknownSubscription/g 13:35:22 b) s/InvalidMessage// 13:36:02 c) s/EventSourceUnableToProcess// 13:36:15 d) s/UnableToRenew// 13:36:22 RESOLUTION: Combine the above discussion with the 7553. SubscribeRequestInvalid, EventSourceUnableToProcess, UnableToRenew, InvalidMessage become genericsoap fauls 13:37:07 RESOLUTION: InvalidSubscription renamed as above 13:37:33 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 RESOLUTION: Agree above 13:39:47 yves - I'm blocked again 13:39:55 TOPIC: Issue http://www.w3.org/Bugs/Public/show_bug.cgi?id=7586 13:40:18 Bob: Subject to action on Gil from earlier 13:40:29 192.212.29.75 13:40:32 topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7589 13:40:49 this one is not blocked and has never been 13:40:49 TOPIC: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7589 13:41:18 Vikas has joined #ws-ra 13:41:43 195.212.29.83 13:41:45 Gil: Need to define how to compute this URI if it not there 13:42:21 dug, this one is not blocked 13:42:26 sigh 13:42:42 can't get to anything 13:43:58 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 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 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

q+ 14:38:39 q- 14:38:47 q- 14:38:50 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 Ram: What is the fault if the sender does not send a notifyTo when that is required 14:41:05 s/Ram/Asir 14:41:07 q+ 14:41:48 Bob: Do we have an agreement that we will clarify the conformance section regarding optional sender aspects 14:42:20 Wu: Yes. This will satisfy our first concern 14:44:26 Martin: In response to Asir's question - we need to be clear as to what fault is returned 14:44:51 Bob: What other aspects need to be considered Li? 14:45:02 acl li 14:45:05 ack li 14:45:39 This "OPTIONAL" clarifying is needed, because it beyond the original def of "Optional" as in RFC 2119 14:47:32 q+ 14:47:53 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 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 q+ 14:50:53 Bob: ... is that written in the spec? My belief is that the spec covers this. 14:52:45 ... I believe the question is WHEN is the notification sent. Is this correct Li? 14:52:48 ack mart 14:52:48 Li: yes 14:53:50 Martin: You can't say how long it takes to reply to something. 14:53:56 q+ 14:54:50 Gil: How about filtering or batching? This would take time 14:55:26 ack wu 14:55:39 Bob: I think that Li's issue is regarding the wording of Push 14:55:43 q+ 14:55:48 scribe: Dug 14:55:58 Wu: missing async unsolicited 14:56:24 how can in be unsolicited when you asked for it by sending a Subscribe request? 14:56:24 Bob: async with respect to what? 14:56:45 Wu: async with respect to the event sending behavior 14:56:49 scribe: Katy 14:57:39 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 q+ 14:58:45 ack dave 14:58:50 ... 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 ack gpi 14:59:00 q- 14:59:14 ack mart 14:59:36 q- 15:00:27 Martin: I can't see what other normative text could be added for this behaviour 15:00:47 q+ 15:02:34 q- 15:03:03 Li: As the current spec already implies the behaviour of push, I think this works. 15:04:28 RESOLUTION: Add text to the conformance section to clarify optional sender behaviour means required receiver 15:04:54 ACTION: Doug to come up with proposal across all 4 specs and also to uppercase OPTIONAL 15:04:54 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 TOPIC: Issue http://www.w3.org/Bugs/Public/show_bug.cgi?id=6402 15:07:32 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 RESOLUTION: Resolve 6402 with comment 7 and schema update 15:08:29 jeffm has joined #ws-ra 15:17:32 TOPIC: Issue 7478 15:18:23 Yves, please could you unblock me? - 195.212.29.92 15:19:35 katy can you retry? 15:21:04 Wu's proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Oct/att-0001/7478-7587_proposal_v2.doc 15:22:15 Yves thanks working now 15:22:37 Gil's proposal: http://www.w3.org/Bugs/Public/attachment.cgi?id=760 15:24:20 Wu: Starting with proposal uses boolean attribute in section 1 15:24:30 ... can support existing use of expires 15:24:57 ... need to add attribute in schema in 4.1 15:25:18 q+ 15:25:45 ... called exact and this optional attribute has value of true then MUST create with the expration time or else fault 15:26:17 ... if it has value of FALSE, then expiration time needn't be exact 15:27:48 ack martin 15:27:51 ... 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 Martin: If you say exact=false, what does that mean? 15:28:41 q= 15:28:45 q+ 15:28:45 q+ 15:28:48 q+ 15:28:48 q- 15:28:50 q+ 15:28:52 ... I understand the true case 15:29:00 q+ 15:29:11 suggest that we don't call other participant's use case silly 15:29:27 can we call each other silly? 15:29:31