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

["Michael Procter" <[e-mail]>]

Paul Kyzivat wrote:
> Venkatesh wrote:
> > 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.
> 
> Even if the information were available, I would not expect 
> that removal 
> of authorization to register would automatically remove current 
> registrations from that source.

RFC3680 specifically lists this as an approach to take to revoke
a registration early, in section 3.1.  It goes on to discuss how
to use the reg package to monitor your own registration, to see
if/when it is shortened.

> > 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? 

Well, a slight variation to the scenario suggests to me that it
is compelling.  Assume Alice and Alice's voicemail both register,
but the voicemail performs a 3rd party registration, and uses a
suitable q-value.  This seems like a plausible voicemail deployment
so far.

Now, subscribing to the reg package for presence information for
Alice (as discussed in RFC3680 Sec 3.2), you will only get
the information that *something* can take a call.  This isn't
useful, since I would hope that the voicemail server is
available almost all the time.

This problem can certainly be 'hacked around' to get something
that mostly works, but since we already have a mechanism (3rd
party registrations) to allow a UA to say 'I'm not Alice, but
I can take calls on her behalf', then it seems unfortunate not
to expose that in the reg event package.

> 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.

Indeed.  It doesn't seem very related to your draft, except that
both your draft and this change seek to update RFC3680.  Maybe
a new draft is required to describe these changes in isolation.

Regards,

Michael Procter

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP