Subject: RE: AW: AW: [Simple] Data model - attempt at summary

From: [email-masked]
Date: Thu, 11 Nov 2004 15:06:49 +0200

Hi Paul,

See inline.

Paul Kyzivat wrote:
> 
> Markus,
> 
> To describe a service that can't be described with prescaps, you just 
> need to use some other (perhaps proprietary) extension 
> entitites within 
> tuple or status.
>

Yes, I understand this is the idea.
 
> I had wanted the callerprefs extension mechanism mapped over 
> to prescaps 
> in order to make extensions to presence as simple as extensions to 
> callee caps, but that got lost along the way. Nevertheless I 
> don't think 
> it is very hard to define your own xml schema for this purpose.
> 

It is not hard as such. The problem I would like to address actually this: 
The user has service foo that uses SIP to open some media sessions. It is possible to create capability extensions which make it clear for the other end that this is foo. However, is it possible for the user to authorize the service tuple published by foo in some clear way? Originally I thought class could be used as this type of selector (although no conflict resolution exist for class values), but it is no longer supported. Currently the only ways to select tuples in authorization phase are URI scheme and URI itself. But if we accept the case that there can be several tuples/services with the same URI, they become an unseparable unit from authorization point of view. Some sort of id in the tuples that services/publishers could consistently use would help, and why not using that then to tell something to the watchers too.

> 	Paul

Markus 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Nov 2004 20:04:33 -0500

Markus - comments at the end.

	Paul

[email-masked] wrote:
> The user has service foo that uses SIP to open some media sessions.
 > It is possible to create capability extensions which make it clear
 > for the other end that this is foo. However, is it possible for the
 > user to authorize the service tuple published by foo in some clear way?
 > Originally I thought class could be used as this type of selector
 > (although no conflict resolution exist for class values), but it is no
 > longer supported. Currently the only ways to select tuples in
 > authorization phase are URI scheme and URI itself. But if we accept the
 > case that there can be several tuples/services with the same URI, they
 > become an unseparable unit from authorization point of view. Some sort
 > of id in the tuples that services/publishers could consistently use
 > would help, and why not using that then to tell something to the
 > watchers too.

I'm not sure why you would want to do this. Perhaps it is a capability 
that only some of your watchers possess, but does it hurt to tell the 
other watchers?

If it is important to do so, then it ought to be equally important to be 
able to authorize based on other capabilities. For instance, maybe I 
don't want everyone to know that I have a phone with video capabilities. 
Currently this is handled by simply not disclosing the capability of 
concern. This works fine if I have a device with audio+video and I don't 
tell everyone about the video. It works less well if I hide both audio 
and video from some people, because then I am telling them I have an 
open device with no indication of supported media. Just one more reason 
why capabilities should be reported with both positive and negative 
values, so that the absence of a value isn't treated as having it.

If it is really necessary to condition authorization on the presence or 
value of some arbitrary element in the tuple then presumably something 
could be added to the authorization rules to do this.

	Paul