* Daniel Gultsch [2022-06-14 22:07]:
> a) Proposed XMPP Extension: WebSocket S2S
> (https://xmpp.org/extensions/inbox/websocket-s2s.html)
+1 though I wonder if it makes sense to release a XEP for s2s where we
have an RFC for c2s. Maybe harmonizing both under the same organization
would be more
* Peter Saint-Andre [2022-03-10 16:06]:
> IIRC, sipub is correct and si-pub is incorrect.
Thanks for chiming in, Peter!
> What does the schema say?
That was a great question. I didn't find a schema in '72, but it's
actually present at http://www.xmpp.org/schemas/sipub.xsd (linked from
'137)
Hi,
I've been looking into our legacy namespaces recently (the ones starting
with `http://jabber.org/`), with a goal to implement HTTP Redirects to
the respective XEPs (first map at https://op-co.de/tmp/namespacemap.txt)
I identified a bunch of inconsistencies in examples, for some of which
I've
> 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 publicly accessible.
> I've made a
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
Yes, this is a needed use case.
> 2. Does the specification solve the problem stated in the introduction
> and requirements?
No. This has been pointed out by Marvin very well, so not
* Sam Whited [2021-12-07 19:38]:
> I would like to point out that this specification relies on XEP-0359,
> XEP-0422, and XEP-0428 all of which are deferred. While 0359 is widely
> implemented and probably fine to rely on, I don't believe 0422 is as
> widely used and we should probably let a
Sorry this is so late, and thanks to Sonny for taking up the hard task
of fighting this through the Council.
* Jonas Schäfer [2021-09-07 16:04]:
> This message constitutes notice of a Last Call for comments on
> XEP-0459 [...] XMPP Compliance Suites 2022
1. As part of the work on XEP-0313, two
* Dave Cridland [2021-09-08 10:50]:
[Spoofing of the Forwarded element]
> I can agree with this in principle, though the query id within MAM
> queries dramatically lessens the scope for an attack here.
I'm aware of this point. However, many implementations process stanzas
in callback functions
* Kevin Smith [2021-09-07 18:41]:
> At the risk of repeating myself, I think that storing groupchat messages in
> the user archives is helpful, and people do this in the wild.
Right, I remember hearing that before, and IIRC the reason for that was
to allow for server-side message search?
Now I
:
* Georg Lukas [2021-03-31 18:50]:
> Time and again, specifications that use Message Forwarding have
> fallen victim to impersonation attacks (there is a number of CVEs
> around, like CVE-2017-5589, CVE-2019-16235, and CVE-2020-26547).
>
> The XEP urgently needs a respective section
Hello,
in the past, implementations of certain XEPs have been susceptible to
security vulnerabilities, and it would be great if we could prevent
future implementors from repeating the same errors.
On the one hand, we already have progressively strong wording in our
Security Considerations, and
* Jonas Schäfer [2021-03-24 17:03]:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
Yes.
> 2. Does the specification solve the problem stated in the introduction
> and requirements?
Yes.
> 3. Do you plan to implement this
* Jonas Schäfer [2021-03-16 21:23]:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
Yes.
> 2. Does the specification solve the problem stated in the introduction
> and requirements?
Mostly yes.
> 3. Do you plan to implement this
* Sam Whited [2021-03-11 15:05]:
> The authors of message carbons haven't been active for a while if I'm
> not mistaken.
As somebody who has done the most non-editorial changes on the XEP in
the last six years, and saw (and contributed to) it failing Last Calls
in 2020, 2019, 2018, 2017, and
* Tedd Sterr [2021-01-12 16:04]:
> 4a) Proposed XMPP Extension: MUC Mention Notifications -
> https://xmpp.org/extensions/inbox/muc-mention-notifications.html
-0
I stick to what I said before:
> Georg thinks this should be configurable per member, not just per room by
> admin, otherwise
* Tedd Sterr [2020-11-21 20:14]:
> 4b) Proposed XMPP Extension: Stateless file sharing -
> https://xmpp.org/extensions/inbox/sfs.html
+1
I still think this should be an edit of SIMS and not a new
largely-duplicate XEP, but numbers are cheap, so let it go. I like some
of the things it
Hi Dave,
* Dave Cridland [2020-11-04 12:48]:
> TL;DR: When the session has a ping timeout, do push notifications, but
> otherwise leave it open - mobile clients will often recover after several
> minutes have passed.
That's a great analysis and I haven't considered this situation yet, but
your
Hi Dave,
* Dave Cridland [2020-11-03 22:55]:
> This is a very comprehensively written XEP for an initial submission.
Thank you very much for your review!
> My main concern here is the addition of a further IQ during unauthenticated
> state. In the case of every server I've worked with, the IBR
* Tedd Sterr [2020-10-23 15:35]:
> 4a) MR !22 (XEP-0118: add composer, date, genre, language, lyricist, and
> performer tags; make rating optional) -
> https://gitlab.com/xsf/xeps/-/merge_requests/25
I'd also like to see some more exploration of what's possible in this
space (put the tune in
* Jonas Schäfer [2020-10-06 18:12]:
> 2) Agenda Bashing
I'd like to add https://gitlab.com/xsf/xeps/-/merge_requests/22 as
discussed today with Kev on xsf@, see
https://logs.xmpp.org/xsf/2020-10-07#2020-10-07-6ee75d202c925239 for the
logs.
Main point of the change: encourage IM clients to send
Hi,
I tried to enter a room on a bridge, and my client refused to do so,
because the bridge didn't provide the right combination of feature and
identity. As it happened in the past, and XEP-0045 (§6.2 and §6.4) is
very vague on this, I have multiple questions that I'd like to clarify
(and update
Hi Andrew,
thanks for your suggestion!
* Andrew Nenakhov [2020-09-04 11:08]:
> I understand that boy with a hammer treats everything as a nail, but
> come on: if you really want a compliance suite, you shouldn't pollute
> the list of extensions with this day-to-day bureaucracy, but simply
>
* Dave Cridland [2020-09-02 17:27]:
> If you have an XMPP product or public project, do you claim compliance with
> XEP-0423?
I'd love to claim yaxim's compliance with Core IM and Advanced Mobile,
but can't due to a lack of badges.
I'm not sure what the marketing effect of such compliance
* XEP Editor Pipeline [2020-08-04 18:07]:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
Yes.
> 2. Does the specification solve the problem stated in the introduction
> and requirements?
Partially. The XEP omits explicit
Hi,
MUC-PMs are prone to errors, have weird interactions with Carbons, MAM
and other specs and require the recipient to be in the room at the time
of delivery. While I don't want to abolish them altogether, there is a
compelling IM use case for direct messages to replace PMs: non-anonymous
MUCs
* Ruslan N. Marchenko [2020-07-14 23:52]:
> The sections 7 & 8 are referring to RFC 6121 for message delivery and
> mentions the CC should be after delivery. In 7 kind of implicitly, in 8
> ambiguous, 'and' could mean 'and then' or 'and also'. The question is -
> what happens for unsuccessful
* Tedd Sterr [2020-06-22 19:13]:
> 4b) PR #961 (XEP-0030: Specify that the disco#info feature may not be
> explicitly set) - https://github.com/xsf/xeps/pull/961
-1
As stated time and again, neither removing the mandatory 0030 feature,
nor adding the 0030 feature to all disco examples in all
* Tedd Sterr [2020-06-01 00:53]:
> 4a) Proposed XMPP Extension: SASL Channel-Binding Type Capability -
> https://xmpp.org/extensions/inbox/xep-sasl-cb-types.html
+1
> 4b) PR #949 - Add status-addresses registrar entry -
> https://github.com/xsf/xeps/pull/949
> Jonas notes the on-list
* Tedd Sterr [2020-05-22 23:56]:
> 4a) Advance XEP-0339 (Source-Specific Media Attributes in Jingle) -
> https://xmpp.org/extensions/xep-0339.html
+1
> 4b) Advance XEP-0320 (Use of DTLS-SRTP in Jingle Sessions) -
> https://xmpp.org/extensions/xep-0320.html
+1
Greetings, Georg
* Sam Whited [2020-05-23 15:40]:
> On Sat, May 23, 2020, at 06:24, Mathieu Pasquet wrote:
> > Sorry for the necromancer update, but would it not make sense to allow
> > stanza-id elements as children to the and elements?
Yeah, that's actually what also came to my mind as an easy and
* Jonas Schäfer [2020-05-09 18:36]:
> Please reply to this message on-list or privately to me if you are interested
> in participating within a week.
I'm interested!
The rules for Carbons, MAM, CSI and Push are different, partially
implicit (payload), partially explicit (hints). We need to fix
* Tedd Sterr [2020-04-22 16:46]:
> https://logs.xmpp.org/council/2020-04-15?p=h#2020-04-15-515165c7293c9539
>
> 4a) Proposed XMPP Extension: Room Activity Indicators -
> https://xmpp.org/extensions/inbox/room-activity-indicators.html
I'm actually very much torn on this. I can understand that
* JC Brand [2020-04-01 20:07]:
> If the server only sends presence for affiliated users (see 5.1) and also
> sends unavailable presences (see 5.2.1), then ghost users won't be
> created.
Right, but there is no way to discover that on the client side ;-)
> I was however reluctant to make these
Hi together,
* Jonas Schäfer [2020-03-31 20:39]:
> Title: MUC presence versioning
This is an awesome extension to the MUC protocol, and I think it fits in
well. Next step is to re-organize the MUC membership query from four IQs
to something with differential semantics as well ;)
Re disco#info:
* Tedd Sterr [2020-03-06 01:24]:
> 4a) Proposed XMPP Extension: Reminders -
> https://xmpp.org/extensions/inbox/reminders.html
+1
I'm not quite sure about the specific wire protocol for this, but I
can see there is a need for it and I can see how having a standardized
protocol will benefit
* Jonas Schäfer [2020-03-17 17:28]:
> - Are clients allowed to reply receipt requests when fetching messages from
> MAM? I think they are, despite the wording in the text (which IMO only
> considers the user browsing an archive), but I guess the wording needs
> cleaning up.
In my
Hello,
I agree with the sentiments that there should be a way to query for
existing reminders, and also that ad-hoc command syntax is probably not
too bad for this kind of use case.
However, I think we have yet another mechanism that might be used /
useful for that kind of data, and it's PEP.
I
* Andrew Nenakhov [2020-03-06 11:10]:
> It is not possible to determine with Delivery Receipts either. If you
> were offline when they were sent, you will not receive them.
> If the recipient was offline when the messages were sent, a client
> won't send the receipts too. So, it is only
* Tedd Sterr [2020-02-19 18:15]:
> 3a) Last Call: XEP-0429 (Special Interests Group End to End Encryption) -
> https://xmpp.org/extensions/xep-0429.html
+1
> 3b) Proposed XMPP Extension: Simple JSON Messaging -
> https://xmpp.org/extensions/inbox/udt.html
+1 - It still has udt in the inbox
* Florian Schmaus [2020-02-13 21:14]:
> With the advent of WebSockets and QUIC around the corner, we shouldn't
> miss the opportunity to allow stream resumption over different
> transports (TCP, BOSH, WebSocket, QUIC, …).
Indeed, this is one historical quirk of 0198 that needs to be fixed,
* Jonas Schäfer [2020-01-29 17:34]:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
Yes, it's a significant improvement over existing bookmarks.
> 2. Does the specification solve the problem stated in the introduction
> and
* Tedd Sterr [2020-01-28 19:04]:
> 3a) Proposed XMPP Extension: Full Text Search in MAM -
> https://xmpp.org/extensions/inbox/fulltext.html
+1 this is a good first step, and I'm sure we can figure out the
remaining parts (like an additional form field for "exact string match")
on the go.
> 3b)
* Tedd Sterr [2020-01-07 17:07]:
> http://logs.xmpp.org/council/2020-01-02?p=h#2020-01-02-a37a199502a4581c
> 3a) Proposed XMPP Extension: MAM Fastening Collation -
> https://xmpp.org/extensions/inbox/mamfc.html
+0
The general functionality is something that we really need, but I think
we need
* Kim Alvefur [2020-01-10 18:30]:
> On Tue, Jan 07, 2020 at 04:04:56PM +, Tedd Sterr wrote:
> > 3c) Proposed XMPP Extension: Fallback Indication -
> > https://xmpp.org/extensions/inbox/fallback.html
> That specific case is also covered by XEP-0380.
Speaking of which... Should we rewrite
* Jonas Schäfer [2020-01-08 17:12]:
> Revert version 0.3.0, which was merged prematurely and incorrectly.
Thanks, Jonas.
I've resubmitted the change as https://github.com/xsf/xeps/pull/874
Marc also kindly asked to bring this up for wider discussion, so here it
is.
Council feedback on the
* Jonas Schäfer [2019-12-30 14:29]:
> This specification proposes a mechanism by which message bodies can be
> marked as being purely for fallback purposes, and therefore to be
> ignored by intermediaries and anything that understands the remainder
> of the message.
I'm very much split on this
+1 on Proposed XMPP Extension: Character counting in message bodies
Please add a clarification that counting has to happen before encoding / after
decoding XML entities. Having multiple alternative encodings for & and < with
different lengths really makes this case clear, despite the gymnasts
* Kevin Smith [2019-11-06 12:24]:
> I think the addition of ’66 is well-intentioned, but jabber:x:oob
> is underspecified (it defines a syntax, but semantics are
> missing).
I agree, but nobody has written down the semantics yet, so there is no
place to link to. On the other hand, this
Hi goffi,
* goffi [2019-11-05 22:58]:
> I'm really busy these days and couldn't do an extensive review, but here is
> my feedback:
Thank you for your feedback!
> It's really chat focused, and I would like to see other categories, notably
> a "social" one. I would put there XEP-0277 as the bare
* Tedd Sterr [2019-10-16 16:32]:
> Proposed XMPP Extension: Message Moderation -
> https://xmpp.org/extensions/inbox/message-moderation.html
+1
> Proposed XMPP Extension: Message Retraction -
> https://xmpp.org/extensions/inbox/message-retraction.html
+1
Both are useful additions, and we
* Maxime Buquet [2019-10-15 14:23]:
> I don't think 0392 (Consistent Color Generation) should be included at
> all.
as mentioned before, I disagree with that, as in my eyes, 0392 is
conceptually not different from Avatars in any way, except that it
doesn't add wire protocol.
With my XEP author
* Florian Schmaus [2019-10-11 12:35]:
> I am going to give feedback based on
> https://op-co.de/tmp/xep-0423.html
> which is, if I understood Georg correctly, the current state.
Yes, it is. Thank you very much for your feedback!
> There are two protocol extension evaluations that are currently
* Evgeny [2019-10-09 17:08]:
> I would like to see BOSH dropped and moving the XEP to historical or
> deprecated state, because I see zero advantages over Websockets now
> (supporting both XEP-0198 and BOSH makes no sense at all).
there is still an open issue with WebSockets for anonymous
* Tedd Sterr [2019-09-30 03:07]:
> 2019-09-25 (expiring 2019-10-09)
>
> PR #824 - XEP-0060: Add pubsub#public in Publish-Subscribe features -
> https://github.com/xsf/xeps/pull/824
-1 - as discussed recently, this needs to have its own feature var.
+1 under the condition that such a var is
* Jonas Schäfer [2019-09-11 17:34]:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> Title: Authorization Tokens
thank you very much for writing this up. Indeed, this is some badly
needed functionality. However, I have mixed feelings regarding this
specific way to tackle it.
* JC Brand [2019-09-24 15:10]:
> > Additionally in MUCs, one could send an IQ to the room so that the MUC
> > itself broadcasts it to all participants of that room.
> I don't like the idea of there being two ways of doing the same thing in a
> MUC.
Those are not actually the same thing. One is
* Andrew Nenakhov [2019-09-05 09:45]:
> [..] So we have to
> operate fully without presence, thus, if a caller rejects a message at
> the exact moment we fetch an archive, we won't receive
> message in normal XMPP way.
You can enable Carbons to receive live messages. If you do so before
* Tedd Sterr [2019-09-02 22:00]:
> 4a) Advance to Draft: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)
> - https://xmpp.org/extensions/xep-0300.html
+1
> 4b) Advance to Draft: XEP-0353 (Jingle Message Initiation) -
> https://xmpp.org/extensions/xep-0353.html
> Georg needs to review
* Philipp Hancke [2019-09-03 14:15]:
> 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
> (hence no body).
Let's imagine the following:
- 0353 or 0313 get changed to store all 0353 messages into
* Tedd Sterr [2019-08-18 23:00]:
> PR #806 - XEP-0060: Add pubsub#public in Publish-Subscribe features -
> https://github.com/xsf/xeps/pull/806
-0. I agree that this is a useful addition, but technically it belongs
into the registry in https://xmpp.org/registrar/disco-features.html and
not into
Hi,
error type stanzas are currently ephemeral, and not taken seriously by
many (client) developers. As one step in increasing the (perceived)
reliability of XMPP messaging, I'd like to make message errors
persistent, so that users can better gauge which of their messages
actually arrived at the
* Tedd Sterr [2019-07-29 03:16]:
> Proposed XMPP Extension: Message Reactions -
> https://xmpp.org/extensions/inbox/reactions.html
> Dave: [pending]
> Georg: +0 (for now; still undecided)
> Jonas: +1 (details can be ironed out)
> Kev: [pending]
> Link: +1 (issues can be ironed out before Draft)
Hi Marvin,
* Marvin W [2019-07-24 22:02]:
> > Referencing messages
I agree with all that you wrote about XEP-0372, and I suppose the only
reason it gets referenced so often in these discussion is because it's
inadequately titled "Message References".
> On the contrary, XEP-0367 does not suffer
* Jonas Schäfer [2019-07-15 17:59]:
> Title: Message Reactions
> This specification defines a way for adding reactions to a message.
This is a long overdue feature. However, I have some principal and some
practical issues with that.
1. Referencing messages
This is yet another XEP that creates
* Tedd Sterr [2019-06-24 00:47]:
> Last Call: XEP-0300 (Use of Cryptographic Hash Functions in XMPP) -
> https://xmpp.org/extensions/xep-0300.html
> Dave: +1
> Georg: [pending]
> Jonas: +1
> Kev: [pending]
> Link: +1
+1 to LastCall it. I think that "Table 1: Additional Hash Function
Textual
* Jonas Schäfer [2019-06-19 17:00]:
> Title: Stanza Content Encryption
This was long overdue.
Some ideas for consideration:
1. I'd like to see certain fields of the being REQUIRED,
especially:
- the from address
- maybe, possibly, the recipient address(es)
- a (or ) element
- the @id /
Hi,
recently I started noticing bounces for CSNs (XEP-0085) sent to an
offiline (ejabberd) user. This behavior corresponds to XEP-0160, §2.3:
> Recipient's server determines that if the server can store offline
> messages on behalf of the intended recipient; if not (e.g., because
> the
* Kevin Smith [2019-04-17 20:28]:
> > PR #779 - XEP-0184: add a box about types and JIDs -
> > https://github.com/xsf/xeps/pull/779
>
> This seems a little backwards to me - it’s only saying the completely
> non-normative 'is a good practice’ for doing the right thing, while
> saying ’should’
Hello together,
I'd like to propose the following for today's Council agenda:
1) Roll Call
2) Agenda Bashing
As this is merely an agenda proposal, this might be a good time to add
more significant items.
3) Items for voting:
3a) https://github.com/xsf/xeps/pull/778 XEP-0280: Rewrite of the
* Dave Cridland [2019-04-16 18:21]:
> a) https://github.com/xsf/xeps/pull/736
>
> XEP-0308: Allow message correction in MUC
While we are at it, I'd like to also add:
aa) XEP-0308: relax from-full-JID requirement
https://github.com/xsf/xeps/pull/784
Thanks very much,
Georg
signature.asc
* Jonas Wielicki [2018-01-25 14:45]:
> XEP-0382 (Spoiler messages) has been Deferred because of inactivity.
As this has been recently resurrected into implementation, and I somehow
missed commenting on it when it was initially proposed:
I think the XEP is getting it all backwards. If the intent
[stripping out the arguments I don't disagree with, to further
illuminate a specific point]
* Kevin Smith [2019-04-02 13:03]:
> I don’t really think what you’re looking for here is a clarification
> of the intent of the XEP, but a change of behaviour.
I can agree with that, so in retrospect,
Hello Kev,
thank you for picking this up again, and I'm sorry for the -1. I wrote
in the Meeting that it's not impossible to convince me to change my
mind, but you have to provide very strong arguments...
* Kevin Smith [2019-04-02 10:52]:
> It’s the original message @id - if you follow the
* Jonas Schäfer [2019-03-26 17:44]:
> * Taken over ownership.
> * Improved structure of category and level names.
> * Added XEP-0313 and XEP-0412 to 'Advanced Group Chat' (gl)
I would like to finally have a vote about moving this to Draft in
Council tomorrow.
Georg
signature.asc
Description:
* Tedd Sterr [2019-03-17 21:53]:
> Proposed XMPP Extension: E2E Authentication in XMPP: Certificate Issuance and
> Revocation - https://xmpp.org/extensions/inbox/eax-cir.html
+1
I have some minor detail issues with this, but nothing critical:
- A CA doesn't _need to_ be a server entity. It's
* Guus der Kinderen [2019-03-07 09:26]:
> I'm very much in favor of not applying changes to the 2019 suite that can
> wait for the 2020 edition.
Alright, I'm convinced. Let's not further delay XEP-0412, and then let's
hope client implementors will move away from the horrible mess that the
0066
* Tedd Sterr [2019-03-06 21:30]:
> Naysayers are invited to comment now, or forever hold their piece.
because I love to be the naysayer, here is one:
"Modern" clients are using a small subset of XEP-0066, namely §3, to
communicate inline images in messages. A small subset of those clients,
* Thilo Molitor [2019-02-17 14:03]:
> Does anyone of you use XEP-0013 in your client other than for purging offline
> messages when you support MAM?
To write down our discussion from the MUC: I think this is a bad idea
for multiple reasons.
1. 0013 is just a workaround for a problem that
* Wiktor Kwapisiewicz [2019-02-05 10:39]:
> Hmm... did I get this right that I should add a paragraph
> with the explanation of "Access-Control-Allow-Origin: *" inside the XEP?
Yes, I think that or a link to the respective w3c docs would be helpful,
but I'm not going to require it.
> Would
Hi Wiktor,
* Wiktor Kwapisiewicz [2019-02-04 23:00]:
> I did a quick "git grep" but it seems XEPs do not use any stylistic WARNING
> messages so I added a paragraph:
>
> https://github.com/xsf/xeps/pull/743/files#diff-4fd958d9730d81a5ba1b395dba37039bR239
+1 (formally, now)
Thanks very much!
Hi,
two more XEP-0410 issues that were brought up in the MUCs:
It might make sense to create a *new* additional error condition in the
not-in-MUC error response, so that a client not wanting to implement the
different "ping error that is not an error" matches, and that relies on
the new
Hi together,
I've added a "Message IDs and References" agendum to the Summit
discussion agenda. As I probably won't be able to attend, I wanted to
elaborate what exactly the problems I'd like to see solved are, and
maybe even ignite a bit of on-list discussion pre-Summit.
We currently have three
Hi Daniel, folks,
* Georg Lukas [2019-01-15 16:35]:
> thanks very much for your feedback. I'd like to improve the XEP text to
> make the points clearer to understand.
I've incorporated a number of smaller text changes in
https://github.com/xsf/xeps/pull/739 and would like t
* Tedd Sterr [2019-01-16 19:43]:
> 1) Roll Call
> Apologies: Link, Georg
Sorry for missing it on short notice.
> 3) Proposed XMPP Extension: Cryptographic Hash Function Recommendations for
> XMPP - https://xmpp.org/extensions/inbox/hash-recommendations.html
+1
> 4) Outstanding Votes
> One
* Jonas Schäfer [2019-01-08 17:55]:
> This message constitutes notice of a Last Call for comments on
> XEP-0280.
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
Yes, it is a very important piece for modern multi-client
* Tedd Sterr [2019-01-16 21:50]:
> My own preference would be for Deferred to represent a state of "good
> idea; still needs more work; contributions welcome" - which it
> arguably already does,
I fully agree.
> but it also includes many that should legitimately be obsoleted (not
> that it's
Hi Daniel,
thanks very much for your feedback. I'd like to improve the XEP text to
make the points clearer to understand.
* Daniel Gultsch [2019-01-08 18:31]:
> I’m not sure. Is the intent of the XEP to keep me reliably connected
> to a MUC or is it intended to figure out if I’m connected to a
* Jonas Schäfer [2018-12-14 16:18]:
> I think adding a distinct feature is a good idea. Even if clients don’t act
> on
> it (I’m not sure what they could (not) do by knowing that the server does
> (not) support it), it is useful to meter the deployment in the wild.
>
> I suggest to use
* Daniel Gultsch [2018-12-24 14:25]:
> I don’t consider the XEP (as written) to be fit for use.
Being one of the developers making the most use out of it, could you
provide a PR of the XEP outlining your use case and maybe even including
the client sync by carbons-of-markers use case?
Georg
--
* Georg Lukas [2018-12-12 18:07]:
> There are some pet XEPs I have that I'd like to integrate:
And another one:
Advanced IM Client: XEP-0333: Chat Markers
(should also be used/usable for inter-client read-state sync)
Georg
signature.asc
Description: PGP signat
* Kim Alvefur [2018-12-08 20:01]:
> Anyways, if clicking a button sends an exact string given on the button
> then there should be no ambiguity?
This is the second issue I have with this proto-XEP, because the i18n
fails when clicking the button. You click "Ja" but your client sends
"yes". This
* Georg Lukas [2018-12-12 18:07]:
> There are some pet XEPs I have that I'd like to integrate:
I'd like to also suggest XEP-0308: Last Message Correction
for advanced IM.
Georg
signature.asc
Description: PGP signature
___
Standards mailing l
Hello,
I'd like to ask for a Last Call for XEP-0410. It's got implemented in
two clients and two servers so far:
- poezio 0.12
- yaxim 0.9.3
- ejabberd 18.12
- prosody 0.11
One question that was brought up recently is whether a MUC service
should advertise support for the self-ping optimization
* Jonas Schäfer [2018-12-08 20:06]:
> Title: XMPP Compliance Suites 2019
thanks for taking up the work!
Some remarks:
IMO XEP-0184 is sufficiently important to become IM-Core, not just
IM-Advanced.
I'm not sure whether it makes sense to have only Push in the "Advanced"
category for Mobile
* Philipp Hörist [2018-11-26 12:01]:
> > But surely if a client connects and doesn't send an origin-id, you know
> > the message id might not be unique?
>
> Yes and thats the reason why origin-id is needed.
> It seems like a useful information to know if a client uses unique ids or
> not.
* Ненахов Андрей [2018-11-26 10:46]:
> Because stanza-ids from XEP-0359 have a requirement that they MUST be
> unique and stable within a scope, message ids don't have this explicit
> requirement.
If your client is using them to associate message reflections, I am sure
you can make them unique
* Ненахов Андрей [2018-11-26 10:16]:
> So, the purpose of the origin-id is to be a temporary ID on client
> side until it knows a 'true' stanza-id assigned by it's server.
How is that different from just using the message @id?
Georg
signature.asc
Description: PGP signature
* Florian Schmaus [2018-11-20 16:44]:
> > -1, but we should add the Note about examples not being normative.
>
> The primary purpose of the (unwritten) rule that examples are considered
> non-normative is that broken examples cannot become or seen as correct
> behaviour as of the specification.
(this includes my previous votes for the sake of completeness)
* Tedd Sterr [2018-11-15 20:41]:
> http://logs.xmpp.org/council/2018-11-14/#16:01:26
>
> 3) Advance XEP-0357 (Push Notifications) to DRAFT -
> https://xmpp.org/extensions/xep-0357.html
(still) -1 (high priority topic hasn't been
* Jonas Schäfer [2018-11-17 17:39]:
> I tend slightly towards posting subsequent corrections against the original
> @id. This is because in my mind, the correction replaces the payload, not the
> message itself. However, if all current implementations refer to the ID of
> the
> previous
1 - 100 of 279 matches
Mail list logo
