[Jingle] Jingle bits

[Peter Saint-Andre]

A few more notes...

Peter Saint-Andre wrote:
> 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.

Fixed.

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

Fixed.

>> XEP-0167

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

But, per our discussions in Portland, I added support for SRTP. :)

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

I'm going to publish updated versions of XEP-0166, XEP-0167, and 
XEP-0176 before turning my attention to XEP-0234.

/psa


-------------- 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/20080731/a67d092a/attachment.bin