* XEP proposal3: better contact integration. The contacts data on XMPP apps
of Android is very isolated from the rest of apps. All other messaging apps
interact well with the device contacts and phone numbers, except for XMPP
because it doesn't use phone numbers as identifiers. But once we have
There is no special use case other than a dedicated node ID.
The purpose is a a concensus node ID which should ease on
interoperability betweeen systems.
Suppose project Betula (links directory system) adds intergration with
XMPP PubSub, and choses "betula" as node ID.
Normally I would expect
There doesn't seem to be a need for a well-known node name for this? Unless
I'm missing the use case...
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org
URL: https://xmpp.org/extensions/inbox/notification-filter.html
This seems to introduce a new child-less XML element with only attributes
and no content. These are a common XML anti-pattern I think we probably
shouldn't encourage more of.
Two alternatives:
never
Seperate from this
3. We should more actively discourage release of functionality based on
ProtoXEP and Experimental XEPs in production (except hidden behind feature
flags or options clearly marked as experimental).
And that's how you end up with Pidgin not having MAM or the like for years.
Because they indeed
It has to be a "chatroom of any particular groupchat protocol". While
you are free to argue that 1:1 chats are groupchats of a group of two
and therefor regular chat messages form a groupchat protocol, I doubt
it was intended that way by the authors (neither in XEP-0402 nor in any
other XEP).
The XEP is explicit that you *can* assume the chat to be MUC and that
it must be a groupchat chatroom (which rules out a JID of a user that
can be used to talk 1:1).
A 1:1 chat *is* a groupchat with two participants. It's not a MUC but as you
quoted the XEP says it doesn't have to be.
These all seem like things an XMPP server could choose to support. I don't
think there's any standards work blocking such an implementation.
It could be implemented, but wouldn't it require breaking
compliance with XEP-0045 by introducing a new send-only role, cf
For MUCs, it is a perfect fit for XEP-0402: PEP Native Bookmarks
, in the spirit of XEP-0469: Bookmark Pinning? eg:
For MUCs or for any other chat with more than one person inside, which
includes 1:1 chat. Bookmarks2 says exolicitlg that you can't assume the
chats are MUCs.
What can this member do?
* Send messages
* Send media
* Add members
* Pin messages
* Change group info
Restricted until:
* Forever
* For 1 day
* For 1 week
* Custom
These all seem like things an XMPP server could choose to support. I don't
think there's any standards work blocking such an
- It is smaller. While individual pieces of data may be tiny, the
cumulative amount is significant, and efficiency is crucial.
Why is efficiency crucial when events are being produced at the rate a human
can produce them?
If something over Jingle *is* desired, I'm a bit uncomfortable with
URL: https://xmpp.org/extensions/inbox/remote-control.html
I'm unclear on the benefits of this CBOR-over-Jingle approach vs a XML-based
-based approach? Unlike audio/video this data is tiny and does not
benefit nearly as much from direct transmission or binary packing.
If something over
Also, I suspect the naive way to implement this will be to hash the bare
JID. We probably want to mention that this is a bad idea and that these
identifiers should be random (or we should explicitly define the security
properties that are required if they're derived, which probably includes
However it does lack any way to support indicating to the server
which
credential will be used, other than perhaps by implication from the SASL
mechanism.
That's not the purview of a SASL profile. If a SASL mechanism supports
multiple credentials, that's entirely encapsulated within that
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
Yes, we currently have no way to use multiple SASL or otherwise to acheive a
similar result.
2. Does the specification solve the problem stated in the introduction
and requirements?
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
"Needed" is a strong word, but it is useful to have everything enabled at
once.
2. Does the specification solve the problem stated in the introduction
and requirements?
Yes
3. Do
If we are going to standardize this we should be using existing standard
color spaces that are widely implemented.
I had to go re-read the XEP to see what it is you mean here. I do consider
it odd that the spec mentions HSLuv in normative text. Since the algorithm
only generates a hue
* The server assist was added because of the feature request that the
server parses . However
this puts unnecessary burden on the server because the server then has
to look up the stanza-id from the message-id (which is used by
Displayed Markers (Chat Markers)). So with that feature request /
Somebody signing messages as Jonas Schäfer wrote:
I would like to discuss the removal of the following part-sentence from
XEP-0030 (in Final status!):
every entity MUST support at least the
'http://jabber.org/protocol/disco#info' feature
I would support this change
Maybe because QUIC is still experimental
QUIC was published as RFC 9000 almost 3 years ago.
I meant XMPP QUIC, which is still an experimental XEP :)
signature.asc
Description: PGP signature
___
Standards mailing list -- standards@xmpp.org
To
This essentially re-introduces the major security flaw that was addressed
in XEP-0156 by removing the TXT record, just with a warning.
Isn't this security flaw inherent to all possible discovery mechanisms for
browser-based connection with domain delegation? Unless you can somehow
trust the
Somebody signing messages as Florian Schmaus wrote:
On 01/12/2023 03.46, Stephen Paul Weber wrote:
Has this been discussed much before? SCE clearly calls out OX as
inspiration, but especially since both are still experimental would
it not make sense to "reverse the arrow" a
Has this been discussed much before? SCE clearly calls out OX as
inspiration, but especially since both are still experimental would it not
make sense to "reverse the arrow" and have OX be a profile of SCE?
signature.asc
Description: PGP signature
My main observation about this proposal is that it attaches meaning to
otherwise-opaque var strings, and in general reads more like a hack than a
solution. I am sympathetic to the need here, but I think we can solve it
without resorting to this, and even still without needing to update caps.
Can we really replace XEP-0071 with something that is as "powerful" without
triggering all the reasons that people wanted it deprecated in the first
place?
I would say if you want the power, keep using XEP-0071. It's implemented
just about everywhere, and works very well, no matter what the
The 'autojoin' flag name is a bit misleading in the time of always-on
clients. Maybe we should change the text to indicate that a client is
supposed to join and stay joined(!) if this flag is set, and maybe also
to automatically leave when the flag is unset.
I’d argue that clients should
entity or resource" which implies it might be resonable to have
resource-less presence, at least so far as the standard is concerned.
Looking for guidance on my interpretation here. Thanks.
--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer
s required to use it at all, why
not clean up everything while we're at it?
--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
___
Standards mailing list
Info: https://mail.jabber.org/
ke
it suit my immediate needs at least. Doesn't solve the more general use
case of two XMPP users calling each other over PSTN, but that's not an
immediate need.
Who is implementing Rayo now? And for what purposes? I'm curious what use
cases it's actually imagined for (might give context
this being used to enable XMPP contacts
to call each other over PSTN directly (without advertising a permanent
telephone number in vCard, but instead giving out numbers on a case-by-case
call-establishment basis), or many other cases.
--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> This is Section 2.3 of XEP-0050
Yes, that's where I got it from.
- --
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
-BEGIN PGP SIGNATURE-
Version:
Obviously the above stanzas are unlikely to produce the desired UI
with obivous implementations of XEP-0050 (more likely, the menu
advertisement, while allowed by the XEP, would be ignored by most clients in
this context).
- --
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net>
Firstly, this is altering a Final XEP via the backdoor, by reusing the
same XML namespace for an altered protocol. This is trivial to fix - just
use a different namespace
This is barely an alteration. In fact, I originally thought this would work
with XEP-0070 until is seemed no client
== Host Informs Entity of More Fields Needed ==
Enter the code you received via SMS
== Entity Provies Further Information ==
123456
== Host Informs Entity of Successful Registration ==
--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.n
be supported by servers for compatability, but this is not really relevant
to the particular issue of multi-stage support.)
So it seems there is more need in the world than just mine, and two
independently-developed but identical solutions. Should we write up
a "real" XEP?
--
Stephen
widely deployed and old,
can really be changed easily. Though, the data forms extension got added at
some point -- was that before or after it became final?
So this is a question for the rest of the mailing list that knows the
process more: how should we proceed?
--
Stephen Paul Weber
You're correct, a final standard cannot be changed in this way. A new
XEP is the way to go. Looking forward to it :)
What's the right procedure, here? Author XEP based on the HTML I see on
existing XEP and then submit to mailing list for initial comment?
--
Stephen Paul Weber, @singpolyma
lti-stage be supported. What fields are sent and
how the server interprets them will of course depend on what sort of
registration is being done, but that seems out of scope (and likely not
needed in most cases).
--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how
-stage registration case, the user
submits one form and then another, it's not really a "dynamic form".
I'm willing to be convinced otherwise, but the two seem orthogonal.
--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edit
thread.) In fact, having reasonable business
logic rules might be enough to differentiate vs just active/ from 0085
(which it currently is essentially equivalent to).
--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph
signature.asc
.
--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph
41 matches
Mail list logo
