Subject: RE: AW: [Sipping] Comments on draft-poetzl-sipping-call-completion-00.txt

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Fri, 7 Jul 2006 09:02:34 +0200

Hi Gonzallo,

"..., but you are effectively extending an event package to perform floor control (or FIFO queue management if you prefer to call it like that), and that should be discussed, because it is not the typical behavior of an event package."

The FIFO management is part of the ccbs/ccnr service logic which is not really in the scope of this I-D since IETF does not define service logic. However this service logic relies on a notification mechanism provided by SUB/NOT. As far as I can see, the event packages that have been defined up to now are each unique, and have in common to require a notification mechanism which is controlled by some logic behind that depends on the functionality of the package (e.g. presence logic, message-summary logic...). 

Regards,
sébastien 

-----Message d'origine-----
De : Gonzalo Camarillo [mailto:[email-masked]] 
Envoyé : vendredi 7 juillet 2006 08:33
À : Alexeitsev, D
Cc : Jesske, R; Poetzl,Joachim; [email-masked]
Objet : Re: AW: [Sipping] Comments on draft-poetzl-sipping-call-completion-00.txt

Hi,

> The required functionality is not to manage the access to a specific 
> resource, but to manage the processing of the notifications for change 
> in the state of a resource.

yes, event packages deal with notifications.

> In the regular case multiple subscribers to the same resource will get 
> the notification about the change of the resource state 
> simultaneously. This behaviour is required for some applications, but 
> not wanted for the ccbs/ccnr service. In order to cope with it, the 
> regular notification procedures are extended with the FIFO management 
> policy that is initiated during dialog establishment.

The FIFO management you are talking about here consist of managing the "access to a specific resource", statement that you do not agree with in the paragraph at the top of this email. You propose a FIFO queue in order to decide who gets access to the resource (i.e., being able to talk to the user).

> That is in our opinion an event package internal extension, that does 
> not required any external interfaces.

It does not require external interfaces, but you are effectively extending an event package to perform floor control (or FIFO queue management if you prefer to call it like that), and that should be discussed, because it is not the typical behavior of an event package.

My opinion is that this type of management should be outside the scope of an event package.

Cheers,

Gonzalo

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use [email-masked] for questions on current sip Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 Jul 2006 10:40:38 +0300

Hi,

this service needs to have clients introduce and remove entries on a 
FIFO queue, right? Now, what mechanism do you propose to perform those 
introductions and removals? The draft seems to propose to use the event 
package for that.

Cheers,

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Jul 2006 17:03:18 -0400

> introductions and removals? The draft seems to propose to use the event 

As I understand it, it isn't really a FIFO queue. Entries can be 
suspended, and then other entries pass them by. That isn't a queue at all.

It doesn't really change the point, except that it calls for even more 
complex state management to be tunneled via sub/not.

I am still deciding whether this rises to the level of inappropriate use 
or not.

	Paul

>> "..., but you are effectively extending an event package to perform 
>> floor control (or FIFO queue management if you prefer to call it like 
>> that), and that should be discussed, because it is not the typical 
>> behavior of an event package."
>>
>> The FIFO management is part of the ccbs/ccnr service logic which is 
>> not really in the scope of this I-D since IETF does not define service 
>> logic. However this service logic relies on a notification mechanism 
>> provided by SUB/NOT. As far as I can see, the event packages that have 
>> been defined up to now are each unique, and have in common to require 
>> a notification mechanism which is controlled by some logic behind that 
>> depends on the functionality of the package (e.g. presence logic, 
>> message-summary logic...).
>> Regards,
>> sébastien
>> De : Gonzalo Camarillo [mailto:[email-masked]] Envoyé 
>> : vendredi 7 juillet 2006 08:33
>> À : Alexeitsev, D
>> Objet : Re: AW: [Sipping] Comments on 
>> draft-poetzl-sipping-call-completion-00.txt
>>
>> Hi,
>>
>>> resource, but to manage the processing of the notifications for 
>>> change in the state of a resource.
>>
>>> In the regular case multiple subscribers to the same resource will 
>>> get the notification about the change of the resource state 
>> The FIFO management you are talking about here consist of managing the 
>> "access to a specific resource", statement that you do not agree with 
>> in the paragraph at the top of this email. You propose a FIFO queue in 
>> order to decide who gets access to the resource (i.e., being able to 
>> talk to the user).
>>
>> It does not require external interfaces, but you are effectively 
>> extending an event package to perform floor control (or FIFO queue 
>> management if you prefer to call it like that), and that should be 
>> discussed, because it is not the typical behavior of an event package.
>>
>> This list is for NEW development of the application of SIP Use 
>> [email-masked] for questions on current sip Use 
>> [email-masked] for new developments of core SIP
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 08 Jul 2006 08:40:42 +0300

Hi,

> I am still deciding whether this rises to the level of inappropriate use 

this is exactly the discussion we need to have.

Thanks,

Gonzalo