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

If I understand the suggested change correctly, it's mostly a cosmetic one. That, to me, is not worth risking relaxing a definition/restriction that we made in 0001 (which is quite the core of what we're basing things on). I'm in camp "let's live with the wart". - Guus On Tue, Mar 12, 2024 at

[Standards] Re: Proposed XMPP Extension: HTTP Online Meetings

Hello! Thank you for your feedback. Dele and I discussed Marvin's comments, and agreed with his suggestion. We will provide an update to XEP-0483 to refer to XEP-0482 for the applicable functionality described therein. Kind regards, Guus On Mon, Dec 11, 2023 at 6:04 PM Daniel Gultsch wrote:

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

t; > > > Hallo Guus, > > > > Thanks for sharing your thoughts. In my comments below, I haven't yet > > provided suggested text, but I wanted to reply quickly and I will > send > > another note when I can make concrete proposals. > > > >

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

Hello, Thank you for the work that has gone into this. To me, the document is clearly worded. I would appreciate elaboration on the sentence "Humour is not a mitigating factor here" in section 2.3. An additional suggestions is to add a reminder that we do not all share a common cultural

[Standards] Re: Proposed XMPP Extension: Reporting Account Affiliations

Hi all, I've been toying with an Openfire-based implementation for the Reporting Account Affiliations plugin. The plugin has not seen much real-world use yet (it barely has been smoke tested). So far, I've only implemented the 'reporting' functionality (the Info-request query mechanism, and the

[Standards] Re: Wrapping up the XMPP Lemmy Experiment

I fear that this never lived up to its potential. Unless someone is actively going to do something with this, I'd not let it linger. That only adds to fragmentation and overhead. Too bad though. - Guus On Tue, Jun 6, 2023 at 1:45 PM Sam Whited wrote: > Hi all, > > It's been over a year and

[Standards] XEP - 0045: nick attribute in member/owner/admin lists

Dear XMPP aficionados, XEP-0045 section 9.5[1] defines a to-be returned member list as follows: "The service MUST then return the full member list to the admin qualified by the 'http://jabber.org/protocol/muc#admin' namespace; each item MUST include the 'affiliation' and 'jid' attributes and MAY

Re: [Standards] XEP-0227 update

Hi Matt, Thanks for reviving this thing. It was indeed pretty outdated. Openfire has an implementation too, although I'm not aware if it was ever tested against other servers. Should we consider introducing a change to the namespace as used in the portable data, to more explicitly handle the

Re: [Standards] Proposed XMPP Extension: DOAP usage in XMPP

My thoughts: Informational. I believe that the XSF should be concerned more with maintaining the XMPP standards than it should be concerned with ensuring that information regarding projects that relate to XMPP is made available in a structured fashion (which are covered by the other two options

Re: [Standards] Use of XEP-0198 resumption under adverse network conditions

Hi Dave, Thanks for sharing this. To verify that I got it wrong, can I dumb your suggestions down by summarizing them as: - Increase the timeout after which a connection is considered unrecoverably dead (to ... how many minutes?) - After a period of inactivity that's a lot shorter than

Re: [Standards] Very Simple Questions about Compliance Suites

We have not, for Openfire. We've never had anyone ask us if the product has a particular level of compliance either. That's not to say that there is no interest, but I believe there's not much interest, at least not in our community. I'd be happy to start including compliance claims, but,

Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)

Hi Jonas, Thanks for all of the effort that you're putting into this. A concern that I have with the shared gitlab/github solution is that it has a lot of moving parts, a lot of dependencies, and a lot of places where things can go wrong. Complexity of the implementation increases (to save

Re: [Standards] XEP-0289 FMUC: Do joined nodes know what mode is configured?

back, indicating that it is an echo (a 'status 110'-like solution). d) Have the joining node persist each stanza that it sends to the joining node, allowing it to evaluate each inbound stanza to determine if it's an echo. Thoughts? On Mon, 4 May 2020 at 12:53, Guus der Kinderen wrote: > He

