[Standards] Resuming after or before binding?

[Jefry Lagrange]

Hi! I'm implementing XEP-198, and it says that negotiation is done
only after authentication and binding, which is fine. But at the time
of resumption I don't know if I should start it after authentication
and binding or only after authentication. The document at
http://xmpp.org/extensions/xep-0198.html is not very explicit about
it.

Thanks.


--
Jefry Lagrange



-- 
Jefry Lagrange

[Standards] NEW: XEP-0298 (Delivering Conference Information to Jingle Participants (Coin))

[XMPP Extensions Editor]

Version 0.1 of XEP-0298 (Delivering Conference Information to Jingle 
Participants (Coin)) has been released.

Abstract: This specification defines an XMPP extension for tightly coupled
  conference calls. It allows users who participate in multiparty Jingle
  calls via a focus agent (mixer) to retrieve information and receive
  notifications about the state of the call and the other participants.
  This extension is also meant to provide a straightforward way of
  connecting SIP and XMPP clients to the same conference room.


Changelog: Initial published version. (psa)

Diff: N/A

URL: http://xmpp.org/extensions/xep-0298.html

Re: [Standards] hash agility in file transfer

[Peter Saint-Andre]

On 6/1/11 4:55 PM, Waqas Hussain wrote:
> On Thu, Jun 2, 2011 at 3:26 AM, Peter Saint-Andre  wrote:
>> Last year we had some discussions about hash agility in file transfer,
>> as a result of which I made an interim version of XEP-0096:
>>
>> http://xmpp.org/extensions/diff/api/xep/0096/diff/1.1/vs/1.2rc1
>>
>> However, it seems that the XMPP Council never considered publication of
>> that version. Do folks on the list think we need to do anything more
>> than what's at that diff?
>>
>> (And yes, we might need to look at hash agility in other extensions,
>> too, but we started with file transfer...)
>>
>> Peter
>>
> 
> This way of going about hash agility has the same issue as the entity
> caps hash's agility. You can only serve one hash, and you have no idea
> what hashes the recipient supports. Senders would forever be stuck
> with sending MD5, because doing otherwise will not be interoperable
> with existing recipients, unless all clients were updated. The interop
> failure case is quite severe, with the user possibly getting a prompt
> that the transferred file is corrupted, data getting auto-discarded,
> etc.
> 
> A simple solution is to use tags instead of attributes:
> 552da749930852c69ae5d2141d3766b1
> 
> This lets clients which wish to use a stronger hash interop nicely
> with clients which only support MD5. Tags also allow specifying
> additional meta-data via attributes, and complex structured data which
> is more than just a hex string.
> 
> But if we go with tags, do we even need to specify that? We can always
> add tags later in new namespaces, even defined in new XEPs, e.g.
> ...
> or
> ...

Waqas, I think you're right that we want separate elements, not
attributes. However, I think that's a breaking change to XEP-0096. Given
that we're moving away from XEP-0096 anyway, I think the best path
forward is to define a new format for XEP-0234, and make that new format
more extensible (or at least explicitly extensible).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/





smime.p7s
Description: S/MIME Cryptographic Signature

[Standards] UPDATED: XEP-0266 (Codecs for Jingle RTP Sessions)

[XMPP Extensions Editor]

Version 0.4 of XEP-0266 (Codecs for Jingle RTP Sessions) has been released.

Abstract: This document describes implementation considerations related to 
voice and video codecs for use in Jingle RTP sessions.

Changelog: Recommended G.711 as mandatory-to-implement for audio. (psa)

Diff: http://xmpp.org/extensions/diff/api/xep/0266/diff/0.3/vs/0.4

URL: http://xmpp.org/extensions/xep-0266.html