Re: [Standards] [Fwd: XEP78; Non-SASL Authentication]

Peter Saint-Andre wrote: It seems wrong to compare iq:auth to SASL or to say that iq:auth is less secure. SASL PLAIN over an unencrypted connection is less secure than iq:auth with digest password, whereas SASL EXTERNAL is probably more secure than iq:auth. It all depends on the mechanism used

[Standards] XMPP Protocol Flows for Inter-Domain Federation

I've started to work on a document that will define in great detail the possible protocol flows for various permutations of federation policies and digital certificates: http://www.xmpp.org/extensions/inbox/federation.html I'd like some feedback from server developers. Will it be helpful for m

[Standards] XSF IPR Policy

As approved by the Board of Directors, the XSF's IPR Policy has been updated to use a modified MIT license rather than the old Creative Commons Attribution License: http://www.xmpp.org/extensions/ipr-policy.shtml Not all the XEPs reflect the new license yet. That will be fixed soon. Peter --

[Standards] UPDATED: XEP-0001 (XMPP Extension Protocols)

Version 1.19 of XEP-0001 (XMPP Extension Protocols) has been released. Abstract: This document defines the standards process followed by the XMPP Standards Foundation. Changelog: Updated to reflect version 1.4 of XSF IPR Policy. (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extension

[Standards] [Fwd: XEP78; Non-SASL Authentication]

An anonymous forward from someone who pinged me about some of the text in XEP-0078... -- Begin Forwarded Message -- I have a small question on the mentioned XEP. In the "Security Considerations" there is the sentence "Authentication using the 'jabber:iq:auth' method is known to

Re: [Standards] XEP-80 addition

Peter Saint-Andre wrote: Joe Hildebrand wrote: I've been pinged off-list about adding velocity to XEP-80. It would be xs:decimal, velocity in meters/sec. Obviously optional. Any objections? That seems fine to me. I am not saying I need this, but if someone asked about speed, maybe they'd

Re: [Standards] XEP-0118: music rating?

Provisionally added: http://www.xmpp.org/extensions/tmp/xep-0118-1.2.html http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0118.xml?r1=1555&r2=1596 /psa Peter Saint-Andre wrote: FYI from the SIMPLE WG list, a suggestion to include music rating in the XEP-0118 format. Not a bad idea,

Re: [Standards] XEP-80 addition

Peter Saint-Andre wrote: Joe Hildebrand wrote: I've been pinged off-list about adding velocity to XEP-80. It would be xs:decimal, velocity in meters/sec. Obviously optional. Any objections? That seems fine to me. http://www.xmpp.org/extensions/tmp/xep-0080-1.5.html http://svn.xmpp.org:18

[Standards] XEP-0225: Multiple Connections Per JID?

Hi folk! We have a need to connect multiple iterations of a component to the same JID. It's expected that this external component is aware that a simple XMPP conversation held with it's JID can/will dance between the external component's nodes. At first we considered having the server configu

Re: [Standards] XEP-80 addition

Joe Hildebrand wrote: I've been pinged off-list about adding velocity to XEP-80. It would be xs:decimal, velocity in meters/sec. Obviously optional. Any objections? That seems fine to me. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signatur

[Standards] XEP-80 addition

I've been pinged off-list about adding velocity to XEP-80. It would be xs:decimal, velocity in meters/sec. Obviously optional. Any objections? -- Joe Hildebrand

Re: [Standards] Proposed XMPP Extension: Client Information

On Śr, 2008-01-23 at 08:24 -0700, Peter Saint-Andre wrote: > >> URL: http://www.xmpp.org/extensions/inbox/clientinfo.html > > > > I've implemented it in jabberd 2. > > You may check current SVN trunk, or see it live on chrome.pl server. > > What does it mean for a server to implement client info?

Re: [Standards] Proposed XMPP Extension: Client Information

Peter Saint-Andre wrote: Peter Saint-Andre wrote: Tomasz Sterna wrote: On Pn, 2008-01-21 at 21:56 -0600, XMPP Extensions Editor wrote: Abstract: This document specifies an XMPP protocol extension for including detailed data about an XMPP client in service discovery responses. URL: http://www.

Re: [Standards] Proposed XMPP Extension: Client Information

Peter Saint-Andre wrote: Tomasz Sterna wrote: On Pn, 2008-01-21 at 21:56 -0600, XMPP Extensions Editor wrote: Abstract: This document specifies an XMPP protocol extension for including detailed data about an XMPP client in service discovery responses. URL: http://www.xmpp.org/extensions/inbox/

Re: [Standards] Proposed XMPP Extension: Client Information

Tomasz Sterna wrote: On Pn, 2008-01-21 at 21:56 -0600, XMPP Extensions Editor wrote: Abstract: This document specifies an XMPP protocol extension for including detailed data about an XMPP client in service discovery responses. URL: http://www.xmpp.org/extensions/inbox/clientinfo.html I've imp

Re: [Standards] Proposed XMPP Extension: Client Information

On Pn, 2008-01-21 at 21:56 -0600, XMPP Extensions Editor wrote: > Abstract: This document specifies an XMPP protocol extension for > including detailed data about an XMPP client in service discovery > responses. > > URL: http://www.xmpp.org/extensions/inbox/clientinfo.html I've implemented it in

Re: [Standards] Proposed XMPP Extension: Client Information

On Wt, 2008-01-22 at 15:43 -0700, Peter Saint-Andre wrote: > A question: should this clientinfo extension include the software name, > or do we assume that is provided properly in the service discovery > identity? If the latter, I'll make that clear in the extension spec. (It > seems preferable

[Standards] Publish-subscribe collection node deassociation notification

Hi, I am working on getting publish-subscribe collection nodes implemented in Idavoll. There are two ways to subscribe to a collection nodes using the 'pubsub#subscription_type' subscription configuration option: nodes and items. In the 'nodes' case, you get notifications when nodes get associate