[Standards] XEP-0289 FMUC: Do joined nodes know what mode is configured?

Hello all, A XEP-0289 FMUC question, related to section 5.2 ( https://xmpp.org/extensions/xep-0289.html#messages ). The example describes how a joining FMUC node (elsinore) sends a message to the joined FMUC node (rabbithole). Federation is configured to use the master-slave mode (where

Re: [Standards] Call for Experience: XEP-0198: Stream Management

You've clearly never experienced my parent's WiFi. Op vr 21 feb. 2020 09:25 schreef Daniel Gultsch : > Only someone who hasn't been on a German high speed train can say with > confidence that desktop and web clients don't need stream management. > ___

Re: [Standards] Council Minutes 2020-02-05

On Mon, 10 Feb 2020 at 11:10, Dave Cridland wrote: > PEDANTRY WARNING! > > Welcome back. > On Thu, 6 Feb 2020 at 23:03, Tedd Sterr wrote: > >> http://logs.xmpp.org/council/2020-02-05?p=h#2020-02-05-9b7fab88b70a9fc4 >> >> *1) Roll Call* >> Present: Georg, Jonas, Daniel, Zash >> Apologies:

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

On Tue, 14 Jan 2020 at 22:42, Jonas Schäfer wrote: > This message constitutes notice of a Last Call for comments on XEP-0363. > The > Last Call was restarted after the Council election, because the previous > Council did not vote on the ongoing LC. > > Title: HTTP File Upload > Abstract: > This

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

This XEP might want to add an implementation note that relates to https://xmpp.org/extensions/xep-0245.html. When XEP-0245 is used, clients often use a different representation of the message from what's in the body (eg: replacing "/me" with a nickname). This makes it very easy to make mistakes in

Re: [Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)

Thanks for the effort to push this well before the end of the year. :) On my first reading, I noticed two things: XEP-0385 "Stateless Inline Media Sharing (SIMS)" is mentioned both in section 1.1 "Changes since 2019", but also in section 3 "Future Development". Is that an error, or intended? I'd

[Standards] XEP-0059 RSM Before, after, index combinations

Hello, As far as I can tell, XEP-0059: Result Set Management does not clearly state how requests that include a combination of the before, after and index elements should be handled. It does not appear to make much sense to allow for this. Without having identified explicit use cases, I'd argue

Re: [Standards] Whitespace "ping"

it either. On Tue, 11 Jun 2019 at 14:24, Mickaël Rémond wrote: > Hello Guus, > > On 11 Jun 2019, at 14:00, Guus der Kinderen > wrote: > > What we need basically is a way to negotiate the interval with server > > > I'm not sure if this is _needed_? Without this being a

Re: [Standards] Whitespace "ping"

s though, it was 5+ years > ago since we tested it. Also, I think that in current state of affairs the > way to go are push notifications, and thus the need for ping is somewhat > diminished. > > вт, 11 июн. 2019 г. в 17:01, Guus der Kinderen < > guus.der.kinde...@gmail.com>:

Re: [Standards] Whitespace "ping"

> > What we need basically is a way to negotiate the interval with server I'm not sure if this is _needed_? Without this being a requirement, much of the complexity of "making this more standard" falls away. A server could, before determining that a connection is lost, attempt to send any IQ

[Standards] XMPP Compliance Badges, prototype feedback requested.

Hello, There's an effort under way to have developed visual badges associated to the XMPP Compliance Suites. To my knowledge, three variants of badges are under development: - https://op-co.de/tmp/xmpp-compliance-badges/ - https://bitbucket.org/mrtedd/compliance-badges/src -

Re: [Standards] MIX Implementation (Prosody module)

Your cat has skills! On Mon, 1 Apr 2019 at 11:04, Tedd Sterr wrote: > I wasn't at the Berlin sprint, so I held my own mini-sprint - at home, > pair-programming with my cat - which mainly involved me coding and her not > paying any attention. After an extended weekend, too much caffeine, and >

