date:20180316

> This is true, however mostly these are quite coarse-grained. Extensions with 
> lots of optional

> parts inside - I'm thinking about XEP-0060 for example - tend to end up with 
> various interop issues.

I don't disagree with that, and I'm not suggesting 0394 turns into a mass of 
optional parts.

My argument is that forbidding the use of text colouring because some don't 
want to use it is not a good solution, and an alternative solution is that 
clients are free to ignore such formatting as is their choice. Those who want 
to use it can do so, and those who don't never have to see any evil formatting.

Quoting XEP-0394, section 2 (bullet 5):
  "Entities SHOULD be able to cherry-pick a subset of the markup which is 
suitable for their presentation (for example, a terminal-based client may 
support inline emphasis and strike through, but no block-level markup)."

This is no different to what I am suggesting.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

On 16 Mar 2018 17:49, "Tedd Sterr"  wrote:

> If you ever intend to make XMPP adopted by masses, zillion of optional
> features is actually a bad solution.

XMPP is nothing but optional features!

Beyond XMPP-CORE and XMPP-IM, everything else is optional.

See https://xmpp.org/extensions/ for just how many optional features there
are.

This is true, however mostly these are quite coarse-grained. Extensions
with lots of optional parts inside - I'm thinking about XEP-0060 for
example - tend to end up with various interop issues.

For an example of this, read Daniel Gultsch's recent blog post around his
struggle with using OMEMO on naive PEP services.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

> If you ever intend to make XMPP adopted by masses, zillion of optional
> features is actually a bad solution.


XMPP is nothing but optional features!

Beyond XMPP-CORE and XMPP-IM, everything else is optional.


See https://xmpp.org/extensions/ for just how many optional features there are.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

> Some users want it, some don't. Including it as an optional feature is a
> good solution.

If you ever intend to make XMPP adopted by masses, zillion of optional
features is actually a bad solution.

-- 
Ненахов Андрей
Директор ООО "Редсолюшн" (Челябинск)
(351) 750-50-04
http://www.redsolution.ru
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

> XMPP can offer so many possibilities to it's users. Everyone can have
> a very special capability that only he and his chat partner will use.
> The downside is that total userbase would be 700 users.
> With so many unsolved problems concentrating on features that worsen
> UX and make client developer's life harder is counterproductive.


Some users want it, some don't. Including it as an optional feature is a good 
solution.

Those who want to use it can, and those don't want to use it can simply ignore 
it.

Not changing the text colour in response to a  span doesn't seem 
particularly complex to me.


If the feature is not defined then it may well lead to the 'very special 
capability' type implementations that we should try to discourage.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

I really don't see the problem - clients would surely implement such things?
They could, but they're not required to.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

> You're not forced to display colours in your client, but why force others not 
> to be able?

XMPP can offer so many possibilities to it's users. Everyone can have
a very special capability that only he and his chat partner will use.
The downside is that total userbase would be 700 users.
With so many unsolved problems concentrating on features that worsen
UX and make client developer's life harder is counterproductive.


-- 
Ненахов Андрей
Директор ООО "Редсолюшн" (Челябинск)
(351) 750-50-04
http://www.redsolution.ru
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

> Sender can't know what color scheme recipient has. It can be light or
> dark mode, where colors are inverted. There is no way to make text
> look consistently good if it's using various colors, and attempt to
> display user-colored text would lead to chat window looking like
> Geocities-era websites. No.


The sender doesn't need to know, but the receiving client obviously already 
does and can display as it deems appropriate.

Appropriate could mean reducing the colours to make them 'nicer' or simply 
ignore colouring altogether.


If a sender wants to send crazy multi-coloured messages, that is their choice - 
and the receiver is free not to display it as such.

You're not forced to display colours in your client, but why force others not 
to be able?

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

> It could be, but given that this was a feature before and no client ever 
> implemented this
> I don't see why it's something we should suddenly rely on now.

It doesn't have to be relied upon - I suggested a simple solution to the 
problem of lacking contrast between text and background colours.
Make text colouring optional, and each receiving client is free to ignore it 
entirely.
Forbidding a feature just because you don't want to use it doesn't seem 
sensible.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

