[Standards] Re: Remove requirement to send disco#info feature in XEP-0030

On 11 March 2024 10:51:39 CET, Kevin Smith wrote: > > [..] > >It seems to me that, although this has always seemed like a strange wart, the >fact that it might cause implementations to need to be updated (whether such >implementations are known of by The Internet or not), making the change is

Re: [Standards] FYI: Urgent XEP published: XEP-0464

Congrats! In the best of traditions, I think it would be proper to fix the date and track, possibly with a force push. -- ralphm From: Jonas Schäfer Sent: Friday, April 1, 2022 08:34 To: standards@xmpp.org Subject: [Standards] FYI: Urgent XEP published: XEP-0464

Re: [Standards] XEP-0060: PubSub events with multiple "item" and "retract" elements

On 09/02/2022 16.56, Melvin Keskin wrote: Thanks for the history! I think that there are two main questions: 1. Should it be possible to publish or retract multiple items within one request? 2. May event notifications contain multiple items (if batch processing is possible or if the server

Re: [Standards] XEP-0060: PubSub events with multiple "item" and "retract" elements

On 09/02/2022 12.17, Melvin Keskin wrote: Hi, I am wondering why the XML schema for PubSub events ( https://xmpp.org/extensions/xep-0060.html#schemas-event) specifies that the "items" element of events may contain multiple "item" and "retract" elements:

Re: [Standards] [Members] Feedback on the proposed CoC

. Kind regards, Ralph Meijer ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] [XEP-0030] we can't get basic information on a bare JID without presence subscription

On 19/01/2022 10.11, Georg Lukas wrote: The problem is that I need to have presence subscription to do that on a bare JID (due to "https://xmpp.org/extensions/xep-0030.html#security;), even if the node I want to request (in the presence case, it's XEP-0277's microblog node) is open and thus

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

On 04/01/2022 18.55, Jonas Schäfer (XSF Editor) wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: PubSub Namespaces Abstract: This extension defines a new PubSub node attribute to specify the type of payload. URL: https://xmpp.org/extensions/inbox/pubsub-ns.html

Re: [Standards] Proposed XEP-0060 Changes

Hi, I too think that MUST is too strong here, as it leaves no room for services to ignore or override certain values, e.g. for policy reasons. SHOULD would be adequate here, indicating that one should understand the full ramifications of deviating from the specified behavior. -- ralphm

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

On June 11, 2021 10:12:31 PM GMT+02:00, Dave Cridland wrote: >On Fri, 11 Jun 2021 at 17:10, Kevin Smith wrote: > >* "No person has any automatic right to join a chatroom, or write a XEP." >in §3 ought to be something else, since writing a XEP doesn't need the >XSF's permission as such. > >I'm

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

Thanks for your comments. I'll let Dave respond in detail, except on this: On 11/06/2021 14.19, Sam Whited wrote: Also a general nit picky note for the editor: all the various hyphens should be converted to em-dashes and "a XEP" should be "an XEP" (I thought? Maybe that's not true in all

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

Hi Andrew, Thank you for your feedback. When the XSF (then JSF) started publishing XEPs they were known as Jabber Enhancement Proposals. We modeled this after other organizations, in particular the well-known PEP series of the Python Software Foundation. It is explicitly the intent to

Re: [Standards] XSF (unofficial) Modernization Working Group looking for XEPs to discuss

On May 30, 2021 4:35:01 AM GMT+02:00, Sam Whited wrote: >On Sat, May 29, 2021, at 15:40, Dave Cridland wrote: >> > But I don't see how this is different if the discussion took >> > place on a XSF mailing list (or even at the XSF summit). I don't >> > remember agreeing that every idea I express

[Standards] Renewing XSF Sponsorship for 2020

ttps://xmpp.org/community/sponsorship.html>. Should you have any questions, please let us know at that same e-mail address. Thank you for your consideration. Kind regards, Ralph Meijer Chair of the XMPP Standards Foundation ___ Standards mailin

Re: [Standards] Offline Feature Negotiation and Device Lists

On 17-02-2020 14:58, Matthew Wild wrote: [..] > > If we have to handle the case where there is no available device to handle the feature, what is this protocol to be used for? I don't think there's a way that all cases can be handled perfectly. I want to expand my original use case with

Re: [Standards] Offline Feature Negotiation and Device Lists

On 17-02-2020 13:44, Matthew Wild wrote: On Mon, 17 Feb 2020 at 12:14, Ralph Meijer wrote: On 17-02-2020 13:04, Matthew Wild wrote: I really don't want to just design an account capabilities system without some real concrete use-cases that demonstrate it's our best option. Ok

Re: [Standards] Offline Feature Negotiation and Device Lists

On 17-02-2020 13:04, Matthew Wild wrote: I really don't want to just design an account capabilities system without some real concrete use-cases that demonstrate it's our best option. Ok, concrete use case from my time at VEON: calling. In the situation where most/all of your "known

Re: [Standards] Offline Feature Negotiation and Device Lists

On 17-02-2020 09:57, Dave Cridland wrote: On Sun, 16 Feb 2020 at 12:49, Ralph Meijer <mailto:ral...@ik.nu>> wrote: > Have you considered special disco nodes on the account that get > synthesized by the server based on the disco information from > registered devices?

Re: [Standards] Offline Feature Negotiation and Device Lists

Hace you considered special disco nodes on the account that get synthesized by the server based on the disco information from registered devices? Do you think there's value in the ability to subscribe to this information via PEP? -- ralphm From: Dave Cridland

Re: [Standards] XEP-0384: Rejecting? [Was: Re: Proposed XMPP Extension: Ephemeral Messages]

On 02-01-2020 16:51, Sam Whited wrote: On Thu, Jan 2, 2020, at 15:39, Dave Cridland wrote: So I should accept your assertion that it is possible, but not Philip's assertion on this list that it is not? You should, because I have done so and shown that it was possible. At the time you insisted

Re: [Standards] XEP-0384: Rejecting? [Was: Re: Proposed XMPP Extension: Ephemeral Messages]

On 02-01-2020 14:36, Marvin W wrote: [..] The board did not update the diagram alone, it also specifically added a rule in the text to allow that behavior [1]. If it happened before, it was behavior outside the rules of XEP-0001. We updated this for clarity, so there's a clear process. The

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

On December 21, 2019 12:32:03 PM GMT+01:00, Andrew Nenakhov wrote: >сб, 21 дек. 2019 г. в 16:21, Ralph Meijer : > >> Just making sure everyone has the same interpretation: >> >> Case 1) The text has the sequence ]]>. In this case, in XML the > >MUST be >>

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

