Subject: Re: [Simple] Three dimensions of service

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Feb 2005 13:34:30 -0500

Comment down near the end.

	Paul

Brian Rosen wrote:
> 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.
> 
> I agree that:
> 
>>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.
> 
> 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.

We are getting closer. What you suggest seems relatively benign. But it 
depends on exactly how we spin it, and how it ends up being used. Used 
wrong, it could result in huge and unnecessary difficulties in 
communicating.

If going this way I think we need at least a very generic "unstructured 
communications" type, and it SHOULD be used for all "regular" voice, 
video, and IM communications.

I am concerned that, e.g., MS will decide that its type is "MS-RTC" and 
then not talk to anything else. And lots of other implementations do 
likewise. If that happens, and maybe if it doesn't, it may be necessary 
to allow declaring multiple types for the same service instance.

What we don't need is gratuitous balkanization.

	Paul

> Brian

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

---

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

I understand the caution.  I certainly don't mind defining "telephony", and
"instant messaging" as services and encouraging their use whenever possible.

Brian

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Feb 2005 17:34:38 -0500

> "instant messaging" as services and encouraging their use whenever possible.

Hey, we're making some progress!

But I don't agree that "telephony" and "instant messaging" are different 
D3s. They are both "real time, unstructured, IP media communication", or 
something like that. The specific media involved are a separate dimension.

(RTUIPMC - much more convenient than "telephony" :-)

	Paul

>>>The magic document contains human understandable text that tells the
>>
>>reader
>>
>>>how the service works.  It probably also specifies what protocol
>>
>>mechanisms
>>
>>>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.
>>>
>>>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.
>>>
>>>I agree that:
>>>
>>>
>>>I would only add that you may need a document to create a high quality
>>
>>user
>>
>>>means, the client might.  The human that wrote the client code may
>>
>>interpret
>>
>>>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
>>
>>>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
>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 14 Feb 2005 03:36:12 -0500

Sorry for jumping into this thread late. Its an important one, and a 
topic we have touched on many times already.

I think that whether you need some kind of D3 indicator depends entirely 
on the answer to this question - "if a caller had no information on the 
service besides the prescaps information, would they be able to make a 
successful communications attemtp that did something sensible"?

In most cases, I think the answer is yes. In such cases, I don't think 
you gain much by conveying this parameter.

But then we have these anomaly cases like doom where, if you don't 
generate the SIP INVITE from your doom app, you're not going to get 
something that makes sense. If Doom has prescaps of audio and video, 
just connecting to it from my generic sip softphone is NOT going to do 
the right thing.

Thus, to me, this D3 flag feels more like an application launcher. If 
you click on that tuple in a presence document, the D3 value tells you 
what application on your PC to launch. In this case, it would launch the 
doom game.

That would argue for something that is a name bound to a registry, much 
like MIME types launch viewers on my PC.

If that parameter is not provided, then the URI scheme provides the 
indicator of what application to launch.

Thats why I don't think we need to define values for "IM" or "telephony" 
- those should work from a generic sip client.

-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: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Feb 2005 09:32:40 -0500

> you gain much by conveying this parameter.

I would go further, and propose that implementors should bend over 
backwards to make this be the case. Situations where it is not the case 
should be rare.

> just connecting to it from my generic sip softphone is NOT going to do 

That depends on how it is done. AFAIK there hasn't been any real 
engineering done on sip-for-doom, but based on the informal conversation 
we had on the subject in this thread, it seems plausible to me that just 
calling somebody's doom game from a regular phone could indeed provide a 
passable communications experience, even if not one the operator of the 
doom machine might prefer.

> like MIME types launch viewers on my PC.

That does seem like roughly what Brian is proposing.

> - those should work from a generic sip client.

I think this is just a matter of style in the way an optional attribute 
is handled:
- when the attribute is missing, a particular default value.
   The same effect can be obtained by specifying the default value.
- absence implies a certain default behavior. But there is no
   value for the attribute corresponding to the default behavior.

While I don't object to defaults, I tend to prefer the first approach, 
where the same behavior can be specified explicitly. But this is a 
matter fo taste.

What is more important is that the default behavior be the one used in 
the vast majority of cases.

	Paul

>> But I don't agree that "telephony" and "instant messaging" are 
>> different D3s. They are both "real time, unstructured, IP media 
>> communication", or something like that. The specific media involved 
>> are a separate dimension.
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Feb 2005 21:20:30 -0500

> you gain much by conveying this parameter.

