Subject: Re: [Simple] xcap/geopriv alignment issue 6: subscription confirmation

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 02 Dec 2003 15:05:45 -0500

inline.

Ben Campbell wrote:

> Jonathan Rosenberg wrote:
> 
>> Folks,
>>
>> In the current xcap-auth model, there is an important assumption that 
>> if there are no statements that apply to a watcher, the implication is 
>> that their subscription is pending, and that the presentity should get 
>> a winfo notification about the fact that its pending, so that they can 
>> make a policy decision. This assumption is based on another assumption 
>> I made, which is that the ONLY reason that a watcher would go into the 
>> pending state, is if you have not specified a policy for them yet.
>>
>> However, geopriv doesnt make this assumption. They have an element 
>> called "confirm-subscription". If present, it means that the 
>> presentity should be alerted about the subscription, and asked for 
>> confirmation. As a result, there is a way to EXPLICITLY say "let me 
>> know if this person subscribes".
>>
>> I think there are legitimate use cases for this, which came up during 
>> the geopriv meeting in Minneapolis. In particular, I may grant my boss 
>> permission to subscribe during the day, but during the evening, I want 
>> to be prompted each time, to see if I will grant it or not.
>>
>> To do this, we could follow their lead and add a 
>> "confirm-subscription" boolean, which would explicitly place the 
>> watcher into the pending state.
>>
>> I think this makes sense, and I would suggest adding this capability 
>> to xcap-auth.
> 
> 
> I think I like this. So if we were to do this, would that mean the 
> default for when no rules apply would become "deny"?

Yes. Generally, for any boolean type, the default is FALSE.

> 
> This does, however, bring up a concern that I tried to express in 
> Minneapolis, but am not sure I ever managed to make my point. Most 
> existing presence systems have a concept of blocking an identity. The 
> additive permissions approach seems to make this difficult to implement. 
> If I, for example, want to block [email-masked], I must make sure 
> that no other rule can possibly include alice. This is further 
> complicated if some of my rules apply to external lists. Even if Alice 
> is not on such a list today, someone might put her on one tomorrow, and 
> invalidate my block. The easiest way to make sure this never happens 
> would be to add an except clause for Alice to _every_ rule I have. That 
> seems pretty cumbersome and error prone.
> 
> And yes, I understand the arguments in geopriv about black-lists being 
> useless. I just don't think I could sell those arguments to a customer.

I think this is a separate discussion, which we are having in the 
thread associated with issue 8, exceptions. Do you see a specific 
interaction with subscription confirmation?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 02 Dec 2003 15:05:45 -0500

inline.

-Jonathan R.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 03 Dec 2003 16:15:58 -0600

Jonathan Rosenberg wrote:

>>> if there are no statements that apply to a watcher, the implication 
>>> is that their subscription is pending, and that the presentity should 
>>> get a winfo notification about the fact that its pending, so that 
>>> they can make a policy decision. This assumption is based on another 
>>> assumption I made, which is that the ONLY reason that a watcher would 
>>> go into the pending state, is if you have not specified a policy for 
>>> them yet.
>>>
>>> the geopriv meeting in Minneapolis. In particular, I may grant my 
>>> boss permission to subscribe during the day, but during the evening, 
>>> I want to be prompted each time, to see if I will grant it or not.
>>>
>> additive permissions approach seems to make this difficult to 
>> implement. If I, for example, want to block [email-masked], I must 
>> make sure that no other rule can possibly include alice. This is 
>> further complicated if some of my rules apply to external lists. Even 
>> if Alice is not on such a list today, someone might put her on one 
>> tomorrow, and invalidate my block. The easiest way to make sure this 
>> never happens would be to add an except clause for Alice to _every_ 
>> rule I have. That seems pretty cumbersome and error prone.
>>
> I think this is a separate discussion, which we are having in the thread 
> associated with issue 8, exceptions. Do you see a specific interaction 
> with subscription confirmation?

No. It simply triggered the thought in my head--but I agree it is being 
covered enough in other threads.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 03 Dec 2003 16:15:58 -0600