On December 21, 2019 11:57:19 AM GMT+01:00, Andrew Nenakhov wrote: >сб, 21 дек. 2019 г. в 15:45, Philipp Hörist : > >> >> I think you misunderstood the RFC, it's not a violation to send ">" >> unescaped. >> >> > The right angle bracket (>) *may *be represented using the string " > >> ", and

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

On December 21, 2019 10:57:02 AM GMT+01:00, Florian Schmaus wrote: >On 18.12.19 16:00, Marvin W wrote: >> It's indeed a good question if anything in XMPP allows servers or >> in-between entities to do normalization. I was under the assumption >that >> servers do not change the codepoints. In XML

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

On 20-12-2019 12:55, Andrew Nenakhov wrote: чт, 19 дек. 2019 г. в 19:02, Ralph Meijer <mailto:ral...@ik.nu>>: If you want consistent counting on all platforms and languages, counting Unicode characters seems to be the best way forward. We do not dispute that 'countin

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

Oops, the following should have been sent to the list. On 19-12-2019 15:02, Ralph Meijer wrote: On 19-12-2019 13:59, Andrew Nenakhov wrote: ср, 18 дек. 2019 г. в 20:12, Ralph Meijer <mailto:ral...@ik.nu>>:     My assumption was that we are looking at character data on the     abstr

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

On 18-12-2019 16:40, Marvin W wrote: [..] Also that's a weird counting there, usually I would expect end to point to the position after the last referenced character - at least that's what you do in most programming languages (e.g. ""[0:14] will give you "" without the last ";"). I'd not

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

My assumption was that we are looking at character data on the abstract layer /after/ parsing XML. You shouldn't see entities there (they'd be resolved to their respective characters), nor should you see

[Standards] Message Attaching, Fastening, References

Hi, With recent discussions on Message Attachments, Message Fastening, References, SIMS, edits (LMC, but any message) and Reactions, I took (quite) some time to write up a post [1] showing how they all could fit together. Lots of examples, and how they could be rendered. I took the liberty

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