There are two aspects to communication and to choosing communication 
options?

(1) Will the bits flow correctly? (Sound comes out of the speaker, video 
pops up, etc.)

(2) Will these bits make sense to the human?

By the principle that presence should reduce the surprise factor, 
knowing that clicking that SIP URL will connect to the sounds of machine 
gun fire and exploding monsters instead of a "hello" is a useful thing, 
in rather limited circumstances.

I fully agree that D3 should *never* be necessary for aspect (1). It 
should only facilitate a human to choose an appropriate communication 
service based on its content. Clearly, it is not necessary for the 
default human-to-human generic and unconstrained communication, i.e., in 
almost all cases.

I should note that information about whether a device is an answering 
machine (D2), for example, is not necessary to "make a successful 
communication attempt".

> what application on your PC to launch. In this case, it would launch the 

In most cases. In some cases, a generic application will work 
sufficiently well to be useful, e.g., if you just want to listen to the 
Doom background music or record a game session remotely.

> like MIME types launch viewers on my PC.

That was my example (game/doom), although I don't think the current MIME 
apps registry works as is.

> indicator of what application to launch.

Not necessarily. This can be a SIP URI.

> - those should work from a generic sip client.

I fully agree that there is no need for those.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Feb 2005 21:31:59 -0500

Paul Kyzivat wrote:

> backwards to make this be the case. Situations where it is not the case 

Fully agreed.

> doom machine might prefer.

There are other scenarios that prescaps can't quite capture, namely 
special media types and special event types. The D3 label can provide 
some hint that there might be more than classical audio and presence 
events involved. I can picture various scientific remote monitoring 
applications or even a home control application with PUB/SUB/NOT. 
Definitely the exception, however.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 16 Feb 2005 03:06:15 -0500

inline.

Henning Schulzrinne wrote:

>> I think that whether you need some kind of D3 indicator depends 
>> entirely on the answer to this question - "if a caller had no 
>> information on the service besides the prescaps information, would 
>> they be able to make a successful communications attemtp that did 
>> something sensible"?
>>

Right.

> 
> I fully agree that D3 should *never* be necessary for aspect (1).

We have, though, in the past, considered issues which could rightfully 
be issue (1) but are not yet covered by prescaps. In particular, cases 
where the caller has to support a particular non-standard behavior that 
may or may not even show up as an extension. For example, the OMA PTT is 
really a set of behaviors that aren't easily listed as an extension per 
se, but i will not be able to make a call from my xten phone to an OMA 
PTT client and get anything to work.

I have argued that these implementations aren't sip and shouldnt even 
use the sip URI. Rather, they should define their own URI schemes. There 
didnt seem to be consensus around that view though.

Stepping back for a moment, though, is this whole thing here something 
we feel needs addressing in the data model or rpid somewhere? I don't 
think that an "app launcher" attribute really changes the MODEL in any 
way; if we decide we want it or something similar it could be defined by 
a pidf extension as a new service attribute. I also don't think its 
something we should address in the current rpid. In that case, this 
discussion is interesting but not relevant for completing the work at 
hand unless someone can bring some requirements forward that demonstrate 
otherwise.

-Jonathan R.

---

From: Aki Niemi <[email-masked]>
Date: Wed, 16 Feb 2005 13:32:26 +0200

Sorry for jumping in late to this thread. I think this discussion has 
been productive.

Inline.

ext Jonathan Rosenberg wrote:
>>> In most cases, I think the answer is yes. In such cases, I don't 
>>> think you gain much by conveying this parameter.
>>
>>
>>
>> (1) Will the bits flow correctly? (Sound comes out of the speaker, 
>> video pops up, etc.)
>>
>> knowing that clicking that SIP URL will connect to the sounds of 
>> machine gun fire and exploding monsters instead of a "hello" is a 
>> useful thing, in rather limited circumstances.
> 
> 
> Right.
> 
>>

Non-standard is kind of a misnomer here. Surely you don't expect the 
feature set offered by SIP phones to remain static forever. SIP is not 
only voice and video, it can be used for rendezvous and session 
initiation of any medium, standard or non-standard. E.g., comedia gives 
tools for doing just that.

Still, I regard this business as usual. You calling my OMA PTT phone 
with an xten phone would probably fail, as it should. But that is a 
valid outcome of a session initiation attempt -- the phones didn't have 
a commonly supported medium to establish. The same would happen if I had 
a standard MSRP client that you happened to call with a voice-only 
softphone.

