On Tue, 9 Mar 2021 at 21:18, Jonas Schäfer wrote:
> On Dienstag, 9. März 2021 21:54:37 CET Florian Schmaus wrote:
> > On 3/9/21 9:11 PM, Jonas Schäfer (XSF Editor) wrote:
> > > The XMPP Extensions Editor has received a proposal for a new XEP.
> > >
> > > Title: Content Rating Labels
> > >
On Wed, 24 Feb 2021 at 22:34, Paul Schaub wrote:
> I wouldn't be too concerned about periods where the root chain is not
> advanced. The crypto should still be strong enough to protect the message
> contents against offline attacks.
>
>
With MLS and Signal, my understanding is that advancing the
On Mon, 22 Feb 2021 at 19:02, Florian Schmaus wrote:
> On 2/18/21 12:16 AM, Dave Cridland wrote:
> > On Wed, 17 Feb 2021 at 19:22, Kevin Smith > <mailto:kevin.sm...@isode.com>> wrote:
> >
> > On 17 Feb 2021, at 18:42, Florian Schmaus >
not in any way I care about.
> I feel like there’s something in the spec I am missing here.
>
XMPP doesn't say anything at all about reordering as far as I'm aware,
meaning we fall back to XML itself, which treats ordering of child elements
as significant.
>
> > On Feb 17, 2021,
I think, broadly, that stanza contents can be re-serialized in any way that
would not alter the canonicalized form, and not otherwise.
So if you want to reorder attributes, go for it. Reorder elements, not so
much.
There are some obvious exceptions:
Servers can insert new elements just fine and
knowing the
schema, unless someone is actually running about putting
xml:space='default' on their stream headers or stanzas.
> Also, it could change
>
> to
>
>
Those are the same by definition. (Though interpreted differently in some
parsers, to my annoyance).
> On Fe
On Wed, 17 Feb 2021 at 14:49, Kevin Smith wrote:
> On 17 Feb 2021, at 14:44, Dave Cridland wrote:
>
>
>> Attribute order, namespacing method (xmlns vs. prefix), and insignificant
>> white space could also change.
>>
>
> Aside from the latter - it's not clear
to appear before other child element types.
>
> Attribute order, namespacing method (xmlns vs. prefix), and insignificant
> white space could also change.
>
Aside from the latter - it's not clear to me how you tell if whitespace is
truly insignificant - those are all OK, though une
On Tue, 16 Feb 2021 at 15:07, Drew Varner wrote:
> > So, for example, XEP-0141 page elements could be reordered?
>
> No. The spec does not know about markup mini languages like XEP-0141,
> XEP-0071, XEP-0393 and XEP-0394. Markup is validated at the client. Order
> is maintained because the spec
On Mon, 15 Feb 2021 at 19:03, Drew Varner wrote:
> It will affect the stability of child node ordering when forwarding
> stanzas if the model “knows” those elements.
>
>
So, for example, XEP-0141 page elements could be reordered? That would seem
to break things rather badly. Also, of course, any
rs do not. OCaml doesn’t.
>
> I am unsure if other folks are using a map-based DSL for a model driven
> CODEC. I don’t see the value in starting to enforce the order on these
> elements.
>
> Thanks,
> Drew
>
> > On Feb 10, 2021, at 4:00 PM, Dave Cridland wrote:
&
On Wed, 10 Feb 2021 at 20:22, Florian Schmaus wrote:
> Since you asked: Smack relies on the ordering (in case a non-default
> form field type is used), since Smack needs to see the first
> to assign types to the field while parsing the following s.
>
Right, so you're parsing using a SAX-style
On Wed, 10 Feb 2021 at 16:29, Jonas Schäfer wrote:
> I am not aware of any place where we impose an ordering between elements
> which
> have *different* fully-qualified XML names (i.e. after namespace
> expansion) [in
> any Draft or significantly deployed standard]. Introducing this
>
(Sorry, I'm replying slowly, having to carve out time at the moment).
On Wed, 3 Feb 2021 at 17:34, Sonny Piers wrote:
> I agree with the points raised, but I suggest we forget about public
> deployments, looks like the only valid use case for this proposal is to
> have default endpoints for
On Wed, 3 Feb 2021 at 15:50, Florian Schmaus wrote:
> On 2/3/21 3:52 PM, Sonny Piers wrote:
> > On Wed, Feb 3, 2021, at 14:20, Florian Schmaus wrote:
> >> On 2/3/21 1:47 PM, Sonny Piers wrote>
> >> > The equivalent for TCP (srv records) is in core so why not its
> >> > equivalent for web ?
> >>
On Wed, 3 Feb 2021 at 07:33, Jonas Schäfer wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Implicit XMPP WebSocket Endpoints
> Abstract:
> This document specifies implicit connection endpoints for XMPP over
> WebSocket (RFC 7395).
>
> URL:
On Wed, 27 Jan 2021 at 22:11, Tedd Sterr wrote:
> In lieu of an official Summit, I invite all interested parties to
> participate in the unofficial Slummit!
>
> Reply in this thread with a few short paragraphs about what you've been
> working on, participating in, any projects you feel others
On Wed, 13 Jan 2021 at 20:46, Sam Whited wrote:
> Where even are any of the values in this format defined? The DOAP link
> in the proto XEP just links to a giant blob of XML which is not useful.
>
> Every time I go through trying to create one of these I end up with a
> million questions that I
On Wed, 13 Jan 2021 at 20:46, Sam Whited wrote:
> Where even are any of the values in this format defined? The DOAP link
> in the proto XEP just links to a giant blob of XML which is not useful.
>
> Every time I go through trying to create one of these I end up with a
> million questions that I
On Wed, 13 Jan 2021 at 18:24, Sam Whited wrote:
> I'd like to recommend that we do not publish this spec in its current
> form. The XML community has the tendency to over-engineer everything to
> try and reuse schemas as much as possible which just makes things more
> difficult for no reason.
Some discussion in Council as to where this fits. I'm quite happy it is
useful as a XEP.
So, is this:
Informational: It's a Best Practice for the community. We are recommending
that projects use DOAP.
Standards Track: It's a specification we want to standardize for the
community to use. Section
On Wed, 30 Dec 2020, 16:33 JC Brand, wrote:
>
>
> On 18.12.20 19:10, Dave Cridland wrote:
> > On Fri, 18 Dec 2020 at 17:01, JC Brand > <mailto:li...@opkode.com>> wrote:
> >
> > Hi all
> >
> > I've submitted a PR for a new protoXEP: MUC Menti
On Wed, 9 Dec 2020 at 19:21, Sam Whited wrote:
> I believe this is a mischaracterization of my argument. My argument is
> "everything will have a way to get at the underlying bytes, not
> everything will have them pre-converted into code points".
I think this, in particular, is not correct.
On Fri, 18 Dec 2020 at 17:01, JC Brand wrote:
> Hi all
>
> I've submitted a PR for a new protoXEP: MUC Mention Notifictions
>
> https://github.com/xsf/xeps/pull/1022
Thanks, this looks like a solid start and I will be voting to accept it.
Comments:
1) I think it would benefit from an example
On Wed, 16 Dec 2020 at 16:19, Jonas Schäfer wrote:
> If
> happen to work in some critical industry, thank you for your service in
> this
> very very strange year.
>
And you know, we all do.
The technology we make here is used by several clinical messaging systems
around the world. It's used
I would just like to say that use of the word "anatidaephobic" means this
debate is now, in my view, essentially won by Ivan (though some details may
need to be discussed further of course).
On Tue, 15 Dec 2020 at 02:18, Ivan Vučica wrote:
> Hi Marvin,
>
> sorry for taking so long to respond.
On Tue, 8 Dec 2020 at 09:25, Kevin Smith wrote:
> Just to focus on a tiny bit of this...
>
> On 8 Dec 2020, at 08:40, Dave Cridland wrote:
> "this wasn't really a message at all, this message explains why". The
> latter feels like a case of failed feature negotiation,
Sorry, I completely missed this for some reason.
On Thu, 19 Nov 2020 at 15:30, Marvin W wrote:
> Hi,
>
> On 19.11.20 12:04, Dave Cridland wrote:
> > * Indicate to clients that if they're just going to display the body
> > tag, then they are missing something. There was s
On Wed, 2 Dec 2020 at 14:09, Sam Whited wrote:
> I've been having a think about dialback recently and came to the
> conclusion that it would be nice to begin discouraging its use on the
> public network. This would raise the overall quality of authentication
> on the network by beginning to
Andrew,
On Wed, 18 Nov 2020 at 17:56, Andrew Nenakhov <
andrew.nenak...@redsolution.com> wrote:
> Using pubsub for stickers is a horrible, no good, very bad idea.
>
The proposal as written only exchanges sticker packs via pubsub; the
stickers themselves are sent as a normal message with a
On Wed, 18 Nov 2020 at 20:40, Marvin W wrote:
> Hi,
>
> On 18.11.20 18:08, Dave Cridland wrote:
> > 1) Use of fallback body
> >
> > I really dislike this as a general mechanism, but at least let's mark it
> > using XEP-0428 (and if that's not quite righ
Hey all,
I think I'm too old to understand Stickers, but anyway...
Some comments about Stickers:
1) Use of fallback body
I really dislike this as a general mechanism, but at least let's mark it
using XEP-0428 (and if that's not quite right, let's fix it).
2) It uses SFS, but modifies its
On Wed, 11 Nov 2020 at 02:43, Tedd Sterr wrote:
> *4b) Proposed XMPP Extension: Pre-Authenticated In-Band Registration* -
> https://xmpp.org/extensions/inbox/ibr-token.html
> Georg: +1
> Daniel: [on-list]
> Jonas: [on-list]
> Zash: [on-list]
> Dave: [on-list]
>
> The author, Georg, thanks Dave
On Fri, 6 Nov 2020 at 17:41, Georg Lukas wrote:
> 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
Hey all,
We (that is, myself and others from Forward Clinical Ltd, my employer) have
been doing some extensive work to support high latency networks such as
Satellite Links, in relation to our work with UK Defence Medical Services.
Our "long thin" links cover the C2S link.
We believe these
On Tue, 3 Nov 2020 at 15:59, XEP Editor Pipeline <
xep-editor-pipel...@zombofant.net> wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Pre-Authenticated In-Band Registration
> Abstract:
> This document extends the In-Band-Registration protocol to use
>
Jonas,
I'm unfortunately unable to attend this meeting, so please accept my
apologies.
Dave.
On Tue, 27 Oct 2020 at 14:33, Jonas Schäfer wrote:
> Hi everyone,
>
> The next XMPP Council Meeting will take place on 2020-10-28 at 16:00Z in
> xmpp:coun...@muc.xmpp.org?join. Everyone is welcome to
On Tue, 20 Oct 2020 at 15:33, Jonas Schäfer wrote:
> If you have any comments about advancing XEP-0363 from Draft to Final,
> please provide them by the close of business on 2020-11-03. After the
> Call for Experience, this XEP might undergo revisions to address
> feedback received, after which
Jonas,
Can we put Reactions on the agenda for adoption - assuming that the authors
remain happy to cede IPR and change control given it's been rejected twice.
I've spent another few hours trying to find a consensus position on
fastenings, but I don't think there's much point in trying further to
Hi all,
Having been prodded into it by people implementing Inbox, I'm doing a sweep
over it.
So far, I've removed the two dangling references to the conversation
marking scheme we removed at the Summit, which seems uncontroversial.
* There is a reference to MAM-FC, which I'll remove on the
On Tue, 29 Sep 2020 at 14:53, Marvin W wrote:
> On 29.09.20 12:23, Dave Cridland wrote:
> > * UUIDv4 becomes an "advised to use"; the requirement is uniqueness. I
> > think UUIDv4 is a good thing, and people are unlikely to get anything
> > wrong if they use
On Tue, 29 Sep 2020 at 11:05, Marvin W wrote:
> I'd like to propose a feature that announces that
> a) origin-id, if present, matches the message id field of the original
> message
> b) message id of the original message (and thereby origin-id if present)
> is a random UUID v4
> - If this
On Mon, 28 Sep 2020 at 15:44, Holger Weiß wrote:
> * Dave Cridland [2020-09-28 09:51]:
> > The implication here is that the MAM messages returned are redundant
> data,
> > and what we're looking to do is optimize for that case.
> >
> > However, for all outgoing
On Mon, 28 Sep 2020 at 11:03, Ruslan N. Marchenko wrote:
> Am Montag, den 28.09.2020, 09:51 +0100 schrieb Dave Cridland:
> >
> >
> > On Sun, 27 Sep 2020 at 16:46, Holger Weiß
> > wrote:
> > >
> > > I think it would be good to find a better solution.
On Sun, 27 Sep 2020 at 16:46, Holger Weiß wrote:
> When opening a new session, MAM clients might want to use the
> most-recent known XEP-0359 stanza ID to sync messages. One problem they
> face is that there's no way to figure out the stanza ID of outgoing
> messages, short of actually querying
On Thu, 17 Sep 2020 at 18:10, Tedd Sterr wrote:
> Would it ever make sense to set the limit to zero? If not, maybe max='0'
> could be more appropriate ("no limit").
>
Yes, it makes sense - it means the node stores no items. I think the MIX
messaging node is like that (since you query an archive
On Tue, 15 Sep 2020 at 10:08, Florian Schmaus wrote:
> On 9/14/20 9:28 PM, Sam Whited wrote:
> > What escaping mechanism, the JSON one or the XML one (probably the JSON
> > one to avoid weird double-escaping issues)?
>
> I wonder if this does matter.
>
> The tricky part are code points that do
ing
> Paul
> Am 14.09.20 um 12:30 schrieb Dave Cridland:
>
>
>
> On Sat, 12 Sep 2020 at 12:36, Paul Schaub wrote:
>
>> Hi List,
>>
>> I see there have been past activities around creating signatures for
>> stanzas/elements.
>>
>> Ther
On Sat, 12 Sep 2020 at 12:36, Paul Schaub wrote:
> Hi List,
>
> I see there have been past activities around creating signatures for
> stanzas/elements.
>
> There are two deferred, competing proposals (XEP-0274: Design
> Considerations for Digital Signatures in XMPP ([1]) & XEP-0285:
>
On Fri, 4 Sep 2020 at 13:51, Andrew Nenakhov <
andrew.nenak...@redsolution.com> wrote:
> пт, 4 сент. 2020 г. в 16:37, Georg Lukas :
>
> > This was discussed before, and in my eyes the XEP hammer looks
> > sufficiently right for this, as it gives us:
> >
> > - a proper process to decide what goes
Hey all,
Really simple questions, so please do reply and answer:
If you have an XMPP product or public project, do you claim compliance with
XEP-0423?
If you do not claim compliance, are you aiming for compliance with XEP-0423?
Dave.
___
Standards
My apologies for not replying to this one, though I think it's covered
elsewhere in this discussion. For completeness:
On Wed, 1 Jul 2020 at 13:28, Philipp Hancke
wrote:
> If the receiving server follows the process described in #9 of
>https://xmpp.org/extensions/xep-0178.html#s2s
> which
On Tue, 21 Jul 2020 at 18:57, Florian Schmaus wrote:
> Based on the discussion in this thread, I suggest the following changes
>
> http://geekplace.eu/xeps/xep-sasl-cb-types/diff.html#sasl-mech-interaction
Is it worth making tls-server-endpoint an MTI for XEP-0440?
It is, as you note, trivial
On Wed, 8 Jul 2020 at 12:44, Ruslan N. Marchenko wrote:
> Am Dienstag, den 07.07.2020, 10:55 +0100 schrieb Dave Cridland:
>
>
>
> On Mon, 6 Jul 2020 at 15:41, Ruslan N. Marchenko wrote:
>
> Am Montag, den 06.07.2020, 16:20 +0200 schrieb Ruslan N. Marchenko:
>
> Am Mo
On Mon, 6 Jul 2020 at 15:41, Ruslan N. Marchenko wrote:
> Am Montag, den 06.07.2020, 16:20 +0200 schrieb Ruslan N. Marchenko:
>
> Am Montag, den 06.07.2020, 13:19 +0100 schrieb Dave Cridland:
>
>
>
> On Mon, 6 Jul 2020 at 12:44, Ruslan N. Marchenko wrote:
>
> Am Mo
On Mon, 6 Jul 2020 at 12:44, Ruslan N. Marchenko wrote:
> Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland:
>
>
>
> On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko wrote:
>
> Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave Cridland:
>
>
>
> On
On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko wrote:
> Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave Cridland:
>
>
>
> On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko wrote:
>
> Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave Cridland:
>
>
>
On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko wrote:
> Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave Cridland:
>
>
>
> On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko wrote:
>
>
> Because Alice's authentication fails on this particualr conneciton? So it
>
On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko wrote:
> Am Mittwoch, den 01.07.2020, 10:37 +0100 schrieb Dave Cridland:
>
>
>
> On Tue, 30 Jun 2020 at 17:59, Ruslan N. Marchenko wrote:
>
> Am Dienstag, den 30.06.2020, 17:59 +0200 schrieb Jonas Schäfer:
> > H
On Tue, 30 Jun 2020 at 19:59, Holger Weiß wrote:
> * Jonas Schäfer [2020-06-30 17:59]:
> > On behalf of the Council, I'd like to bring this pull request to the
> attention
> > of the community:
> >
> > https://github.com/xsf/xeps/pull/963
>
> Wait, is this PR actually modifying the
On Wed, 1 Jul 2020 at 10:41, Dave Cridland wrote:
>
>
> On Tue, 30 Jun 2020 at 19:46, Kim Alvefur wrote:
>
>> This does result in a number of different possible configurations. Not
>> great for something security related. Personally I hope we might be able
>> to ph
On Tue, 30 Jun 2020 at 19:46, Kim Alvefur wrote:
> This does result in a number of different possible configurations. Not
> great for something security related. Personally I hope we might be able
> to phase out Dialback in the future. Today, largely thanks to Let's
> Encrypt, more and more
On Tue, 30 Jun 2020 at 17:59, Ruslan N. Marchenko wrote:
> Am Dienstag, den 30.06.2020, 17:59 +0200 schrieb Jonas Schäfer:
> > Hi list,
> >
> > (Editor hat on)
> >
> > On behalf of the Council, I’d like to bring this pull request to the
> > attention
> > of the community:
> >
> >
Hey,
I think there is considerable merit in moving to Gitlab - I've found it
impressive to use "in anger" as a product, and the technical abilities that
Jonas outlined below are mouth-wateringly exciting, but also it feels
generally more aligned to our FLOSS-friendly stance as an organisation.
Hey,
Really quick thought, but the server's automatic unavailable will still go
to the full jid, since that's where the directed presence goes. So sending
to the bare jid only helps in an explicit leave, and not an implicit one
due to going offline - which I suspect is the majority of cases.
On Wed, 10 Jun 2020 at 16:39, Florian Schmaus wrote:
> On 6/3/20 10:50 PM, Dave Cridland wrote:> That said, I think there's two
> useful things we can do here:
> >
> > 1) Validation information is clearly useful in this case; we should add
> > that to the XEP-0068 r
On Fri, 5 Jun 2020 at 10:15, Andrzej Wojcik
wrote:
> Hi everyone,
>
> I'm sorry but this will be a long email.
>
>
No need to apologise; this is really useful feedback, so thank you.
> I've started the implementation of XEP-0427 with a goal to use the
> collation of fastenings (and
On Wed, 3 Jun 2020 at 16:30, Jonas Schäfer wrote:
> Hi everyone,
>
> Flow and I got in a discussion about whether it is OK to add foreign,
> namespaced elements to Registry entries.
>
> I’m not sold to either side, I was just curiously wondering if there’s
> precedent and if it’s considered a
On Mon, 1 Jun 2020 at 17:20, Marvin W wrote:
> Hi,
>
> Sorry, long mail ahead.
>
> I'd like to express that I am very much unhappy where this is leading.
>
Thanks for writing this; it's an excellent summary of where we are, and
seems to have sparked some more constructive debate. (In other
On Mon, 1 Jun 2020 at 09:19, Dave Cridland wrote:
>
>
> On Sun, 31 May 2020 at 23:50, Tedd Sterr wrote:
>
>> *4c) Advance XEP-0393 (Message Styling)* -
>> https://xmpp.org/extensions/xep-0393.html
>> Dave quite likes this, but is aware that many people d
On Sun, 31 May 2020 at 23:50, Tedd Sterr wrote:
> *4c) Advance XEP-0393 (Message Styling)* -
> https://xmpp.org/extensions/xep-0393.html
> Dave quite likes this, but is aware that many people don't.
> Jonas has a multitude of concerns: community recommendations for an
> explicit opt-in switch;
On Sun, 24 May 2020 at 11:40, Maxime Buquet wrote:
> On 2020/05/24, Dave Cridland wrote:
> > On Sun, 24 May 2020 at 10:24, Maxime Buquet wrote:
> > It doesn't actually distinguish between chatrooms and individuals, if you
> > look closely - it just references the conversat
On Sun, 24 May 2020 at 11:37, Matthew Wild wrote:
> On Sun, 24 May 2020, 11:32 Dave Cridland, wrote:
>
>> Would .well-known work? So for status information on xmpp:jabber.fr,
>>> you'd follow redirects from
>>> https://jabber.fr/.well-known/xmpp-server-status
On Sun, 24 May 2020 at 10:24, Maxime Buquet wrote:
> Hi Standards,
>
>
> I was reading Inbox again yesterday and I notice that it mentions
> "chatrooms" twice, but not how it's supposed to work with such
> chatrooms.
>
>
It doesn't actually distinguish between chatrooms and individuals, if you
On Sat, 23 May 2020 at 11:53, Mathieu Pasquet wrote:
> On 23.05.2020 11:38, Matthew Wild wrote:
> >On Sat, 23 May 2020, 10:51 Maxime Buquet, wrote:
> >
> >All those who expressed feelings against adding this to 157 at the
> time
> >you sent this didn't mention why.
> >
> >I
Hi all,
TL;DR - This is why I might reject a ProtoXEP. Feel free to talk to me
about it.
Since I was discussing it privately, I thought stating my current criteria
for accepting ProtoXEPs might be useful. I've made a conscious effort to
try and minimize vetoing new XEPs, in order to try and
On Sun, 10 May 2020 at 14:43, Sam Whited wrote:
> > I'd be fine with putting channel bindings alongside mechanisms, just
> > not pretending they are mechanisms.
>
> I still don't see why it bothers anyone. We already do this with "-
> PLUS", so what is wrong with adding another suffix? So far
On Tue, 12 May 2020 at 18:39, Sam Whited wrote:
> No one has indicated why they think this is a bad thing yet.
They are not mechanisms, but pretend to be, thus breaking the semantics of
what that element is intended to contain.
> It seems
> fine to me. As I said, these mechanisms aren't full
Further to this: Sam's Draft is now in the process of being adopted - it'd
be great if people would join that list and show interest in working on it.
On Wed, 6 May 2020 at 22:51, Dave Cridland wrote:
> Hi all,
>
> Sam has also submitted this XEP in a significantly expanded form to th
On Wed, 6 May 2020 at 23:20, Sam Whited wrote:
> On Wed, May 6, 2020, at 18:03, Dave Cridland wrote:
> > The TL;DR is "horrible syntax, but really useful idea". … So, I would
> > love to see this problem tackled properly, but without a syntax that
> > inv
On Tue, 5 May 2020 at 20:09, Jonas Schäfer wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Channel Binding Pseudomechanisms
> Abstract:
> A method for advertising and negotiating types of channel binding
> supported by SCRAM based SASL mechanisms.
>
> URL:
Hi all,
Sam has also submitted this XEP in a significantly expanded form to the
[IETF], and raised it in the [KITTEN] working group. The current status
within the IETF is an "individual draft", and while it can get to RFC
status like that, I think formal adoption as a "working group draft" would
On Wed, 29 Apr 2020 at 15:34, Tedd Sterr wrote:
> https://logs.xmpp.org/council/2020-04-22?p=h#2020-04-22-8bddd57b73bab8fc
>
> *1) Roll Call*
> Present: Daniel, Zash, Jonas, Georg
> Apologies: Dave
>
> *2) Agenda Bashing*
> It's already long enough.
>
> *3) Editor's Update*
> * Expired calls:
On Tue, 28 Apr 2020 at 18:28, Georg Lukas wrote:
> * 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
>
>
On Thu, 23 Apr 2020 at 12:51, Kim Alvefur wrote:
> On Thu, Apr 23, 2020 at 10:16:41AM +0100, Dave Cridland wrote:
> > * The XML namespace is not under XSF control.
> >
> > Of these, the last is blocking for me; we have run into problems when
> > non-XSF namespace
On Wed, 22 Apr 2020 at 15:46, Tedd Sterr wrote:
> https://logs.xmpp.org/council/2020-04-15?p=h#2020-04-15-515165c7293c9539
>
> *1) Roll Call*
> Present: Daniel, Jonas, Zash, Georg
> Apologies: Dave
>
> *2) Agenda Bashing*
> No additions.
>
> *3) Editor's Report*
> * Expired calls: None
> * Calls
On Tue, 21 Apr 2020 at 21:24, Matthew Wild wrote:
> ### Why not use data forms?
>
> Data forms have existed for a long long time. They are quite powerful, and
> have been reused successfully in a bunch of places for both human and
> machine interactions.
>
> They are too complex for this
On Tue, 21 Apr 2020 at 20:20, Sam Whited wrote:
> Hi Dave et al,
>
> I'm not against publishing this as an RFC. However, despite the broad
> scope of this XEP making it a good fit for the IETF in some ways, I
> think there is value in having a document that contains specific
> recommendations
On Tue, 21 Apr 2020 at 11:50, wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Best practices for password hashing and storage
> Abstract:
> This document outlines best practices for handling user passwords on
> the public Jabber network for both clients and
Not blocking comments, but I'd like to explore the forms thing a bit more:
On Tue, 21 Apr 2020 at 13:40, wrote:
> I agree that forms are a better fit for more complicated use-cases with
> multiple fields and options. And I can see that the benifit of a
> single-click "yes" vs. a manually typed
On Tue, 21 Apr 2020 at 13:26, Andrew Nenakhov <
andrew.nenak...@redsolution.com> wrote:
>
>
> вт, 21 апр. 2020 г. в 16:51, :
>
>> One example use-case for Quick Response is the memberbot, which asks
>> yes/no multiple times during membership voting. Memberbot does not use a
>> form to ask for
:* Dienstag, 21. April 2020 um 13:32 Uhr
> *Von:* "Dave Cridland"
> *An:* "XMPP Standards"
> *Betreff:* Re: [Standards] Proposed XMPP Extension: Quick Response
> This seems to be a two-in-one.
>
> Do I assume the intent is that both responses and actions wou
On Mon, 20 Apr 2020 at 16:20, Matthew Wild wrote:
> On Fri, 3 Apr 2020 at 21:51, Matthew Wild wrote:
>
>> Hi folks,
>>
>> XEP-0313 is a well-established protocol at this point, but didn't yet
>> make it to the next stage in the standards process. Time to fix that!
>>
>> I have made a final
This seems to be a two-in-one.
Do I assume the intent is that both responses and actions would be
presented as the same UX in the receiving client?
Otherwise, I'm sort of leaning toward these being in different XEPs.
On Tue, 21 Apr 2020 at 11:50, wrote:
> The XMPP Extensions Editor has
On Wed, 1 Apr 2020 at 17:31, Tedd Sterr wrote:
> http://logs.xmpp.org/council/2020-04-01?p=h#2020-04-01-679b0ee4558ba19a
>
> *1) Roll Call*
> Present: Zash, Georg, Jonas, Daniel
> Apologies: Dave
>
> *2) Agenda Bashing*
> Nothing to add.
>
> *3) Editor's Update*
> * Expired calls: None
> * Calls
On Sun, 12 Apr 2020 at 14:13, Jonas Schäfer wrote:
> On Samstag, 11. April 2020 17:07:20 CEST Kim Alvefur wrote:
> > Hi,
> >
> > Some time ago I tried to join an IRC channel via a gateway, but the
> > client said that the room had too many users in it. Confused, I dug into
> > logs to see what
On Wed, 25 Mar 2020 at 16:08, Tedd Sterr wrote:
> http://logs.xmpp.org/council/2020-03-18?p=h#2020-03-18-d77f2f5c2e5ea3ba
>
> *1) Roll Call*
> Present: Daniel, Georg, Jonas, Zash
> Apologies: Dave
>
> *2) Agenda Bashing*
> Nothing to add.
>
> *3) Editor's Update*
> * ProtoXEP: Reminders
> *
Hello!
Today is a Sunday. It's normally a quiet day in the National Health Service
in the UK - only emergency cases get dealt with.
Yesterday, however, the service I help run peaked at more messages than
it'd normally see on a weekday - and it'll do the same today. If the growth
curve holds,
On Fri, 13 Mar 2020 at 23:47, Tedd Sterr wrote:
> http://logs.xmpp.org/council/2020-03-11?p=h#2020-03-11-8d229823ff2ec504
>
> *1) Roll Call*
> Present: Zash, Jonas, Georg, Daniel
> Apologies: Dave
>
> *2) Agenda Bashing*
> Nothing to add.
>
> *3) Editor's Update*
> * ProtoXEP: Reminders
> *
Hi everyone,
As you may know, my employer (Pando) provides IM services (over XMPP, of
course) to various health services around the world, including the National
Health Service in the UK.
For some reason, things are quite busy at the moment...
https://hellopando.com/covid-19/
XSF work is,
101 - 200 of 1594 matches
Mail list logo
