Subject: [Simple] Three dimensions of service

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 06 Feb 2005 22:05:03 -0500

I think it might be helpful to dis-entangle describing a service into 
(at least) three dimensions:

(D1) Protocol and network capabilities, describing what is necessary so 
that two devices can exchange messages. This encompasses most of 
prescaps. Knowing this won't guarantee that the service does what a 
human expect. For example, a user might be surprised to be connected to 
a robot when expecting a human to answer.

(D2) Interaction capabilities: how does the service act - is it a human? 
does it only announce or only record? This applies across a range of 
protocols and media.

(D3) Content - what gets conveyed by the media exchange. Am I talking to 
a flight reservation system or a Doom character or the game audio 
background music? This clarly applies to a range of media, protocol 
capabilities and even interaction styles. (Flight information can be 
delivered by a human or multiple kinds of robots.)

PTT is mostly a media signaling and floor control mechanism and doesn't 
really affect D2 and D3.

There seems to be some hierarchy, with D1 as the lowest level, but I 
don't think that particularly matters for the discussion. In some cases, 
only one or two of the three dimensions may be known or relevant.

D1 and D2 seem to be more amenable to enumeration, while it seems to 
require a full-blown ontology to do justice to D3, so that we may simply 
have to live with free text and maybe rendering hints (e.g., icons).

A service tuple should have a unique combination of these dimensions, 
which includes the "I don't know", "can be any one of a subset of them - 
call and you'll find out" and "I won't tell you" cases for any one of them.

Henning

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

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 7 Feb 2005 09:27:44 -0500

Henning

I'm not sure I understand the difference between D2 and D3, unless you
somehow think that D2 can be specified in some way that without additional
knowledge you can automatically determine how to interact with it.

I think there are only two dimensions:
D1, which are those characteristics that a service has that map into defined
protocol mechanisms

D2, which are those characteristics that a service has that don't map into
precise SIP/SIMPLE protocol mechanisms and depend more on the specification
of the service itself

I think you can enumerate services defined by D2 characteristics, and you
can have a specification for each of them that defines how they work, but
that's about it.  I think that's sufficient.  For presence, we need a
registry, and nothing else.  For D1, we have prescaps, as you observe.

I think that's enough, but I think we need a notion of service and a
registry of services so that a presentity and its watchers have the same
characteristics in mind when they see the service in the tuple.

With respect to PTT, you can argue all you want about whether there is some
kind of generic meaning to PTT, but I claim it doesn't matter; no one will
ever precisely define it, and no one needs a generic PTT to be defined.  The
OMA guys can define their version of PTT, and someone else could define
their own notion of PTT.  I don't want someone trying to guess what the
combination of, say, half duplex and floor control implies.  It implies
nothing other than there is a floor and the media streams are half duplex.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Henning Schulzrinne
> Sent: Sunday, February 06, 2005 10:05 PM
> To: Simple WG
> Subject: [Simple] Three dimensions of service
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Feb 2005 10:47:39 -0500

> precise SIP/SIMPLE protocol mechanisms and depend more on the specification

Brian, that definition of D2 is entirely circular, and hence useless.

We can argue about the precise difference between D2 and D3, and whether 
there is a difference or not. But as defined by Henning they are both 
related to the semantic content of the resulting session, rather than to 
the syntax of the session.

I get the impression that you don't agree with that distinction. I think 
it is an important one to make.

> registry, and nothing else. 

For an IANA registry I think it is necessary to provide a template for 
the elements that must go into a specification for each one.

What kinds of things would you expect to be in that, in order to 
describe "how they work"?

> For D1, we have prescaps, as you observe.
> 

We have to ban that word "service"!

We currently have a definition of service, that doesn't include this. 
And at the very least, what you are talking about, which is roughly what 
Henning is talking about, is another dimension or two in the description 
of a service. Call it D2 if you like, but not "service", or we will 
continue to tie ourselves in knots.

> ever precisely define it, and no one needs a generic PTT to be defined. 

So Sprint PTT, Nextel PTT, and OMA PTT will all continue forever to be 
different "services" that cannot interoperate?

