[Jingle] Jingle bits

Peter Saint-Andre stpeter at stpeter.im
Sun Jul 27 22:31:55 CDT 2008

Robert McQueen wrote:
> Most of this is pretty minor...
> XEP-0166 Section 5/Table 2:
> • In content-add and content-replace, what does it mean to "ignore"
> actions received from the other party? Drop on the floor, return an
> error, ack but do nothing? Certainly if each content is uniquely
> identified by (creator, name), there's no problem with two adds taking
> place simultaneously, or other stuff like transport-info or
> content-modify on other contents, etc.
> • content-modify can probably be sent in reply to an unacceptable
> content-modify, you just have to not reply twice, or something... :D
> • The documented handling of two crossing over "content-replace" actions
> is broken - both ends can't just ignore it. I suggest the initiator-wins
> tiebreak, so when the initiator gets a content-replace for a content he
> was trying to replace, he responds with an error saying he was already
> doing it, and the responder discards his proposed replacement if he gets
> one from the initiator, and ignores the error.

I'll review these rules soon.

> • use of the wording "content type" in section 5 is misleading, each
> content-* action is just for one content in the session (ie, you can
> have >1 instance of a type in a session)

I suppose you can, yes.

> Other XEP-0166 stuff:
> • 6.4 - removing streams when the session is pending is OK
> • 7.2 - emphasise that the name is unique for the creator


> • 7.3 - is <condition> really necessary, 

No, it's not. I'll remove that layer of indirection.

> and can't the reason-specific
> fields (eg <sid>) be a child of that reason?


> • condition list in schema is incomplete

AFAICS, only <alternative-session/> is missing. Correct?

> XEP-0167
> • 9.2 - stun checks should be marked as === out of XMPP


> • get rid of profile! 


> example 9.4 seems pretty half-baked, if you want
> to add security to the RTP session, add an element which can be included
> under the RTP <description> with the security information *or* as some
> <transport> which adds it, but it should be signalled one way or the other.

I removed that entire section.

> • not sure I need to be acknowledged as well as an being listed as an
> author? :D


> XEP-0176
> • 5.1 - stun checks should be marked with === too?
> • examples have profile= in <content>


> • 5.7 - replace doesn't have <description> is, but the reply does. maybe
> "transport-replace" is less scary?

Yes, will fix in line with XEP-0166.

> XEP-0181
> • why does this exist? it's less interoperable than proper RFC 4733
> events, and has all sorts of timing ambiguity - signalling path
> differing from streaming path, so you push buttons, keep talking, then
> the other end gets your DTMF XML 2 seconds later, and plays over your
> speech... I don't really understand why we don't just say "use telephone
> events" in the RTP XEP.

See separate thread.

> XEP-0234

This one needs quite a bit of work to bring it in line with our 
discussions in Portland.

> • 2 - show non-XMPP content as ===?
> • example 1 - do we need another level of <offer> below <description>?
> the action should imply it correctly.
> • 3.1 I really don't like the implication that >1 content of the same
> type is for the purpose of transport fallbacks, it seems at odds with
> multi-content calls. duplication of file description seems bad too.


> • example 11 - content remove shouldn't have all the stuff in it
> • example 23 - surely this can be ~empty too?
> • example 27 - describes the wrong file offer...?

I'll clean up XEP-0234 (etc.) soon and then publish revised versions of 
all the Jingle specs.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/jingle/attachments/20080727/42c7dc0f/attachment-0001.bin 

More information about the Jingle mailing list