Subject: RE: reducing xcap-auth scope, was: Re: [Simple] A proposal for xcap direction

From: [email-masked]
Date: Tue, 22 Jul 2003 16:57:12 +0300

Hi,

Comments below.

Jonathan Rosenberg wrote:
> 
> I agree. We have a pressing need to finish publish, xcap, xcap buddy 
> list, xcap auth, rpids, and message sessions. I believe that 
> xcap-package, filtering, and partial notifications are important but 
> are not as critical. As such, I think we should seriously consider 
> de-scoping and simplification wherever possible to accelerate stuff.
>

I agree with this prioritization of SIMPLE WG items.
 
> > 
> > Another comment I have is that we could still at least TRY to
> > simplify the baseline solution for presence authorization.
> > Hopefully the most complex rules could be left as optional
> > extensions.
> 

To me there are two main things that the presence authorization should be able to deal with:
- Who's subscriptions should be accepted and who's denied
- What is the content to give in the notifications for accepted subscriptions. This would have to work at least on tuple level, hopefully even based on attributes within a tuple.

I would be happy to leave most of the other stuff out if we can ensure that it could be added as extensions to the baseline schema. 

> I agree. I would suggest removing the following things:
> 
> * the accept-if conditions related to filters (requested-namespace, 
> requested-element, requested-tuple).
> 

Agreed.

> * I could be convinced to remove accept-if altogether. I do 
> think that 
> accepting subscriptions based on durations (to allow only 
> fetches), is 
> pretty useful. Other opinions?
> 

I think duration and anonymous are important, and in some cases auth-mechanism would be useful too.

> * we could remove the rule-permissions altogether. This would get 
> around most of the complexities of naming and addressing of 
> XML elements.
> 

I agree with this.

> * I think we still need content-permissions. We could descope 
> show-element so that you can only give permission by element 
> name, not 
>   by xpath expression. What do we lose if we do this? If a presence 
> doc has two tuples, and you wanted to allow a watcher to see 
> "placetype" in one, but not the other, you couldnt do it. you could 
> only allow or disallow "placetype"  for any tuple. I think thats OK 
> for the first version.
> 

Content permissions would definitely be needed. I'll still have to think what would be an acceptable level of simplification, I suppose what you propose makes sense. I'm not sure why XPath would be so bad on the server side?

> * We could remove show-values, as it also requires xpath.
> 
> * I think we still need transformational attributes. I would 
> recommend 
> that "set-element" and "change-value-from" would specify the element 
> by element-name (i.e., "placetype"), and would impact all 
> instances of 
> that element within the presence document.
> 

In general sounds good. Transformational attributes might be useful for providing different types/levels of presence info to different watcher groups.

> 
> 
> What do people think of this scope reduction?
> 
> Thanks,
> 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
> 
> 

Markus

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 29 Jul 2003 01:53:26 -0400

I was hoping for some additional comments on scope from folks besides
Markus and Henning. Please do comment. In the interim, I will rev 
xcap-auth to descope it based on the discussion here.

One response inline:

[email-masked] wrote:

>> name, not by xpath expression. What do we lose if we do this? If
>> a presence doc has two tuples, and you wanted to allow a watcher
>> to see "placetype" in one, but not the other, you couldnt do it.
>> you could only allow or disallow "placetype"  for any tuple. I
>> think thats OK for the first version.
>> 
> 
> 
> Content permissions would definitely be needed. I'll still have to
> think what would be an acceptable level of simplification, I
> suppose what you propose makes sense. I'm not sure why XPath would
> be so bad on the server side?

Its not complexity, so much as that the user needs to guess where in 
the XML document the data will show up. Its the same issue with using 
Xpath for filters that I have expressed previously.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 29 Jul 2003 01:53:26 -0400

One response inline:

-Jonathan R.