This only becomes a problem with presence, where you would want to know 
if this is likely to happen *before* the attempt is made. More on that 
below.

> didnt seem to be consensus around that view though.

I don't understand what is non-SIP about an INVITE-20O-ACK that 
establishes a session?

Rather, I think this is a problem caused because of the limitations 
imposed to us by PIDF, which has a rather simplistic view of what a 
contact element indicates. There a SIP contact indicates that the tuple 
is a SIP service, and presumably negotiation (that happens within SIP) 
will determine what type of service specifically will result by 
selecting that contact.

But to know beforehand, for any service (standard, non-standard, 
fictional, etc.), we would need some service-type indication that goes 
beyond the standard prescaps markup along with a "require-to-understand" 
flag, so that the watcher could determine whether it understands the 
service, and consequently decide whether even should even render the 
tuple to the user.

Surely defining a new URI scheme would hack around this problem in terms 
of representation in PIDF, but in more general terms it is exactly what 
we want to avoid. I don't want half a dozen or more URIs printed on my 
business card, vCard, web page or anywhere else. This is what we are 
currently faced with e.g., by having multiple IM systems, and we should 
not go there in SIP.

After all, we don't have a new URI scheme for MSRP for the purpose of 
sticking it in presence documents. Presumably, one would still initiate 
MSRP by calling a SIP URI, even though a voice-only phone would not 
accept the call.

> hand unless someone can bring some requirements forward that demonstrate 

I agree. The "app launcher" doesn't make or break the model, but the 
model has to accomodate such extensions that may be unknown to the 
composer. So assuming the existance of such unknown extensions, the 
composer MUST be allowed to pass tuples along intact, and the watcher 
MUST be able to handle this. I think this means "many tuples" instead of 
"single tuple".

Cheers,
Aki

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Feb 2005 08:29:18 -0500

Sorry for being away from this for a couple of days; busy on other things.

I was with Aki right until the end.  I think that we need a "service"
indication in the tuple to cover all of those things that are 
discussed that mean the difference between being able to predict 
whether a "call" will "succeed".  That's in the human sense; 
will I get what I expected to happen?  Presence is all about 
providing information to predict what will happen if you (a human) 
launch a session establishment request.  The result of presence is
not an INVITE.  The result is some kind of display to a human.
The human then makes a decision to initiate session establishment.
If he doesn't get what he expected, we've failed.

It is foolish, I think, to believe that you will always be able to 
make that kind of prediction within the limitations of prescaps and
similar mechanical things.  They may allow devices to have some kind
of media flow, but that isn't interesting.  What I want to know is
will it "work", that is, does it meet my expectations?

Multiple tuples won't answer the question.  We would have to make 
a large variety of capabilities we can individually 
define such that a specific set of them is unique enough that the human
believes that it "worked".  Even if that worked in the mechanical 
sense, there isn't any way to make that work in a presence system 
because we can't reasonably show the human what is happening; 
too much detail, not enough big picture.  We need a more abstract 
way to do that.

A name (with a registry) is the easiest thing I can think of that
will provide the human with the right sense.  If I say I'm "open"
for "Doom", then if your "Doom" client calls me, its going to work the
way I expect it will.  If your "Asheron" client calls me, it probably
wont.

Same for OMA PTT

Same for anything else.

Brian

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Aki Niemi
> Sent: Wednesday, February 16, 2005 6:32 AM
> To: ext Jonathan Rosenberg
> Cc: 'Simple WG'; Henning Schulzrinne

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Feb 2005 11:15:47 -0500

> will it "work", that is, does it meet my expectations?

I'm not buying this. I think it just means you are trying to avoid the 
work of understanding what it is that "won't work".

I do buy the value in describing the kinds of semantic content that I 
might experience - but that is not the same thing as "won't work". For 
instance if I want to talk to you, and a particular tuple will take me 
to a VM server or assistant, the call to that will "work" and provide a 
plausible call experience, but may not be what I desire.

> too much detail, not enough big picture. 

I'm not convinced of that. The individual capabilities MAY each be 
represented as an ICON. That may be great in some cases, or an 
overwhelming amount of detail in others. But a UA with limitied 
capabilities can bound this, not bothering to represent capabilities 
that it has no way of exploiting, and perhaps recognizing groupings of 
capabilities are are of note to it and representing them specially.

> We need a more abstract way to do that.

That just puts off a problem. We need to have some notion of how this is 
will be useful operationally.

> way I expect it will.  If your "Asheron" client calls me, it probably

