Subject: Re: [Simple] Three dimensions of service

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 08 Feb 2005 09:12:17 -0500

Brian,

you still haven't answered what this magic document you describe would 
contain that could not be contained in a presence document.

I agree that while you can get basic interoperability using presence 
descriptions, this may not be sufficient for more than getting bits to 
flow and initiating the right software components. But in many cases, 
that's sufficient - the software application doesn't have to know that 
the left and right channel of audio refer to the moderator and speaker, 
respectively. Through either in-band (notes) or out of band (I know I'm 
connecting to a particular session), the user can figure this out.

I have no hope of conveying in a structured document the meaning of Doom 
- and I see little point of trying. In my D3, you would simply indicate 
"Game/Doom" or something of that nature.

You'd basically need the user's manual to tell the recipient what to do 
with the information and what user interactions make sense.

Henning

Brian Rosen wrote:
> 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

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

---

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

The magic document contains human understandable text that tells the reader
how the service works.  It probably also specifies what protocol mechanisms
are employed, which are required and which are optional.

I'm not arguing with what capabilities a service presents in the presence
document that already have been defined.  They are necessary.  I don't think
they are sufficient.

It's always possible that if you have a somewhat congruent set of
capabilities, you can create a session and try it.  It might work.
For that, you don't need a notion of service beyond some simple display of
the name of the service for the human.  I think you would like to know the
name of the service.

> with the information and what user interactions make sense.
I would only add that you may need a document to create a high quality user
experience; it's not just the human that could understand what Game/Doom
means, the client might.  The human that wrote the client code may interpret
the document to figure out how to create an excellent user experience.

So, maybe we are in fact converging.  We need no new mechanisms to get your
D1/D2 stuff done.  All we need for D3 is a name, which implies a registry.
The registry would point to a document that describes Game/Doom, which could
be the "user manual", but might be something more spec like.

That's all I've asked for: services have names, and names are registered.
Services have some set of (existing) capabilities.  If you don't know what
the name means, you support the capabilities, and you want to try
establishing a session, go for it.

Brian