Re: [Standards] LAST CALL: XEP-0215 (External Service Discovery)

On 7/13/22 17:03, Jonas Schäfer (XSF Editor) wrote: This message constitutes notice of a Last Call for comments on XEP-0215. Title: External Service Discovery Abstract: This document specifies an XMPP protocol extension for discovering services external to the XMPP network. URL:

Re: [Standards] XEP-0353: Rework whole spec, namespace bump

Am 07.12.21 um 23:31 schrieb Lance Stout: +1 on merging. There’s been a lot of foundational improvements since mid-2014 that we can safely rely on now, so these changes make sense. with authors hat: what Lance said! IIRC the only reason we didn't go for a full carbons + mam dependency back

Re: [Standards] XEP-0371: Jingle ICE Transport Method - Question on ICE Restart detection

Am 16.11.21 um 20:31 schrieb Daniel Gultsch: Hi, I’m trying to implement ICE Restarts with XEP-0371. The XEP states that ICE restarts can be detected by a changed ufrag and pwd attributes in the transport-info. However what I'm currently unclear about is how I can detect if the incoming

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

Am 11.08.21 um 23:49 schrieb Peter Saint-Andre: On 8/11/21 3:35 PM, Kim Alvefur wrote: On Wed, Aug 11, 2021 at 02:25:56PM -0600, Peter Saint-Andre wrote: Too bad we didn't stick to our guns in 2003 and insist on two ports instead of one, but STARTTLS was the recommended approach back then...

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

tl;dr: its a mess. What is the deployment state of xep-0368? Am 11.08.21 um 19:08 schrieb Peter Saint-Andre: Perhaps of interest here... Forwarded Message Subject: [Uta] STARTTLS vulnerabilities Date: Wed, 11 Aug 2021 17:42:40 +0200 From: Hanno Böck To: u...@ietf.org Hi,

[Standards] XEP-0294: update the reference from RFC 5285 to RFC 8285 and add a mapping for a=extmap-allow-mixed

I submitted a PR to update XEP-0294 here: https://github.com/xsf/xeps/pull/1044 after Chrome 89 (after a lot of time) started shipping the a=extmap-allow-mixed attribute (which old Chrome versions wrongly attempted to parse as a=extmap: ...) There are two meta issues here (and as the

Re: [Standards] Deprecating Dialback

Am 03.12.20 um 15:13 schrieb Sam Whited: I lied, I got interested and got started on it last night after work / this morning. https://github.com/xsf/xeps/pull/1017 That has less features than 220, in particular you can't add new domains on *either* side, no? (ofc stream headers suck a bit

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

If the receiving server follows the process described in #9 of https://xmpp.org/extensions/xep-0178.html#s2s which says that you do the authentication at this point (and then again in #11) how can external fail? If the receiving server can not authenticate the request its a policy decision to

Re: [Standards] XEP-0167: Jingle RTP Sessions - payload type parameters w/o value?

fmtp is a bit free-form... my interpretation of that has always been "parameter is empty string, value is not". see https://github.com/ESTOS/strophe.jingle/blob/master/strophe.jingle.sdp.js#L544 Lance: it looks like stanza doesn't map this (telephone-event) anymore (otoh I don't see it

Re: [Standards] XEP-0215: External Service Discovery

Am 11.04.20 um 20:35 schrieb Holger Weiß: * Philipp Hancke [2020-04-11 20:24]: Am 11.04.20 um 20:01 schrieb Holger Weiß: 1. The "type" attribute specifies the "service type as registered with the XMPP Registrar". As far as I can see, no types are registered so

Re: [Standards] XEP-0167: What happened with

. That is colibri extensions for the channel bundle, which is different from BUNDLE even. Philipp Hancke apparently wrote a patch for XEP-0167 that introduced as an element in the description (based on what Google did) in 2014 [2]. However apparently that didn’t get merged. I remember sitting

Re: [Standards] XEP-0215: External Service Discovery

Am 11.04.20 um 20:01 schrieb Holger Weiß: I stumbled over two things while adding XEP-0215 support to ejabberd: 1. The "type" attribute specifies the "service type as registered with the XMPP Registrar". As far as I can see, no types are registered so far; and at least to me, it's not