I still don't get this. We went through several scenarios of how doom 
might be integrated with sip. The only plausible ones had a special 
protocol for control of game play, with other media simply being 
gratuitous. As long as there is a unique prescaps representation for 
each game protocol stream, one game will know what to look for to find 
another instance of the same game, and callers that support only the 
gratuitous media should get some kind of meaningful result.

> Same for OMA PTT

It is putting PTT into this category that bothers me the most. I want to 
know how, without any changes, that PTT would be represented in 
presence, what that would lead watchers to erroneously conclude, and 
what the end result would be.

If PTT is enough like regular voice that it could be mistaken as such by 
a watcher, then it seems to me that it would be far better for it to 
work in a degraded mode when one of the clients is a regular voice 
client. (E.g. maybe the regular voice client can't request the floor, 
and so is always in receive-only mode.) Worst case would be that the PTT 
uses a special codec that is not supported by normal voice clients. But 
that is no different than any case where there is no codec in common.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Feb 2005 14:15:53 -0500

> plausible call experience, but may not be what I desire.
Actually, I think that is part of the disconnect we are having.
The point of presence is to prevent this very thing.

I don't need presence if I call and maybe I get you and maybe I get
VM and maybe I get an assistant.  The point of presence is to tell you what
you will get.

.... 
> capabilities are are of note to it and representing them specially.
Yep, I understand that you think this is possible.  I don't.
Try to think of what it is that the icon would look like that would
show you the difference between, say, a PTT that was half duplex and another
that was full duplex.  Is that what you want to see?  

> will be useful operationally.
I don't agree that it pushes the problem off.  It recognizes that the
problem is so hard, that we will never solve it.  It offers a reasonable
way to deal with a hard problem.  We will invent services faster than we
will invent ways to classify services such that you can tell, from an icon,
whether two services are compatible enough that your expectation when you
initiate a session matches what you expected to happen.  A human isn't
bad at that sort of thing, and most are quick learners.  Presence systems
are unlikely to be good, and are very slow learners, unless you are
expecting the user to "score" the presence server after each session
attempt.

> gratuitous media should get some kind of meaningful result.
Maybe a poor example because the Doom game stream is different from the
Asheron game stream.  Maybe a better example is team Doom and solo Doom,
where the game stream is the same protocol, although used somewhat
differently, and the audio/video mechanisms are different.

> what the end result would be.
I'm sorry, I don't understand the question.  There are in fact several
variants of PTT.  While we may evolve to one winner and a bunch of losers, I
wouldn't hold my breath.  I'm sure some variants might be recognizable from
the prescaps, but I doubt it will work for all of them.

> that is no different than any case where there is no codec in common.
A human can decide to initiate a session when the services don't match.
That's up to him.  His expectation in that case would be shaped by his prior
experience.  If he had none, he would have low expectations - might work,
might not.  Next time, he would know - doesn't work, works okay, works
great.

Having the presence system try to intuit what that experience will be based
on things like prescaps is, to my way of thinking, crazy, and it won't
improve over time unless the programming team is kept very busy.  Too much
possible variation, and I don't WANT to see a lot of variables.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Feb 2005 17:58:42 -0500

> VM and maybe I get an assistant.  The point of presence is to tell you what

I think the disconnect is that there are a multitude of potential use 
cases out there. We are both trying to figure out how to describe them 
with some finite number of attributes. But we are disagreeing on what 
the dimensions are, and the kinds of attributes needed to describe them.

I think you are trying to declare a big "other" category with a single 
registry used to accumulate names for the cases. Henning and I, and I 
think Jonathan as well, agree that there is an "other" category, but 
include less in it than you do. There are more things that we think can 
be identified by other attributes.

I don't think that "voicemail", "attendant", "Doom", "Asheron", and 
"Acme-brand-PTT" are all just different "service types".

> that was full duplex.  Is that what you want to see?  

I don't know how to answer that, because I don't have the data about 
what id different about these things. I suspect some variants are just 
broken, and shouldn't be accomodated at all.

This seems no different than if Motorolla sip phones couldn't talk to 
Cisco sip phones. Should we just declare them to be different "service 
types" and write it off as an acceptable incompatibility?

> expecting the user to "score" the presence server after each session

It seems to me you are talking about *tunneling* of another protocol via 
sip and a set of negotiated media streams. As opposed to what sip is 
intended for, which is *initiating* protocols.

I am inclined to declare representation of that out of scope.

> Asheron game stream. 

Exactly.