[Standards] XEP-0313 / XEP-0359 interaction

XEP-0313 "Message Archive Management" (v0.6.3) relies on XEP-0359 "Unique and Stable Stanza IDs" to identify content in the archive. MAM provides an archive on the server, which can be efficiently synchronized with a client-sided archive. It does this using the IDs from XEP-0359. It's a simple

Re: [Standards] Is the World Ready for Compliance Suites 2019?

I'm very much in favor of not applying changes to the 2019 suite that can wait for the 2020 edition. On Thu, 7 Mar 2019 at 08:39, Daniel Gultsch wrote: > Am Mi., 6. März 2019 um 21:07 Uhr schrieb Georg Lukas : > > Example 1: "Modern" Use of OOB for Inline Images > > > >

Re: [Standards] Third month with no updated compliance suites

I do not dislike publishing the Compliance Suite content as part of the website. It will make things more clear. I do not believe, however, that the process of choosing what goes on that page is going to be faster, as compared to doing this as a XEP. If anything, for a XEP, we have a process. On

Re: [Standards] Confusing Language in XEP-0261 (Jingle In-Band Bytestreams Transport Method)

Hi Larry, I don't think that this mailinglist is the right place to discuss your questions. Although I'm not familiar with your issue, I think you should address them at Google, not the XMPP standards mailinglist. I suggest that you start at https://support.google.com/ and see where that gets

Re: [Standards] XMPP Council Minutes 2018-12-19

/me points at dwd What he said. On Fri, 21 Dec 2018 at 10:11, Dave Cridland wrote: > Hi folks, > > There were two heavy chunks of "Process" in this meeting. Surprisingly, I > hate process - as anyone I've worked with can attest - but I'm usually the > one defending it, so here I go again. > >

Re: [Standards] NEW: XEP-0412 (XMPP Compliance Suites 2019)

Hi Jonas, To clarify: - There is absolutely no indication that anyone tried to pressure anyone into doing anything. Board's comment can be seen as to wanting to prevent such leverage to become possible in the future, by establishing a precedent of keeping prematurely published XEPS

Re: [Standards] Server status pages

I need to hurt my eyes to squint hard enough for this to fit in XEP-0157. I don't have an alternative available, though. - Guus On Mon, 3 Dec 2018 at 11:03, Matthew Wild wrote: > Hi all, > > I'd like to allow servers to advertise status pages to their users. > See for example

[Standards] Summit 23 (Brussels, Belgium) announcement

Hello, The XMPP Standards Foundation (XSF) will hold its 23th XMPP Summit in Brussels, Belgium, on Thursday January 31st and Friday February 1st 2019. These are the two days preceding FOSDEM 2019. The XSF invites you all to attend, and discuss all things XMPP! If you're interested in attending,

Re: [Standards] UPDATED: XEP-0198 (Stream Management)

Changelog date is off by a year, I think? On Fri, 6 Jul 2018 at 09:18, Jonas Wielicki wrote: > Version 1.5.3 of XEP-0198 (Stream Management) has been released. > > Abstract: > This specification defines an XMPP protocol extension for active > management of an XML stream between two XMPP

Re: [Standards] the meaning of "MUST be empty"

On Tue, 19 Jun 2018 at 13:47, Kevin Smith wrote: > On 19 Jun 2018, at 12:09, Bartłomiej Górny < > bartlomiej.go...@erlang-solutions.com> wrote: > > > > Hi > > > > If a XEP states that an attribute "MUST be empty", does it mean that it: > > a) must be present and have a value "" > > b) must not

Re: [Standards] the meaning of "MUST be empty"

I don't remember ever making use of a. I'd expect implementations to generate b, but accept c. On Tue, 19 Jun 2018, 13:11 Bartłomiej Górny, < bartlomiej.go...@erlang-solutions.com> wrote: > Hi > > If a XEP states that an attribute "MUST be empty", does it mean that it: > a) must be present and

