Subject: Re: [issue30] Event subscription

From: Weiming Wang <[email-masked]>
Date: Fri, 3 Jun 2005 22:35:19 +0800

Not sure if this issue can be closed by leaving it for model team to decide. Actually it does not relate to the protocol  specification very much.

Weiming
----- Original Message ----- 
From: "Avri Doria" <[email-masked]>
To: <[email-masked]>
Sent: Monday, May 23, 2005 2:29 AM
Subject: [issue30] Event subscription

New submission from Avri Doria <[email-masked]>:

6.7

   Editorial Note:  There is an argument that it is preferable to have
                    all events subscribable.

----------
category: Technical
draft: draft-ietf-forces-protocol
messages: 47
nosy: avri
priority: Must fix
status: No discussion
title: Event subscription

___________________________________________________
Forces issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/forces/issue30>
___________________________________________________

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 3 Jun 2005 14:27:05 -0400

My current inclination is that the definition of an event identifies the 
subscription point, that all events are subscribable, and that by default 
all subscriptions are off.
This creates a clean, simple, understandable, operting mode.

The assumption that lead me to this is simply that without a CE there is no 
point in a notification, and if there is a CE, he can determine what he 
wants to register for.  Any race condition is handled by the CE getting the 
information he needs about current state.

Yours,
Joel

At 10:35 AM 6/3/2005, Weiming Wang wrote:
>Not sure if this issue can be closed by leaving it for model team to 
>decide. Actually it does not relate to the protocol  specification very much.
>
>Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 6 Jun 2005 08:55:26 -0400

Hi Weiming,

On Fri, 2005-03-06 at 22:35 +0800, Weiming Wang wrote:
> Not sure if this issue can be closed by leaving it for model team to decide. 
> Actually it does not relate to the protocol  specification very much.

The protocol has to provide the semantics to allow for events.
Why do you say "it does not relate to the protocol"?

cheers,
jamal

---

From: Weiming Wang <[email-masked]>
Date: Mon, 6 Jun 2005 23:26:42 +0800

Jamal, 

Very glad to see you again :)

The original question is "if all events should be subscribable or not". By saying it does not relate to the protocol, I actually thought that the protocol only need to provide the protocol semantics for the subscription if the events are subscribable, but an event is subscribable or not still have to be defined in the model definitions for the event. In another word, the protocol specification does not care if an event is subscribabal or not. If it is not a subscribable event while it were tried to subscribe, an error will return. 

This is can also be described as "if an XML definition for an event need to have the attribute as "SUBSCRIBABLE/UNSUBSCRIBABLE" or not.

Regarding the issue itself, I personally incline to have all  events subscribable, which, as Joel pointed out, will lead to a very clear grammar, and all events should be off when system is first booted. This also means the XML definition for an event does not need to have an attribute as "SUBSCRIBABLE/UNSUBSCRIBABLE".

Cheers,
Weiming

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email-masked]>