Re: [Standards] NEW: XEP-0452 (MUC Mention Notifications)

The mention of “Server IP Check” XEP-0279 seems to be a typo? On Tue 26 Jan 2021 at 16:04, Jonas Schäfer wrote: > Version 0.1.0 of XEP-0452 (MUC Mention Notifications) has been > released. > > Abstract: > This specification documents how a user may be informed when they're > mentioned in a MUC

Re: [Standards] NEW: XEP-0449 (Stickers)

24.11.20 22:20, Ivan Vučica wrote: > > However it also seems to me like the current spec might be suboptimal > > in case a sticker pack wants to provide PNG + animated GIF + any other > > media format. For instance, I may provide an animated GIF thumbs up, > > an animate

[Standards] XEP-0363: Restricted set of headers when requesting a slot

Hi, I'm trying to direct the chat client to talk directly to the cloud storage API using 'signed URLs', granting time-restricted upload access to possessing a URL, where I can still restrict file size. The cloud storage API happens to be Google Cloud Storage, but to my understanding, a similar

Re: [Standards] NEW: XEP-0449 (Stickers)

of the 0447 element What does everyone think? (And, more importantly, what do the client authors think?) On Tue, Nov 24, 2020 at 8:31 PM Ivan Vučica wrote: > > This refers to two XEPs in inbox that are 404ing: > > 2. XEP-: File metadata element > <https://xmpp.org/ext

Re: [Standards] NEW: XEP-0447 (Stateless file sharing)