> Maybe a better example is team Doom and solo Doom,

Bad design. They can find a better way to do it - different variants of 
the Doom protocol. But still orthogonal from other potential 
capabilities of the same endpoint.

For instance, I may not have a sip-enabled Doom machine anyway. What I 
may have is a sip-enabled game machine, that can support both Doom and 
Asheron, as well as voice. So I may well be able to see that, call from 
my comparable machine, using just voice, and discuss whether to play 
Doom or Asheron. When that is decided we just reinvite to initiate the 
proper protocol for game control.

> the prescaps, but I doubt it will work for all of them.

Maybe having some sort of rational integration with presence should play 
a part in which is the winner and which are the losers.

I would find it at least weird and annoying if every cell phone showed 
up as two distinct tuples - one for regular audio, one for PTT. Ever 
worse if there is yet another one for audio+video. Functionally they are 
just modalities, not different devices.

> possible variation, and I don't WANT to see a lot of variables.

I'm not suggesting that there be no difference in the descriptions of a 
PTT device and a regular voice device. But AFAIK PTT is a modality, or 
option. It ought to look like that.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Feb 2005 18:30:30 -0500

Aki Niemi wrote:

>> where the caller has to support a particular non-standard behavior 
>> that may or may not even show up as an extension. For example, the OMA 
>> PTT is really a set of behaviors that aren't easily listed as an 
>> extension per se, but i will not be able to make a call from my xten 
>> phone to an OMA PTT client and get anything to work.
> 

But "MSRP client" and "voice-only softphone" aren't "service types". I 
can have a device that does both MSRP and voice. Then both your "MSRP 
client" and your "voice-only softphone" can call it, and it can call 
them, successfully. If we made these all "service types" then their 
users would think they were incompatible. Or else they would have to 
know all the other service types they were compatible with.

We might just as well drop all presence capabilities in favor of just a 
single attribute which is the brand/model of the device. Then I can see 
that you have a Nokia-9999, while I have a Motorola-8888, and I can just 
"know" whether those are compatible. Yuck!

I am lacking data because I don't know much about your OMA PTT. What is 
there that can't be described with capabilities, assuming we can add 
additional capabilities if needed? Apparently it has an audio 
capability, but not one that will interwork with any other kind of 
device with an audio capability. If so, then I would conclude that it 
just doesn't have what the audio capability describes, so it shouldn't 
claim that. It has some other capability (e.g. ptt-audio), so invent 
that and use it like any other prescap.

>> use the sip URI. Rather, they should define their own URI schemes. 
>> There didnt seem to be consensus around that view though.
> 
> 

capabilities.

> currently faced with e.g., by having multiple IM systems, and we should 

I don't think I agree with Jonathan that this isn't sip. (Maybe if I 
knew more of the details I would.) But I think this isn't regular audio.

	Paul

>> way; if we decide we want it or something similar it could be defined 
>> by a pidf extension as a new service attribute. I also don't think its 
>> hand unless someone can bring some requirements forward that 
>> demonstrate otherwise.
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 16 Feb 2005 21:47:46 -0500

> PTT client and get anything to work.

Why precisely will this fail?

I would rather extend prescaps if it can't do the right thing now, i.e., 
describe composable protocol behavior elements rather than just lump 
everything into a label.

Labels are either:

(1) essentially a cop-out if there isn't structured data to describe the 
behavior in simpler terms - "you know it when you see it";

OR

(2) a reference to a set of structured data, where the point of the 
reference is to avoid including the description repeatedly.

(1) works reasonably well in the "app-launcher" case if there is 
essentially a single application that can deal with this. Doom is the 
canonical example.

(2) suffers from combinatorial explosion - I need to create a label for 
each new set of capabilities. In the degenerate case, it just becomes a 
URL or URN pointing to the description document.

> didnt seem to be consensus around that view though.

This is a separate topic. There are other more realistic examples that 
are probably closer, such as the earlier work on device control using 
message-like behavior, which combines possibly a new SIP method with 
PUB/SUB (and maybe INVITE, e.g., for a remote-controlled camera).

> hand unless someone can bring some requirements forward that demonstrate 

At best, this is an RPID issue, similar to the 'status-icon' mechanism 
that's already there.

One purpose of this discussion (for me...) was to see if we could 
distill a set of characteristics or needs into such a descriptor that I 
could characterize and delineate from existing descriptors in a 
paragraph that we could all understand. I don't think we're close enough 
to that.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Feb 2005 03:51:37 -0500

inline.