On 03/09/2019 15.02, Andrew Nenakhov wrote: вт, 3 сент. 2019 г. в 17:14, Philipp Hancke >: 0353 was explicitly designed for push (by not including the full payload due to size constraints) in conjunction with 0357 and should not go to MAM

[Standards] XMPP Summit 24: January 30/31 2020

Hi, Summer is almost over and the FOSDEM team has announced the dates of FOSDEM 2020: Saturday 1 and Sunday 2 February. As usual the XSF will organise the anual European XMPP Summit ahead of FOSDEM. So put these dates in your calendar and start planning your visit: * Thursday 30 January *

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

On June 30, 2019 5:20:09 PM GMT+02:00, Sam Whited wrote: >On Sun, Jun 30, 2019, at 15:16, Ralph Meijer wrote: >> Hmm. On which port? I want to point out explicitly that although 5223 >> has been used a bunch since before the IETF standardization, IANA has >> assigned it

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

On June 30, 2019 5:07:08 PM GMT+02:00, Sam Whited wrote: >On Sun, Jun 30, 2019, at 14:58, Ralph Meijer wrote: >> Just to be clear, in the same way as for xmpp-client, as per RFC >2782? > >I think so; I meant by fetching the A/ record of the domain part of >the JID

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

On June 30, 2019 4:45:40 PM GMT+02:00, Sam Whited wrote: >On Sun, Jun 30, 2019, at 09:54, Dave Cridland wrote: >> 1) It's not A/ fallback "as per RFC 6120", because we're talking >>about a Direct TLS fallback. It should be per section... erm... >> 2) This document doesn't mention a A/

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

On June 30, 2019 11:53:39 AM GMT+02:00, Dave Cridland wrote: > [..] >OK, two comments, which are essentially both my fault: > >1) It's not A/ fallback "as per RFC 6120", because we're talking >about >a Direct TLS fallback. It should be per section... erm... >2) This document doesn't mention a

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

On June 29, 2019 4:32:15 PM GMT+02:00, "Jonas Schäfer" wrote: >Hi list, > >It is not clear to me how to interpret, in a library connecting to an >XMPP >service, a single SRV record for _xmpps-{client,server} which has `.` >as the >target. > >For RFC 6120 _xmpp-{client,server} records (note the

Re: [Standards] SIMS issues

On 19/06/2019 19.46, Sergey Ilinykh wrote: Hi I mostly implemented SIMS in Psi and see next problems 1) The requirement for top-level reference element looks strange.    In Most of the case when I want to share something, I don't want to refer to anything.    If I really want to have a

Re: [Standards] Stanza Content Encryption

Hi, Dave, thanks for explaining why we have traditionally accepted specifications early. The IPR angle might not necessarily be compelling for some, but we have had issues around this before. Other organizations have similar policies, and IETF even has stronger ones, which include all

Re: [Standards] MIX

Hi, I started working on this reply last week, I still need to fully address the PubSub/MAM/MIX thing, but that'll have to be a separate message. The rest is below. On 12/03/2019 13.00, Dave Cridland wrote: Hi all, I've been writing a quick and dirty implementation of MIX. > > [..] > *

Re: [Standards] Proposed XMPP Extension: DNS Queries over XMPP (DoX)

On 13/03/2019 15.09, Travis Burtrum wrote: On 3/13/19 3:40 AM, Philipp Hörist wrote: Whats the use case for this XEP? Until now i only needed DNS querys to connect to the XMPP Server, i see this XEP is not helping with that as it already needs an active connection to the XMPP Server. Like

Re: [Standards] Tidying Deferred

On 17/01/2019 14.29, Georg Lukas wrote: [..] I agree with the idea of crowd-sourcing the review of Deferred XEPs, and to allow anyone to propose them for LC, with the LC resulting in either of: - Rejected or Obsolete (we have consensus that this is a dead end) - Experimental with new author

Re: [Standards] Tidying Deferred

On 17/01/2019 12.43, Dave Cridland wrote: On Thu, 17 Jan 2019 at 10:38, Ralph Meijer <mailto:ral...@ik.nu>> wrote: Unfortunately, XEP-0001 seems to require an updated version for moving it out of Deferred back to Experimental. I doesn't seem a reasonable requiremen

