Subject: Re: [Simple] Three dimensions of service

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 07 Feb 2005 22:56:36 -0500

> 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

Obviously, for many normal conversations, the semantic content is not 
defined beyond "human-to-human conversation". But for many of the 
services that have been used as examples, they are precisely 
distinguished by the fact that they don't lead to normal human 
conversation, but instead to talking to a Doom game engine or other 
services. For some human-to-human communications, semantic content can 
be described to the extent that it is useful to distinguish tuples; see 
my airline information example. While the Delta airlines rep may be 
willing to talk about the weather and your new startup company if 
pressed, they may still want to advertise the service as "flight 
information".

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

We discussed indirection before (it was offered by somebody else) and 
there seemed to be agreement that indirection simply defers the problem 
to agreeing on what this document might contain. A description in 
unstructured English prose isn't any more useful than a notes field.

> 
> 
>>What kinds of things would you expect to be in that, in order to
>>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.

That's all D1 and D2 stuff.

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 8 Feb 2005 08:28:59 -0500

I still can't fathom what you are talking about, but I don't think it
matters.

You, and Paul, think you can infer the end device requirements to initiate a
session to a service by the protocol visible characteristics that a presence
tuple would give you, and you believe that it should be possible to describe
services in terms of (presumably unique) sets of these characteristics.

I think you are dreaming, and most services cannot be so simply defined.
The most common services could be (basic telephony, instant messages, and
the like).  I think all the other examples we have used, including Doom and
PTT cannot.

If Doom supplies audio out, but not audio in, what device would be suitable?
If you call it with a telephone, would anything useful happen?  How would
you know?  Suppose it has two audio outputs with labels "Left" and "Right"? 
You, as a human, can guess what that means.  How would an arbitrary client
that had ways to handle multiple input streams (i.e. local mixing
capability).  Suppose doom supports audio in and out.  Now what devices are
suitable?  Suppose it has a floor control.  Does that floor control the
audio in?  How do you know?

You know only if you know what "Doom" means.  Doom is a service.  You cannot
tell from the presence visible characteristics.  Some other document has to
tell a client what Doom means.

The same is true of PTT. Sprint PTT and OMA PTT are different services.
They work differently.  You can't tell the difference from the presence
visible characteristics.

I think this is an unsolvable problem; we will never be able to infer how a
service works, and thus how to make a good endpoint, if all we have are the
presence visible characteristics.  I think services are always defined by a
document that describes the service with sufficient detail that an excellent
client could be built.   It may be possible for a general purpose device to
initiate a session with a service it was not built for, and get an
acceptable enough user experience, but if you wanted a good user experience,
you need to know how the service works.

I think we need to uniquely name services, and have the name be associated
with a document.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, February 07, 2005 10:57 PM
> To: Brian Rosen
> Cc: 'Paul Kyzivat'; 'Simple WG'
> Subject: Re: [Simple] Three dimensions of service
> 
>