On the contrary, I think the world needs for these to converge. Helping 
them to diverge is not a good way forward. Making everybody carefully 
think through exactly what is unique about what they are doing has got 
to help.

> The

In the case of half-duplex, I agree there is a problem. But it is a 
problem to be fixed, by defining what it means, for by declaring it 
useless and obsolete. It is quite possible tht half-duplex is the wrong 
way to describe PTT.

Because of the conference work, I think we have a better understanding 
of floor control. To the extent that PTT follows that model of floor 
control I don't think there is a problem. To the extent that this or 
that "PTT" uses some other mechanism for floor control, it may be that 
PTTs won't interoperate. This seems a lot to me like incompatibilities 
in supported codecs.

We choose not to expose codecs in presence, even though 
incompatibilities there may prevent communication. I believe that is 
because it is assumed not to be a problem in practice - that there will 
almost always be some codec in common, or else a transcoder will be 
involved.

In the case of floor control we may need to revisit that kind of 
assumption. Perhaps there needs to be a presence attribute that 
describes floor control, including the floor control protocol(s) 
supported. But I think if we can properly define floor control, then 
that is the only new thing needed to describe PTT. PTT is all about 
syntax of the signaling, not about the semantics of the media content.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 07 Feb 2005 13:13:52 -0500

> the syntax of the session.

I made the distinction for somewhat pragmatic reasons: The D2 
differences are observable pretty much by looking at bit flows and 
boxes. You can tell an answering service by the box it uses, regardless 
of whether it returns the weather or sports scores. (From a presence 
perspective, there is also the idea that some kinds of OPEN are more 
useful for deriving person-level presence. The availability of answering 
services, for example, is pretty useless for that.)

I don't think it is strictly necessary to make the distinction between 
D2 and D3, but it seems helpful, as the entities knowing the difference 
are likely different. An answering service or (VoiceXML) IVR service, 
say, can report itself as such without having to worry about what 
messages the owner records or what precise VoiceXML interaction is being 
offered.

In summary: D1, D2 and D3 are all reported by different layers in a 
typical implementation.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 7 Feb 2005 14:35:12 -0500

I'm sorry to be so difficult here, but you seem to be talking a language I
don't understand, or at least, you seem to think things are a lot more
standardizable than they are now, or I think they could be.

See in-line

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, February 07, 2005 10:48 AM
> To: Brian Rosen
> Cc: 'Henning Schulzrinne'; 'Simple WG'
> Subject: Re: [Simple] Three dimensions of service
> 
> 
> 
> Brian Rosen wrote:
> > Henning
> >
We must be talking past each other.  I'm saying that we can't define a
service by its protocol characteristics; two services may have the same
protocol offer/answer/capabilities, and one service might, in different
sessions have different protocol offer/answer/capabilities.  I'm suggesting
that you can write a specification defining a service, and you can have a
registry that allows you to use a name (as an ID) in a protocol mechanism to
precisely differentiate one service from another.

> the syntax of the session.
Here is an example of where I am lost.  I haven't the faintest idea of what
you mean.  The "semantic content of a resulting session" can't be known to
anyone but the humans; not even the automatons know what the semantic
content is.  The semantic content of the protocol mechanisms used to
establish the session might be specifiable, but I don't get that we are
arguing about that exactly, although we are discussing what the semantic
content of a tuple is.

I know we aren't arguing about syntax of protocol mechanisms, at least yet.

> it is an important one to make.
Well, if I understood it, maybe I would agree.

> the elements that must go into a specification for each one.
Not necessarily, and I'm not really sure if that is needed here.  What we
need really is just to make sure that when a service is called out in a
tuple, both ends understand what it means, and for that, a unique ID, which
is bound to some kind of document, is sufficient.

> describe "how they work"?
What media streams are supported, and how they relate to one another, what
kinds of control mechanisms (such as floor control) are supported, and how
they relate to the media streams.  Things like that.

> We have to ban that word "service"!
Not hung up on names.  Suggest another.