Re: [Standards] Tidying Deferred

On 17/01/2019 11.25, Evgeny wrote: On Thu, Jan 17, 2019 at 1:05 PM, Dave Cridland wrote: we do not require it until Final - not even Draft has an absolute requirement. I thought transitioning to Draft requires Call For Implementors, but whatever. Again this raises a question about how sane

Re: [Standards] Tidying Deferred

On 17/01/2019 10.19, Ненахов Андрей wrote: I'd suggest not accepting XEPs without any kind of existing technical implementation in the future. If one suggests a standard extension, he should provide a working software that supports it. This is explicitly not how our standards process has been

Re: [Standards] Tidying Deferred

Replying to Dave and Goffi in one go: On 17/01/2019 10.19, Goffi wrote: Hello, Le jeudi 17 janvier 2019, 09:55:17 CET Dave Cridland a écrit : On Wed, 16 Jan 2019 at 20:48, Tedd Sterr wrote: Three things leap out at me: 1) Is it worth "cleaning Deferred"? That is, is having 177 documents in

Re: [Standards] MIX: Getting hold of your own participant ID

On 2018-12-07 10:27, Daniel Gultsch wrote: [..] However it would be nice to also figure out by looking at the JID if that message might be a reflection or a message from ourself. Isn't this case covered by the inclusion of the as per example 30 (XEP-0369) and the prose just above it? The

[Standards] MIX channel info and xml:lang. Was: Re: MIX (XEP-0369) post-summit update to 0.8

On 20/02/2017 04.32, Steve Kille wrote: On 16 February 2017 19:51, Jonas Wielicki wrote: I’m having trouble with § 3.9.7 and Example 4. The text says: The name and description values MUST contain a "text" element and MAY contain additional text elements. Where multiple text elements are

Re: [Standards] MIX: The Nick Name Problem (TM) aka The Identity Crisis (TM)

On 29/11/2018 13.09, Daniel Gultsch wrote: Hi, [..] So let me paint you a picture of my use case. In WhatsApp the user creates an account; usually tied to a phone number - but that’s not the point; and sets a Name and an Avatar. That name isn’t unique. It would be pretty stupid if WhatsApp

Re: [Standards] MIX (XEP-0369) channel discovery

odes. It's the only clash between the protocols. Seems fair to have the channel nodes be children of an abstract mix node. But this should only be needed for disco#items, not disco#info. Dave. On Thu, 20 Sep 2018 at 08:43, Ralph Meijer <mailto:ral...@ik.nu>> wrote: Hi, Recently

[Standards] MIX (XEP-0369) channel discovery

Hi, Recently I have been looking at discovery of entities to determine what kind of thing it is, knowing nothing more than its JID. The starting point is a client that shows a list of entities, based on past conversations (MAM), ordered by last interaction. Entities could be regular user

Re: [Standards] XEP-0060: "entity element" should be "subscription element"

Hoi Melvin, Thanks for your comment. I agree this is likely a leftover. If you want, you can create a pull request over at https://github.com/xsf/xeps. Otherwise, just attach a patch to an email here. -- ralphm From: Melvin Vermeeren Sent: Friday, July 27,

Re: [Standards] XEP-0369: MIX - About create a room/channel

On 2018-04-24 09:09, Steve Kille wrote: -Original Message- From: Standards <standards-boun...@xmpp.org> On Behalf Of Ralph Meijer Sent: 23 April 2018 21:41 So, does that mean you can create a room in such a way that you lack full control over? That doesn't sound optimal, alth

Re: [Standards] XEP-0369: MIX - About create a room/channel

On April 23, 2018 5:34:06 PM GMT+02:00, Steve Kille wrote: > > >> -Original Message- >> From: Manuel Rubio >> Sent: 23 April 2018 16:12 >> To: XMPP Standards >> Cc: Steve Kille >> Subject: Re:

Re: [Standards] RFC 6120 vs. Bind2 XEP

On 06-02-17 15:53, Marvin Gülker wrote: On Mon, Feb 06, 2017 at 03:25:15PM +0300, Evgeny Khramtsov wrote: I guess that's your opinion? Or where is it stated in the RFC? is a mandatory-to-negotiate feature (at least if included), thus, clients MUST NOT ignore it. I tend to agree with this.