Re: [Standards] Proposed XMPP Extension: MUC presence versioning

Am 31.03.20 um 20:35 schrieb Jonas Schäfer (XSF Editor): The XMPP Extensions Editor has received a proposal for a new XEP. Title: MUC presence versioning Abstract: This specification defines a versioning mechanism which reduces the amount of presence traffic in a XEP-0045 MUC URL:

Re: [Standards] XEP-0371 (Jingle ICE): update RFC 5245 -> RFC 8445

Am 12.03.20 um 22:30 schrieb Sergey Ilinykh: https://github.com/xsf/xeps/pull/905 PR Changes: 1. RFC 5245 is replaced with RFC 8445 who is implementing 8445? 2. Aggressive nomination is not supported anymore Firefox only implements aggressive nomination.

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

Am 29.08.19 um 13:24 schrieb Andrew Nenakhov: I might be late to the party. This email was sent by me on August 03 after changing my email address and resubscribing to this list, but it seems that I wasn't put through. My points against XEP-0353 in current form still stand. I obviously missed

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

Am 29.08.19 um 11:06 schrieb Dave Cridland: On Thu, 29 Aug 2019 at 09:09, Daniel Gultsch wrote: Am Di., 30. Juli 2019 um 18:42 Uhr schrieb Jonas Schäfer < jo...@wielicki.name>: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Yes

Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?

Am 01.07.19 um 10:08 schrieb Dave Cridland: [...] Do you know which server implementations currently support both TLS and non-TLS (with STARTLS) on the same port? I have a vague recollection that Fippo mentioned this trick years ago - perhaps Psyc, perhaps even the original Jabberd? psyced

Re: [Standards] PR #793 - XEP-0166: Relax transport element requirement

Am 22.06.19 um 17:18 schrieb Sergey Ilinykh: In response to Council Minutes 2019-06-19 quote from https://wiki.xmpp.org/web/XEP-Remarks/XEP-0260:_Jingle_SOCKS5_Bytestreams_Transport_Method Another problem with early (before accept) transport replace is the fact we have to send the same offer

Re: [Standards] XEP-0260 (jingle socks5 transport) candidate-complete event

I was summoned... :-) Am 29.04.19 um 12:02 schrieb Sergey Ilinykh: Hi There is a problem with jingle-s5b in the way how it handles additional candidates sent with transport-info message. Let's imagine a situation. We have an accepted session. Both sides sent their host candidates in

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

Am 14.03.19 um 15:52 schrieb Xander Dumaine: Genesys implemented XEP-0353 for both voice and video calling, and we've been very happy with it. The following code uses it on top of code written by Lance and for jingle.js and stanza.io

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

Am 13.03.19 um 22:16 schrieb Kevin Smith: On 13 Mar 2019, at 17:37, Peter Saint-Andre wrote: I can help, but I would not object to adding a more active co-author (preferably an implementor of the spec). Do you want to request a last call? Under the new rules Council aren’t allowed to

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

Lance, I think we had an implementation of it somewhere? Am 13.03.19 um 14:27 schrieb Daniel Gultsch: To draft?! If anything we should probably bring it back to Experimental. I suggest you implement it and then provide feedback on how well it performed. I’ve looked into into that XEP in the

Re: [Standards] XEP-0288 - Bidi - Maybe CFE?

Am 18.12.18 um 09:45 schrieb Dave Cridland: Hi folks, I'm thinking of asking the Editor to issue a Call For Experience on XEP-0288. I would do so now, but I'm not entirely sure who actually implements it. So, who does implement it? (And is your implementation open source)? I did, a long

Re: [Standards] Renaming XEP status 'Draft' to 'Stable'

Am 01.11.2017 um 13:40 schrieb Matthew Wild: On 1 November 2017 at 12:35, Matthew Wild wrote: As such, I've prepared a change of XEP-0001 here: https://github.com/mwild1/xeps/commit/9cebf36e11d5918352b49c1a3e27fec2f17d8005 Without my Board hat on... a couple of things

Re: [Standards] XEP-0234: Denote used hash function in session-initiate