This refers to XEP-0446 using a broken link and probably needs fixing. Since this now refers to deferred XEP-0103, will that one be advanced again? Maybe changed to experimental or draft, possibly marking the "use with SI" session as deprecated (since session initiation itself is marked

Re: [Standards] NEW: XEP-0449 (Stickers)

This refers to two XEPs in inbox that are 404ing: 2. XEP-: File metadata element < https://xmpp.org/extensions/inbox/file-metadata.html>. (apparently now XEP-0446) 4. XEP-: Stateless file sharing < https://xmpp.org/extensions/inbox/sfs.html>. (apparently now XEP-0447) I suppose the

[Standards] XEP-0396 (jet-omemo) links to a broken URL

Hi, https://xmpp.org/extensions/xep-0396.html links to https://xmpp.org/registrar/jet-omemo.html which doesn't exist. Was this meant to link to something else? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards

[Standards] XEP-0313 for transports

Hi, Sometimes, protocols backing transports may support querying for an archive similar to how it's done with XEP-0313. tl;dr Can querying archives on non-own, non-MUC, non-pubsub JID for 1:1 chats be standardized? Can it be standardized that server implementations don't have to support

[Standards] Connected vs available resource

Hi, RFC 6121 makes a distinction between a connected and available resource. Connected resource appears to be the one that's been through a , and an available resource seems to be the one that has had an initial sent -- that is, there is a 'presence session' active. RFC 6120 doesn't proscribe

Re: [Standards] Let us zap master passwords from devices

On Thu, Feb 14, 2019 at 1:20 PM Ненахов Андрей wrote: > > > > чт, 14 февр. 2019 г. в 17:09, Ivan Vučica : >> >> An advantage is that OAuth2 tokens are scoped. Such a token could in future >> be scoped for XMPP or for subsets of XMPP operations — or even f

Re: [Standards] Let us zap master passwords from devices

If the goal is to get rid of passwords completely, sounds interesting. If the goal is to get rid of password present in every client, I’ll just throw this idea out and see what y’all think. I would also consider OAUTHBEARER SASL mechanism as a simpler approach. (See RFC 7628.) AIUI other

Re: [Standards] SASL MTI

On Thu, Jan 24, 2019 at 9:40 PM Jonas Schäfer wrote: > > On Donnerstag, 24. Januar 2019 21:03:27 CET Evgeny wrote: > > I personally prefer: > > 1) MUST for EXTERNAL and PLAIN > > 2) SHOULD for SCRAM-SHA-X-Y (I'd prefer not to use SCRAM at all > >given all the problems I have described in

Re: [Standards] Proposed XMPP Extension: Simple Buttons

Some things: - other clients (chatbots) cannot discover capability to show buttons, nor provide alternate text in case buttons are supported. - how does this interact with XHTML-IM or its replacement(s)? On Thu, Dec 6, 2018, 20:54 Dave Cridland wrote: > Looks like a problem worth solving, but

Re: [Standards] Network IO best practices

If you were waiting for CR/CRLF, you would similarly be reading “one byte at a time” (probably buffering first and then seeing whether the buffer contains a newline?). What you are looking for are streaming XML parsers. You can do this in Go with encoding/xml; you will get individual tokens which

Re: [Standards] Proposed XMPP Extension: OMEMO Media sharing

Typo: data:image/jpep What can a client do to discover whether the new URL schema is supported? I exchanged some messages with a friend yesterday and I used Gajim to send pictures. He was surprised to see the aesgcm URL in, I believe, Chatsecure. Leaking the anchor was raised as a problem. This

Re: [Standards] Proposed XMPP Extension: Terms of Services

Thanks -- I think this is a much needed xep. Few comments; I hope they make sense: --- 4.2.1.1 Protocol support required If the client did not include a element in the initiating request and the server requires support for the Terms of Service protocol, it replies with an error: --- On first

[Standards] XEP-0068 and MAM

Hi, Today I learned about XEP-0068 which seems to specify an IDL-like XML for data forms. It also defines a registry for FORM_TYPEs maintained by the XMPP Registrar. I feel this could be very useful to client libraries, which can generate code with structs for predefined types a-la protocol

Re: [Standards] XMPP Council Minutes 2018-04-18

> On 20 Apr 2018, at 19:19, Tedd Sterr wrote: > > On a related note: though I'm happy to continue summarising, do people find > it useful, or is it more detail than necessary? This is useful. signature.asc Description: Message signed with OpenPGP

Re: [Standards] XEP-0394: too weak to replace XEP-0071

On Thu 15 Mar 2018 at 22:46 Ivan Vučica <i...@vucica.net> wrote: > On Thu 15 Mar 2018 at 18:40 Ненахов Андрей <andrew.nenak...@redsolution.ru> > wrote: > >> > > However, user always knows that if he styles text using markdown, >> > >

Re: [Standards] XEP-0394: too weak to replace XEP-0071

On Thu 15 Mar 2018 at 18:40 Ненахов Андрей wrote: > > > However, user always knows that if he styles text using markdown, > > > it'll always be presented in rich text form. > > > > This is emphatically not true. > > > > A useful reason to use Markdown is to keep

Re: [Standards] XEP-0394: too weak to replace XEP-0071

On Thu, Mar 15, 2018 at 3:48 PM, Jonas Wielicki wrote: > Speaking of which, please, turn HTML off when sending to the list. Thanks. I'm not sure that's a reasonable expectation to make of casual contributors to a mailing list. Not every client makes that easy. Same goes for

Re: [Standards] XEP-0394: too weak to replace XEP-0071

On Thu, Mar 15, 2018 at 3:29 PM, Ненахов Андрей wrote: > However, user always knows that if he styles text using markdown, > it'll always be presented in rich text form. This is emphatically not true. A useful reason to use Markdown is to keep it human readable.

Re: [Standards] MAM Corner Cases: MUC-PMs and Self-Messages

On Feb 21, 2018 19:05, "Georg Lukas" wrote: Hi, Philipp H. pointed out an interesting issue today: MUC-PMs are sent by a MUC to all joined client full-JIDs, so if you are joined to a MUC with two devices, your account will see two copies of the messages. Your MAM archive is also

Re: [Standards] Entity Capabilities 2.0

On Mon, Feb 12, 2018 at 10:53 AM, Evgeny Khramtsov wrote: > A server can change configuration in runtime at any time, potentially > changing its disco#info. How to notify local clients about that? How to > notify clients from remote servers? How to notify connected servers

Re: [Standards] Instant Stream Resumption 0.0.5 ProtoXEP

Offlist: looking at diff I spotted another small typo: ommited :) On Fri, Dec 1, 2017, 16:23 Florian Schmaus <f...@geekplace.eu> wrote: > On 01.12.2017 13:44, Ivan Vučica wrote: > > Some typos: > > > > - example 1, mechaisms > > - section 4, “which is send as” (

Re: [Standards] Instant Stream Resumption 0.0.5 ProtoXEP

Some typos: - example 1, mechaisms - section 4, “which is send as” (should be sent) - section 5.1 and 5.2 and elsewhere, “htpps” In “If the with-isr-token' attribute is set to 'false',”, it’s unclear to me what that attribute is attached to. What if the attribute is omitted? Thanks for your

Re: [Standards] Rename XEP status identifiers

On Tue, Sep 26, 2017 at 6:57 PM Sam Whited <s...@samwhited.com> wrote: > On Tue, Sep 26, 2017, at 12:37, Ivan Vučica wrote: > > > > On 26 September 2017 at 14:47:27, Sam Whited (s...@samwhited.com) wrote: > > > > As others have said, the real naming problem

Re: [Standards] Rename XEP status identifiers

On 26 September 2017 at 14:47:27, Sam Whited (s...@samwhited.com) wrote: As others have said, the real naming problem is "draft". We can't actively advance draft as much (since final really is final and can't be touched ever again) Is that a bad thing? Conversely, is it a good thing that