Re: [Standards] RFC 6120 vs. XEP

On 07-02-17 13:41, Marvin Gülker wrote: Hi, On Mon, Feb 06, 2017 at 04:46:58PM -0700, Peter Saint-Andre wrote: RFC 6120 author here. :-) Great! :-) Note that the order of features matters. In the Bind2 proposal, the order is this: I have to disagree. RFC 6120, section 4.3.2 says this,

[Standards] FOSDEM 2017 RTC Devroom and XMPP Summit

Hi all, Daniel Pocock has once again been taken on the job of managing the submissions for the Real-Time Communications developer room at FOSDEM. I'm sure you've seen his reminders for the CfP [1]. He mentioned that there a quite a number of submissions, but not so many on XMPP specifically,

Re: [Standards] SASL's DIGEST-MD5: host or domain?

On August 16, 2016 4:51:51 PM GMT+02:00, Christian Schudt wrote: >Hi, > > > >when using Java's SASL API [1], you would use the following to create a >SASL client for DIGEST-MD5 authentication: > > > >Sasl.createSaslClient("DIGEST-MD5", authzid, "xmpp", serverName,

Re: [Standards] SASL's DIGEST-MD5: host or domain?

On August 16, 2016 3:09:31 PM GMT+02:00, Kurt Zeilenga wrote: > >> On Aug 16, 2016, at 5:41 AM, Guus der Kinderen > wrote: >> >> Interoperability problems galore! > >Welcome to DIGEST-MD5! > >I recommend avoiding this mechanism. Use SCRAM

Re: [Standards] XEP-0375: View from Openfire

On 2016-07-12 05:11, Sam Whited wrote: > I've tried to address some of this feedback here: > > https://github.com/xsf/xeps/pull/206 > > I think the only thing I left out was getting rid of the IM compliance > suites (in case any of the IoT crowd chime in). > > I also added MIX as a possible

Re: [Standards] MIX progress

On 2016-07-05 12:23, Kevin Smith wrote: > On 5 Jul 2016, at 11:21, Florian Schmaus wrote: >> >> On 05.07.2016 12:07, Kevin Smith wrote: >>> On 5 Jul 2016, at 11:06, Florian Schmaus wrote: On 05.07.2016 11:10, Kevin Smith wrote: > On 5 Jul 2016,

Re: [Standards] A MIX Tape of suggestions.

On 23-05-16 13:28, Dave Cridland wrote: 2) Creation There's no way to create a room. Given the complexities of room locking in '45, I'd like to have an explicit create, and I have a reasonably strong preference (not absolute) to having this directed to the service rather than a non-existent

Re: [Standards] A new SASL Profile strawman