> I agree with not supporting explicit font faces and sizes, also background
> colouring, but text colour can be used to convey useful information. Of
> course this could be abused, but so could many other features.

Sender can't know what color scheme recipient has. It can be light or
dark mode, where colors are inverted. There is no way to make text
look consistently good if it's using various colors, and attempt to
display user-colored text would lead to chat window looking like
Geocities-era websites. No.

-- 
Ненахов Андрей
Директор ООО "Редсолюшн" (Челябинск)
(351) 750-50-04
http://www.redsolution.ru
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

On 16 March 2018 at 15:58, Sam Whited  wrote:
> On Fri, Mar 16, 2018, at 09:20, Tedd Sterr wrote:
>> For displaying coloured text on a badly contrasting background, e.g.
>> white text on a white background, this can easily be handled
>> intelligently by the receiving client: the client knows its own
>> background colour, so if receiving white text it can either display this
>> as light grey text or simply ignore the colouring entirely.
>
> It could be, but given that this was a feature before and no client ever
implemented this I don't see why it's something we should suddenly rely on
now.

I really don't see the problem - clients would surely implement such things?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

2018-03-16 Thread Sam Whited

On Fri, Mar 16, 2018, at 09:20, Tedd Sterr wrote:
> For displaying coloured text on a badly contrasting background, e.g. 
> white text on a white background, this can easily be handled 
> intelligently by the receiving client: the client knows its own 
> background colour, so if receiving white text it can either display this 
> as light grey text or simply ignore the colouring entirely.

It could be, but given that this was a feature before and no client ever 
implemented this I don't see why it's something we should suddenly rely on now.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

From: Standards  on behalf of Sam Whited 

Sent: 15 March 2018 14:38
Subject: Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

>>  4. Using different fonts, font sizes and colors, for the same as in 3
>> or as parts of congratulation cards: ~3%.

> This is an anti-pattern. It's bad for users and bad for accessibility. There 
> is a reason most
> modern messaging systems leave it out. If I have a black background and you 
> send me
> messages with your text color set to black, I can no longer read it. If you 
> set your font to be
> tiny and I'm hard of seeing, I can no longer read it. If you set it to be 
> huge and I'm on my
> phone, it takes up half the screen and I'm annoyed. etc.

I agree with not supporting explicit font faces and sizes, also background 
colouring, but text colour can be used to convey useful information. Of course 
this could be abused, but so could many other features.

A receiving client should give its user the option to not display such coloring 
- this is necessary for vision limitations, colour-blindness, and plain 
annoyance - but that's not a reason to throw away the feature entirely; I think 
it is a desirable feature for many users.

For displaying coloured text on a badly contrasting background, e.g. white text 
on a white background, this can easily be handled intelligently by the 
receiving client: the client knows its own background colour, so if receiving 
white text it can either display this as light grey text or simply ignore the 
colouring entirely.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0394: too weak to replace XEP-0071

I like the idea and design of 0394, and look forward to seeing these 
extensions; the unholy hybrid attempting to shoehorn in 0393, not so much.

Attempting to extend the inline text styling to support all of the additional 
formatting features is going to result in plain text messages that resemble 
Perl programs, which is really not good for readability. And essentially 
forcing clients to support 0393, while also including additional styling that 
0393 does not support will do nothing to aid compatibility.

There is no need to combine the two - keep it simple and straightforward.


Regarding graceful degradation: there should be a service discovery string to 
indicate support for 0394; thus a sending client knows in advance whether to 
send 0394 formatting to another client.

The sending client can still degrade gracefully - there are four possibilities:

1. The receiving client supports 0394, the sender formats their text and sends 
it, the receiver receives the text and displays it in all its formatted glory, 
all is good in the world;

2. The receiving client does not support 0394 (or support has been disabled), 
so the sender does not send 0394 formatted text, but still allows the user to 
format messages (with appropriately limited features) and falls back to sending 
inline text styling à la 0393, the receiver receives the text and displays it 
in its somewhat formatted glory;

3. The receiving client doesn't support 0394, so the sender sends 0393 text 
instead, but the receiver doesn't support 0393 and simply displays the text 
as-is complete with readable line-noise;