What do you think? +1 -- this was actually the intent of adding during session-initiate in 0.16. But the wording of this is a bit weird: One or more elements MUST be present when offering a file, but those elements MAY be empty if the hash has not yet been computed. If there is no

Re: [Standards] XEP Authors

Am 09.06.2017 um 16:58 schrieb Sam Whited: On Thu, Jun 8, 2017 at 4:08 PM, Dave Cridland wrote: I'm considering advising Board that we should address this by instituting a policy whereby changes to XEPs result in all listed authors being notified (a PR will do, I imagine),

Re: [Standards] XEP Authors

However, I don't think this is particularly contentious. We have lots of documents for which one of the "Authors" hasn't made any input for several revisions. See the Jingle XEPs for example. I doubt the Google folks listed as authors have looked at this spec in a _decade_ (and at least one

Re: [Standards] Advance XEP-0368 to Proposed

3) Should we request IANA register 5223 and 5270 as default ports? I may sound like a broken record but I don't see why servers can't do TLS and starttls on the same port. jabberd1 has showed how to do that at least since 2004. Basically the server peeks at the first byte which is either

Re: [Standards] Jingle PSTN sessions

Am 21.01.2017 um 20:59 schrieb Stephen Paul Weber: I'd like to get feedback on a crazy proposal I've been batting around. Many times an XMPP client or other JID is in a context where it has some access to PSTN (either because the client is on a cell phone, or it has access to a VoiP bridge, or

Re: [Standards] Comments on XEP-0320 (DTLS-SRTP)

Am 21.12.2016 um 00:25 schrieb Jonathan Lennox: Hi — a few comments on XEP-0320 (DTLS-SRTP). (I know the formal Last Call period has closed, but I think these are both pretty serious.) Thanks for raising them! Also for pointing out that this has been in "proposed" state for way too long...

Re: [Standards] LAST CALL: XEP-0371 (Jingle ICE Transport Method)

Am 29.10.2016 um 23:46 schrieb XMPP Extensions Editor: This message constitutes notice of a Last Call for comments on XEP-0371 (Jingle ICE Transport Method). I think its currently bad timing to LC this as the definition of the end-of-candidates notification is changing, see e.g.

Re: [Standards] Proposed XMPP Extension: Burner JIDs

Am 28.10.2016 um 21:01 schrieb Sam Whited: On Fri, Oct 28, 2016 at 1:51 PM, Philipp Hancke <fi...@goodadvice.pages.de> wrote: It was not clear to me what the shared secret is used for here I originally had a different mechanism drafted out for this that used a shared secret. Turns out

Re: [Standards] Proposed XMPP Extension: Burner JIDs

Am 28.10.2016 um 19:49 schrieb XMPP Extensions Editor: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Burner JIDs Abstract: A mechanism by which users may request arbitrary anonymizing "burner" JIDs for short term use. URL:

Re: [Standards] Changing RTP codec list in Jingle?

Am 09.06.2016 um 23:34 schrieb Jonathan Lennox: Does XEP-167 (or some other XEP) make it possible for a Jingle endpoint to change, or reorder, its list of supported codecs? The description-info method makes it possible to change the properties of a codec; but XEP-167 explicitly says that the

Re: [Standards] XEP-0167: Something, I can't understand

Am 02.07.2016 um 18:19 schrieb Константин Козлов: Hello! There's something, I still cannot understand in XEP-0167. I tried to ask in both j...@conference.jabber.org and x...@muc.xmpp.org but got no answer so far. XEP-0167 chapter 5 says about *session-initiate* request: /When the initiator

Re: [Standards] XEP-0167: How to?

Am 19.06.2016 um 09:12 schrieb Kozlov Konstantin: Hello! Just trying to implement XEP-0167: Jingle RTP Sessions in my client software. There's something, I can't understand. According to 5. Negotiating a Jingle RTP Session, instances should start exchange media just after session-accept sent

Re: [Standards] [XEP-0353] Jingle Message Initiation

Am 27.04.2016 um 21:50 schrieb Dumaine, Xander: It looks like my email composer lost some text. Corrected: In XEP–0353: Jingle Message Initiation, section 3.4 Rejecting Intent to Start a Session we have: Instead of accepting the call, the responder might want to ignore the call and tell all

Re: [Standards] MUC: Opt-out of presence broadcasting

For us presence flooding is a major problem as we have some customers with MUC rooms that have 10s of thousands of participants, but we don't actually need Sounds like you are using MUC for something it was not built for. to know if the majority of those are online at any given time. that

Re: [Standards] Proposed XMPP Extension: Jingle ICE Transport Method

Am 06.01.2016 um 17:00 schrieb Dave Cridland: On 6 January 2016 at 15:38, Philipp Hancke <fi...@goodadvice.pages.de> wrote: before publication What? Why on earth do we want to make changes before publication as a XEP? wouldn't such a change to the schema need a namespac

Re: [Standards] Proposed XMPP Extension: Jingle ICE Transport Method

Am 06.01.2016 um 17:15 schrieb Dave Cridland: On 6 January 2016 at 16:13, Philipp Hancke <fi...@goodadvice.pages.de> wrote: Am 06.01.2016 um 17:00 schrieb Dave Cridland: On 6 January 2016 at 15:38, Philipp Hancke <fi...@goodadvice.pages.de> wrote: before publication What?

Re: [Standards] Proposed XMPP Extension: Jingle ICE Transport Method

Am 17.12.2015 um 11:50 schrieb XMPP Extensions Editor: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Jingle ICE Transport Method Abstract: This specification defines a Jingle transport method that results in sending media data using datagram associations via the

Re: [Standards] Proposed XMPP Extension: Jingle ICE Transport Method

oh... just noticed this introduces types for tcp-active etc. This is rather unfortunate as there can be candidates of type host with protocol udp and a tcptype active. Mapping this seems complicated, i'd prefer to have a separate tcptype attribute. Also, the 6544 reference is not work in

Re: [Standards] namespace versioning for XEP-0176

Does anyone have concerns with this approach? WFM. I suppose the bigger change is going to be the addition of and end-of-candidates element? ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe:

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

Am 05.11.2015 um 11:51 schrieb Travis Burtrum: Hello Peter, On 11/05/2015 01:27 PM, Peter Saint-Andre wrote: I haven't yet had time to look at your proposal in detail. However, there is no _tls Protocol name in RFC 2782 or RFC 6335. It seems strange for us to be the only ones using that

Re: [Standards] Deprecating Privacy Lists

I would say writing XEPs requires tons of effort: translating it into English (for non-native speakers), arguing on the list, maintaining it, etc. But you usually get feedback in return for your investment. Which, at least for me, makes it worth it.

Re: [Standards] LAST CALL: XEP-0320 (Use of DTLS-SRTP in Jingle Sessions)

Am 26.08.2015 um 08:59 schrieb XMPP Extensions Editor: This message constitutes notice of a Last Call for comments on XEP-0320 (Use of DTLS-SRTP in Jingle Sessions). Abstract: This specification defines how to use DTLS-SRTP (RFC 5763) in the Jingle application type for the Real-time Transport

Re: [Standards] LAST CALL: XEP-0320 (Use of DTLS-SRTP in Jingle Sessions)

Am 16.09.2015 um 14:04 schrieb Dave Cridland: On 16 September 2015 at 19:34, Philipp Hancke <fi...@goodadvice.pages.de> wrote: DTLS is currently the way all WebRTC calls get established (minus Google Hangouts which still uses SDES but technically that makes them "not w

Re: [Standards] Proposed XMPP Extension: HTTP File Upload

2015-07-30 11:07 GMT+02:00 Goffi go...@goffi.org: On 30/07/2015 02:29, Sam Whited wrote: HTTP give  no advantage over Socks5, and doesn't do NAT traversal as Jingle can do, and it's an other whole different server to maintain. When uploading a file to a server you don't need NAT

Re: [Standards] LAST CALL: XEP-0327 (Rayo)

Am 17.04.2015 um 11:48 schrieb Ben Langfeld: Changes suggested to this specification in this thread, with the exception of those deferred to v2, are available at https://github.com/rayo/xmpp/compare/1b4ee7f...feature/rayo.patch ah... LGTM. Can you resubmit please? (if I had only said that

Re: [Standards] Nonzas: What are they and do we need them?

Am 20.04.2015 um 06:27 schrieb Florian Schmaus: In order to make the following easier, I'd first like to define the term Nonza: A Nonza is every top level XMPP stream element which is not a Stanza. (see also [1]). http://geekplace.eu/xeps/xep-nonza/xep-nonza.html#rules db:result/ and

Re: [Standards] LAST CALL: XEP-0327 (Rayo)

hey Ben, Yes. It is certainly better than doing something like uaCSTA ( http://www.ecma-international.org/publications/files/ECMA-TR/TR-087.pdf) over XMPP. I'll note as a preface to my below comments that CSTA is somewhat of a motivation for Rayo being the way it is: stupidly simple. CSTA

Re: [Standards] LAST CALL: XEP-0327 (Rayo)

Am 06.04.2015 um 07:26 schrieb XMPP Extensions Editor: This message constitutes notice of a Last Call for comments on XEP-0327 (Rayo). Abstract: This specification defines an XMPP protocol extension for the third-party control of telephone calls and other similar media sessions. The protocol

Re: [Standards] Advancing XEP-0280 Carbons

On 1 April 2015 at 17:37, Dave Cridland wrote: poor timing :-) +1 - Other types beyond 'chat'. see http://mail.jabber.org/pipermail/standards/2014-August/029100.html

Re: [Standards] LAST CALL: XEP-0294 (Jingle RTP Header Extensions Negotiation)

Am 06.01.2015 um 10:53 schrieb XMPP Extensions Editor: This message constitutes notice of a Last Call for comments on XEP-0294 (Jingle RTP Header Extensions Negotiation). Abstract: This specification defines an XMPP extension to negotiate the use of the use of RTP Header Extension as

Re: [Standards] LAST CALL: XEP-0293 (Jingle RTP Feedback Negotiation)

Am 06.01.2015 um 10:59 schrieb XMPP Extensions Editor: This message constitutes notice of a Last Call for comments on XEP-0293 (Jingle RTP Feedback Negotiation). Abstract: This specification defines an XMPP extension to negotiate the use of the Extended RTP Profile for Real-time Transport

Re: [Standards] Proposed XMPP Extension: namespace delegation

Am 27.11.2014 um 00:32 schrieb Goffi: G'day, Thanks for your feedback, and sorry for the late answer... Does this really have to use query + type=request? request xmlns=urn:xmppp:delegation:0' delegation='admin' Indeed, binary told me the same thing on a MUC, I'll remove it in the next

Re: [Standards] Carbon copies of non-chat messages

Am 23.11.2014 um 15:16 schrieb Holger Weiß: Why does XEP-0280 restrict its scope to message stanzas of type chat? Wouldn't you usually expect to also receive copies of normal messages, at least? See http://mail.jabber.org/pipermail/standards/2014-August/029104.html I think it is on Matt's

[Standards] XEP-0322 Last Call comment summary

This is a summary of Last Call comments concerning XEP-0322, and is a method of attempting to (re)stimulate discussion in order to get the XEP moved from Experimental. It does not constitute a formal action of Council, Board, or the XSF as a whole, nor set any kind of precedent - it results

Re: [Standards] LAST CALL: XEP-0332 (HTTP over XMPP transport)

Am 08.10.2014 18:33, schrieb XMPP Extensions Editor: This message constitutes notice of a Last Call for comments on XEP-0332 (HTTP over XMPP transport). Abstract: This specification defines how XMPP can be used to transport HTTP communication over peer-to-peer networks. URL:

Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)

Am 08.10.2014 18:33, schrieb XMPP Extensions Editor: This message constitutes notice of a Last Call for comments on XEP-0322 (Efficient XML Interchange (EXI) Format). Abstract: This specification describes how EXI compression can be used in XMPP networks. URL:

Re: [Standards] UPDATED: XEP-0234 (Jingle File Transfer)

[...] using a transport-info message as described under Communicating the Hash. So I make slide text about spec bugs and notice another bug: transport-info - session-info

Re: [Standards] UPDATED: XEP-0155 (Stanza Session Negotiation)

Am 14.01.2008 um 21:32 schrieb XMPP Extensions Editor: Version 1.2 of XEP-0155 (Stanza Session Negotiation) has been released. Abstract: This specification defines a method for formally negotiating the exchange of XML stanzas between two XMPP entities. The method uses feature negotiation

[Standards] XEP-0280: carbons + message/ stanzas of type normal

I want to use the forking of message/ stanzas as described in http://tools.ietf.org/html/rfc6121#section-8.5.2.1.1 in order to fork Jingle calls in a way that allows the receiver to pick the device which accepts the call. In order to use this forking, my resource needs to have a non-negative

Re: [Standards] XEP-0280: carbons + message/ stanzas of type normal

[...] 1) can we change 0280 to also allow this type of processing for messages of type normal? prosodys mod_carbons seems to do this anyway. I think that's reasonable, but I would still argue against any other message/ types. Right. For groupchat and error the change from the behaviour

