Subject: [Simple] Change to prescaps XML schema

From: [email-masked]
Date: Wed, 13 Oct 2004 13:23:27 +0300

Hi,

Here is a proposal to change current XML schema defined for prescaps. Intention is to align this work with the latest presence data model.
At a moment all prescaps attributes are defined in a single schema. Proposal is to spilt XML schema  into tree parts: person, service, and device. Below is the list how I think prescaps elements should be divided. This is my first iteration on this so please check the list and comment if you notice something strange.

Device schema:
<mobility>
<description>
<priority>

Person schema:
<description>
<languages>

Service schema:
<audio>
<video>
<application>
<control>
<text>
<type>
<automata>
<class>
<duplex>
<description>
<event-packages>
<priority>
<methods>
<extensions>
<schemas>
<actor>
<is-focus>
<languages>

- Mikko

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

---

From: "Dag Ekengren" <[email-masked]>
Date: Wed, 13 Oct 2004 13:25:37 +0200

Hi,

I have a small suggestion, which actually has nothing to do with the
splitting of prescaps attributes.

I would like to be able to express that (for a service) audio is full
duplex and video is half duplex.

Let me give an example:
* A PC has a softphone with audio and video capabilites
* The user has not yet plugged in a camera

The softphone will be able to send and receive audio but only receive
video. If I understand the prescaps draft correctly, this is not
possible to express. Either the whole service is full duplex or half
duplex.

Thanks,
Dag

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: den 13 oktober 2004 12:23
>To: [email-masked]
>Subject: [Simple] Change to prescaps XML schema
>
>Hi,
>
>Here is a proposal to change current XML schema defined for prescaps.
>Intention is to align this work with the latest presence data model.
>At a moment all prescaps attributes are defined in a single schema.
>Proposal is to spilt XML schema  into tree parts: person, service, and
>device. Below is the list how I think prescaps elements should be
divided.
>This is my first iteration on this so please check the list and comment
if
>you notice something strange.
>
>Device schema:
><mobility>
><description>
><priority>
>
>Person schema:
><description>
><languages>
>
>Service schema:
><audio>
><video>
><application>
><control>
><text>
><type>
><automata>
><class>
><duplex>
><description>
><event-packages>
><priority>
><methods>
><extensions>
><schemas>
><actor>
><is-focus>
><languages>
>
>- Mikko
>

---

From: [email-masked]
Date: Wed, 13 Oct 2004 14:41:44 +0300

Hi,

inline

> possible to express. Either the whole service is full duplex or half

Yes, that is correct. Basically this 'limitation' comes from caller preferences because prescaps draft tries be very close to the model presented in caller preferences. This is why you can now only specify duplex for a whole contact. However, in presence it actually might make sense to be able to specify different duplex modes for different medias in a single tuple. 
Other way to solve this could be to split the service into multiple tuples which map into single device (softphone). One tuple would have full duplex audio and other one half duplex video.  

- Mikko

---

From: [email-masked]
Date: Wed, 13 Oct 2004 14:56:58 +0300

Hi, 

See at the bottom.

> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext [email-masked]
> Sent: 13 October, 2004 14:42
> To: [email-masked]; [email-masked]
> Subject: RE: [Simple] Change to prescaps XML schema
> 
> 
> Hi,
> 
> inline
> 
> > Hi,
> > 

In this case video is not even half duplex but simplex into one direction. The question is whether we can ever get to this kind of detail within presence. On this list I have seen people saying that details such as supported codecs etc. are outside the scope of presence and will be negotiated with SDP once the session establishment is in progress. You can similarly find out the limitation you explain below through SDP.

But the main point I wanted to say was that instead of half-duplex the correct way would be defining something like "receive-only". 

> Yes, that is correct. Basically this 'limitation' comes from 
> caller preferences because prescaps draft tries be very close 
> to the model presented in caller preferences. This is why you 
> can now only specify duplex for a whole contact. However, in 
> presence it actually might make sense to be able to specify 
> different duplex modes for different medias in a single tuple. 
> Other way to solve this could be to split the service into 
> multiple tuples which map into single device (softphone). One 
> tuple would have full duplex audio and other one half duplex video.  
> 

