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

From: "Michael Procter" <[email-masked]>
Date: Fri, 28 Oct 2005 11:09:04 +0100

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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Oct 2005 09:39:34 -0400

inline

> to use the reg package to monitor your own registration, to see

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.

> suitable q-value.  This seems like a plausible voicemail deployment

Yes.

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

> 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

---

From: Venkatesh <[email-masked]>
Date: Sat, 29 Oct 2005 10:29:50 -0700

Comments Inline....

> UA that did the registration can figure out it needs to reregister.

 [VV]: There are two distinct issues here. The one RFC 3680 is talking about
is the scenario where by you *want*
all entities to re-register themselves with the registrar as the admin
suspects fraud. The scenario I am talking about
is where an end user wants to revoke the previlages provided by him/her to
another end user. In this scenario, there is
no way for the end user or the UA or the registrar to know which of the
registrations/bindings are from the user whose previlages are being revoked
(especially if the user had provided previlages to three or four others and
has a couple of devices he/she has registered as him/herself, i.e. first
party). Ofcourse the solution could be to drop *all* registrations and force
all the bindings to reregister to discover the same but it seems like an
inefficient way to accomplish the same.

> message-taker and an automaton, not a real person.

 [VV]Sure. But it still leaves issue around the ability of applications like
presence servers to use registration information to compose presence (as is
one of the uses of the reg-event package as outlined in RFC 3680)
information meaningfully; especially when third party registrations are
involved. Someone that I authorized to register on my behalf is not "me"
(rather I should say, there are scenarios where I might want to distinguish
the two).

> > a new draft is required to describe these changes in isolation.

[VV] My intent was not to hold up the gruu-reg-event draft.

> identity. I don't associate any particular semantics with that

 [VV]: Like I said, it is of use for applications that are relying on this
information to build applications (like presence). For example, even the
simple "Welcome Notice" pushed down to the phone could be different if I had
this information.
_______________________________________________
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