Re: [Standards] Disco conflict between 30 and 163

[...] These are, in general, desirable effects from a UX standpoint. The downside is that one can use them to harvest real jids for abuse and other nefarious purposes. However, it's not specific to Disco, and we should be careful of being distinctly uneven in our protection here. As such, my

Re: [Standards] UPDATED: XEP-0332 (HTTP over XMPP transport)

Am 13.08.2014 18:12, schrieb XMPP Extensions Editor: Version 0.3 of XEP-0332 (HTTP over XMPP transport) has been released. Abstract: This specification defines how XMPP can be used to transport HTTP communication over peer-to-peer networks. Changelog: [See revision history] (pw) Diff:

Re: [Standards] UPDATED: XEP-0332 (HTTP over XMPP transport)

hey Peter, Thanks for your comment. Just wanted to point out the possibility as such, even though it would probably not be used by the web server. Since content is normally returned based on query parameters and request headers, the actual content selection would probably be made by the

Re: [Standards] UPDATED: XEP-0234 (Jingle File Transfer)

Am 12.08.2014 um 01:08 schrieb XMPP Extensions Editor: Version 0.16 of XEP-0234 (Jingle File Transfer) has been released. Abstract: This specification defines a Jingle application type for transferring a file from one entity to another. The protocol provides a modular framework that enables

