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

[Paul Kyzivat <[e-mail]>]

inline

Michael Procter wrote:
> 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.

I should have been clearer. I meant that I didn't expect the removal of 
authorization to register could cause *the registrar* to automatically 
remove current registrations from that source.

If some other agent wants to do that, its fine with me.

In any case, 3680 isn't describing the same case. I think it is 
suggesting that registration be removed by external means, with the UA 
that had performed the registration discovering that fact and 
reregistering. It doesn't imply any change in authorization rules for 
registration. Nor does it require knowing who did the registration - the 
UA that did the registration can figure out it needs to reregister.

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

Yes.

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

We have another mechanism already defined for this. It is called 
callee-caps, RFC3840. With that, the VM can describe that it is a 
message-taker and an automaton, not a real person.

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

I'm not concerned with changing (extending) 3680. That is only about 
exposing state that is already present. But this suggestion requires an 
addition to the state that the registrar must maintain. That is a bigger 
deal.

My personal feeling is that *who* a registration is from is only 
relevant to the authorization of the particular transaction that does 
the registration. Potentially, a contact could be registered using one 
identity, then refreshed with a 2nd identity, and removed using a third 
identity. I don't associate any particular semantics with that

However, the work on the Consent Framework is raising some very 
interesting issues that are likely to change some of the rules around 
registration. In that case there are more compelling reasons for change. 
I would like to see how that plays out.

	Paul

> 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