[Standards-JIG] Jingle schema extensibility
jean-louis.seguineau at laposte.net
Mon Apr 3 17:52:23 UTC 2006
Joe, I am in agreement with what you said. My question was related to the
notion of channel. Now that we have de-coupled the various pieces session,
media description and transport, am I right in saying that channel is linked
to transport? If this is the case, then do you think it possible to have a
common approach for all transports types were the name of the channel would
be always declared the same way?
>From your answer, I have the feeling this is not the case. How then can we
ensure channels are properly named?
Date: Mon, 3 Apr 2006 09:40:00 -0700
From: "Joe Beda" <jbeda at google.com>
Subject: Re: [Standards-JIG] Jingle schema extensibility
To: "Jabber protocol discussion list" <standards-jig at jabber.org>
<dbfdfee20604030940n5c9c0a29naf1fe420bd760114 at mail.google.com>
Content-Type: text/plain; charset="iso-8859-1"
My thinking is that a channel has a name associated with it. It is up to
the session type to define the streams to be used and push data over them.
It is up to the transport to provide a way to move that data from one peer
to another. While most of the transports so far use something like a
<candidate/> element to define a channel (or a possible route for a channel)
this isn't necessary for all transports.
For example, for JEP-0177, it might make more sense to have a <channel/>
element under the transport instead of <candidate/> since there is one and
only one choice.
On 4/2/06, Jean-Louis Seguineau <jean-louis.seguineau at laposte.net> wrote:
> JEP-166's glossary describes a channel as a 'named way to get information
> between the endpoints...' From the rest of the description I am under the
> impression that a channel is linked to the transport of a media type.
> In effect, from the various transport JEPs, it appears that the common
> practice id to have a <candidate/> element as a child of a <transport/>
> element. And the name attribute is described as required for most all of
> them except JEP-179.
> This is just an example of potential interpretation issues. Couldn't we
> include additional schema definitions in JEP-166 describing the mandatory
> attributes of <transport/>, <candidate/> and <description/> in addition to
> open extensibility (xs:any)?
> The idea is not to indicate that, if these <transport/>, <candidate/> and
> <description/> are to be used in their respective application context,
> they must provide a minimum required information. We could do this in high
> level JEPs for media description and transport, but it seems adequate to
> JEP-166 for this.
More information about the Standards