Re: [Standards] RFC: XEP-0045 MUC should not rewrite message IDs

Am 25.07.2014 um 09:22 schrieb Kevin Smith: On Fri, Jul 25, 2014 at 3:06 PM, Georg Lukas ge...@op-co.de wrote: XEP-0045, section 7.4 http://xmpp.org/extensions/xep-0045.html#message states: Note well that for tracking purposes this service assigns a new 'id' to each message it generates (here

Re: [Standards] UPDATED: XEP-0343 (Signaling WebRTC datachannels in Jingle)

Am 23.07.2014 um 11:08 schrieb Ivan Vučica: Wouldn't it be nicer to promote SCTP to a new transport type instead of specifying the type to be UDP? An client might ignore the new sctp/ and fingerprint/ elements and assume the offering party is willing to perform an operation using UDP. Is it an

Re: [Standards] Multimegasmarticasting

[...] I slightly disagree here. But not enough anymore to really object. I would dearly love you to disagree here. Not only because I'd rather like to be wrong, but it'd be just like the good old days - and in any case, I'd rather get the debate aired rather than raised later. Well, I was

Re: [Standards] Proposed XMPP Extension: Recipient Server Side Notifications Filtering

Am 23.06.2014 09:41, schrieb Sergey Dobrov: So guys, what are the exact concern around the XEP-0033 None of us has ever seen 0033 deliver on reducing the amount of s2s traffic. Even the authors of 0033 agreed to this in the repeater introduction. Using 0033 unconditionally has trust

