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

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

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.

(So using the example of the proprietary push-to-talk app that I described some time ago: I think that should just define a single capability extension, and definitely NOT include voice and half-duplex capabilities in its tuple to fool a watcher who has half-duplex VoIP to call.) 

What is needed is merely a way to be able to define authorization rules, which can select this type of tuples individually. Currently you can do this only if you support GRUU. I think this is the main use case for having some other identifier available for the selection.

So maybe the "service ID" as such is not needed after all?

Markus    

> -----Original Message-----
> From: ext Boehmer Bernhard Com Berlin
> [mailto:[email-masked]]
> Sent: 11 November, 2004 11:29
> To: 'Jonathan Rosenberg'; Henning Schulzrinne
> Cc: Boehmer Bernhard Com Berlin; Simple WG; Isomaki Markus
> (Nokia-TP/Espoo)
> Subject: RE: AW: AW: [Simple] Data model - attempt at summary
> 
> 
> Anything is a hard word ... 
> There are different issues which must be addressed:
> 
> - the description of services; I'm still not convinced
> that the description via prefs is applicable to services
> in general. Pointing to a description document is a way
> to address that. A more direct poiting to such a doc would
> be definitly nicer if possible.
> - the inclusion of proprietary services: This is related to
>  to the first point.
> - the definition of a unique service ID which is well known.
> The tmodel approach is a proposal to generate and publish
> such an ID.
> 
> I would certainly appreciate other solutions are avoiding at 
> least one of the two levels of indirection.
> 			Regards Bernhard
> 
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Mittwoch, 10. November 2004 07:54
> To: Henning Schulzrinne
> Cc: Boehmer Bernhard ICM Berlin; Simple WG
> Subject: Re: AW: AW: [Simple] Data model - attempt at summary
> 
> 
> I agree with Henning here; I don't see how the layer of indirection 
> solves anything.
> 
> -Jonathan R.
> 
> Henning Schulzrinne wrote:
> 
> > Boehmer Bernhard ICM Berlin wrote:
> > 
> >> Hi Henning,
> >> service ID: certainly indirection has its drawbacks;
> >> in this case the main question is whether the higher
> >> flexibility of indirection outweighs the overhead
> >> introduced with that. Actually, the whole XML schema
> >> architecture is using it heavily (this becomes obvious
> >> to me each time I edit XML schemas without being connected
> >> to the Internet...:).
> > 
> > 
> > While it is easy for a mobile provider to publish a UDDI 
> directory entry 
> > for its limited number of phones, say, it seems much harder for the 
> > average user in a corporate network or using a provider. 
> They will have 
> > to rely on the provider or corporate network to host this 
> information. 
> > Unless you want to rely on web pages for configuration, 
> every new source 
> > of information means that there needs to be authentication, 
> a means to 
> > publish this information and to change it.
> > 
> > The only advantage of inclusion by reference is space 
> saving. Otherwise, 
> > whatever service description you include by reference can also be 
> > included by value.
> > 
> > The space saving only matters if the mobile transmits the 
> information. 
> > This seems unlikely, even with inclusion.
> > 
> > Thus, I'm at a loss to see why adding another protocol 
> machinery for 
> > managing UDDI stores to every PUA or PA adds significant value that 
> > outweighs the complexity incurred.
> > 
> > Henning
> > 
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> > 
> 
> -- 
> 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
> 

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

---

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

Markus Isomaki wrote:

> What is needed is merely a way to be able to define authorization
> rules, which can select this type of tuples individually. Currently
> you can do this only if you support GRUU. I think this is the main
> use case for having some other identifier available for the
> selection.
> 

We already have a tuple ID for unique identification. I don't see how 
another random-looking identifier adds significant value.

The only value I can see is that you'd have multiple tuples that have an 
identical service and you'd want to filter all of them, without doing 
detailed XML element and attribute matching. I suspect this is not all 
that common.

Henning

---

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

> - 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 listi…

Based on your assumptions I agree.
(It would be better not to build the device this way, if possible.)

It might be better to explicitly indicate that the "common" capabilities 
are *not* supported, just in case your special capability is filtered 
out or ignored and a watcher might assume you have some unstated 
capability. (e.g. voice.)

> - 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…

Yup. Much more friendly behavior.

> (So using the example of the proprietary push-to-talk app that I described some time ago: I think that should just define a single capability extension, and definitely NOT include voice and half-du…

In that case I agree.

I think there is work to do to define half duplex more precisely. Maybe 
it will then be suitable to describe some kinds of PTT service, or maybe 
not.

But I do think it would be better if PTT were defined in such a way that 
it would interoperate with a regular voice caller, perhaps in only a 
limited way. For instance the caller might not know about the floor 
control needed, and so it would have to be handled by the PTT UA, or by 
the "mixer" if one is in the call. This would obviously be limited for 
the unaware party, but maybe not so limited as not calling at all.

> What is needed is merely a way to be able to define authorization rules, which can select this type of tuples individually. Currently you can do this only if you support GRUU. I think this is the m…

I still don't quite get it re the authorization rules. See my prior reply.

	Paul