Subject: Re: [Sipping] draft-kyzivat-sipping-gruu-reg-event-03.txt

From: Venkatesh <[email-masked]>
Date: Thu, 27 Oct 2005 10:26:23 -0700

On Second thoughts, may be the registrar should persist this information if
it is accepting third party registrations. I can think of a atleast one
other reason why this might be required.
 1. Lets say Alice allows Bob to register on behalf of her AOR. Bob
successfully registers. At some point later in time, Alice decides she no
longer wants to allow Bob to register on behalf of her and removes this
capability. Without the registrar storing which of the bindings it has
recorded is from whom, it will not be able to remove the appropriate
binding. Ofcourse, Bob will not be able to refresh his third party
registration but until the time the registrations expires, Alice calls will
also be delivered to Bob.
 Also, my main intent is to enable applications that rely on reg-events to
decide whom or when to subscribe to for various event packages. Suppose
Carol wants to monitor Alice's presence status and it relies on the
reg-event feed to decide when to subscribe. In the above case, Carol would
either end up SUBSCRIBing to presence status of all registrations of Alice
(this might be OK or not, depending on what the actual intention of the
application is).

Venkatesh

On 8/8/05, Paul Kyzivat <[email-masked]> wrote:
>
>
>
> Venkatesh wrote:
> > Hi:
> >
> > I was trying to see if adding this information sounded like a good idea
> > to others as well for starters :-). The current reg-event package
> > provides information somethng like "Someone that I know you have
> > authorized is modifying your registrations". I am thinking providing
> > something like "A John Doe that you have authorized is modifying your
> > registrations" has more value.
> >
> > The registrar by itself might not have any use for this information and
> > need not persist this information. It only needs to have access to this
> > information when sending out the reg-event. Most of the events generated
> > by the registrar are usually when it acts on a REGISTER request. At this
> > point it has the AOR it has authenticated. It can simply copy over the
> > same into the reg-event. Ofcourse there may be some scenarios where it
> > might generate events where it doesnt have access of the AOR (purging
> > registration on timer expiry). In these cases, it doesnt need to
> > populate this information as it is an action undertaken by it's own.
>
> The assumption that the info is only needed when a registration changes
> it is just wrong. Any time a new subscription is received an initial
> notification must be sent with the status of all the currently
> registered contacts.
>
> Supplying info on an as-available basis seems a sure fire formula for
> failure.
>
> I think if this is going to be added as a capability then it must also
> ammend 3261 to require capturing this information. But I don't think
> that is likely. Maybe others have a different opinion on that.
>
> Personally I don't think there is any particular relevance for this bit
> of information.
>
> Paul
>
> > Venkatesh
> >
> >
> > On 8/4/05, *Paul Kyzivat* <[email-masked]
> > <mailto:[email-masked]>> wrote:
> >
> >
> >
> > Venkatesh wrote:
> > > RFC 3680 current allows a UA to subscribe for registration events and
> > > get notified of any changes in the registration state for a AOR.
> > While
> > > it allows the UA to receive most of the information contained in the
> > > register (the AOR being registered, the duration, the CSEQ, the
> > call-id
> > > used et al), one of the things that might be useful for a UA
> > receiving
> > > this information is if this registration was a first party or a third
> > > party registration and if third party who the registering user
> > is. I can
> > > think of a couple of use cases for this (although there might be
> > a few
> > > others):
> > >
> > > 1. An application such as shared line appearances might want to
> > use this
> > > information to decide when to initiate distribution of dialog
> > state to
> > > various entities and when to stop the same.
> > >
> > > 2. An application might want to provide a UI to the end user to
> > display
> > > his/her list of active registrations. It might also want to
> > indicate to
> > > the end user which of the registrations being displayed are his/hers
> > > (first party) and which of those are from other users he/she has
> > > authorized to register on his/her behalf.
> > >
> > > I was wondering if others consider obtaining this information useful
> > > enough and if yes, can the same be enabled as a part of the changes
> > > being proposed by the gruu-reg-event draft.
> >
> > There is a problem with this idea: the behavior of a registrar as
> > defined in 3261 does not in any way suggest that the registrar retain
> > any information about the identity of the identity of the request that
> > registers a contact. The notion of first party or third party
> > registrations is one that is at most an issue of authorization. Once
> > authorized, that knowledge need not be retained.
> >
> > Paul
> >
> >
>
_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Oct 2005 18:55:58 -0400

Venkatesh wrote:
> On Second thoughts, may be the registrar should persist this information 
> if it is accepting third party registrations. I can think of a atleast 
> one other reason why this might be required.
>  
> successfully registers. At some point later in time, Alice decides she 
> no longer wants to allow Bob to register on behalf of her and removes 
> this capability. Without the registrar storing which of the bindings it 
> has recorded is from whom, it will not be able to remove the appropriate 
> registration but until the time the registrations expires, Alice calls 
> will also be delivered to Bob.

Even if the information were available, I would not expect that removal 
of authorization to register would automatically remove current 
registrations from that source. If Alice wants Bob's registration gone 
right away, she can remove any registration she thinks is improper. 
(E.g. doesn't look like one of her UAs.)

> Also, my main intent is to enable applications that rely on reg-events 
> to decide whom or when to subscribe to for various event packages. 
> Suppose Carol wants to monitor Alice's presence status and it relies on 
> the reg-event feed to decide when to subscribe. In the above case, Carol 
> would either end up SUBSCRIBing to presence status of all registrations 
> of Alice (this might be OK or not, depending on what the actual 
> intention of the application is).

Sure, if the information was there somebody will be able to find a use 
for it. But is the need compelling enough to make the change? Remember 
that it will no doubt have to be optional behavior, which won't do you 
any good unless your favorite registrar supports it.

I don't *oppose* this change. But neither to I support it, because I 
just don't find it compelling. If you can round up concensus for it then 
I see no problem. But I don't want to hold up 
draft-kyzivat-sipping-gruu-reg-event- waiting for that.

	Paul

> Venkatesh
> 
> On 8/8/05, *Paul Kyzivat* <[email-masked] 
>     <mailto:[email-masked]>
>      > <mailto: [email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >
>      >
>      >     Venkatesh wrote: