RE: [Sip] FW: New Draft - Suppression of Refer Implicit Subscription

["Sriram Parameswar" <sriramkp@attbi.com>]

Rohan,

Thank you for your comments. Its not only a question of trading pair of
messages for an option-tag. Implicit subscriptions themselves are
problematic, as has been discussed on this list several times - the memo
provides for a method to suppress them, while being backwardly compatible.
If the UA receiving the REFER does not have to create the state information
for the subscription - then I see that as a distinct advantage

As for content push, there is no guarantee that the fetch happens
instantaneously - there could be the need for human interaction before that
happens. As for the attended transfer case, admittedly its a weaker example,
but in an enterprise setting - say between an employee, boss and secretary -
I see no need for the creation of additional messaging.

HTH,

Sriram

-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Monday, October 28, 2002 11:21 PM
To: Sriram Parameswar
Cc: sip@ietf.org
Subject: Re: [Sip] FW: New Draft - Suppression of Refer Implicit
Subscription


Hi,

So you are just trading a pair of messages (NOTIFY/481) for an option
tag in the REFER?  It doesn't seem that compelling to me personally.
It certainly doesn't follow the generality over efficiency argument.
Can you elaborate a bit more on your motivations?  The transfer draft
recommends waiting for NOTIFY for attended transfer for robustness, so
I'm not convinced there.  As for the "push content" model, I envisioned
an immediate fetch, with a NOTIFY to deliver the status of that fetch.

thanks,
-rohan


On Monday, October 28, 2002, at 01:00 AM, Sriram Parameswar wrote:

> Hi All,
>
> I have submitted a draft (to SIPPING) that examines the requirements
> and one
> _potential_ mechanism to suppress the implicit subscription created by
> the
> REFER method.
>
> Till it appears in the IETF site - please pick up a copy at the site
> below:
>
> http://home.attbi.com/~sriramkp/draft-parameswar-sipping-norefersub-
> 00.txt
>
> <abstract>
>    The recipient of the REFER method [1] creates an implicit
>    subscription to the 'refer' event. This subscription causes the
> REFER
>    recipient to send NOTIFY messages to the sender informing him of the
>    progress of the REFER. This memo provides for the requirements and
>    one potential mechanism to suppress the creation of this implicit
>    subscription, via an option tag - 'norefersub'. This gives the agent
>    sending the REFER control over the creation of the subscription,
>    while being backwards compatible with [1].
> </abstract>
>
> Your comments are highly appreciated.
>
> Regards,
>
> Sriram Parameswar
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

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