On Thu, Nov 9, 2017 at 11:13 PM, Kim Alvefur wrote:
>
> But perhaps this one?
> https://xmpp.org/extensions/xep-0355.html
>
XEP-0355 is not included in the last call 2018 compliance suite. The issue
I raised was over XEP-0114.
The question is whether a server implementation should be considered
On Thu, Nov 9, 2017 at 5:00 PM, Diane Trout wrote:
> Also a better justification for the component protocol is that it
> allows people to develop reasonably portable new features like xep 363.
> https://github.com/siacs/HttpUploadComponent
I agree with you that being able to implement a new fea
On Thu, Nov 9, 2017 at 12:30 PM, Florian Schmaus wrote:
> A component protocols allows components to piggyback on the
> s2s capabilities of the XMPP server. And s2s is not trivial to implement
> (Dialback, SASL EXTERNAL, possibly BIDI, …). Therefore a component
> protocol allows developers to foc
of it as a feature would only impact sysadmins
trying to run XMPP components.
Beyond that, I'd think any XEP on the MTI list should be standards track,
not historical.
On Wed, Nov 8, 2017 at 11:57 PM, Florian Schmaus wrote:
> On 09.11.2017 02:07, Arc Riley wrote:
> > Since XEP-01
Since XEP-0114 is historical and its purpose predates SRV records, I'm
wondering why it was included in the suite for server compliance?
On Tue, Nov 7, 2017 at 11:41 AM, Sam Whited wrote:
>
>
> On Wed, Nov 1, 2017, at 11:50, Dave Cridland wrote:
> > On 1 November 2017 at 17:14, Sam Whited wro
s/xep-0266.html#mti
>
> On 11/7/17 2:11 PM, Arc Riley wrote:
> > https://xmpp.org/extensions/xep-0385.html#sect-idm139941991230272
> >
> > Since the IETF has standardized the patent-clear Opus codec, this should
> > be recommended. It is already used for WebRTC and broa
https://xmpp.org/extensions/xep-0385.html#sect-idm139941991230272
Since the IETF has standardized the patent-clear Opus codec, this should be
recommended. It is already used for WebRTC and broadly supported.
https://tools.ietf.org/html/rfc6716
https://caniuse.com/#search=Opus
On Wed, Oct 4, 20
I'm on email, it did not go to spam.
On Fri, Nov 20, 2015 at 9:47 PM, Daniel Pocock wrote:
>
>
> On 20/11/15 23:32, Dave Cridland wrote:
> > The original went straight into my Google spam folder.
> >
> > Conspiracy theories welcome.
> >
>
>
> I don't use gmail myself. Could you contact the supp
I've been writing an Apache module for implementing this and have been
making notes regarding the working draft as I go. I also have some
examples to contribute.
On Wednesday, October 31, 2012, Peter Saint-Andre
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> FYI.
>
>
> - O
FYI, Google recently documented their X-OAUTH2 SASL method;
https://developers.google.com/talk/jep_extensions/oauth
There isn't one. Much of this XEP would work a lot better as a wiki page.
On Thu, Jun 16, 2011 at 6:51 PM, dmex wrote:
> What's the point of including it on the document when it's not finalized
> and
> has potential patent claims?
>
I'm concerned about the MTI audio codec specified in this XEP (G.711).
A mantra of the IETF (and many standards bodies) is "rough consensus and
running code". We've reached rough consensus on an MTI audio codec, and
this is good, but based on the discussion on the Jingle list I do not
believe we
On Thu, Jun 2, 2011 at 12:30 PM, Sergey Dobrov wrote:
> I agree but if file attachment already in XEP we have to specify how
> client could upload it. Am I wrong?
The XEP is in "experimental" status, something being in the current XEP does
not mean it must remain there.
I believe that file att
On Thu, Jun 2, 2011 at 7:03 AM, Sergey Dobrov wrote:
>
> > some files. But I never heard of the XEP-0135, will read it as soon as
> > possible. Anyway, by looking at it quickly, it gives me some ideas about
> > how we could manage photo albums/file albums to extend XMPP social
> > features!
> > 1
A group of us with HacDC were working on a similar system to what Nathan
proposed for our sensors project; PubSub (in our case, with
presence=subscription and body-xslt so it works from non-pubsub clients) and
AdHoc Commands for, well, commands. That project has been idle for a few
months now, but
Ping.
It doesn't appear that any work has been done on this since last Fall.
On Sat, Sep 12, 2009 at 10:59 PM, Peter Saint-Andre wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 9/12/09 12:51 AM, Jason wrote:
> > This saddens me too.
>
> No one has died. Let's not get too sad. :)
Is there any effort to collaborate with the Infinote developers?
http://gobby.0x539.de/trac/wiki/Infinote
On Wed, Jun 9, 2010 at 1:53 PM, Peter Saint-Andre wrote:
> Over the last few months I've been working with Tom Pusateri on some
> updates to the Shared XML Editing spec, based on his impleme
> But if several people don't expect that under the title "Multi-User
> Gaming" then we should look for a more appropriate title.
Cool, we're in agreement then. I think the key point here is to contrast it
with multiuser games where players use XMPP for chat and negotiate server
connections via
and wrote:
> On Wed Apr 15 22:22:44 2009, Arc Riley wrote:
>
>> I'd like to repeat my earlier request for the title of this XEP to specify
>> "in-band" gaming
>>
>>
>> I hate the expression "in-band", actually, but "Multiplayer ga
I'd like to repeat my earlier request for the title of this XEP to specify
"in-band" gaming
thanks
On Fri, Apr 10, 2009 at 4:12 PM, XMPP Extensions Editor wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Multi-User Gaming
>
> Abstract: This document defines a
> Is there any information available about your game engine? Also, I'm not
> sure what you mean by "metaservers".
http://www.pysoy.org/
In most networked game setups, game servers run the game, metaservers
provide a central directory of servers which game clients connect to for a
list.
Our inte
We're building our game engine to use XMPP for "metaservers" and game
announcements.
The extensions you proposed handle a small niche of games, I'm envisioning
games like Go, Chess, and Blackjack working well with this, but those games
could run just as well with game specific extensions running t
22 matches
Mail list logo
