[Jingle] Rebooting XEP-298: Delivering Conference Information to Jingle Participants (Coin)

Ben Langfeld ben at langfeld.co.uk
Wed Jul 17 12:30:59 UTC 2013


A minor one from me on first pass:

For SIP endpoints you are providing a full URI:

<endpoint entity="sip:4kfk4j392jsu at example.com;grid=433kj4j3u">

For XMPP (Jingle) you're not:

<endpoint entity="juliet at capulet.lit/balcony">

though you are including the scheme in the <user/> element.

Is there any good reason for leaving the scheme out of endpoint#entity?
This is specified as a string, but I can't help think it should be anyURI:

<xs:attribute name="entity" type="xs:string"/>

Ben

On 9 July 2013 04:10, Saúl Ibarra Corretgé <saul at ag-projects.com> wrote:

> Hi Philip,
>
>
> > Quick feedback (based on the example in section 6):
> > - <conference-description/> is basically the MUC topic. I suppose that
> if jingle were <message/> based you could even pull it out of the jingle
> element.
> >
>
> We will add a reference to
> http://tools.ietf.org/html/draft-ivov-grouptextchat-purpose-03, which
> says how to indicate a related MUC to a Jingle conference, so assuming a
> MUC is also taking place, the focus could pull in the subject.
>
> > - <users/> is going to hit the maximum stanza size rather quickly. In
> MUC i would deliver that (in particular: src-ids) with the individual
> participants <presence/> elements and collate when receiving the code=110
> presence. (this might even work nicely with the "PLAN B" stuff)
> >
>
> RFC4575 specifies how to use partial notifications:
> http://tools.ietf.org/html/rfc4575#section-4.4
>
> > It seems the example is not even valid xmpp because it iq has two
> children (the fact that google does <jingle/> and <session/> does not make
> this valid :-)). Example 5 has the conference-info as child of jingle, I
> suppose that is the plan here as well.
> >
>
> Oh, we need to fix that :-S There are 2 different things going on here:
> the 'conference' element, set by the focus (in the jingle stanzas) to
> indicate that she is acting as a mixer and the 'conference-info' payload
> (rfc4575) which carries the participants information. The information about
> participants is not necessarily bound to Jingle, we added the jingle
> element to add a reference to the session so that clients can track to what
> sesion the payload belongs. Since the rfc4575 schema allows for extensions,
> I'll probably put the jingle element with the session id inside the
> conference-info payload, thus making it valid XMPP.
>
> >
> > The design of not using MUC bothers me for a number of reasons...
> > (but I can't allocate the time necessary for writing up how I would do
> it instead :-/). The major advantage of this approach is that is maps
> easily to RFC 4579, eh?
>
> We will add some text on how this interacts with MUC hopefully soon. 4579
> is the application of 4575 to SIP conferencing, this is the XMPP
> equivalent, in a way.
>
>
> Thanks a lot for the feedback!
>
> --
> Saúl Ibarra Corretgé
> AG Projects
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jingle/attachments/20130717/7059613a/attachment.html>


More information about the Jingle mailing list