> continue to tie ourselves in knots.
Not sure if the word service is the source of the problem.  I think its that
you expect to be able to recognize a particular set of protocol "settings"
as implying a specific set of endpoint behaviors (such as voice+floor
control+half duplex = someone's definition of PTT).  I don't think that is
possible.

> different "services" that cannot interoperate?
OMA can define a service, and Nextel or Sprint could choose to implement it.
If they did, their services would be interoperable.  If they didn't they
wouldn't be.  No one is going to be able to claim that OMA has defined PTT.
They have defined one possible implementation of a service called PTT.
Sprint can, if it wants to, define another service, which Nextel might now
have to implement.  We care, in presence, that an endpoint tell us what
service it supports, which could be the Sprint PTT, the OMA PTT, both,
neither, ...

There is no one, universally agreed definition of PTT, and I don't think
there is going to be.  Like conferencing, we COULD create a generic kind of
service definition with options, but, like conferencing, we would have to
create or extend the available protocol mechanisms to enable or distinguish
the options.

> think through exactly what is unique about what they are doing has got
Oh, I'd prefer if we all settle on one definition, for sure.  I just don't
think there is any way that we can state that whenever you see audio+floor
control+half duplex, you can infer that you have that commonly agreed
definition of PTT.

> useless and obsolete. It is quite possible tht half-duplex is the wrong
Maybe so.  Not really the issue; it's a symptom of the problem we are
having, not the cause of it.

> PTTs won't interoperate. This seems a lot to me like incompatibilities
I don't agree with this.  The problem we are having with "service" is
roughly analogous to the "media flow graph" problem in conferencing.  I
think you believe it is possible to infer what service is provided by what
protocol mechanisms & capabilities are available.  I think it's impossible
to do that.

> almost always be some codec in common, or else a transcoder will be
Yes, I understand that.  I don't really see the connection to the problem at
hand, because there are no equivalent assumptions.  Here, we are trying to
discover if you can infer from the "knobs" what the "service" is.  If there
were a small number of possible services, and we had a sufficient number of
knobs, that should be possible.  I don't think we have that case. 

> syntax of the signaling, not about the semantics of the media content.
Nope.  Unless you extend floor control to define EXACTLY how the floor
affects the media stream, and you define in SIP how you relate a specific
floor to a specific media stream, or set of streams, then I think you can't
get where you seem to want to go.

I'll take that back because there is no assumption that a floor has to
affect a media stream.  It could, but it doesn't have to.

I have this black box.  I tell you that the black box has one audio channel,
one floor, and the audio is half duplex.  You want to say "ah ha, you must
support PTT.  I support PTT, therefore if I initiate a session with you,
we'll all be happy". I think you are dreaming, and that there are several
services that can be constructed with those parts.

I want to say "here is a document that defines a service called Foo.
Endpoints that support foo must support audio, one floor and either half or
full duplex.  When you have the floor, you may send audio.  When you don't
have the floor, any audio sent will be ignored, ..."  If you implement Foo,
and I say in my presence that I can support Foo, when you call me on the
contact in that tuple, we'll be able to interoperate.

Again, sorry to be a pain here.  I know I'm holding up progress.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 7 Feb 2005 15:40:16 -0500

The problem I have here is that while for something like an IVR service, the
difference between one that gives weather and one that gives sports scores
is not implementation of the client dependent. So I agree that we don't need
to define them differently with respect to presence.

Using Paul's PTT example is better, because we can definitely have two
services that have the same protocol characteristics and thus won't be
differentiateable by looking at prescaps and other defined mechanisms.

That's why I don't see the usefulness of differentiating between D2 and D3
if the only difference is that you can observe protocol
mechanisms/capabilities etc for D2 and not for D3.  Services are not in
general differentiateable from each other by such things.

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, February 07, 2005 1:14 PM
> To: Paul Kyzivat
> Cc: Brian Rosen; 'Simple WG'

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Feb 2005 09:24:00 -0500

Thanks Henning,

I've been trying to tease this distinction out of the discussion, but 
you have done a good job of spelling it out clearly.

I think dealing with D3 can either be ignored or at least postponed 
until later. But it would be good to settle on exactly what is special 
about PTT, and how it should be characterized. I still think it is all 
about floor control. I think the only thing that we don't have a good 
way to describe right now is the case where both voice and floor control 
are offered, but a call with just voice is not acceptable.

	Paul