Re: [Standards] Proposed XMPP Extension: Best practices for GDPR compliant deployment of XMPP

> > I'm curious as to what the concerns with the XSF offering anything that > might be considered "legal advice" actually are. > 1. Liability. 2. Giving the wrong advice. On Fri, 25 May 2018 at 23:08, Dave Cridland wrote: > Since we're sitting on this for a bit, I'm curious as to what the

Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

On 18 March 2018 at 18:56, Jonas Wielicki <jo...@wielicki.name> wrote: > On Sonntag, 18. März 2018 18:48:49 CET Guus der Kinderen wrote: > > Having implemented 0048 via 0223 earlier this week, I can only applaud an > > effort of making the documentation eas

Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

Having implemented 0048 via 0223 earlier this week, I can only applaud an effort of making the documentation easier to digest. Thanks for this! I am, however not sold on the idea of having a bookmark-per-item: what problem is that solving, or what benefit does this give us? I appreciate how it

[Standards] Private Data storage discrepancy

Hello, I'm working on migrating Bookmarks ( https://xmpp.org/extensions/xep-0048.html) from Private XML Storage ( https://xmpp.org/extensions/xep-0049.html) to PEP ( https://xmpp.org/extensions/xep-0223.html). I'm was surprised to find a difference between the Pubsub node defined in 0048 example

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

Primarily due to security concerns. There's a lot of discussion available in the mail archive. This is a good place to start: https://mail.jabber.org/pipermail/standards/2017-October/033546.html On 7 March 2018 at 17:13, Kozlov Konstantin wrote: > I wonder, why this one was

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

On 22 February 2018 at 12:34, Kevin Smith wrote: > On 21 Feb 2018, at 21:35, Ruslan N. Marchenko wrote: > > > > Am Mittwoch, den 21.02.2018, 16:17 + schrieb Kevin Smith: > >> On 21 Feb 2018, at 13:21, Jonas Wielicki wrote: > >>> >

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

se confusion in the client being terminated. Regards, Guus On 7 February 2018 at 20:57, Ruslan N. Marchenko <m...@ruff.mobi> wrote: > Am Mittwoch, den 07.02.2018, 08:40 +0100 schrieb Guus der Kinderen: > > > I propose that the XEP is updated with an instruction to, upon detection &

[Standards] XEP-0198: Stream should be closed when 'h' value is to high

Hello, XEP-0198 Stream Management relies on a stanza count that is being send as an acknowledgement that a certain amount of session data has been received (the 'h' value). The XEP does not specify what should happen if the acknowledgement is off - when the remote entity appears to acknowledge

Re: [Standards] Proposal: Server selection for user-registration

We currently have a pre-existing central directories of XMPP domains at https://xmpp.net/directory.php - the code powering the observatory is available (the most up-to-date code is in Jonas' repo: https://github.com/horazont/xmppoke-frontend-docker ) The upside of that project is that it's an

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

On 29 November 2017 at 20:16, Jonas Wielicki wrote: > This message constitutes notice of a Last Call for comments on > XEP-0363. > > Title: HTTP File Upload > Abstract: > This specification defines a protocol to request permissions from > another entity to upload a file to a

Re: [Standards] Proposed XMPP Extension: Styling

On a side-note: please try to keep discussions positive. Not only does that make for a friendlier conversation, arguments are much more likely to be taken into consideration if you don't start off by putting people off. On 15 November 2017 at 08:45, Evgeny Khramtsov wrote:

[Standards] Rename XEP status identifiers

Hello all, Should we rename the status names that we use in XEPs? One of the recurring criticisms about XMPP that I read is "Pretty-standard-feature XYZ has a XEP that is only "experimental"! By doing some window dressing, we will improve the perceived maturity and stability of the protocol.

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

