Subject: RE: [Simple] Change to prescaps XML schema

From: [email-masked]
Date: Fri, 15 Oct 2004 15:41:23 +0300

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. This UA can host one or multiple service. 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. Also as we have more expression power in XML I think we should take advantage out of that. 

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.

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

We remove the <type> element. I think we have agreed this before but for some reason it is still there.

what do you think?
- Mikko   

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 14 October, 2004 02:10
> To: Goix Walter
> Cc: Lonnfors Mikko (Nokia-NRC/Helsinki); [email-masked]
> Subject: Re: [Simple] Change to prescaps XML schema
> 
> 
> Walter,
> 
> These were designed to align with the capabilities in 
> callee-caps. They 
> have the same definitions. There is plenty of opportunity to create 
> other capabilities, but I would like to see the callee-caps 
> mapped in a 
> direct way.
> 
> 	Paul
> 
> Goix Walter wrote:
> >>Service schema:
> >><audio>
> >><video>
> >><application>
> >><control>
> >><text>
> > 
> > How would you define support for msrp? A <message> element could be
> > fine. But then you may also need to add support for other 
> SDP medias,
> > like "image" or others. Wouldn't be a <medias> / <media> 
> hierarchy more
> > flexible?
> > E.g. 
> > 	<medias>
> > 		<media>audio</media>
> > 		<media>video</media>
> > 		<media>message</media>
> > 	</medias>
> > 
> > 
> >><type>
> > 
> > Some content types are only allowed in specific services, which are
> > related to specific methods and extensions...Some 
> multimedia types can
> > be supported in MESSAGE or mrsp but not in INVITE, while 
> NOTIFY allow
> > other content types, perhaps different based on the type of 
> event...In
> > some cases, splitting caps in multiple tuples may work but 
> you may get
> > an explosion of the number of tuples. Is there any way to 
> express a raw
> > set of prescaps and combine them into bundles, wchi can be 
> gathered into
> > the same tuple?
> > 
> > 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
> > ====================================================================
> > 
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> > 
> 
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Oct 2004 15:33:17 -0400

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.

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.

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.

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

I don't see the distinction. If they both apply to a tuple, what is 
differnet?

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

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

> We remove the <type> element. I think we have agreed this before but for some reason it is still there.

I don't remember.