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