d". Is this "legacy" connection method the > same as the one described in this XEP? If so, is this XEP also encouraging > direct TLS unlike those servers? > > > Guus der Kinderen 於 2017年09月23日 02:08 寫道: > > > Wait, what are we discussing again? >> >>

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

> Wait, what are we discussing again? > > We were discussing if I was fully, or completely right, of course. :-P Also, I again have to postpone my bikeshed-warming-party. It's not finished yet. Will let you know. ___ Standards mailing list Info:

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

On 22 September 2017 at 19:15, Florian Schmaus <f...@geekplace.eu> wrote: > On 22.09.2017 13:50, Guus der Kinderen wrote: > > I suggest to improve the wording of this XEP by replacing the command > > name "STARTTLS" with the technique name "Opportunisti

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

On 22 September 2017 at 15:58, Peter Saint-Andre <stpe...@stpeter.im> wrote: > On 9/22/17 5:50 AM, Guus der Kinderen wrote: > > I suggest to improve the wording of this XEP by replacing the command > > name "STARTTLS" with the technique name "Opportunist

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

I suggest to improve the wording of this XEP by replacing the command name "STARTTLS" with the technique name "Opportunistic TLS". This way, we're not comparing apples to oranges, when mentioning both in the same text. To retain clarity, this term should be added to the glossary, with a mention

Re: [Standards] XMPP Meetup during T-DOSE in Eindhoven (NL) in November

nterested to come, do a conference, a XMPP meetup or something > related, please put it on this page :) > > Regards, > > Timothée > > Le lundi 31 juillet 2017 à 12:18 +0200, Guus der Kinderen a écrit : > > Hi Timothée, > > > > Thanks for taking the time

Re: [Standards] Any XMPP Extension for sharing JIDs?

Hello, There are several ways that you could go about this. There is extended stanza addressing, "https://xmpp.org/extensions/xep-0033.html which lets you add additional addresses to a stanza. It's very bare-boned though. A more elaborate option would revolve around creating multi-user chat

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

uot;Block" and "Report" I'm all for a single report-spam-and-dont-get-any-from-that-jid-anymore, but I don't feel that we should require this to be built on XEP-0191. On 12 September 2017 at 13:35, Matthew Wild <mwi...@gmail.com> wrote: > On 12 September 2017 at 12:10, Guus

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Although I agree that not receiving messages from the reported entity is a good thing. I'm still not comfortable with embedding the spam-reporting in blocking functionality. I'd much more prefer a solution where spam is reported (as a stand-alone action, not embedded in a block), with an

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Blocking Reason and Spam Reporting 2.0 could happily coexist. :-) On 11 Sep 2017 23:32, "Sam Whited" wrote: > On Mon, Sep 11, 2017, at 16:29, Evgeny Khramtsov wrote: > > Let me answer. Because he thinks that those two actions should be > > always performed together. But in

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

wrote: > On Mon, Sep 11, 2017, at 15:29, Guus der Kinderen wrote: > > I'm not sure if the "reporting" bit should automatically go hand in hand > > with "blocking" specifically. There might be value in defining an entity > > that simply just receives spam rep

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

<s...@samwhited.com> wrote: > On Mon, Sep 11, 2017, at 15:21, Guus der Kinderen wrote: > > The integration with block is an optional part of the XEP, isn't it? I'm > > reading it as: spam can be reported to any entity that advertises > > support, > > and could

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

The integration with block is an optional part of the XEP, isn't it? I'm reading it as: spam can be reported to any entity that advertises support, and could be inlined with Block if/when desired. On 11 September 2017 at 21:56, Evgeny Khramtsov wrote: > Mon, 11 Sep 2017

Re: [Standards] HTTP-Upload: Content-based slots

Clearly, benefits, but I do wonder what can of worms this opens with regards to confidentiality. "Wait, someone else uploaded this?" There is also talks about being able to update content (which I personally dislike) - but your proposal adds quite a bit of complexity there too. >From a storage