On 04-05-16 20:45, Lance Stout wrote: On May 4, 2016, at 7:00 AM, Dave Cridland <d...@cridland.net> wrote: Folks, I had a nice chat with Ralph Meijer, and we idly discussed replacing the SASL profile in order to gain access to 2FA, fold in the Stream Resumption (Florian Schmaus's

[Standards] Pubsub Account Management (PAM)

Hi, What is the status of the PAM proposal [1]? I found that it was approved as experimental XEP by the Council on February 3, but I don't see it published. Has this slipped through the cracks? [1] -- Cheers, ralphm

[Standards] Who's coming to FOSDEM / XMPP Summit 19?

Hi all, Looking at the list of participants at for the upcoming Brusses summit at , I notice that 12 people have signed up to attend, so far. In order to plan Summit Lunches and the XSF Dinner, I have to know how many people are coming. If you do plan on

[Standards] Fwd: [jdev] [CFP] FOSDEM 2016, RTC devroom, speakers, volunteers neeeded

Contact === For discussion and queries, please join the free-rtc mailing list: https://lists.fsfe.org/mailman/listinfo/free-rtc The dev-room administration team: Daniel Pocock <dan...@pocock.pro> Ralph Meijer <ral...@ik.nu> Saúl Ibarra Corretgé <s...@ag-projects.com> I

Re: [Standards] Deprecating IBR

On 2015-11-16 15:55, Matthew Wild wrote: > I understand that open registration is a > problem on the federated network, but it's not a protocol issue and > XEP-0077 as a protocol should not be deprecated. Agreed. It is mostly about what happens after registration, too. In the end, for spammers it

Re: [Standards] Deprecating Privacy Lists

On 2015-10-12 21:20, Evgeny Khramtsov wrote: > Mon, 12 Oct 2015 16:04:43 -0300 > Ben Langfeld wrote: > >> "We want to deprecate Privacy Lists because we think it's a bad spec." >> "You'll have to write a good spec first!" >> "A good spec would be nice. Do you (or anyone else in

Re: [Standards] Deprecating Privacy Lists

On 2015-10-06 19:24, Evgeny Khramtsov wrote: > Tue, 6 Oct 2015 11:35:58 -0500 > Sam Whited wrote: > >> and I doubt that >> anyone's going to try and come up with a new thing *unless* the old >> one is deprecated > > The thing is nobody will come up even in the case the XEP

Re: [Standards] Deprecating Privacy Lists

On 2015-10-08 12:52, Evgeny Khramtsov wrote: > Thu, 8 Oct 2015 12:21:41 +0200 > Ralph Meijer <ral...@ik.nu> wrote: > >> If nobody comes up with a new specification for >> functionality beyond XEP-0191, then my conclusion would be that there >> is no sufficient

Re: [Standards] XEP-0060: be more consistent with reply #106

On 2015-10-05 10:48, Stefan Strigler wrote: > Hey there, > > when implementing parts of XEP-0060 I came across a maybe inconsistency > when it's about unsubscribing from a Node (Section 6.2.2 > - http://xmpp.org/extensions/xep-0060.html#subscriber-unsubscribe). > > If we'd allow to also have a

[Standards] 18th XMPP Summit -- October 9-10 -- Richland, WA, USA

booking at the Columbia River, contact mailto:c...@andyet.com. For questions about XSF Summit content, schedule, and plans, contact Ralph Meijer (mailto:ral...@ik.nu or xmpp:ral...@ik.nu). -- Cheers, ralphm

Re: [Standards] Move Carbons to Last Call (Proposed)

On August 12, 2015 4:50:18 PM GMT+02:00, Kevin Smith kevin.sm...@isode.com wrote: On 12 Aug 2015, at 15:44, Ralph Meijer ral...@ik.nu wrote: On August 12, 2015 3:07:44 PM GMT+02:00, Kevin Smith kevin.sm...@isode.com wrote: The thread is moving somewhat away from Carbons Last Calls

Re: [Standards] Move Carbons to Last Call (Proposed)

On August 12, 2015 3:07:44 PM GMT+02:00, Kevin Smith kevin.sm...@isode.com wrote: The thread is moving somewhat away from Carbons Last Calls, but this is all related so I won’t feel too guilty. I have two opinions here: [..] 2) Carbons will need some changes in the (hopefully near) future once

Re: [Standards] Move Carbons to Last Call (Proposed)

On August 12, 2015 5:31:25 PM GMT+02:00, Kevin Smith kevin.sm...@isode.com wrote: On 12 Aug 2015, at 16:14, Ralph Meijer ral...@ik.nu wrote: On August 12, 2015 4:50:18 PM GMT+02:00, Kevin Smith kevin.sm...@isode.com wrote: On 12 Aug 2015, at 15:44, Ralph Meijer ral...@ik.nu wrote

Re: [Standards] Move Carbons to Last Call (Proposed)

On August 12, 2015 11:54:06 AM GMT+02:00, Dave Cridland d...@cridland.net wrote: On 12 August 2015 at 09:01, Georg Lukas ge...@op-co.de wrote: The carbon relevant things from that list and from the last 0280 advance discussion are: * Carbons for non-chat messages. Jingle signalling of

Re: [Standards] OTR

On February 3, 2015 10:37:14 AM WAT, Florian Schmaus f...@geekplace.eu wrote: On 03.02.2015 10:04, Dave Cridland wrote: On 2 Feb 2015 18:49, Peter Saint-Andre - yet pe...@andyet.net mailto:pe...@andyet.net wrote: On 2/2/15 5:22 AM, Hund, Johannes wrote: Since it was undisclosed that even the

Re: [Standards] xep-0060 features delete-items and retract-items