[Standards] autoaway (was: Re: Proposed XMPP Extension: Recipient Server Side Notifications Filtering)

2) We route shitload of presences to a client. On and on this goes. clients generated a shitload of autoaway presence. darth is busy now (Away as a result of being idle more than 5 min) and ten minutes later darth is away now (Away as a result of being idle more than 15 min) Seriously, what is

Re: [Standards] Multimegasmarticasting

[...] The converse of these - bandwidth efficient, secure/private, RTT efficient - would form our requirements. makes sense. I'd note a couple of changes to the server landscape might affect our thoughts here. a) As annoying as it is to me, compression seems related to a number of security

Re: [Standards] Fwd: Minutes 20140521

Am 29.05.2014 21:15, schrieb Ben Langfeld: Matt, did you have an answer to this? I'm a little confused about how this stands, since the original council vote was in favour of publishing, and it hasn't been published yet. urm, i'm still veto-ing on this --

Re: [Standards] Proposed XMPP Extension: Buddycloud Channels

URL: http://xmpp.org/extensions/inbox/buddycloud-channels.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP. some notes I wrote down while reviewing it: section 1: s/inter-operate/interoperate/? section 2: s/. find the/./ Use a

[Standards] -1 on rayo-clustering (was: Re: [Council] Minutes 2014-04-23)