That's not right either, since the service capability is really the combination of those two medias, and there are no two separate services, as that kind of tuple splitting would suggest.

> - Mikko

Markus

---

From: [email-masked]
Date: Wed, 13 Oct 2004 15:42:08 +0300

> In this case video is not even half duplex but simplex into 
> one direction. The question is whether we can ever get to 
> this kind of detail within presence. On this list I have seen 
> people saying that details such as supported codecs etc. are 
> outside the scope of presence and will be negotiated with SDP 
> once the session establishment is in progress. You can 
> similarly find out the limitation you explain below through SDP.

Right. As <duplex> is defined right now it applies to *all* media elements like <voice>, <video> and etc that are listed in a tuple. Now the question is does that make sense? If it doesn't then we have two option: remove it altogether or define it so that it can appear under media (voice,...) elements.
 
> But the main point I wanted to say was that instead of 
> half-duplex the correct way would be defining something like 
> "receive-only". 
> 
> That's not right either, since the service capability is 
> really the combination of those two medias, and there are no 
> two separate services, as that kind of tuple splitting would suggest.

Yes, I think you are right.

- Mikko

---

From: Goix Walter <[email-masked]>
Date: Fri, 15 Oct 2004 15:43:27 +0200

[snip]

So below is a proposal how to fine-tune prescaps to fit into service model. Still, I don't think we should be moving any SDP negotiation properties into presence documents i.e. adding individual medias under methods where they may be supported. 

[walter] I agree. I don't think we should go into more detailed description at media level (e.g. codecs). My suggestion was a content-type/method association, but i would prefer not to have it described as you propose rather than having a list of types, which i cannot associate with methods

[snip]

Elements:
<audio>
<video>
<application>
<control>
<text>

apply to whole service tuple i.e. it is not possible to model individual media capabilities per service if the service tuple contains multiple services. In addition to this I would propose that we add new media feature tag: <message>. Without this there is really no way for a watcher to guess that MSRP is supported.

Duplex seems to be an attrinute of a media. For this reason I think we should include it as a parameter into all media elements like this:

<audio duplex="full">true</audio>.

[walter] sounds reasonable to me. It may also be useful to further describe the "application" element with a "format" attribute (not in a/v for codecs), since the information it provides cannot directly be interpreted as a capability, since the "m=application" line can be used in a variety of contexts (e.g. PoC, wb, etc.) which are significantly different.

walter

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================

---

From: [email-masked]
Date: Mon, 18 Oct 2004 10:40:36 +0300

Hi Paul,

Inline:
> Mikko - see inline comments.
> 
> 	Paul
> 
> [email-masked] wrote:
> > Hi,
> > 
> > Actually now that I think this little bit more I think we may need
>  > to revisit this thinking. Callee-caps is defined to convey 
> capabilities
>  > of the user agent. This means user agent as a whole.
> 
> I think that depends on what you mean by UA.
> If by UA you mean "the thing that uses this particular 
> contact address", 
> then I agree.

Then we agree.

> If you mean "a device" (like a phone) then I disagree.
> 
> The callee caps are associated with a single contact address 
> that is in 
> turn associated (via registration) with a single AOR. The same device 
> may have other contacts bound to the same or different AORs, and the 
> same AOR may have contacts that are bound to other devices.
> 
>  > This UA can host one or multiple service.
> 
> By the definition we have begun to use in the presence data 
> model this 
> is may not be true. The service is defined by a tuple with a contact. 
> Jonathan wants to require the contact of each service to be 
> unique. In 
> that case this isn't true.

Yes, in a sense that single tuple represents a single service for a watcher. But for example a PS may have merged multiple service into a single one during the composition process.