Re: [Standards] SASL2 Update incoming

On August 25, 2017 6:53:43 PM GMT+01:00, Evgeny Khramtsov wrote: >Fri, 25 Aug 2017 12:29:55 -0500 >Sam Whited wrote: >> We can't just skip auth and go straight to the roster > >Sure we can Presence value is also useful information. I am more likely to

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

On Wed, 19 Oct 2016, 19:40 Kim Alvefur, wrote: > > The question becomes why should we standardize something that only works > in a closed system? The reason to standardize is, as with open systems, so that multiple servers and clients can provide the same feature.

Re: [Standards] Extending MAM results with results from a transport component

On Wed, Jul 6, 2016 at 8:44 PM, Florian Schmaus <f...@geekplace.eu> wrote: > On 06.07.2016 20:42, Ivan Vučica wrote: > > If I am interpreting XEP-0313 correctly, for person-to-person use case, > > archive is obtained by inquiring the 'current server'. This is usually &g

[Standards] Extending MAM results with results from a transport component

Cheers, If I am interpreting XEP-0313 correctly, for person-to-person use case, archive is obtained by inquiring the 'current server'. This is usually fine. However, in case of an external transport component communicating with an IM network that can provide its own history, there does not seem

Re: [Standards] Using XMPP In A Mobile Environment

On Tue, Feb 10, 2015 at 6:12 PM, Florian Schmaus f...@geekplace.eu wrote: Let's start by classifying inbound stanzas into three types. There are stanza that… 1. require immediate delivery Even those stanzas can be slightly deferred and be bundled, I believe. Just the interval will be

Re: [Standards] Using XMPP In A Mobile Environment

On Fri, Feb 13, 2015 at 3:33 PM, Florian Schmaus f...@geekplace.eu wrote: I'm not an iOS export, but I think I've heard that TCP connection are terminated anyway after something like 60 seconds (of inactivity?). While I have not tested this, I would highly doubt this is the case for the

Re: [Standards] Hello

On Sat, Feb 7, 2015 at 8:10 PM, AliReza Mosajjal alireza.r...@gmail.com wrote: hi I got a question regarding XMPP muc. I wanted to know if it's possible to add push-to-talk functionality to XMPP muc. Voice conferencing functionality is described in XEP-0272:

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

: http://xmpp.org/extensions/diff/api/xep/0343/diff/0.1/vs/0.2 URL: http://xmpp.org/extensions/xep-0343.html -- Ivan Vučica i...@vucica.net

Re: [Standards] DEFERRED: XEP-0313 (Message Archive Management)

state. Here, I was asking about reading the state, and not about modifying the state :-) As far as I can see, the XEP specifies only that the full state will be returned upon modification; it does not state how to actually retrieve the state without first transmitting the state. -- Ivan Vučica i

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

Re: section 3.3.x Doesn't more choices for discovery mean servers and clients need to implement all choices? I'd go with the mDNS/DNSSD method only as it is already widely used for other discovery uses. DHCP may not be easily configurable by the XMPP server administrator. sent from phone On Mar

Re: [Standards] LAST CALL: XEP-0152 (Reachability Addresses)

Adán, Interesting proposal, but that should be a separate XEP. XEP-0152 is something that in no way depends on server side support. I never noticed this XEP before, but it seems interesting by itself (and hopefully will see adoption by major clients). Turning this XEP itself into something more

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

Hi Peter, On 5. studenoga 2013. at 12:53:52, Peter Waher (peter.wa...@clayster.com) 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

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

On 10. studenoga 2013. at 15:37:26, Peter Waher (peter.wa...@clayster.com) wrote: Having said that, do you feel there’s an interest in implementing support for a XEP sending table messages that is not based on XHTML-IM? I’d have no trouble with that, and I suspect that clients that seem to be