> Why precisely will this fail?

Others know OMA PTT better than I, but I'll take a stab.

The OMA client assumes that both sides support the floor control 
protocol they are using. It also assumes that PTT calls have passed 
through a network with specific topologies that invokes the PTT arbiter 
in the right places. There is nothing in the protocol messages that 
conveys the latter assumption. I am not sure if OMA is using SDP to 
signal the floor control.

I will note that, I believe that OMA may have defined a callee-cap that 
decalres OMA support, i.e., ";oma-v1.1=true" in order to allow caller 
prefs to route a call to a PTT phone instead of a regular SIP phone with 
the same AOR. That happens to play well with prescaps, where you more or 
less end up with the label Brian is asking for as a capability.

I've heard of other PTT implementations that use RTP tricks for floor 
control; in those models there is no new protocol to signal, just 
assumed behaviors that the PTT arbiter makes on the way in which the 
clients send RTP packets.

> describe composable protocol behavior elements rather than just lump 

To be frank, I think we are sorely missing requirements here. We can 
posit all kinds of theoretical applications that can or cannot be 
represented with prescaps. I would rather someone come to IETF and say, 
"hey, I want to use simple for my application but I can't do it in 
prescaps because of A,B,C". We are simply not seeing that now. Until we 
have that, this discussion is all interesting but theoretical.

> essentially a single application that can deal with this. Doom is the 

Or so we think. Since no one has come forward with requirements on using 
Doom we are just guessing. I'll also note that Half Life 2 is far better 
than doom and we should be considering that instead ;)

> PUB/SUB (and maybe INVITE, e.g., for a remote-controlled camera).

My argument here is based on the view that the whole point of a URI is 
that it provides complete context. You should be able to take a URI, 
pass it to an application that knows the scheme, and it should be able 
to invoke it and have the right thing happen. We are having proposed 
cases where that isn't the case, and its because the implementations are 
using SIP but are layering additional semantics and behaviors which make 
it distinctly non-SIP and break interop.

-Jonathan R.

---

From: Aki Niemi <[email-masked]>
Date: Thu, 17 Feb 2005 12:55:05 +0200

Inline.

ext Paul Kyzivat wrote:
>> initiation of any medium, standard or non-standard. E.g., comedia 
>> gives tools for doing just that.
>>
>> valid outcome of a session initiation attempt -- the phones didn't 
>> have a commonly supported medium to establish. The same would happen 
>> if I had a standard MSRP client that you happened to call with a 
>> voice-only softphone.
>>
>> This only becomes a problem with presence, where you would want to 
>> know if this is likely to happen *before* the attempt is made. More on 
>> that below.
> 
> 

I'm not sure I understand. My point was that in any case, you will have 
user agents, addressed by SIP URIs that don't share commonly supported 
communications medium. I don't think it makes any difference whether 
this medium is "standard" or "non-standard".

> "know" whether those are compatible. Yuck!

That's not what I'm talking about at all. Simply knowing about 
capabilities gives no indication of what the current availability or 
willingness of the presentity is regarding those capabilities.

> additional capabilities if needed? 

This is easy. For one, the OMA PoC client has more states than a simple 
on/off. It can be in Do-not-disturb mode, available mode, and 
session-active mode at least. I believe OMA has currently specified 
extensions to the <status> element that communicate these different 
statuses.

Secondly, an OMA PoC client can receive other SIP requests as well, 
i.e., MESSAGEs that I believe are either like off-line invitations to 
join a group, or alerts to say "please call back". Having said that 
though, this might be representable in prescaps as well, since those 
requests do have a special MIME type.

> Apparently it has an audio 

OMA already seems to have gone the other route, which means they have 
some sort of service-id element that indicates OMA PoC, including 
version. Howerer, this part *could* as easily be done using prescaps.

> knew more of the details I would.) But I think this isn't regular audio.

Agreed. For one, it requires a controlled floor, even in one-to-one 
sessions.

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Thu, 17 Feb 2005 13:17:54 +0200

Inline.

> signal the floor control.

I believe they do signal it in SDP. That is the sanest thing to do 
anyway, because when floor control is explicitly signaled, then you can 
also upgrade or change that protocol to something else in the future and 
clients can handle legacy gracefully.

> less end up with the label Brian is asking for as a capability.

Agreed. That solves the capability description needs.

> clients send RTP packets.

This is clearly not a desireable way to implement things. Something you 
can get away with in closed environments, but not in the real world.

