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 w
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
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 ap
aining one or more equivalents 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
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
deprecated
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 tex
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
Unsubscri
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 date-base
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 th
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 for othe
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 federate
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 anoth
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 n
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
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 p
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 rea
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 buffer
> 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
_
On Thu 15 Mar 2018 at 22:46 Ivan Vučica wrote:
> 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.
>> >
>> >
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 it human readable.
>
> It will be
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 people requesting "pl
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. Offline
backup of critical docume
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 going to store t
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 after all?
Sounds like
Offlist: looking at diff I spotted another small typo: ommited :)
On Fri, Dec 1, 2017, 16:23 Florian Schmaus wrote:
> On 01.12.2017 13:44, Ivan Vučica wrote:
> > Some typos:
> >
> > - example 1, mechaisms
> > - section 4, “which is send as” (should be sent)
&g
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 work
On Tue, Sep 26, 2017 at 6:57 PM Sam Whited 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 is "draft". We can
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 certain
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 email an
offline contact than send them
Hi,
Has there been any discussions on how would, hypothetically, XSF
standardize lookup of contacts based on phone numbers?
Context would be a hypothetical "modern-style" mobile IM client that bases
everything around phone numbers.
I have some vague thoughts about it, and no real ideas how to so
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.
__
On Wed, Jul 6, 2016 at 8:44 PM, Florian Schmaus 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
> fine.
> >
&
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 t
On Fri, Feb 13, 2015 at 3:33 PM, Florian Schmaus 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
'VOIP' class of back
On Tue, Feb 10, 2015 at 6:12 PM, Florian Schmaus 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 much th
On Sat, Feb 7, 2015 at 8:10 PM, AliReza Mosajjal
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:
http://xmpp.org/extensions/xep-0272.html (note
lement. (ph)
>
> Diff: 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
xt of
> > the XEP?
>
> should never modify 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...@vucica.net
use of
> inactivity.
>
> Abstract: This document defines a protocol to query and control an archive
> of messages stored on a server.
>
> URL: http://xmpp.org/extensions/xep-0313.html
>
> If and when a new revision of this XEP is published, its status will be
> changed back to Experimental.
>
--
Ivan Vučica
i...@vucica.net
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
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 i
running an "XMPP 2.0" clean redesign just isn't a
> practical concept. It'd be very interesting from the point of view of a
> thought experiment in protocol design, but utterly useless in terms of
> realistic deployment.
>
>
>> What would be left, is to modify the presence stuff to get rid of the
>> need for ever lasting (tcp) connections.
>>
>
> Actually, presence hasn't required everlasting TCP connections for years.
>
> Between BOSH and XEP-0198, that's again a solved problem.
>
> For anywhere I've said "solved problem", you're free to substitute the
> words "case where the state of the art has mitigated the problem to the
> point the incremental gain from a fuller, but more drastic, solution is no
> longer worthwhile".
>
> Dave.
>
--
Ivan Vučica
i...@vucica.net
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
t
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
e IMG-tag.
>
>
>
> However, the new extension HTTP over XMPP (XEP-0332) solves this by
> defining a new URI scheme: *httpx*. A reference to XEP-0332 would be in
> order from §7.5 (Image Module Profile) stating that images can be
> transferred using URLs if support for the httpx URI scheme is available by
> both sender and receiver.
>
> http://xmpp.org/extensions/xep-0332.html#httpxscheme
>
>
>
>
>
> Any comments?
>
>
>
> Best regards,
>
> Peter Waher
>
>
>
>
>
--
Ivan Vučica
i...@vucica.net
45 matches
Mail list logo