Re: [Standards] Permanent slots for HTTP Upload

, Daniel Gultsch <dan...@gultsch.de> wrote: > 2017-09-08 11:04 GMT+02:00 Guus der Kinderen <guus.der.kinde...@gmail.com > >: > > Perhaps it'd be sensible to always add a reference to the desired > retention > > policy - also for temporary slots.

Re: [Standards] Permanent slots for HTTP Upload

Hi Daniel, Perhaps it'd be sensible to always add a reference to the desired retention policy - also for temporary slots. Perhaps the server should answer with the applied policy too? Regards, Guus On 8 September 2017 at 10:58, Daniel Gultsch wrote: > Hi all, > > when I

Re: [Standards] Proposed XMPP Extension: Jingle Encrypted Transports

On 31 August 2017 at 15:37, Peter Saint-Andre wrote: > On 8/31/17 1:59 AM, Dave Cridland wrote: > > On 30 August 2017 at 21:32, Daniel Gultsch wrote: > >> 2017-08-30 22:10 GMT+02:00 Paul Schaub : > >>> First things first: My

Re: [Standards] Call for participation for a XMPP-based EU Funded project on data portability

I think it'd be interesting to have XMPP be used as an EU standard for data portability (or for any other purpose, for that matter). That sounds like a good opportunity to further improve and promote the application of XMPP. I'm hopeful that the Board will act on this. I'm certainly interested in

Re: [Standards] XMPP Meetup during T-DOSE in Eindhoven (NL) in November

Hi Timothée, Thanks for taking the time to organize this! I'd certainly be interested in attending. As for XSF support: what exactly do you need? This year, the XSF created the SCAM (somethingsometing, Conferences And Meetups) workgroup (of which I may or may not be a part). I am not aware of

[Standards] Password-protecting a MUC room

XEP-0045 defines two `room_config` fields that relate to the password protection of a room: Arguably, setting the room password implies that a user wants the the room to be password protected. What is the purpose of having two fields? Should

Re: [Standards] XEP Authors

; wrote: > On 9 June 2017 at 08:49, Guus der Kinderen <guus.der.kinde...@gmail.com> > wrote: > > You're making sense to me (which appears to be a habit of yours > *hattip*). > > > > Dave's original question was if he should propose a policy change to the > >

Re: [Standards] XEP Authors

to pay attention. > I'm not convinced that it's the SDO's job to protect you from yourself. > My sense of the WebRTC-PC issue is that the spec author involved is very > busy and wasn't necessarily paying attention all the time. The solution > is to pay attention or remove yourself from the auth

Re: [Standards] XEP Authors

I am the first to admit that I have next to no legal knowledge, and I'm not familiar with the background other than reading the comment that Dave linked to, but: this feels like an overreaction to me. Because (American - how does this apply to other countries?) juries assume things, we need to

Re: [Standards] NEW: XEP-0387 (XMPP Compliance Suites 2017)

Thanks for getting the ball rolling on this one again, Sam. Is footnote 10 "Support can be enabled via an external component or an internal server module/plugin." relevant? I suggest o remove footnote 6, and simply make CAPS a requirement on it's own. - Guus On 9 February 2017 at 00:32, XMPP

Re: [Standards] 2017 Compliance Suites

Sam, you recently sparked a discussion on competing XEPs - obsoleting one of those is currently under vote at the council, if I skimmed over my emails correctly. Perhaps that's something that could be addressed in these suites - promote one XEP over another similar one? - Guus On 18 January

Re: [Standards] Easy XMPP

What I am doing here, first, and foremost, is having fun. Having gotten that out of the way: the discussion so far revolves around the use-case of a single user, wanting to do IM with friends. Undoubtedly that's an important part of the ecosystem (on which we can and should improve) but I've seen

Re: [Standards] "Self-destruct" message timeout deletion hints