Clearly in these cases, if everything is based on assumptions, then 
using a SIP URI makes no sense either.

>> I would rather extend prescaps if it can't do the right thing now, 
>> i.e., describe composable protocol behavior elements rather than just 
>> lump everything into a label.
> 
> 

I've tried, several times. Let me try again.

The requirement from my point of view is: One needs to be able to 
indicate finer grained status for a "service" than a simple on/off. 
Capabilities can only go as far as indicating on/off status, but that's 
not enough.

For example, even with a "game/doom capability", you'd still need to be 
able to indicate things like whether you're hosting, in deathmatch, 
idle, or practicing at the moment. Each state would be represented to 
the user in the form of a different icon, for example, all very much 
dependant on the "service".

But again, we don't need to define anything except to say that such 
extensions (I believe D3 in Henning's terminology) may exist, and 
probably should go under the <status> element.

The only thing where the model is affected is that if you have two 
tuples that have the same extension that is unknown to the composer, but 
known to the watcher, and one has value foo and one has value baz, the 
composer *cannot* merge the states (tuples) because it doesn't know 
whether to choose foo, baz, or put both in.

...snip...

> to invoke it and have the right thing happen. 

What do you mean by "invoke it"? Do you mean a voice call, a video call, 
or what? And what do you mean by "the right thing"? Is receiving a 415 
such a case?

> We are having proposed 

You may have a different example in mind, but adding new media in SDP 
IMHO doesn't constitute layering additional semantics to SIP, but to 
SDP, and I can't see that having anything to do with whether SIP can be 
used to offer such SDP or not.

Cheers,
Aki

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 17 Feb 2005 09:03:29 -0500

> Capabilities can only go as far as indicating on/off status, but that's 

If I understand you correctly, this is much more closely related to 
activities than to a capability.

> dependant on the "service".

The game state indication seems like a natural extension to the 
'activities' element in RPID. This, along with other RPID element, 
provides context to the open/closed  status and thus qualifies it to the 
watcher.

RPID already has a 'status-icon', which seems rather close to what 
you're proposing.

> probably should go under the <status> element.

I don't think this is a capability necessary to ensure connectivity 
(which is what I meant D1 through D3 to describe at various layers).

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 17 Feb 2005 09:23:17 -0500

> extensions to the <status> element that communicate these different 

Just to highlight this, as it seems hint at the source of the confusion: 
We seem to be talking here about two different indications:

(1) relatively static capabilities (Brian's labels, my D1-D3) that 
indicate how to get the bits flowing and what they might mean. This is 
the domain of prescaps, for example.

(2) the state of a device, elaborating beyond the simple "is available 
for communication or not". RPID <status> extensions, not prescaps, are 
the responsible for that type of information.

For extensions to (2) which are not currently handled by RPID, we need 
to decide in each case whether they describe activities of the person, 
for example, or are device-specific or service-specific state.

Henning

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Feb 2005 10:04:05 -0500

Aki,

I think I have been lumping together your arguments and Brian's, and 
arguing against that combination. It now is becoming more evident to me 
that the two of you don't have the same position. So I apologize if I 
attributed something incorrectly to your position.

More inline.

	Paul

Aki Niemi wrote:
>>> feature set offered by SIP phones to remain static forever. SIP is 
>>> not only voice and video, it can be used for rendezvous and session 
>>> know if this is likely to happen *before* the attempt is made. More 
>>> on that below.
>>

This argument should have been addressed to Brian. Perhaps you and I do 
not disagree here.

>> We might just as well drop all presence capabilities in favor of just 
>> a single attribute which is the brand/model of the device. Then I can 
>> see that you have a Nokia-9999, while I have a Motorola-8888, and I 
>> can just "know" whether those are compatible. Yuck!
> 

Here I think we may differ. And it is a point worth discussion.

Lets assume for a moment that I have a softphone with capability for 
voice, video, and MSRP. But it has a bunch of controls in its UI that 
enable/disable each of the media. If I am in a meeting I might disable 
voice and video but leave MSRP enabled. If I am doing something 
graphically intensive I may disable MSRP. And if I am in my underwear I 
may disable video.

How does that affect presence?

I think that as I change these settings, my presence capabilities will 
also be changed. So while I am in that meeting with voice and video 
disabled, the tuple describing this softphone will show that it is open, 
and capable of msrp, but not capable for voice or video. And when the 
meeting is over that one tuple will get updated, indicating that it is 
open and capable of MSRP *and* voice and video.

>> I am lacking data because I don't know much about your OMA PTT. What 
>> is there that can't be described with capabilities, assuming we can 
>> add additional capabilities if needed? 
> 

OK. There is a subtle line between capability and status. As you say, we 
have other forms of status. It seems like there is sufficient 
expressiveness here for PTT, and if not some small addition should deal 
with it.

> requests do have a special MIME type.

These MESSAGEs are not content that is displayed to the user - but 
rather are a way to tunnel some other proprietary signaling protocol?

This probably requires further discussion if we are to achieve a 
meaningful and open representation of presence.

>> Apparently it has an audio capability, but not one that will interwork 
>> with any other kind of device with an audio capability. If so, then I 
>> would conclude that it just doesn't have what the audio capability 
>> describes, so it shouldn't claim that. It has some other capability 
>> (e.g. ptt-audio), so invent that and use it like any other prescap.
> 

Well then, maybe I appologized too soon. This is exactly what I was 
complaining about. If 'audio' capability is being advertised, but it 
will only interwork with the audio of those who have the 
'OMA-PoC-inside' sticker, then I think they are non-standard, regardless 
of how you encode the sticker.

If that is the way it has to be, just lose the claim of support for 
audio. (More - explicitly state that audio is *not* supported.) Then 
people won't be deceived.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Feb 2005 16:53:26 -0500

inline.

Aki Niemi wrote:

>> through a network with specific topologies that invokes the PTT 
>> arbiter in the right places. There is nothing in the protocol messages 
>> that conveys the latter assumption. I am not sure if OMA is using SDP 
>> to signal the floor control.
> 
> 

Right. The issue that makes it non-SIP in this regard is that there is 
no fallback if that SDP stream is not present in the INVITE request.

> 
>> I will note that, I believe that OMA may have defined a callee-cap 
>> that decalres OMA support, i.e., ";oma-v1.1=true" in order to allow 
>> caller prefs to route a call to a PTT phone instead of a regular SIP 
>> phone with the same AOR. That happens to play well with prescaps, 
>> where you more or less end up with the label Brian is asking for as a 
>> capability.
> 
> 
>> represented with prescaps. I would rather someone come to IETF and 
>> say, "hey, I want to use simple for my application but I can't do it 
>> in prescaps because of A,B,C". We are simply not seeing that now. 
>> Until we have that, this discussion is all interesting but theoretical.
> 
> 

What I mean is, folks keep talking about doom and other random apps that 
don't actually get signaled with SIP, and for which we don't have anyone 
that really implementing them. We do appear to have a concrete app in 
the form of OMA PTT.

> indicate finer grained status for a "service" than a simple on/off. 

Umm, isnt that what RPID is for?

> dependant on the "service".

Sure, so go ahead and bring some requirements forward about states you 
want to see in Doom. What part of the model doesn't support this?

> probably should go under the <status> element.

I fear there is some perception here that the data model is saying that 
presence states aren't extensible. I don't know what in the document 
would convey that impression though.

> whether to choose foo, baz, or put both in.

This is fodder for the presence processing draft that I just submitted 
(which is basically the tail end of the former data model draft). It 
needs to address merging rules for unknown attributes. That is a 
reasonable thing. However, there are problems. If the compositor doesnt 
know the extension, the only outputs it can produce which have a chance 
of being compliant to that extension are to pick one. I don't think it 
can put both in, since the schema may not allow it.

> or what? And what do you mean by "the right thing"? Is receiving a 415 

Invoke it means that any remaining context is derived from local 
information. In the case of SIP, you would include the full set of media 
capabilities that the user had set as the default to use.

Same is true for http. If I get an http URI, I can "invoke it". The 
browser might include extra headers, cookies for example, or 
Accept-Content or whatever, based on local information, but no 
additional data is needed about the remote side to connect.

> 
>> We are having proposed cases where that isn't the case, and its 
>> because the implementations are using SIP but are layering additional 
>> semantics and behaviors which make it distinctly non-SIP and break 
>> interop.
> 
> 

See above on fallback behavior.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Feb 2005 18:50:32 -0500

Trimming - only want to comment on one point.

	Paul

Jonathan Rosenberg wrote:

>> tuples that have the same extension that is unknown to the composer, 
>> but known to the watcher, and one has value foo and one has value baz, 
>> the composer *cannot* merge the states (tuples) because it doesn't 
>> know whether to choose foo, baz, or put both in.
> 

Perhaps we need to create a special <ambiguous> element, whose only 
purpose is to contain unreconciled conflicts.