Am 24.04.2014 10:58, schrieb Kevin Smith: Room logs: http://logs.xmpp.org/council/2014-04-23/ [...] 3) http://xmpp.org/extensions/inbox/rayo-clustering.html Accept as Experimental Lance/Philipp to post their objections to the council/standards lists. here we go... the requirements make

Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery

The alternative is we just say Components are privately-authenticated S2S connections, and invoke BiDi and SASL auth and make it happen. This is functionally equivalent, but differs in that components are no longer special in any way (aside from near-mandatory support for XEP-0288), aren't

Re: [Standards] Need help with problems regarding XEP-0114.

Hi Peter, Trying this on the server I use (OpenFire), messages (and IQ stanzas) sent to bare JIDs are not forwarded to the corresponding client. Should it? iq stanzas are never forwarded. Message stanzas are only forwarded to available resources, i.e. resources that that sent initial

Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery

Hi Peter, section 3.3.1 describes how to find an xmpp servers. The methods described there aren't limited to iot (at least the dhcp one), so it might be a good idea to split them off. Not sure how useful that is however. Ok. Can we break this out at a later stage? I agree it makes sense to

Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery

Am 13.03.2014 17:26, schrieb XMPP Extensions Editor: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Internet of Things - Discovery Abstract: This specification describes an architecture based on the XMPP protocol whereby Things can be installed and safely discovered

Re: [Standards] Last connection time of friend

Am 02.03.2014 20:08, schrieb Peter Waher: Is there a means to figure out the last time a friend connected to its XMPP server? Can you ask the server hosting the user account for last connection time? (You might not have been online to receive the presence message when the user went offline.)

[Standards] ProtoXEP: Impact of TLS and DNSSEC on Dialback

Oh mighty XEP Editor team, we humble authors do implore and beseech thee to accept this specification on the impacts of TLS and DNSSEC on Dialback. ?xml version='1.0' encoding='UTF-8'? !DOCTYPE xep SYSTEM 'xep.dtd' [ !ENTITY % ents SYSTEM 'xep.ent' %ents; ] ?xml-stylesheet type='text/xsl'

Re: [Standards] ProtoXEP: Impact of TLS and DNSSEC on Dialback

