Subject: RE: [Simple] Knowing which tuples to select

From: [email-masked]
Date: Sun, 9 Nov 2003 20:14:13 +0200

Hi Jonathan,

See inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 30 October, 2003 17:30
> To: Simple WG
> Subject: [Simple] Knowing which tuples to select
> 
> 
> Folks,
> 
> As I mentioned in a previous note, per list discussion I removed 
> transformational permissions from xcap-auth. Instead of havgin the 
> xcap server apply the transformations, the idea proposed by Henning 
> and others is to have a separate "application" in the network publish 
> tuples for me that contain whatever information I wish to distribute. 
> Indeed, the application itself might live in the endpoint as well.
> 

I'm not sure I follow the "application in a network" idea wrt. what I thought transformational permissions vs. default/hard state publishing were trying to address.

I have two use cases:

1.)
- I want to tell X that I'm in a meeting 
- I want to tell Y that I'm in a bar

In this case I can publish two tuples and authorize one of them to X and the other to Y. The main concern I currently have is that xcap-auth only allows to select tuples based on <class>. At least I have intended to use <class> for instance so that it defines that a tuple is generated by a certain type of application, so it makes easy for a similar application to filter it. Now we would need to overload class for authorization selections too.

2.)
I want that my presence data _always_ includes my e-mail address and homepage. I don't want to use SIP PUBLISH to maintain this type of "hard state". For this I have proposed to define an XCAP application usage for presence publishing.    

So could you (or Henning explain) whether there is something beyond these two cases we want to support that transformational permissions were related to.

Not related to transformation permissions (or perhaps I don't remember their whole concept), there is clealy a third issue, which needs some attention and seems to be the one discussed below. This is that what if the presence agent really has some sources in the "network" that publish presence information (this can be circuit switched call state, network provided location information, whatever). The user should be able to somehow authorize this information from his separate "endpoint". 

> THere are still some open questions about achieving interoperability 
> in such an environment, particularly if the application lives in the 
> network:
> 
> * how does the user configure the behavior of this application? I 
> think this is out of scope; we are not going to try and provide 
> standardized interfaces for this control - thats the whole idea.
> 
> * assuming the user controls the application somehow, it will begin 
> publishing tuples. How does the client know the RPID class of those 
> tuples, so that it can control their distribution via xcap?
> 
> 
> I see only a few choices for the second issue:
> 
> * ignore the problem - presumably the application will tell the user 
> through some kind of UI which class to select
> 
> * agree on a standardized naming convention for tuples published by 
> such applications
> 
> * treat this as a configuration problem. The device needs to be 
> configured with RPID class corresponding to tuples published by 
> applications. In that case, we might be able to place this data into 
> xcap itself, so that it can be read by the client device. This would 
> presumably be a separate application usage.
> 
> 
> I'm inclined to go for the third option.
> 

I support this too. In any case, interoperability will require some specification work not currently available.

> Thoughts?
> 
> -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
> 

Markus

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

---

From: [email-masked]
Date: Sun, 9 Nov 2003 20:14:13 +0200

Hi Jonathan,

See inline.

I have two use cases:

1.)

2.)

Markus