Re: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00

>> That being said, I believe what is triggering the "academic"
>> objections is the underlying model of
>> draft-poetzl-sipping-call-completion-01: multiple subscriptions to a
>> single resource (the CCBS/CCNR queue) but a single notification to
>> the "first, non-suspended subscriber". That goes against RFC3265 (in
>> more than one ways)
> Can you clatify this statement? for me, this  is not completely clear
> why...

RFC3265 defines a model in which subscribers subscribe to a resource, and 
get notified of event changes. The way I interpret the current text in 
draft-poetzl, the resource is the queue of the target user, i.e. a single 
unique resource per callee.

If two subscribers (say A and B) subscribe to some callee's queue Q, and 
some event occurs for Q, then both should receive a NOTIFY. In RFC3265 there 
is no notion of selecting a specific subscriber from the set of all 
subscribers to receive the NOTIFY. A similar argument holds for the notion 
of "suspending" a subscription, in the RFC3265 model you are either 
subscribed to an event or not.

Of course, since RFC3265 there have been extensions that can affect this 
basic pattern. For example, when event filters (RFC4660) are being used, it 
might be that A receives a NOTIFY while B does not, due to filtering. 
However, if this is intended the draft should explicitly talk about that, 
and preferrably reuse what is already standardized, instead of defining an 
entirely different mechanism using a mix of event package parameters, new 
SIP headers, and new usages of existing SIP headers.

The current draft has two (yes, 2 in total) normative references: RFC3261 
and RFC3265. My suggestion would be to investigate whether other existing 
extensions, such as RFC4660, can be leveraged to realize this service. 
Reusing existing, standardized & accepted mechanisms would likely make the 
draft more acceptable to a wider audience

Regards,
Jeroen 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP