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

From: [email-masked]
Date: Mon, 15 Nov 2004 23:05:04 +0200

Hi,

Perhaps I've made things sound too complicated, so I try to clarify.

The scenario which I'm thinking is such that the devices have open SIP and presence APIs, on top of which third party developers are able to create their own applications. For instance currently there is a SIP stack for Symbian OS, and you can install variety of SIP-based apps, such as push-to-talk, file sharing, battleship game, voice IM etc. on top of it. Obviously there will in addition be the "main" SIP UA that takes care of the core things such as voice, video, MSRP and conferencing. 

Each of these applications is pretty independent of each other and can't share capabilities with other apps. So what they need to do is to publish their own individual tuples, which describe the capabilities of that application only. Merging the tuples would give the watchers a wrong idea ("battleship game with PTT suppport" etc.). The applications can very well share the same SIP AoR, since they sit on top of a common SIP stack, which can determine (in most cases) the right application for the initial request based on e.g. caller preferences, other header values, medias in SDP or whatever.

The basic requirement is that these applications should be able to control the authorization to the tuples _they_ publish. For instance PTT app will have a white list to set who are able to see the PTT related tuple(s). It is possible to have a common UI for this to cover all apps, but app specific UIs will also contain authorization.

The requirements derived from this real life scenario are:
1. Applications must be able to publish tuples using the SIP AoR as their contact address in such way that the presence server won't merge the tuples.
	-> Composition rules should allow multiple tuples per AoR, and not override or merge them unless there is some explicit indication on this.
2. Applications must be able to include enough information in their tuples so that other similar applications can identify them.
	-> Prescaps + proprietary capability elements is enough. Service ID is not necessary.
3. Applications should be able to create authorization rules that govern access to the tuples published by them
	-> Some kind of static identifier for the tuples used between PUA and PS would do. If nothing else is provided, at least tuple ids should be then usable for authorization rules in addition to contact URIs. We can use fixed tuple ids that persist over time, although that is not exactly how those ids were meant to be used. Another possibilty would be the class element, for which I currently don't see any other use.

I hope Jonathan could include this type of identifier (tuple id, class, whatever) based tuple selection approach in the authorization rules document. Otherwise it is difficult to support requirement 3.

I don't think doing authorization based on capabilities is essential, although it might be useful in some specific cases.

Regards,
	Markus 

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 12 November, 2004 03:05
> To: Isomaki Markus (Nokia-TP/Espoo)
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: AW: AW: [Simple] Data model - attempt at summary
> 
> 
> Markus - comments at the end.
> 
> 	Paul
> 
> [email-masked] wrote:
> > 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.
> 
> 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
> 
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Nov 2004 18:13:11 -0500

> Perhaps I've made things sound too complicated, so I try to clarify.

The clarification does help.

> The scenario which I'm thinking is such that the devices have open SIP and presence APIs, on top of which third party developers are able to create their own applications. For instance currently th…

Do these applications have different *contact* addresses? E.g.
- sip:[email-masked]
- sip:[email-masked]
- sip:[email-masked]

Or are these demultiplexed in some more obscure way that is not clearly 
identifiable remotely?

> Each of these applications is pretty independent of each other and can't share capabilities with other apps.

OK. At least this is very clearly an OR-OF-ANDS presence representation 
need, as opposed to the just conflicting views where one is right be we 
don't know which one.

In some cases I suppose the independence is intrinsic - you just can't 
share that little screen effectively between the battleship game and the 
IM application. In other cases it may just be an artifact of the 
implementation model that they aren't integrated.

 > So what they need to do is to publish their own individual tuples, 
which describe the capabilities of that application only. Merging the 
tuples would give the watchers a wrong idea ("battleship game with PTT 
suppport" etc.).

I know that Henning is of the opinion that there is no need to 
understand the difference between conflicting tuples and the OR-OF-ANDS 
  case, because they aren't operationally different to the end user.

But they are semantically different. And while that difference may be 
irrelevant to the ultimate watcher, it does make a difference to a 
composer, including a UA that does its own composition for purposes of 
display.

You have that if you can use a different contact address for each 
application. Using GRUUs would solve this. But I guess you have a strong 
resistance to using GRUUs.

The AOR, with a uri parameter to distinguish the contacts, would also 
work. However, with the exception of the grid parameter on gruus, you 
can't count on uri parameters of an AOR being passed on when a request 
is routed through the AOR to a registered contact. But if you are 
content to use the AOR, because you discriminate on some other basis, 
then maybe it doesn't matter to you that the parameter gets lost - it 
will still serve to keep the tuples distinct. So maybe you could 
populate your tuples with contacts like:
	<sip:[email-masked];application=battleship>
   or	<sip:[email-masked];application=im>

 > The applications can very well share the same SIP AoR, since they sit 
on top of a common SIP stack, which can determine (in most cases) the 
right application for the initial request based on e.g. caller 
preferences, other header values, medias in SDP or whatever.
> The basic requirement is that these applications should be able to control the authorization to the tuples _they_ publish. For instance PTT app will have a white list to set who are able to see the…

The idea that applications will control authorization of specific tuples 
that share the same AOR is troubling to me - moreso if they advertise 
the same contact information.

But it is probably not my place to argue about what kind of UI you want 
to provide.

As long as there is *something* that marks the tuples as being 
different, it should be possible to construct an authorization rule that 
  is conditioned on that discriminating attribute. However, there may be 
considerable difficulty in managing the collected set of rules after the 
fact. How do you select the set of rules that belong to one application 
so that it may edit them and not those of another application?

> I don't think doing authorization based on capabilities is essential, although it might be useful in some specific cases.

I am interested to hear your response to my comments above. I feel we 
are getting closer to a common understanding, although slowly.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Nov 2004 15:43:52 -0500

inline.

[email-masked] wrote:

> The scenario which I'm thinking is such that the devices have open 
> SIP and presence APIs, on top of which third party developers are 
> able to create their own applications. For instance currently there 
> is a SIP stack for Symbian OS, and you can install variety of 
> SIP-based apps, such as push-to-talk, file sharing, battleship game, 
> voice IM etc. on top of it. Obviously there will in addition be the 
> "main" SIP UA that takes care of the core things such as voice, 
> video, MSRP and conferencing.
> 
> Each of these applications is pretty independent of each other and 
> can't share capabilities with other apps. So what they need to do is 
> to publish their own individual tuples, which describe the 
> capabilities of that application only. Merging the tuples would give 
> the watchers a wrong idea ("battleship game with PTT suppport" etc.).
>  The applications can very well share the same SIP AoR, since they
> sit on top of a common SIP stack, which can determine (in most cases)
> the right application for the initial request based on e.g. caller 

This is the part that worries me. I really don't see how this is going
to work in the general sense. GRUU would really help here; it would
provide an identifiable URI for each of these different apps.

The problem is that in SIP, the model is really that a user has a number
of contacts against an AOR. When I call that AOR, any one of the
contacts could service the request, albeit with perhaps a subset of the
full capabilities that might get used.

You are using SIP in a different model. Each contact of the AOR
represents a different service. When I initiate communications, I can
only be usefully connected to the service matching the one I am using to
generate the request. That is, if I "call" you from my battleship app,
that call has to get to your battleship app or it doesnt work.

In this kind of model, I think these really represent different user
agents which just happen to share a stack. I would go so far as to argue
that you really want separate AOR for them altogether. Absent that, GRUU
would clearly be the next best match. Otherwise, you are going to depend
on some kind of magical dispatch based on what you *think*
differentiates the INVITE from a battleship app with the INVITE from a
PTT app. That seems incredibly brittle to me.

> 
> The basic requirement is that these applications should be able to 
> control the authorization to the tuples _they_ publish. For instance 
> PTT app will have a white list to set who are able to see the PTT 
> related tuple(s). It is possible to have a common UI for this to 
> cover all apps, but app specific UIs will also contain authorization.
> 
This further seems to argue for separate AORs/presentities for each of
these, in fact.

That said, the current authorization rules document allows for other
selectors to be defined in the future which allow you to choose which
services and tuples get advertised. Today, only two are defined for
services - by URI scheme and by full URI. Other specs can define others
in the future. I'd rather defer the definition of more complicated
selectors to a follow on activity.

> 
> 
> The requirements derived from this real life scenario are: 1. 
> Applications must be able to publish tuples using the SIP AoR as 
> their contact address in such way that the presence server won't 
> merge the tuples. -> Composition rules should allow multiple tuples 
> per AoR, and not override or merge them unless there is some explicit
>  indication on this.

I'll say again that I think that this is a telling sign that you are
dealing with different presentities.

The fact that a compositor may decide to merge contacts for an AOR is
explicitly because of this unstated notion that each contact for the AOR
represens a valid reachable contact for a call to that AOR. Once you
break that assumption, sure, composition doesn't work right anymore.

My fear is that you actually have quite a different model for presence
than in the current data model. You need to fix these inconsistencies at
the root, rather than debtaing whether or not we should allow or
disallow authorization based on capabilities or class.

2. Applications must be able to include enough
> information in their tuples so that other similar applications can 
> identify them. -> Prescaps + proprietary capability elements is 
> enough. Service ID is not necessary. 3. Applications should be able 
> to create authorization rules that govern access to the tuples 
> published by them -> Some kind of static identifier for the tuples 
> used between PUA and PS would do. If nothing else is provided, at 
> least tuple ids should be then usable for authorization rules in 
> addition to contact URIs.

Is this really an out-of-the-gate functionality that is needed?

Markus wrote earlier:
> Hi,
> 
> I have thought about this a bit and my current thinking is this: -
> Prescaps and other decomposed capabilities are good as long as your
> application can interoperate with another application which only
> supports a subset of your capabilities. In some cases this is clearly
> useful, e.g. with different medias. - If you have a proprietary
> application, which can ONLY work with another similar app, there is
> no use in decomposing the capabilities. So for each this kind of app
> you just define a single proprietary capability who is only
> understood by other similar apps. - This type of proprietary app
> should be published in a separate tuple of its own, and actually
> SHOULD NOT included other capabilities. E.g. even if the app
> supported voice, there is no point listing that, if it can't work
> with another app that ONLY supports voice but not the proprietary
> part. - On the other hand if you have an application which has a
> certain proprietary capability, but that is not essential, you can
> just include that in the tuple _in addition_ to all other
> capabilities that you might have.

The root cause problem here is that what you are describing is NOT sip. 
Thus, indicating it with a SIP URI isn't working for you. If it is not 
enough to just know the SIP URI, and you need some additional context 
because you won't interoperate if you don't support a feature, you are 
talking about a non-SIP protocol. I should be able to interoperate with 
any SIP endpoint given just the sip URI, assuming there is an overlap in 
media and codec. That is distinctly different from not interoperating 
because there is some non-standard logic in place.

Thus, IMHO, if you want to indicate these non-SIP SIP protocols, please 
register a new URI scheme. For example, "ptt:" could be used to indicate 
the OMA PTT usage. Once you do this, scheme-based selection of tuples 
for authorization works fine.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Aki Niemi <[email-masked]>
Date: Wed, 17 Nov 2004 13:14:37 +0200

Inline.

> PTT app. That seems incredibly brittle to me.

What exactly is brittle in this? There are a ton of ways by which a 
helper application could register itself to such a dispatcher. The most 
obvious way is to give it an SDP to look for in incoming INVITES. Others 
include MIME types, feature tags, etc.

Requiring any new application to have a separate AOR is an incredible 
barrier for innovation. Also, they simply don't work since I definitely 
don't want either service-specific AORs appearing on my business card, 
or GRUUs appearing in my call logs. I want to be contacted and contact 
people via a single, global, and lasting SIP address.

...snip...
> because there is some non-standard logic in place.

I don't understand what this non-standard logic would be. If one of the 
parties in the call doesn't support ptt, then isn't that exactly a case 
where there is *not* an overlap in media and codec? I.e., business as usual.

Certainly the rendezvous part of it at least is SIP. You can't be 
arguing against that; an unknown media/application doesn't make the 
protocol that carries such an offer non-SIP.

> for authorization works fine.

Thinking beyond voice, video and MSRP, what new applications can there 
then actually be that I can use SIP for, and who decides that? I don't 
think we should be flooding IANA with URI scheme registrations just 
because we can't figure out handles in presence authorization beyond 
contact URI scheme.

Email doesn't require a separate URI scheme for email and calendar 
invitations. Mailto is enough, because the clients know how to dispatch 
helper applications when they need to.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Nov 2004 09:18:16 -0500

> include MIME types, feature tags, etc.

Well, suppose you establish your AOR this way. Then I send an INVITE to 
you without an offer. Are good things going to happen? I don't think so.

Ideally this would result in a response with an offer of everything your 
device is capable of doing, so that the caller could choose what to do.

> people via a single, global, and lasting SIP address

*** Jonathan, please take note ***

The above is an interesting point that we came across in private 
discussions last week. It is potentially a significant issue in using 
GRUUs as the targets for new outbound calls: call logs/histories/billing 
records will not have an address with long term significance. A month 
later when I am trying to decide what that call was about I may not be 
able to tell. Nor will I be able to call it back to find out.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 18 Nov 2004 23:05:51 -0500

Paul Kyzivat wrote:

> able to tell. Nor will I be able to call it back to find out.

To rephrase slightly: while there is a reasonably clear lifetime notion 
for Contact URIs returned under various conditions (within a dialog, 
permanent, etc.), this does not appear to be the case for GRUUs.

The problem occurs in HTTP (the "bookmarking problem", typically due to 
embedding some state into the URI which is later no longer valid), but 
it remains annoying and puzzling to users.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 18 Nov 2004 23:23:38 -0500

I agree with the summary below. tuple-id's are also useful in 
authorizations particularly when the data and the rules are generated by 
the same (logical) entity, regardless of any AOR collision issues.

[email-masked] wrote:
> indication on this. 2. Applications must be able to include enough
> addition to contact URIs. We can use fixed tuple ids that persist
> over time, although that is not exactly how those ids were meant to
> be used. Another possibilty would be the class element, for which I
> currently don't see any other use.
> 
> I hope Jonathan could include this type of identifier (tuple id,
> class, whatever) based tuple selection approach in the authorization
> rules document. Otherwise it is difficult to support requirement 3.
> 
> I don't think doing authorization based on capabilities is essential,
> although it might be useful in some specific cases.
> 
> Regards, Markus

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 18 Nov 2004 23:34:54 -0500

Paul Kyzivat wrote:

> need, as opposed to the just conflicting views where one is right be we 

I probably contributed to the confusion. I think the way to make sense 
of (service) tuples in general is to simply say that all of these are 
alternate services that can be used to reach the presentity. I'm not 
sure it's helpful to call out the same-AOR case, as even without this, 
it is a "or-of-and" enumeration across services.

As I've tried to say before, even non-SIP URIs have never been 
sufficient to uniquely describe the precise service rendition by 
themselves.

>  case, because they aren't operationally different to the end user.

See above. I tried to unify the two notions (service enumeration, 
uncertainty) in my mind and at the microphone, but it didn't work well. 
This doesn't seem necessary, however.

My main concern is not philosophy, but precisely defined watcher 
behavior. As long as we can precisely define what a watcher needs to do 
when it receives a list of service tuples, the data model is 
sufficiently well defined.

Note that a presentity may intentionally give up fine-grained control of 
   allowing certain UAs to control reaching service sub-entities in some 
cases. (If a browser doesn't support Accept-Language, the HTTP "URI 
overloading" mechanism isn't going to work well. This does not imply 
that we should abandon the mechanism.)

> so that it may edit them and not those of another application?

Note that the GRUU doesn't really help any more than a tuple-id. Both 
are random and meaningless to third parties. In other words, if you want 
to select based on GRUUs, you have to still know which service 
description goes with that GRUU, presumably by subscribing to your own 
presence. Once you do that, you can also get the tuple ID.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 18 Nov 2004 23:41:15 -0500

> that call has to get to your battleship app or it doesnt work.

Both models can work and, according to Markus, are being implemented. 
The question for us is not whether one is better than the other, but 
whether we should *disallow* Markus' model. Forcing distinct tuple URIs 
disallows the model.

The services knows whether they need to publish distinct URIs or not. 
The watcher just does its thing, mechanically.

Nobody prevents an entity from using GRUUs, individual contact URIs, 
service-based user names ([email-masked], email style) or 
what have you.

> selectors to a follow on activity.

Why not allow tuple-ids? Well-defined, even in PIDF and have no 
ambiguity whatsoever.

Presumably, <class> would be another selector.