4. The receiving client doesn't support 0394, but the sender does not support 
0393 and thus disables formatting options for the user, and all messages are 
sent as plain unformatted text.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Private Data storage discrepancy

2018-03-16 Thread Christian Schudt

Hi,

although I can't give you a good answer here, this is probably related to the issue I mentioned during the Call for Experience.

It's unclear if a single pubsub item should contain only one bookmark or multiple. The one bookmark per item appraoch seems to be favoured by XEP-223:

"the history of all items published to the node provides a complete list of the user's bookmarks"

It would explain the lack of the storage element.

On the other side 0048 with 0049 uses the storage element with multiple bookmarks.

I think they want us to use one pubsub item per bookmark and then aggregate a list of bookmarks when using the pubsub approach.

And when using the 0049 approach we should use the "storage" wrapper element.

Technically it's also possible to store all bookmarks in a single pubsub item, but I don't think that was the authors' intention.

Nonetheless it's very confusing, how to properly store and aggregate a list of bookmarks.

-- Christian

Gesendet: Freitag, 16. März 2018 um 12:03 Uhr
Von: "Guus der Kinderen"
An: "XMPP Standards"
Betreff: [Standards] Private Data storage discrepancy

Hello,

I'm working on migrating Bookmarks (https://xmpp.org/extensions/xep-0048.html) from Private XML Storage (https://xmpp.org/extensions/xep-0049.html) to PEP (https://xmpp.org/extensions/xep-0223.html). I'm was surprised to find a difference between the Pubsub node defined in 0048 example 3 (the published item root element is 'storage', that itself contains 'conference') and 0233's example 3 (the published item root element is 'conference' directly, without the wrapping 'storage'). I expected those two examples to have the same structure. What's going on there?

Regards,

Guus

___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0394: too weak to replace XEP-0071

2018-03-16 Thread Goffi

Hi I'm the main dev of Salut à Toi

Le vendredi 16 mars 2018, 10:08:12 CET Dave Cridland a écrit :

> Neither Movim nor Salut à Toi etc need to stop using XHTML embedded
> into XMPP (usually, in their case, via Atom).

That's right, we both (Movim and SàT) use full XHTML (even if XEP-0277 
recommand XHTML-IM, this mention should be removed from the XEP now), and 
we do sanitization before displaying it. We probably need a XHTML 
sanitization good practice XEP and I may work on it with anyone interested 
but not before a while, I'm too busy for now.

I was personnaly against deprecating XHTML-IM in the previous thread (and I 
see some arguments coming back here), but I now think it's OK to do it as 
XEP-0394 is a clean and extensible alternative.

I'm still against XEP-0393 because of its mixing of text and markup, and I 
think we can achieve similar result by using XEP-0394 on the wire, and 
whatever markdown developers want to use on clients.

Time will probably set this up.

Anyway, and above the disagrements, thanks to everybody working on that 
(even for XEP-0393 that I dislike :) ) and trying to find the best solution 
to satisfy everybody or at least most of people (developers and users).

Cheers
Goffi


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Private Data storage discrepancy

2018-03-16 Thread Timothée Jaussoin

Hi Guus,