On 2015-01-08 14:37, Edwin Mons wrote: On 08/01/15 14:18, Kurt Zeilenga wrote: On Jan 7, 2015, at 9:27 AM, Ralph Meijer ral...@ik.nu wrote: On 2015-01-07 16:15, Adrien wrote: Hi, On 01/07/2015 03:42 PM, Edwin Mons wrote: Hi all, XEP-0060 lists both delete-items and retract-items

Re: [Standards] xep-0060 features delete-items and retract-items

On 2015-01-08 14:52, Kurt Zeilenga wrote: On Jan 8, 2015, at 5:37 AM, Edwin Mons j...@edwinm.ik.nu wrote: On 08/01/15 14:18, Kurt Zeilenga wrote: On Jan 7, 2015, at 9:27 AM, Ralph Meijer ral...@ik.nu wrote: On 2015-01-07 16:15, Adrien wrote: Hi, On 01/07/2015 03:42 PM, Edwin Mons wrote

Re: [Standards] xep-0060 features delete-items and retract-items

On 2015-01-07 16:15, Adrien wrote: Hi, On 01/07/2015 03:42 PM, Edwin Mons wrote: Hi all, XEP-0060 lists both delete-items and retract-items for the same feature, retract/. delete-items was added in the last revision, but it looks like an error to me. I think 7.2 should be revised, and

Re: [Standards] Veto on Privileged Entity

On 2014-12-17 14:24, Kurt Zeilenga wrote: [..] It seems you are holding this ProtoXEP hostage for a general discussion and possibly more (“a better system”?). Hi, I haven't fully digested all words in this thread. However, I think I understand the general idea of the arguments being made by

Re: [Standards] Last call XEP-0322 XEP-0332

On 2014-11-13 15:59, Peter Waher wrote: Hello everybody Sorry for being out of touch and not having responded to the many mails. I’ve been overwhelmed by work, and have had to focus on certain things to be able to clear things up. It is my plan to retake the effort, review all input

Re: [Standards] OTR

On 2014-11-14 22:25, Genghis Khan wrote: On Sun, 09 Nov 2014 10:46:58 +0100 Winfried Tilanus winfr...@tilanus.com wrote: On 07-11-14 15:39, Stefan Strigler wrote: Hi, But will you mention http://thealiceandbobsuicide.org ? That is quite a dilemma, you know, I am still missing Alice and

Re: [Standards] IOT-Events