Do I understand this correctly: this feature depends on the author of a message enabling an 'auto-destruct' flag? From a user perspective, I'd be terribly annoyed by that. There is hardly any added security or privacy value in this feature, and the the data hygiene that applies to my data is

Re: [Standards] Proposed XMPP Extension: Message Deletion

at 10:16, Guus der Kinderen <guus.der.kinde...@gmail.com> > wrote: > > On 18 October 2016 at 11:12, Kevin Smith <kevin.sm...@isode.com> wrote: > >> On 18 Oct 2016, at 10:09, Guus der Kinderen < > guus.der.kinde...@gmail.com> wrote: > >> > I don't

Re: [Standards] Proposed XMPP Extension: Message Deletion

com> wrote: > On 18 Oct 2016, at 10:09, Guus der Kinderen <guus.der.kinde...@gmail.com> > wrote: > > I don't have much of an argument other than the obvious: both affect > data 'after-the-fact'. Concerns raised against one should likely also be > tested against the other - i

Re: [Standards] Proposed XMPP Extension: Message Deletion

. Implementation-wise, it'd make sense to combine both efforts too, I'd say. On 18 October 2016 at 10:57, Dave Cridland <d...@cridland.net> wrote: > On 18 October 2016 at 09:55, Guus der Kinderen > <guus.der.kinde...@gmail.com> wrote: > > Has the functional overlap wit

Re: [Standards] Proposed XMPP Extension: Message Deletion

Has the functional overlap with XEP-0308 "Last message correction" already been discussed? What's the reason for creating a distinct XEP? Would it be good to have the new XEP include 'correction', and replace 308? On 18 October 2016 at 10:44, Dave Cridland wrote: > On 17

Re: [Standards] XEP-0359 Client vs. non-client IDs

at 19:08, Florian Schmaus <f...@geekplace.eu> wrote: > >>> > >>> On 29.09.2016 19:22, Guus der Kinderen wrote: > >>>> Hi, > >>>> > >>>> What's the purpose of the distinction between "Unique Stanza IDs" and > >>>> &qu

Re: [Standards] XEP-0359 Client vs. non-client IDs

wrote: > On 29 Sep 2016, at 19:08, Florian Schmaus <f...@geekplace.eu> wrote: > > > > On 29.09.2016 19:22, Guus der Kinderen wrote: > >> Hi, > >> > >> What's the purpose of the distinction between "Unique Stanza IDs" and > >> "Client

[Standards] XEP-0359 Client vs. non-client IDs

Hi, What's the purpose of the distinction between "Unique Stanza IDs" and "Client generated stanza IDs"? Why not add a unbounded list of stanza-id elements (each with a unique 'by' attribute value), and not worry about what entity is serving in a client-capacity? Regards, Guus

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

Hi, Over the last few days, some of us at IgniteRealtime have been having fun with the DIGEST-MD5 SASL Mechanism - specifically, with it's digest-uri value. The syntax of this value is: serv-type "/" host [ "/" serv-name ] It's generally accepted [1] that the applicable value for the serv-type

Re: [Standards] How many delay elements?

When more than one delay element is added - assuming that only the defined attributes are used - is there a way to distinguish what element was added for what purpose? The delay element should reference the timestamp on which the stanza was originally send. Is there reason that for one stanza,

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

e: On 12 July 2016 at 15:55, Guus der Kinderen <guus.der.kinde...@gmail.com> wrote: > Perhaps we shouldn't mention MIX at all in this particular compliance > suite. The MIX specification isn't definitive by a long shot, and although > there are some early implementations, it

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

Perhaps we shouldn't mention MIX at all in this particular compliance suite. The MIX specification isn't definitive by a long shot, and although there are some early implementations, it hardly qualifies for something to be compliant with nowadays. I'd save it for the next editions of the

[Standards] XEP-0375 (XMPP Compliance Suites 2016): caps as a server requirement?