Am 28.02.2014 18:37, schrieb Dave Cridland: I hereby assign any and all rights and ownership in this document that I may possess to the XMPP Standards Foundation, and promise to perfect any such assignment in writing as required. So do I (implicitly on all my submissions, but thanks for the

Re: [Standards] ProtoXEP: Impact of TLS and DNSSEC on Dialback

For the record, Dave just fulfilled the promise given in http://logs.jabber.org/j...@conference.jabber.org/2009-04-14.html#15:10:06

Re: [Standards] compliance suites

On Wed, 5 Feb 2014, Peter Saint-Andre wrote: I gather there was some discussion of compliance suites at the Summit. Part Right, notes at http://wiki.xmpp.org/web/Summit_15_Minutes#compliance_suite of our problem before was that we said we would update the suites yearly, and that turned out

[Standards] [Council] Minutes 2014-01-22 (fwd)

FYI. Please change the subject if you want to discuss the list of specs for new compliance suites. -- Forwarded message -- Date: Mon, 27 Jan 2014 11:48:09 +0100 (CET) From: Philipp Hancke fi...@goodadvice.pages.de Reply-To: XMPP Council coun...@xmpp.org To: coun...@xmpp.org

Re: [Standards] Dialback: Limits to Multiplexing between multi-tenants?

Am 27.01.2014 19:23, schrieb Matthew A. Miller: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I've run into a condition that I think requires special considerations in XEP-0220: [...] I imagine the dialback requests would be done again with the new connection, to keep the overall flow

Re: [Standards] Proposed XMPP Extension: COnferences with LIghtweight BRIdging (COLIBRI)

On Thu, 5 Dec 2013, Dave Cridland wrote: I read this through. It seems in remarkably good shape for a mere protoXEP, and the protocol looks solid, useful, and well-designed. The protocol is brilliant -- thanks to Emil. I just made it work with the webrtc API. It basically leverages the

Re: [Standards] Proposed XMPP Extension: Source-Specific Media Attributes in Jingle

Am 03.12.2013 21:49, schrieb XMPP Extensions Editor: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Source-Specific Media Attributes in Jingle Abstract: This specification provides an XML mapping for translating the RFC 5766 Source-Specific Media Attributes from SDP

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[...] Having no federation at least doesn't introduce yet another huge possibility for security problems and as long as you own the source code and aren't forced to use anybody's specific offering it is highly inadeguate to call such a software a silo. In case others are not yet aware:

Re: [Standards] How to add a new reference to XEP

Hello and sorry if this is wrong channel for the question. this is the right place :-) [...] Do you have an example how to add a reference, e.g., an RFC (that is not yet in xep.ent file) as an inline entity to xml file? http://xmpp.org/extensions/xep-0258.xml defines several at the top.

Re: [Standards] Proposed XMPP Extension: Rayo Fax

Quick review: The links (like Rayo CPA in section 2 which should be updated after publication of that spec) seem broken, in particular internal ones like the receivefax/ one. Can you fix them before publication? Example 2: why is presence used here? This seems like it should use message/

Re: [Standards] Proposed XMPP Extension: Rayo CPA

Abstract: This specification defines an extension to the Rayo protocol (XEP-0327) to provide provision for performing Call Progress Analysis on a call under the control of a Rayo client. URL: http://xmpp.org/extensions/inbox/rayo-cpa.html nit: I'd move the CPA definition from the glossary to

Re: [Standards] UPDATED: XEP-0320 (Use of DTLS-SRTP in Jingle Sessions)

Am 14.11.2013 19:48, schrieb XMPP Extensions Editor: Version 0.2 of XEP-0320 (Use of DTLS-SRTP in Jingle Sessions) has been released. Thanks Peter. While I do have another change which might require a namespace bump I felt that with code in the wild that uses this namespace it was good to

Re: [Standards] Dialback, authentication, and authorization

Ejabberd's default key: C5:78:17:B1:34:90:54:D0:5A:16:A4:C6:71:80:6D:C3:F8:8B:F1:31:3D:64:BD:42:8F:1F:C5:D9:21:EB:99:BE That is the CN=ejabberd? Likely the same one I saw back in http://mail.jabber.org/pipermail/standards/2007-July/016086.html

Re: [Standards] Proposed conversation about Board election

Am 14.10.2013 22:20, schrieb Kevin Smith: Applicants to the Board, like SM, can't post to members@. Our bylaws don't require Board to be members. I don't think use of this list was inappropriate in this case (or, at least, I can't think of a better list). See also

Re: [Standards] Proposed XMPP Extension: Jingle SDP Content

Abstract: This specification defines a Jingle application type for transport the Session Description Protocol (SDP) over Jingle. URL: http://xmpp.org/extensions/inbox/jingle-sdp.html hrmpf, it seems I sent the xmpp editor an outdated version. Minor updates at

Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)

Am 21.08.2013 18:01, schrieb Peter Saint-Andre: [...] Digging out my print copy i found some notes regarding stream compression and session managment in 2.1.1 (after example 3). Really old thread alert. :-) Old enough that my print copy which I recently dug out is starting to fall apart :-)

Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)

Am 21.08.2013 19:51, schrieb Peter Saint-Andre: On 8/21/13 11:47 AM, Philipp Hancke wrote: Am 21.08.2013 18:01, schrieb Peter Saint-Andre: [...] Digging out my print copy i found some notes regarding stream compression and session managment in 2.1.1 (after example 3). Really old thread alert

  1   2   3   >