On 2014-09-26 15:26, Kevin Smith wrote: Hi folks, I promised to see if I could think of something sensible to say about IOT-Events. My core concern here is that this spec (http://xmpp.org/extensions/inbox/iot-events.html) is designed such that one entity can publish events, to which

Re: [Standards] XEP-0045 to Final?

On 2014-03-05 11:16, Christian Schudt wrote: Hi, could you elaborate on this proposal a little bit, please? Agreed. I'm a more of a fan of publish-subscribe than the next guy, but I don't see how this is a helpful suggestion without elaboration. Going back to the original question, I don't

Re: [Standards] XEP-0045 to Final?

On 2014-03-05 12:48, Winfried Tilanus wrote: [..] Well, I *assumed* your MUC implementation did not support this. Assuming that, you can try to change your MUC implementation (leaving alone the question if a change to XEP-0045 is needed). But when you have to change your MUC

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

On 2013-11-18 13:07, Andreas Kuckartz wrote: Simon Tennant: IMHO, e2e security would probably make more sense as a XEP and working group that has the time to zoom into all the implementation details. Can that be solved by an XEP ? What about this IETF draft? (I still have to read it)

Re: [Standards] Suggestions for updates to XEP-0071: XHTML-IM

On 2013-11-06 13:41, Peter Waher wrote: Hello Ralph What could be required is to support the markup (and not reject the XHTML as a whole), and either be able to render a small subset or use a valid fallback mechanism (as that explained in Example 8 in the extension). The fallback

Re: [Standards] Suggestions for updates to XEP-0071: XHTML-IM

On 2013-11-04 21:55, Peter Waher wrote: Hello all I have some suggested additions to the XHTML-IM extension XEP-0071 (which is still in Draft). [..] Tables are explicitly forbidden in the current version for the following reasons [..] Forbidden seems a particularly strong

Re: [Standards] Suggestions for updates to XEP-0071: XHTML-IM

On 2013-11-05 13:53, Peter Waher wrote: [..] I would however *not* explicitly require support for tables, as that would imply no IM client could be considered properly compatible with the XEP-0071 without support for rendering HTML tables. What could be required is to support the markup

Re: [Standards] Proposed XMPP Extension: JSON Containers

Please don't top post. Reformatted below. On 2013-10-09 18:58, DOI Yusuke wrote: On 2013-10-09 18:46, Maxim Ignatenko wrote: On 9 October 2013 16:20, XMPP Extensions Editor edi...@xmpp.org wrote: Abstract: This specification defines an element to be used for encapsulating JSON data in XMPP.

Re: [Standards] Proposed XMPP Extension: JSON Containers

On 2013-10-09 19:45, Ralph Meijer wrote: Please don't top post. Reformatted below. On 2013-10-09 18:58, DOI Yusuke wrote: On 2013-10-09 18:46, Maxim Ignatenko wrote: On 9 October 2013 16:20, XMPP Extensions Editor edi...@xmpp.org wrote: Abstract: This specification defines an element

Re: [Standards] XMPP Standards Foundation and XEP-0001

SM s...@resistor.net wrote: Hello, According to XEP-0001: The XMPP Standards Foundation (XSF) adheres to an open standards process I browsed through the www.xmpp.org web site. I found some meeting minutes at http://xmpp.org/about-xmpp/xsf/meeting-minutes/ The minutes for the past year is

Re: [Standards] Heml.is and federation..

On 2013-07-12 20:56, Steffen Larsen wrote: Hi, I just stumbled upon https://heml.is, which is a new XMPP client for IOS and Android. Anyone knows these guys? It uses XMPP and PGP for encryption, but do any of you guys know if they federate?.. What I can see from skimming their page, its yet

Re: [Standards] XMPP URI usage in HTTP over XMPP

On 2013-07-10 22:27, Dave Cridland wrote: So, to be able to create such a seamless transition (which is also important in semantic web scenarios) we need an URI scheme that works in a syntactically identical manner as the already existing http URI scheme. Now, there exists another such URI

Re: [Standards] XMPP URI usage in HTTP over XMPP

Peter Saint-Andre stpe...@stpeter.im wrote: hat type='registrar'/ On 7/9/13 9:53 PM, Peter Waher wrote: Hello Ralph Thanks for your mail. You're absolutely correct. It was sloppy of me to propose a URI scheme with the same name as the previous xmpp scheme. I'm sorry. [ .. ] Defining a

[Standards] XMPP URI usage in HTTP over XMPP

Hi, The usage of the xmpp URI scheme in the HTTP over XMPP proposal does not conform to the syntax and semantics defined in RFC 5122. In the following I will use URI terminology as defined in RFC 3986 (URI: Generic Syntax) to explain how XMPP URIs are structured. The syntax of any URI is as

Re: [Standards] Fwd: Re: [Netconf] XMPP as transport

On 2013-07-03 22:17, Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FYI, yet more potential customers for XMPP. Join the IETF NETCONF list if you're interested. Indeed. Michal Vaner recently wrote [1] to this list about that effort, too. [1]

Re: [Standards] Proposed XMPP Extension: SIP/SDP Over XMPP (SoX)

On 2013-06-13 09:06, Philipp Hancke wrote: [..] The use of trickle might be interesting... basically that would be the example from http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00#section-4 (note that m-line-id should be mid there) Please, do not copy examples, but create new

Re: [Standards] Proposed XMPP Extension: SIP/SDP Over XMPP (SoX)

On 2013-06-13 15:48, Alexey Melnikov wrote: On 13/06/2013 12:35, Ralph Meijer wrote: On 2013-06-13 09:06, Philipp Hancke wrote: [..] The use of trickle might be interesting... basically that would be the example from http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00#section-4

Re: [Standards] ProtoXEP offered; google:queue

On 2013-05-23 16:55, Dave Cridland wrote: On Thu, May 23, 2013 at 3:49 PM, Peter Saint-Andre stpe...@stpeter.im mailto:stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/23/13 1:55 AM, Dave Cridland wrote: The timing's now reached the perfect level

Re: [Standards] XEP 202

On 2013-05-22 12:22, Sergey Dobrov wrote: Hello, Don't you forget to specify user's resource in the to iq's attribute? This is a very good point. Let me clarify. If you send iq/ stanzas to a user's bare JID, these are to be handled by the server on behalf of the user. It makes sense that

  1   2   >