Rate is expected to be long, usually around 5 minutes, so no undue burden on the network.

19:50:45 [gpilz]

q+

19:50:52 [gpilz]

q-

19:51:56 [w3c1]

w3c1 has joined #ws-ra

19:55:41 [wuchou]

q+

19:55:42 [DaveS]

Question: Is the current mechanism only one way, or is the subscriber also tested for being allive by the event deliverer?

19:55:45 [W3C]

ack dave

19:56:58 [MartinC]

where are my skis

19:57:19 [DaveS]

q+

19:57:22 [W3C]

ack dug

20:00:47 [MartinC]

zakim, unmute MartinC

20:00:47 [Zakim]

MartinC should no longer be muted

20:01:01 [W3C]

ack martin

20:01:28 [W3C]

http 1.1 specifies "persistent" connections

20:01:52 [W3C]

http 1.0 had a keep alive mechanism, but it got useless in http 1.1

20:02:14 [W3C]

tcp keep alive is a 60 byte request

20:02:32 [W3C]

but it is widely ignored

20:03:05 [dug]

I would prefer a KeepAlive notification and just make sure your filter includes it

20:03:10 [dug]

zamik, mute Martin

20:03:15 [dug]

zamik, mute MartinC

20:03:25 [dug]

zakim, mute Martin

20:03:25 [Zakim]

MartinC should now be muted

20:03:36 [W3C]

zamik, nobits zaraih!

20:03:47 [dug]

can't type today

20:04:52 [W3C]

tradeoff on persistent connections is the thread needed for each one

20:05:06 [dug]

I can't help but wonder why we're so concerned about a Sub vanishing but not a Transfer resource?

20:05:24 [MartinC]

but this is a fault tolerance issue

20:05:31 [W3C]

ack wu

20:05:59 [dug]

q+

20:06:16 [MartinC]

q+

20:07:10 [W3C]

ack dave

20:09:17 [dug]

me too :-)

20:10:01 [dug]

well, w/o RM the heartbeat could be lost

20:11:23 [MartinC]

this seems to be about connection availability not about server/subscription. we dont explictly tie a subscription to a single connection

20:14:08 [DaveS]

q+

20:14:09 [W3C]

ack dug

20:16:21 [wuchou]

q+

20:20:24 [gpilz]

If the event source terminates a subscription unexpectedly, and it supports the use of the EndTo EPR, and the EndTo EPR was present in the Subscribe message for that subscription (see 4.1 Subscribe), the SubscriptionEnd message MUST be sent to the endpoint reference indicated by that EPR, if possible.

20:22:56 [MartinC]

zakim, unmute MartinC

20:22:56 [Zakim]

MartinC should no longer be muted

20:24:00 [W3C]

ack martin

20:24:22 [asoldano]

is the status of the communication link really a concern of ws-ra?

20:24:39 [dug]

I didn't think so

20:24:59 [dug]

zakim, mute MartinC

20:24:59 [Zakim]

MartinC should now be muted

20:25:23 [MartinC]

stop muting me;)

20:25:25 [dug]

SubEnd will tell you that

20:25:27 [W3C]

ack dave

20:25:31 [dug]

LOL sorry but the echo is bad

20:26:30 [MartinC]

of course the alive is only sent if the subscription is active, but it only tests the connection

20:26:57 [MartinC]

no alive will be sent if a subscription has expired

20:27:34 [asoldano]

lol

20:27:57 [W3C]

q+

20:28:19 [W3C]

+1 dave

20:28:36 [MartinC]

+1

20:28:51 [W3C]

ack wu

20:30:35 [W3C]

ack w3

20:32:44 [Tom_Rutt]

q+

20:32:54 [MartinC]

go idea bob

20:33:01 [MartinC]

s/go/good/

20:33:57 [Fred_Maciel]

Summary: there are different kinds of deployment scenarios that will need different kinds of periodic messages. Might need to be a special message type dependent on the domain of implementation.

20:36:13 [dug]

only issue with a heartbeat event is that you have no control over the timing of it

20:36:42 [dug]

s/event/event sent due to a filter/

20:40:28 [DaveS]

q+

20:40:49 [W3C]

ack tom

20:40:50 [dug]

bob - didn't you mean all of this under one subscription?

20:41:07 [DaveS]

I did.

20:44:36 [W3C]

ack dave

20:44:56 [wuchou]

q+

20:45:30 [dug]

we'd need to modify the Filter stuff to have more than one filter (and make them an OR), no?

20:47:07 [dug]

we could define some AND and OR filters, then people could mix-n-match to get the exact events they want