The XEP lists "Entity Capabilities (XEP-0115)" as a requirement for "Advanced Server", although with this footnote: "Necessary to support Personal Eventing Protocol (PEP)." If there is no reason to include caps as a _server_ requirement, other than as a dependency for another requirement, it

Re: [Standards] disco identity for client/smartphone?

I'm wondering to what extend the new definition would add value, or is more likely to introduce confusion. Smartphones might be more likely to offer specialized functionality, but as the set of functionality that's offered by a particular model will likely be different from another model, you'd

[Standards] RSM and order

Hello, Was it a deliberate choice not to include an explicit attribute that relates to 'order' in XEP-0059 - Result Set Management? XEP-0059 RSM is oriented towards a GUI that contains a scrollable list (in which order is often implied, I guess). A different common GUI element is that of a

[Standards] Incorrect example in XEP-0059 Result Set Management

Hello, Regarding http://xmpp.org/extensions/xep-0059.html: In example 13, shouldn't the value of the 'index' attribute be 371 rather than 10? Regards, Guus

Re: [Standards] Correcting last message

First thoughts: perhaps you should add a section that informs how to handle child elements of the message stanza other than body. XHTML-IM adds an child element that's typically related to the message body content, for example. Other child elements might not (nicknames, for example). Should the

Re: [Standards] XEP-0136: comments about auto save and preferences

2010/6/13, Steven te Brinke s.tebri...@student.utwente.nl: Hello, When reading XEP-0136 I discovered some confusing properties. I will describe these and propose changes that make them more intuitive to me. I am not sure whether the things I propose are better than the official XEP, so let

Re: [Standards] XEP-0136: comments about auto save and preferences

I'm sorry guys. It appears that every time I start the gmail app on my phone, a new, empty response is sent. On 24 June 2010 01:19, Matthew Wild mwi...@gmail.com wrote: On 13 June 2010 15:22, Steven te Brinke s.tebri...@student.utwente.nl wrote: Hello, Hello! Ignoring Guus's mobile's

Re: [Standards] XEP-0136: comments about auto save and preferences

-- Verzonden vanaf mijn mobiele apparaat Not quite sure why my mobile decided that it was a good move to reply to the original e-mail message with a blank message. Certainly was not intentional. Sorry for this. - Guus

Re: [Standards] XEP-0136: comments about auto save and preferences

2010/6/13, Steven te Brinke s.tebri...@student.utwente.nl: Hello, When reading XEP-0136 I discovered some confusing properties. I will describe these and propose changes that make them more intuitive to me. I am not sure whether the things I propose are better than the official XEP, so let

Re: [Standards] Syncing legacy contact list

On 6 June 2010 11:51, Dave Cridland d...@cridland.net wrote: On Sat Jun 5 20:23:05 2010, Guus der Kinderen wrote: That would work indeed. I'm not thrilled by the prospect of having to duplicate all legacy rosters in local persistent storage, but at least this way, we can make the XEPs work

[Standards] Syncing legacy contact list

Hello, XEP-0100 (Gateway Interaction), paragraph 7 states that if legacy roster items are to be added to the XMPP roster of the entity that registered with the gateway, Roster Exchange SHOULD be used. XEP-0144 (Roster Item Exchange), section 7.2 reads: (...) In order to maintain synchronization

Re: [Standards] Syncing legacy contact list

On 5 June 2010 19:58, Brian Cully bcu...@gmail.com wrote: On 5-Jun-2010, at 05:35, Guus der Kinderen wrote: Again, the gateway will initiate a session on Romeo's behalf to the legacy domain. The legacy roster representation is obtained, which now includes Juliet only. A typical gateway

Re: [Standards] XEP-0277 Microblogging over XMPP and the Atom data format

, Guus der Kinderen guus.der.kinde...@gmail.com wrote: Hi all, Recently, I have been working on an XMPP gateway (XEP-0100 Gateway Interaction style) that exposes Twitter functionality in a way compliant with XEP-0277 Microblogging over XMPP. While coding, a number of questions and remarks