Subject: RE: [Sipping] Implicit subscriptions

From: Adam Roach <[email-masked]>
Date: Tue, 23 Jul 2002 14:19:54 -0500

I'd like to second Robert's response that this is a Really
Bad Idea (tm).

In addition to the extremely difficult failure cases (e.g. what
if a registrar wants to accept your registration, but objects
in some way to the subscription?), there's a whole slew of
correlation and lifetime issues. Robert and I had long
conversations about these and related issues while REFER was
going through last call, and concluded that the problems
caused by these sort of implicit subscriptions are not worth
saving the two-packet overhead.

Knowing what we know now, if we had REFER to do over again,
it would have required an explicit subscription.

I strongly advise against any new work that would encourage
implicit subscriptions. As time goes on, in fact, I am beginning
to regret that the implicit subscription text made it back into
3265 at all.

/a

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, July 23, 2002 3:41
> To: [email-masked]
> Subject: [Sipping] Implicit subscriptions
> 
> 
> Packages like Registration Info and Dialog all require 
> explicit subscriptions to get any notification of the state 
> of an earlier request being sent (REGISTER and INVITE). So, I 
> was thinking why don't we have implicit subscriptions for 
> these things.
> 
> Subscription for reginfo almost always follows a REGISTER 
> request. Subscription for dialog almost always follows an 
> INVITE request. So, why not include an implicit subscription 
> when sending the request? (This is when the subscribe and the 
> earlier request are sent from the same UAC. This does not 
> apply if the subscriber is a 3rd party).
> 
> This type of thing was first introduced in REFER using the 
> supported and require headers and I thought this can be 
> generalised for all packages that use earlier sent requests 
> as their source of notification information.
> 
> E.g. 1: If I send an INVITE and then want to trace the state 
> of that dialog, I need to send an INVITE followed by a 
> SUBSCRIBE. This idea eliminates the need to send the SUBSCRIBE.
> E.g. 2: If I send a REGISTER and then want to trace the state 
> of my registration, I need to send a REGISTER followed by a 
> SUBSCRIBE. This idea eliminates the need to send the SUBSCRIBE.
> 
> Other examples include MESSAGE and REFER.
> 
> I also suggest creating a new header for that (instead of 
> using supported and require): "subscribe-event" in the 
> request. The response can simply contain the "event" header.  
> 
> If the UAS does not return the event header in the response, 
> it means that it did not understand the implicit subscription 
> and an explicit one needs to be sent (a SUBSCRIBE).
> 
> This could also be added as an extension to the 
> event-notification RFC3265. New packages are required to add 
> a section describing implicit subscriptions, if applicable 
> (not applicable for packages like presence). Or even SIP 
> extension for new methods can describe which packages 
> implicit subscriptions are possible with it.
> 
> If this idea is acceptable, I can write a short I-D describing it.
> 
> Comments?
> 
> Regards,
> Hisham
> 
> _______________________________________________
> 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