> There is also an unresolved debate on this subject. There are two 
> potential ways that have been suggested where multiple tuples might 
> share a contact:
> - competing views of the *same* service
> - different services sharing the same contact
> 
> Sidestepping the issue of the term "service", I think we *eventually* 
> want to support the OR-of-ANDs of capabilities that can be 
> obtained at a 
> contact address. But I don't see pressure to solve this problem 
> immediately. Its solution may result in multiple tuples with the same 
> contact, or it may be solved some other way.
> 
>  > As presence data model is now defined the closest thing to UA is
>  > the service (tuple) element. But the definition of the 
> service doesn't
>  > exactly match to the definition of a UA.
> 
> I don't think introducing this term into the discussion helps 
> - it just 
> seems to add more confusion.
> 
>  > Also as we have more expression power in XML I think we should take
>  > advantage out of that.
> 
> I think we should take advantage of this, but at the same 
> time, I would 
> like a well defined mapping between callee-caps and a set of elements 
> defined in prescaps.

sure

> This doesn't mean that prescaps can't have added elements 
> that don't map 
> to callee-caps, both as entirely new capabilities and as 
> added elements 
> of the existing capabilities. But when modifying the existing 
> capabilities, we should keep in mind the desired 
> relationship, and do no 
> harm to it.
> 
> > So below is a proposal how to fine-tune prescaps to fit 
> into service model.
>  > Still, I don't think we should be moving any SDP 
> negotiation properties
>  > into presence documents i.e. adding individual medias 
> under methods where
>  > they may be supported.
> > 
> > Elements:
> > <automata>
> > <class>
> > <description>
> > <event-packages>
> > <priority>
> > <methods>
> > <extensions>
> > <schemas>
> > <actor>
> > <isfocus>
> > <languages>
> > 
> > apply to whole service tuple regardless how many services 
> is models. It may be that some of these mainly make sense if 
> you are modeling a single service or that you should only 
> combine services which have certain common characteristic 
> (class, automata, actor, isfocus). 
> > 
> > Elements:
> > <audio>
> > <video>
> > <application>
> > <control>
> > <text>
> > 
> > apply to whole service tuple i.e. it is not possible to 
> model individual media capabilities per service if the 
> service tuple contains multiple services. In addition to this 
> I would propose that we add new media feature tag: <message>. 
> Without this there is really no way for a watcher to guess 
> that MSRP is supported.
> 
> I don't see the distinction. If they both apply to a tuple, what is 
> differnet?

Well, as I started to write this is imagined that there would be some differences. Now it seems that there isn't.

> > Duplex seems to be an attrinute of a media. For this reason 
> I think we should include it as a parameter into all media 
> elements like this:
> > 
> If this is done, what will you do about compatibility with 
> callee-caps?
> 
> I see three possibilities:
> - leave things as they are, with duplex separate from media
> - make this change. Specify that in mapping from callee-caps
>    the duplex setting is applied to each and every media.
>    (This is still a problem if no media are specified.)

Do you think that mapping between callee-caps <-> prescaps will only unidirectional? If it is bi-directional then this may actually be even harder because prescaps could have:
<audio duplex="full"/>
<video duplex="half"/>
and how do you map this into callee-caps.
After this I think that it may be better to leave definition of duplex as it currently is.

> - make this change, but leave the separate capability as well.
>
> While I don't think duplex is well defined, I don't think we 
> are ready 
> to fix it properly. (Which may mean going back into 
> callee-caps.) So I 
> think for now best thing is to leave things as they are.

One issue here is that if something is fixed in callee-caps it doesn't mean that fix automatically transfers to prescaps. If you want to have callee-caps modifications in prescaps you have to do changes into prescaps. So, I think that if we can fix something in the scope of prescaps we should do it already now.

> > We remove the <type> element. I think we have agreed this 
> before but for some reason it is still there.
> 
> I don't remember.
> 
At some point there was email discussion about this but now that I check it seems that it really didn't conclude. I can keep <type> in.

- Mikko