I'm catching up on this thread and I'm replying to two of your mails at
the same time.
On Mon, 03 Jun 2024 12:37:21 +0200, Marvin W wrote:
> I tried to circumvent this by writing XEP-0447 [..] yet there already have
> been implementations from the community in released software.
> This underlines
On 2024/03/10, Daniel Gultsch wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0360.
>
> Title: Nonzas (are not Stanzas)
> Abstract:
> This specification defines the term "Nonza", describing every top
> level stream element that is not a Stanza.
>
> URL:
On 2023/03/17, Matthew Wild wrote:
> I actually think the current behaviour of Prosody (and I think
> ejabberd? others?) is definitely desirable in some cases, and I
> propose making it an explicit option ('discard-oldest'?) - in this
> mode the node is effectively a cache of the most recent
I have just submitted https://github.com/xsf/xeps/pull/1275
I remember first mentioning it here[0] and jonas giving me a quick
answer[1] at the time. I've seen this happen again recently and I
decided to give it some time.
What happens when a client publishes on a full node seems to be
I've been trying to work on Ephemeral Messages (XEP-0466) again, and I
still can't figure out remaining TODOs.
These are my changes on top of the current state of the spec, but
they're here just for information, they don't contain anything related
to this question.
On 2023/01/18, Peter Saint-Andre wrote:
> On 1/18/23 9:26 AM, Thilo Molitor wrote:
> > In Appendix F: Requirements Conformance all our XEPs refer to RFC 2119
> > defining
> > "MUST", "SHALL" etc.
> > But since RFC 2119 does not specify which case should be used for these
> > keywords, a XEP using
On 2023/01/07, Florian Schmaus wrote:
> I believe we would be able bring back the good old days where new protocols
> ideas could be explored and bootstrapped without being bogged down in
> process by having such numberless XEPs and by the XSF to provide the
> infrastructure to host, develop and
On 2022/11/02, Goffi wrote:
> 'pubsub#type' would be "http://www.w3.org/2005/Atom; in any case here, I
> don't
> see how you would use it to get comment nodes or gallery node. You would have
> to add an other metadata for that (which can be done).
Just reacting to this because I feel this is
On 2022/09/23, Jonas Schäfer wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Events
> Abstract:
> This specification describe how to handle events with XMPP.
Thanks Jonas!
Thanks Goffi!
I have skimmed over the spec, and here are a few comments that
On 2022/01/12, Maxime Buquet wrote:
> On 2022/01/09, Dave Cridland wrote:
> > * Also: Put in a PR against XEP-0060 (sorry Ralph/Peter) to indicate that
> > the pubsub#type means a label for the node semantics, and while it is often
> > the same as the payload namespace it can
On 2022/01/09, Dave Cridland wrote:
> On Sat, 8 Jan 2022 at 23:04, Maxime Buquet wrote:
> Therefore, I would:
>
> * Replace the new field with the existing one.
> * Strike section 5.2 (pubsub node, no longer needed)
Maybe only just §5.2.2. §5.2.1 could be moved up in §5.1.
>
On 2022/01/08, Dave Cridland wrote:
> On Tue, 4 Jan 2022 at 17:55, Jonas Schäfer wrote:
>
> > The XMPP Extensions Editor has received a proposal for a new XEP.
> >
> > Title: PubSub Namespaces
> > Abstract:
> > This extension defines a new PubSub node attribute to specify the type
> > of
On 2020/09/18, Maxime Buquet wrote:
> On 2020/09/17, Maxime Buquet wrote:
> > This change to PubSub has been met with some ““resistance”” by the
> > prosody team because the proposed value “max” is not a number and
> > doesn't fit the way they currently handle things with XEP
On 2020/09/17, Maxime Buquet wrote:
> This change to PubSub has been met with some ““resistance”” by the
> prosody team because the proposed value “max” is not a number and
> doesn't fit the way they currently handle things with XEP-0122 (Data
> Forms Validation), setting this value
Hi Standards,
A year ago during a sprint we worked on implementing bookmarks2 and
submitted a few changes to the spec at the same time.
We also submitted a change to PubSub [0] [1] to allow a client to say
“Set pubsub#max_items to whatever the server max is” so that multiple
clients don't
On 2020/09/02, Tedd Sterr wrote:
> I suspect their main benefit, rather than for implementations to claim some
> level of compliance, is as a guide to which features are in use across the
> ecosystem, and therefore worthwhile to implement. As federation requires
> overlapping feature-sets, this
On 2020/06/16, Jonas Schäfer wrote:
> Hi again,
>
> Thanks Sam and Kevin for your valuable feedback. I think what you say
> definitely has merit.
>
> In light of that, we came up with a hybrid solution which may be better or
> worse. We need input on that.
>
> [..]
>
> Again, thank you very
On 2020/06/01, Jonas Schäfer wrote:
> [..]
>
> First off, as Dave mentioned already (and as "everyone" will already know),
> arguably this is deployed very widely. And not because of '393, specifically,
> but because people have been using these types of metamarkers for so long
> already that
On 2020/05/24, Philipp Hörist wrote:
> Hi,
>
> let me try with XEP-0402
>
>
>
>
>
> name='The Plays the Thing'
> autojoin='true'>
> JC
>
>
>
>
>
>
>
On 2020/05/24, Stefan wrote:
> Am Sonntag, den 24.05.2020 um 00:41:53 +0200 schrieb mathi...@mathieui.net:
> > The use cases I have in mind are a bit extreme (e.g. people with > 100
> > MUCs in their autojoined bookmarks), which are unusable on mobile, for
> > example, where screen space is
On 2020/05/24, 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 conversation endpoints b
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 conversation endpoints by bare jid,
> which works for 1:1, MUC, and MIX.
I'
On 2020/05/24, Philipp Hörist wrote:
> What first comes to mind is, that 402 now can hold extended payloads in
> each bookmark item.
> So we just add the profile there?
Not against the idea, even though I'm not entirely sure how it would
work.
0402 is not a bookmark XEP, just like the multiple
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.
How does it work? Is that only meant to work with MIX? If so can that be
made explicit?
I'm apparently not the first one to notice:
On
On 2020/05/24, Mathieu Pasquet wrote:
> Greetings,
>
> I want to raise an issue that appears with bookmarks in their current
> form in the multi-client scenario. It appears as long as we have more
> than one client, and gets worse for every added client and MUC bookmark.
>
> XEP-0048 and
On 2018/12/03, Matthew Wild wrote:
> Hi all,
>
> I'd like to allow servers to advertise status pages to their users.
> See for example https://statut.jabberfr.org/
>
> This information could be cached by clients, and linked to in case of
> problems connecting, for example.
>
> The question is
On 2020/05/12, Jonas Schäfer wrote:
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
No.
> 2. Does
On 2020/04/07, Andrzej Wojcik wrote:
> >
> > However, can we please stop with JSON encoding in XML "because it's
> > smaller". That claim is not true i all cases (not even most) and also
> > not in your specific case:
>
> [..]
>
> And representation may be smaller in XML unless someone will use
On 2020/04/04, Linus Jahn wrote:
> Hello,
>
> I opened a pull request more than 1.5 years ago and received a +1 from
> stpeter,
> but no further interaction. The pull request was not merged.
>
> The pull request can be found here:
> https://github.com/xsf/registrar/pull/30
>
> Can I do
On 2020/03/10, p...@bouah.net wrote:
> Version 0.4.0 of XEP-0384 (OMEMO Encryption) has been released.
>
> Abstract:
> This specification defines a protocol for end-to-end encryption in
> one-to-one chats, as well as group chats where each participant may
> have multiple clients per account.
>
>
On 2020/02/13, Florian Schmaus wrote:
> On 1/29/20 5:33 PM, Jonas Schäfer (XSF Editor) wrote:
> > This message constitutes notice of a Last Call for comments on
> > XEP-0402.
> >
> > Title: Bookmarks 2 (This Time it's Serious)
> > Abstract:
> > This specification defines a syntax and storage
On 2020/02/03, Maxime Buquet wrote:
> > 3. Do you plan to implement this specification in your code? If not,
> > why not?
>
> I have not implemented it yet, but I would.
>
> As this spec allows to handle bookmarks separately, it's easier to
> handle group/Enterprise(tm
My answer is a mix of what Sam, Daniel, and lovetox say. :)
> This Last Call begins today and shall end at the close of business on
> 2020-02-12.
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
> 1. Is this
On 2020/01/21, Jonas Schäfer wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Inbox
> Abstract:
> This specification proposes a mechanism by which clients can find a
> list of ongoing conversations and their state.
>
> URL:
On 2020/01/22, Sam Whited wrote:
> And finally (I hope) XEP-0412: XMPP Compliance Suites 2019 [1] and XEP-
> 0423: XMPP Compliance Suites 2020 [2] are both in draft, which is just
> confusing. The 2019 ones should be obsoleted (which wasn't one of the
> original questions, I know, but it seems
On 2020/01/02, Marvin W wrote:
> But this spontaneous "let's get rid of what many use in practice and
> what significantly boosted XMPPs popularity in the last years" without a
> proper replacement plan makes little sense to me.
I can only agree.
> > The bigger problem is the change by Daniel
On 2020/01/01, Dave Cridland wrote:
> On Wed, 1 Jan 2020 at 18:40, Maxime Buquet wrote:
> > I'm curious if you have any viable alternative to propose while you
> > reject the only widely used encryption mechanism? If not, I think doing
> > this is only going to harm the com
On 2019/12/30, Dave Cridland wrote:
> On Mon, 30 Dec 2019 at 17:16, Philipp Hörist wrote:
> > Am Mo., 30. Dez. 2019 um 17:57 Uhr schrieb Dave Cridland <
> > d...@cridland.net>:
> >
> >> That specification isn't linked from XEP-0384 at all, so how are we
> >> supposed to be able to tell it affects
On 2019/11/25, Jonas Schäfer wrote:
> On Montag, 25. November 2019 10:45:37 CET Dave Cridland wrote:
> > I can't begin to adequately explain how useful this is. The minutes Tedd
> > sends out are highly engaging summaries of what happened in the meetings
> > and I hope they're as useful to others
On 2019/10/15, Maxime Buquet wrote:
> I don't think Council is competent when it comes to UI/UX, as in it
> doesn't have to be within their expertise, it's not required from them.
> It's also not what I look for when I vote for council members, it's only
> bonus.
This certainly ca
On 2019/09/11, Jonas Schäfer wrote:
> Version 0.1.0 of XEP-0423 (XMPP Compliance Suites 2020) has been
> released.
>
> Abstract:
> This document defines XMPP protocol compliance levels.
Some feedback, based on the current state of PR[0].
Overall I still don't know what to think about Compliance
On 2019/10/14, Florian Schmaus wrote:
> On 14.10.19 14:28, Georg Lukas wrote:
> > * Florian Schmaus [2019-10-11 12:35]:
> Please do not mention all MIX XEPs in the compliance suite. The main
> entry point to MIX is a single XEP, and this is the only one the
> compliance suite should mention.
I
On 2019/10/06, Daniel Gultsch wrote:
> Therefor I propose wording for XEP60 that 'clarifies' that max-items 0
> means unlimited.
Is there a way to know as a client when we're going to run into the
limit? Or when we've gone over the limit? Or is the pubsub service just
overwritting stuff and
On 2019/09/30, Maxime Buquet wrote:
> Hi Standards,
>
>
> I've had this in my backlog for quite some time, and while I am not
> planning to work on this right away, I thought it might be good to share
> it anyway. I have looked through the list quickly and I haven't found
>
Hi Standards,
I've had this in my backlog for quite some time, and while I am not
planning to work on this right away, I thought it might be good to share
it anyway. I have looked through the list quickly and I haven't found
much about what I'm going to describe.
As much as I would like to, I
On 2019/09/25, Maxime Buquet wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Message Moderation
> Abstract:
> This specification defines a method for groupchat moderators to moderate
> messages.
>
> URL: https://xmpp.org/
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Message Moderation
Abstract:
This specification defines a method for groupchat moderators to moderate
messages.
URL: https://xmpp.org/extensions/inbox/message-moderation.html
The Council will decide in the next two weeks
On 2019/09/24, JC Brand wrote:
> On Tue, Sep 24, 2019 at 10:40:30AM +0200, Maxime Buquet wrote:
> > What about looking at it the other way around? 1:1 being the general
> > case and MUC something that modifies/enhances it.
> >
> > In 1:1, one would be able to s
On 2019/09/23, JC Brand wrote:
> Based on our off-list discussion, I'm going to go with sending an IQ to the
> MUC
> JID in order to ask for a message to be retracted.
>
> The MUC then sends out the retraction message to all participants. This solves
> the problem of temporary moderators
On 2019/09/04, JC Brand wrote:
> I just read the latest Council minutes (thanks Ted Sterr!)
> and noticed that message retractions came up.
>
> https://mail.jabber.org/pipermail/standards/2019-September/036391.html
>
> > Link notes that multiple people have noticed previous Councils appear to
>
On 2019/08/26, Holger Weiß wrote:
> * Maxime Buquet [2019-08-24 20:26]:
> > I found about this issue while working on the OMEMO implementation in
> > poezio (that should be available soon(tm)), but I guess this can be
> > applied to other things. The issue goes as foll
Hi standards,
I found about this issue while working on the OMEMO implementation in
poezio (that should be available soon(tm)), but I guess this can be
applied to other things. The issue goes as follows:
- Start encrypted chat with non-contact recipient.
At this point, my OMEMO code will
On 2019/08/20, Dave Cridland wrote:
> On Tue, 20 Aug 2019 at 13:03, Georg Lukas wrote:
> > * Tedd Sterr [2019-08-18 23:00]:
> > > PR #805 - XEP-0060: Add a pubsub#rsm disco#info feature to clear
> > confusion - https://github.com/xsf/xeps/pull/805
> >
> > +1. I'd prefer to use `pubsub+rsm` and
Hi standards,
I have implemented Origin-id in Slixmpp[0].
I am not entirely sure if it should be included in every single
though, is there any business rules concerning this? The XEP
almost only talks about stanza-id in there.
[0]: https://lab.louiz.org/poezio/slixmpp/merge_requests/21
Happy
Hi standards,
With edhelas we've been looking at changing XEP-0413: Order-By a bit,
for it to be allowed in disco#items requests.
Order-By is currently mostly used with PubSub (if it is implemented at
all). That is, a PubSub service would advertize it in disco#info, thus
meaning that it's
I assumed this does not apply only to reactions, as you mentioned on
xsf@ yesterday, so I'm using this as a start for these comments.
On 2019/07/19, Georg Lukas wrote:
> 2. Backward compatibility
>
> This XEP does not provide any way for legacy clients to see reactions.
>
> This (silently)
On 2019/07/17, Jonas Schäfer wrote:
> On Montag, 15. Juli 2019 17:57:12 CEST Jonas Schäfer wrote:
> > The XMPP Extensions Editor has received a proposal for a new XEP.
> >
> > Title: Anonymous unique occupant identifiers for MUCs
> > Abstract:
> > This specification defines a method that allows
On 2019/06/24, Florian Schmaus wrote:
> On 18.06.19 11:03, Philipp Hörist wrote:
> > Hi,
> >
> > Im not quite sure what you want to negotiate,
>
> Roughly speaking which secured, i.e. encrypted and/or signed, extension
> elements an entity is going to send to another entity. We may not have
> to
On 2019/06/24, Dave Cridland wrote:
> On Mon, 24 Jun 2019 at 20:11, Paul Schaub wrote:
> > Am 24.06.19 um 19:04 schrieb Ненахов Андрей:
> > > So much for deniability.
> >
> > Yeah, I'd rather keep it flexible and let the encryption XEP which
> > defines a SCE profile decide, which fields to use
On 2019/05/23, Guus der Kinderen wrote:
> There's an effort under way to have developed visual badges associated to
> the XMPP Compliance Suites.
I'm not entirely sold on the idea of Compliance Suite the way it is
currently, and I'm waiting for that magical answer (maybe, maybe not)
that was
Hi Standards,
A Slixmpp user ran into an issue[0] with assumptions that the library
has when it shouldn't.
When playing with the `adhoc_provider` example of Slixmpp, I realized
though that it sends ``, and none of
Gajim and Poezio send `complete`. Gajim sends `execute` to progress
while Poezio
On 2019/03/29, Maxime Buquet wrote:
> On 2019/03/26, Jonas Schäfer wrote:
> > The XMPP Extensions Editor has received a proposal for a new XEP.
> >
> > Title: Automatic Trust Transfer (ATT)
> > Abstract:
> > ATT specifies an automatic transfer of trust in public
On 2019/03/26, Jonas Schäfer wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Automatic Trust Transfer (ATT)
> Abstract:
> ATT specifies an automatic transfer of trust in public identity keys
> used by the end-to-end encryption protocol OMEMO.
>
> URL:
On 2019/03/27, Sam Whited wrote:
>
>
> On Wed, Mar 27, 2019, at 19:33, Ненахов Андрей wrote:
> > How do I turn off markdown processing on your side? I don't even know
> > you do have some thing that misformats my message despite having no
> > intent to be misformatted that way. This is
On 2019/03/27, Sam Whited wrote:
> On Wed, Mar 27, 2019, at 17:14, W. Martin Borgert wrote:
> > 0393 is not bad, IMHO. It might need two or three additions, esp.
> > hyperlinks, but most typical use cases are covered.
>
> What is the use case for hyper links and who does it benefit? I
> keep
On 2019/01/12, Jonas Schäfer wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0345.
>
> Note: Since this is a Procedural XEP under control of Board, the Last Call
> mail goes to both standards@ and members@ (only for XSF members) mailing
> lists. This may lead to
Hi Standards,
I had the opportunity to discuss with people interested in at
the 35C3.
The current state of is not ideal, it is pretty much ephemeral,
and I Ge0rG has been working on it, and we've been discussing it at the
Düsseldorf sprint[0]. I'll keep this thread focused on my question
On 2018/12/01, forenjunkie wrote:
> Hi,
> As Daniel wrote, MUST is probably to strong here, it is enough to mention
> that it can lead to problems if you dont discard such messages.
As I am not especially knowledgeable on OMEMO or the implications yet, I
would appreciate if somebody PR'd against
Hi Standards,
When trying to implement OMEMO support in poezio, I came across a few
points that make me shiver like chalk on blackboard each time I read
them.
All 3 points are in
https://xmpp.org/extensions/xep-0384.html#usecases-messagesend.
> When an OMEMO element is received, the client
On 2018/05/02, Maxime Buquet wrote:
> On 2018/05/02, Florian Schmaus wrote:
> > On 01.05.2018 13:03, Maxime Buquet wrote:
> > > On 2018/05/01, Dave Cridland wrote:
> > >> But if you have it in the same domain, then the domain can manage all
> > >> this
&g
On 2018/05/02, Florian Schmaus wrote:
> On 01.05.2018 13:03, Maxime Buquet wrote:
> > On 2018/05/01, Dave Cridland wrote:
> >>> I wanted to have fancyname@muc and serious-business@muc, pointing to
> >>> the same room.
> >>>
> >>> For this
On 2018/05/01, Dave Cridland wrote:
> > I wanted to have fancyname@muc and serious-business@muc, pointing to
> > the same room.
> >
> > For this particular use case an alias might be best, The component knows
> > what other has joined what JID and speaks to them via this JID. I would
> > also be
On 2018/05/01, Dave Cridland wrote:
> On 1 May 2018 at 00:43, Maxime Buquet <p...@bouah.net> wrote:
>
> > Hi Standards,
> >
> > I was wondering if it was possible to have aliases for a chatroom.
> >
> > Say I want to have foo@muc as a proper room, an
Hi Standards,
I was wondering if it was possible to have aliases for a chatroom.
Say I want to have foo@muc as a proper room, and bar@muc as an alias,
joining bar@muc would make me join foo@muc instead.
Is there a solution for this already?
I was told to have a look at `` (10.9), but it does
On 2018/03/22, Matthew Wild wrote:
> We're discussing the protocol, but there is nothing stopping clients
> having their own overrides (i.e. local autojoin rooms). This could be
> as simple as, when you join a room for the first time "Do you want to
> join this room on all devices?" -> if the user
On 2018/03/21, Maxime Buquet wrote:
> On 2018/03/21, Sam Whited wrote:
> > I agree with this; when I do something on one client, I almost always want
> > it synced to my other clients. Room joining and parting is the same.
> > Similarly, just because my connection dro
On 2018/03/21, Sam Whited wrote:
> On Wed, Mar 21, 2018, at 12:01, Kevin Smith wrote:
> > I’d argue (and did at the Summit) that the opposite is true and that if
> > we want (especially impromptu) MUC to start working nicely across
> > multiple accounts we need clients to react to the user
On 2018/03/20, Jonas Wielicki wrote:
> On Dienstag, 20. März 2018 19:12:57 CET Georg Lukas wrote:
> > > The XMPP Extensions Editor has received a proposal for a new XEP.
> > > Title: Bookmarks 2 (This Time it's Serious)
> >
> > A number of issues I have with the current Bookmarks XEPs, and that
On 2018/03/09, Georg Lukas wrote:
> 1) the Security Considerations spoil all the fun of automatic account
> transfers:
>
> | In order to prevent other users from maliciously altering contacts the
> | client SHOULD NOT automatically subscribe to a JID when it
> | receives an unsubscribe and
Hi Standards,
Below are a few notes of an unofficial meeting held during the 34C3 at
Leipzig.
There was 18 attendees, among which a few client/lib developers, XEP
authors, XSF members, and other generally interested people. Thanks to
all attending.
On 2017/12/15, Maxime Buquet wrote:
> Some display nothing (conversations, dino), I suppose it is
> handled like any presence, or bug? as this should be a kick if I'm
Small clarification here after talking to daniel, Conversations displays
kicks to the person who's been kicked but not to
Hi Standards!
I have been trying to find indications on how to handle the following
kind of presence in MUC (and any other valid error):
```
```
This discussion started with a potential issue in prosody[0]. This is
the answer that I get from it when the payload above happens:
```
Hi there,
A few remarks regarding 0392 after having it implemented in poezio,
thanks to Jonas.
Using JIDs as the source for the hash brings at least an issue to me in MUCs.
You'll see the same person in different colors depending on what room
you're looking at.
Another point I feel about but I
On 2017/10/18, Jonas Wielicki wrote:
> On Mittwoch, 18. Oktober 2017 10:57:19 CEST Sam Whited wrote:
> > On Sat, Oct 14, 2017, at 07:06, Jonas Wielicki wrote:
> > > (b) The ecosystem will fracture in islands of different, underspecified,
> > >
> > > plain-text markups put in .
> >
> > With
On 2017/10/18, Jonas Wielicki wrote:
> On Mittwoch, 18. Oktober 2017 20:09:28 CEST Florian Schmaus wrote:
> > On 18.10.2017 19:58, Jonas Wielicki wrote:
> > > On Mittwoch, 18. Oktober 2017 18:12:54 CEST Florian Schmaus wrote:
> > >> The situation BMH tries to improve is the following: I do have a
On 2017/10/16, Maxime Buquet wrote:
> I am going to repeat what I said on xsf@ a bit.
>
> On 2017/10/16, Florian Schmaus wrote:
> > So the case for BMH are things like
> > - Bots sending potential large status information, where there's a
> > desire to bring some stru
I am going to repeat what I said on xsf@ a bit.
On 2017/10/16, Florian Schmaus wrote:
> So the case for BMH are things like
> - Bots sending potential large status information, where there's a
> desire to bring some structure into that information by using a markup
> language
This can be
On 2017/10/14, Jonas Wielicki wrote:
> PART A
>
> Okay, there has been some discussion in xsf@ yesterday which changed my mind
> a
> little. The key point which convinced me was that Dave brought up the concept
> of protocol breaks, and implied that a protocol break [1] is the only way to
>
Hi Standards,
I came across 0337 and I like the idea. Reading the security
considerations, it is said in [7.3.2]:
"""
[..] even more care should be taken to log only information that can be
published openly. If there's risk for sensitive information to be
logged, the publish/subscribe pattern
On 2017/10/12, Jonas Wielicki wrote:
> TL;DR: I strongly prefer revising XHTML-IM to a more sane subset of XHTML
> plus
> providing a reference implementation of a sanitizer in JavaScript over
> anything else.
I strongly agree with this.
I don't think that getting rid of XHTML-IM and
On 2017/10/13, Kevin Smith wrote:
>
> So I’d like to strike “Stupid people will do stupid things” from the agenda
> of the discussion, and move it towards “What do we need so that diligent but
> fallible people are likely to get it right”.
The problem is that you can't just get rid of this
91 matches
Mail list logo