Thanks for the work on Bookmarks :) Indeed that was, I think, a mistake.
On my side I followed the structure of the 0048 
(https://github.com/movim/moxl/blob/master/src/Moxl/Stanza/Bookmark.php#L30) 
which, I
think is more logical (the storage:bookmarks namespace is defined with this 
 wrapper).

Regards,

Tim

Le vendredi 16 mars 2018 à 12:03 +0100, Guus der Kinderen a écrit :
> Hello,
> 
> I'm working on migrating Bookmarks 
> (https://xmpp.org/extensions/xep-0048.html) from Private XML Storage 
> (https://xmpp.org/extensions/
> xep-0049.html) to PEP (https://xmpp.org/extensions/xep-0223.html). I'm was 
> surprised to find a difference between the Pubsub node
> defined in 0048 example 3 (the published item root element is 'storage', that 
> itself contains 'conference') and 0233's example 3 (the
> published item root element is 'conference' directly, without the wrapping 
> 'storage'). I expected those two examples to have the same
> structure. What's going on there?
> 
> Regards,
> 
>   Guus
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0394: too weak to replace XEP-0071

2018-03-16 Thread Kozlov Konstantin

Hello! 16.03.2018, 12:18, "Jonas Wielicki" :So, believe me that I can understand your frustration. In the discussion lastoctober (you’ll find it in the archives there, or see [0]), I was on the "noway we’re going to deprecate XHTML-IM in favour of a hack like '393" side,too. I have been convinced by the reasons I’m going to repeat, once more,below. Please, please refrain from throwing accusations around that people aredoing things lightheartedly, especially since this whole discussion was dozensof mails and weeks long [1]. Also, you’re discrediting hard work andinvestment of time from volunteers here, which I find not so cool. Thank youfor your consideration.I am sorry for that. My comment was too emotional, excuse me.XHTML-IM is notoriously hard to get right. It includes two massively complexlanguages in the processing flow: CSS (even though only property values) andXHTML.XHTML itself can possibly (I gave up on trying that) be sanitized with someXSL rules, aside from issues like phishing based on using different @hrefvalues than the text suggests.CSS requires to write a proper LR1 (I think, regular expressions at leastwon’t suffice) parser for the software to understand the properties andsanitze them accordingly. Different XHTML rendering engines might havedifferent security properties regarding CSS in @style. Apparently, for examplein Internet Explorer, it was possible to execute _javascript_ solely with thebackground property. See [2] and [3] for examples.So unless we want to force clients to implement iframe-like isolation for eachindividual message or very complex sanitization rules, we have to step awayfrom what XHTML-IM was. Iframe-like isolation has its own usability issues.Sanitization is complex, and will be messed up by clients. Incidentally, forthe same reason why we’re avoiding markdown and such in : Becauseputting structured content (like CSS properties) in an unstructured text fieldleads to complexity leads to security issues.Yes. CSS is really a hard part. But we don't need full support of CSS for IM message styling. Maybe it's better to simplify XEP by specifying a small subset of CSS rules needs to be implemented, as it was done with XHTML tag subset?Also, note that it has been repeatedly said that the deprecation of XHTML-IMdoes NOT mean that the use of XHTML is banned in XMPP. Somebody needs to workout the security considerations and make a new proposal for the embedding ofXHTML if they really want that.Yes, I understand that. And that's nice thing about it.I for one will play with '394 and see if wecan make this a decent replacement for 99.99% of the use-cases (where I see'393 only as a replacement for 99% of the use-cases).Yes. As I said before (many times) I like the idea of XEP-0394, finding it interesting.But I like only the part of separating styling and plain text. It is easy to implement for both rendering and stanza building, it do not allow developer to use existing libraries for automated process of styles. I makes needless to send text twice as it was in XHTML-IM and it allows to have plain text of the message without special processing as it will be with LML.But I don't like the idea of sacrificing ability to compose rich text in WYSIWYG editor in favour to "accessibility".Yes, anyone is annoyed when interlocutor sends messages abusing rich text formatting. But you can abuse any good feature.WYSIWYG is always preferred by end user. Especially when it comes to messaging. Especially on mobile devices, where you need to switch between different keyboards every time you want to type special characters like ',~,`{},_,* and so on.Yes, I'll be annoyed receiving a lot of messages with strange fonts, different font sizes and colors. But for many years of exploiting XHTML-IM enabled client I never was in such situation, 'cause most of the people in this world are adequate.And receiving on my birthday a solf-made postcard with centered text, containing "HAPPY BIRTHDAY!" written with bright orange bold 24.ComicSans at the top, animated gif with Vinnie the Pooh and "Wish you all the best!" written with dark blue italic 16.ArialBlack below, I won't be annoyed. 'Cause I see that my friend has spent his time to make up a fancy bright and funny postcard to cheer me up.And I want to have an ability to send and receive such messages two or three times per year even after I drop support of XHTML-IM in my client in favour to some modern XEP. And also to be able to send "AAARRRGH!" written with big red letters in some SPECIAL situations! ;-) With my best regards,Konstantin ___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Private Data storage discrepancy

2018-03-16 Thread Guus der Kinderen

Hello,

I'm working on migrating Bookmarks (
https://xmpp.org/extensions/xep-0048.html) from Private XML Storage (
https://xmpp.org/extensions/xep-0049.html) to PEP (
https://xmpp.org/extensions/xep-0223.html). I'm was surprised to find a
difference between the Pubsub node defined in 0048 example 3 (the published
item root element is 'storage', that itself contains 'conference') and
0233's example 3 (the published item root element is 'conference' directly,
without the wrapping 'storage'). I expected those two examples to have the
same structure. What's going on there?

Regards,

  Guus
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0394: too weak to replace XEP-0071

On 16 March 2018 at 08:56, Kozlov Konstantin  wrote:
> Hello!
>
> 16.03.2018, 11:31, "Ненахов Андрей" :
>
>
> btw, I'm new here, what were the reasons for deprecating XEP-0071 ?
>
> It's a new tradition here: deprecate XEP not because it is bad, but because
> there is a lot of bad implementations around.
> And a lot of bad implementations of XHTML-IM just because using XHTML allows
> lazy developers to use existing HTML parsewrs and engines instead of coding
> their own XHTML parser.
> That sounds at least strangs, but that's the way it goes nowadays in XMPP
> council.

You're welcome to join the XSF, stand for (or vote for) Council, and
otherwise try to reverse that decision. Complaining about it on list
won't achieve that.

But in the meantime, my reasons for deprecating were:

* A long and unabated history of security bugs introduced by trying
(and failing) to handle XHTML-IM correctly.
* A mismatch between what people wanted from IM styling (mostly
emphasis, preformatted text) and what XHTML-IM provided (font colours,
sizes, etc).
* After discussing the security issues with a number of serious web
developers, the advice I got each time was "Don't do that".

Maybe the security issues only affected lazy developers, but (a) There
are a lot of lazy developers, then, and (b) Developers have every
right to be lazy - protocols should be as easy as possible to
implement in a secure manner. Styled IM messages really shouldn't need
to be a security trap for the unwary.

Now, you're welcome to think that was a bad decision, for bad reasons,
and I fully appreciate it's a decision that was quite contentious -
deprecation was rejected by a previous Council after all. But the fact
is that the decision is made, and unless anyone can present something
new that warrants revisiting - and I think that's very unlikely - we
should move forward, and not revisit the past.

The choice now is between XEP-0393 or XEP-0394; I'd suggest that
repeating technical arguments aren't going to make anyone lean one way
or the other, but widespread implementation might.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0394: too weak to replace XEP-0071

On 16 March 2018 at 07:37, Jonas Wielicki  wrote:
> On Donnerstag, 15. März 2018 19:19:30 CET W. Martin Borgert wrote:
>> Quoting Jonas Wielicki :
>> > If you are doing graphics/text design/publishing with your IM client,
>> > you’re doing it wrong, in my opinion.
>>
>> But XMPP is not only IM. What about blogging or social networks like
>> Movim or Salut à Toi or before Jappix, which present a rich web
>> interface? No need for specific fonts or colours, I agree, but people
>> want probably a little bit more output control then in the IM world.
>
> That’s true, I’ll point edhelas and maybe some others at this thread for
> feedback. Thanks for reminding me.

At this point I shall sound like a broken record, but:

Neither Movim nor Salut à Toi etc need to stop using XHTML embedded
into XMPP (usually, in their case, via Atom).

XEP-0071 describes a specific use-case of styling IM messages by
embedding a small subset of XHTML. That is now deprecated.

Dave,
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0394: too weak to replace XEP-0071

2018-03-16 Thread Kozlov Konstantin

Hello! 16.03.2018, 11:31, "Ненахов Андрей" :btw, I'm new here, what were the reasons for deprecating XEP-0071 ?It's a new tradition here: deprecate XEP not because it is bad, but because there is a lot of bad implementations around.And a lot of bad implementations of XHTML-IM just because using XHTML allows lazy developers to use existing HTML parsewrs and engines instead of coding their own XHTML parser.That sounds at least strangs, but that's the way it goes nowadays in XMPP council. With my best regards,Konstantin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0394: too weak to replace XEP-0071