Subject: Re: [SIP] Informing UA after network initiated deregistration?

From: "Bob Penfield" <[email-masked]>
Date: Fri, 30 Mar 2001 08:48:47 -0500

----- Original Message -----
From: "Romeo Zwart" <[email-masked]>
To: "Sriram Parameswar" <[email-masked]>; "'Romeo Zwart'"
<[email-masked]>; "Bob Penfield" <[email-masked]>; "Baniel
Uri-CUB001" <[email-masked]>; "'Stephen Terrill'"
<[email-masked]>; "'Dean Willis'" <[email-masked]>;
"'Igor Slepchin'" <[email-masked]>; "'William Marshall'"
<[email-masked]>
Cc: "Chen Bonnie-BCHEN1" <[email-masked]>; "Xu Lang-LXU1"
<[email-masked]>; "sip" <[email-masked]>
Sent: Friday, March 30, 2001 4:06 AM
Subject: RE: [SIP] Informing UA after network initiated deregistration?

> At 01:51 AM 3/30/2001, Sriram Parameswar wrote:
>
> >OK - I'll bite.
>
> Great, thanks for the input.
>
> >I totally agree with you that implicit subscription is not supported in
> >the presence specifications.
>
> What was not clear to me is whether it's not supported for good, but
> non-articulated, reasons or just because no one has (yet) considered it
useful.
>
> >That leaves us with two approaches
> >
> >1. Use the draft-roach-sip-subscribe-notify-03.txt where a registration
is
> >an implicit subscription to the *event* of de-registration. You
> >automatically get a NOTIFY upon de-registration. This is the 3GPP
approach.

Just to be acurate, the subscribe-notify draft does not define implicit
subscription for REGISTER. I don't think that it is specifically described
in any I-D. However, it was meantioned during one of the SIP meetings at
IETF-50 last week as a solution to the de-registration notification problem.
Implicit subscription is used by the REFER method described in
draft-ietf-cc-transfer. The REGISTER request will need an Event header to
indicate the event it is subscribing to.

Bob
d:-)

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
(781) 933-6166
[email-masked]

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Romeo Zwart <[email-masked]>
Date: Fri, 30 Mar 2001 11:06:18 +0200

What was not clear to me is whether it's not supported for good, but 
non-articulated, reasons or just because no one has (yet) considered it useful.

>1. Use the draft-roach-sip-subscribe-notify-03.txt where a registration is 
>automatically get a NOTIFY upon de-registration. This is the 3GPP approach.

I don't think there exists a '3GPP approach' yet. :-)

>2. You SUBSCRIBE to your own presence (say automatically with 
>Registration). Upon de-registration, the NOTIFY is automatically sent. 
>This will give you some interesting side effects: if you have set up 
>Authorisation for Watchers(via QAUTH), will it ask you for your 
>credentials? The other effect is: Visibility Rules - which controls how a 
>Presence Service makes Watcher Information available to other Watchers 
>(these could be Presentities). I could have a service where I send Instant 
>Messages to all my Watchers - would this mean I receive my own msg?  None 
>of what I state here is a problem - just interesting side effects.

I agree these seem to be the options. The former would imply a new event 
package to be defined for this use. Which might not be a bad idea, bcs it 
might allow to also use this mechanism for providing other 
Registration/subscription related information to the registered device. 
However, looking at the 3GPP timelines, defining a new package for this use 
may not be feasible for the next release.

The 'interesting side effects' of the latter approach are probably a nice 
basis for someone's add-on service. Again from the perspective of 3GPP's 
deadlines I'd expect a focus for solving the must urgent issue first, i.e. 
notifying a device of the fact that it has lost its registration. Enabling 
this mechanism for providing additional services, if at all a 
standardization issue, is probably a secondary thing.

Romeo

>Regards,
>
>Sriram
>
>__________________________________________
>Sriram Parameswar              Phone: 972-685-8540
>Wireless IP MultiMedia (WIPMM)   Fax: 972-685-3563
>Nortel Networks, Richardson USA  Email: [email-masked]
>
>-----Original Message-----
>From: Romeo Zwart [<mailto:[email-masked]>mailto:[email-masked]]
>Sent: Thursday, March 29, 2001 9:25 AM
>To: Bob Penfield; Baniel Uri-CUB001; 'Stephen Terrill'; 'Romeo'; 'Dean
>Willis'; Parameswar, Sriram [NGB:B658:EXCH]; 'Igor Slepchin'; 'William
>Marshall'
>Cc: Chen Bonnie-BCHEN1; Xu Lang-LXU1; sip
>Subject: Re: [SIP] Informing UA after network initiated deregistration?
>
>At 03:32 PM 3/29/2001, Bob Penfield wrote:
> >Baniel Uri-CUB001 wrote
> > > I remember Jonathan's stating about having the outcome of the discussion
> > > in Minneapolis closes the titled thread.
> > > Can someone provide me please with an appropriate link to the 
> draft/paper,
> >which summarizes the closure which has been achieved on this.
> >
> >I believe the final outcome of this issue is that the REGISTER message can
> >imply subscription to an "unregister" event which would be sent to the 
> UA in
> >a NOTIFY request if and when the event occured.
> >
> >SUBSCRIBE/NOTIFY is described in draft-roach-sip-subscribe-notify-03.txt
>
>This may come down to wordsmithing, but I think Jonathan referred to
>the SIP for presence work - being an existing package for the SUB/NOT
>framework.
>
>One of the reasons the difference may be of interest, is that the
>concept of implicit subscription is not mentioned in the sip-for-presence
>document.
>
>With that particular issue and some other minor questions, I tried to
>resuscitate this thread on the SIMPLE list, but so far without much
>success. Any takers out here?
>
>Romeo
>
> >The implicit subscription notion also exists in the REFER method 
> proposed in
> >draft-ietf-sip-cc-transfer-04.txt
> >
> >Bob
> >d:-)
> >
> >Robert F. Penfield
> >Chief Software Architect
> >Acme Packet, Inc.
> >130 New Boston Street
> >Woburn, MA 01801
> >[email-masked]