Re: [Standards] XEP Dependencies

[Tedd Sterr]

> The others are Deferred, which means they've Expired - we do not, typically, 
> clean-up Deferred XEPs.


Understandable, though I had assumed that Deferred meant "not recently 
maintained" rather than expiration - which suggests 'do not implement.'


So then there is a question of whether there is an issue for current XEPs 
depending on deferred XEPs ...?



(For reference: XEP-0280 on 0296; XEP-0369 on 0292, 0372; and XEP-0373 on 0334)

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

[Standards] DEFERRED: XEP-0386 (Bind 2.0)

[XSF Editor]

XEP-0386 (Bind 2.0) has been Deferred because of inactivity.

Abstract:
This specification provides a single-request replacement for several
activities an XMPP client needs to do at startup.

URL: https://xmpp.org/extensions/xep-0386.html

If and when a new revision of this XEP is published, its status will
be changed back to Experimental.

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] UPDATED: XEP-0060 (Publish-Subscribe)

[XSF Editor]

Version 1.15.1 of XEP-0060 (Publish-Subscribe) has been released.

Abstract:
This specification defines an XMPP protocol extension for generic
publish-subscribe functionality. The protocol enables XMPP entities to
create nodes (topics) at a pubsub service and publish information at
those nodes; an event notification (with or without payload) is then
broadcasted to all entities that have subscribed to the node. Pubsub
therefore adheres to the classic Observer design pattern and can serve
as the foundation for a wide variety of applications, including news
feeds, content syndication, rich presence, geolocation, workflow
systems, network management systems, and any other application that
requires event notifications.

Changelog:
Add missing "retrieve-default-sub" feature to the XML Schema (sc)

URL: https://xmpp.org/extensions/xep-0060.html

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] UPDATED: XEP-0174 (Serverless Messaging)

[XSF Editor]

Version 2.0.1 of XEP-0174 (Serverless Messaging) has been released.

Abstract:
This specification defines how to communicate over local or wide-area
networks using the principles of zero-configuration networking for
endpoint discovery and the syntax of XML streams and XMPP messaging
for real-time communication. This method uses DNS-based Service
Discovery and Multicast DNS to discover entities that support the
protocol, including their IP addresses and preferred ports. Any two
entities can then negotiate a serverless connection using XML streams
in order to exchange XMPP message and IQ stanzas.

Changelog:
Fix incorrect STARTTLS examples. (cs)

URL: https://xmpp.org/extensions/xep-0174.html

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] DEFERRED: XEP-0383 (Burner JIDs)

[XSF Editor]

XEP-0383 (Burner JIDs) has been Deferred because of inactivity.

Abstract:
A mechanism by which users may request anonymous, ephemeral "burner"
JIDs.

URL: https://xmpp.org/extensions/xep-0383.html

If and when a new revision of this XEP is published, its status will
be changed back to Experimental.

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] LAST CALL: XEP-0280 (Message Carbons)

[XSF Editor]

This message constitutes notice of a Last Call for comments on
XEP-0280.

Title: Message Carbons
Abstract:
In order to keep all IM clients for a user engaged in a conversation,
outbound messages are carbon-copied to all interested resources.

URL: https://xmpp.org/extensions/xep-0280.html

This Last Call begins today and shall end at the close of business on
2018-02-22.

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?

2. Does the specification solve the problem stated in the introduction
and requirements?

3. Do you plan to implement this specification in your code? If not,
why not?

4. Do you have any security concerns related to this specification?

5. Is the specification accurate and clearly written?

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

Re: [Standards] XEP Dependencies

[Tedd Sterr]

According to both https://github.com/xsf/xeps and https://xmpp.org/extensions :

* XEP-0105 (Tree Transfer Stream Initiation Profile) [Deferred]
* XEP-0135 (File Sharing) [Deferred]
* XEP-0137 (Publishing Stream Initi-ation Requests) [Draft]
* XEP-0159 (Spim-Blocking Control) [Deferred]
* XEP-0241 (Encryption of Archived Messages) [Deferred]
* XEP-0103 (URL Address Information) [Deferred]
* XEP-0347 (Internet of Things - Discovery) [Deferred]
* XEP-0169 (Twas The Night Before Christmas) [Active]
* XEP-0264 (Jingle Content Thumbnails) [Deferred]


Or is there another secret stash I don't know about?




Thanks, this is a great help! We should probably be doing this periodically.

> * XEP-0159 (Spim-Blocking Control) depends on: XEP-0016

This appears to be the only one that's not also already deprecated, so I've 
added deprecating it to the council's agenda.

Thanks again!

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

Re: [Standards] Adding logo to MUC and PubSub node

[W. Martin Borgert]

Quoting Jonas Wielicki :

On Donnerstag, 8. Februar 2018 14:34:12 CET W. Martin Borgert wrote:

I had another idea before coming up with the configuration variable,
but I find it very ugly, but maybe others might find some beauty
(or pragmatism) in it:

A PubSub node could have a "magic" node


We need to get this terminology straight. When you say "PubSub node", do you
in fact mean a pubsub node (i.e. a specific @node value on a specific pubsub
service with JID X) or a PubSub service with JID X?


I hope to get the terminology right this time:
A PubSub node could have a "magic" item.
A PubSub service could have a "magic" node.
Does this make sense?

For e.g. Movim both a logo for service and for a node seems to be
useful.


I think specifying avatars for each PubSub *node* could be tricky. For
services (which I assume you meant) see below.


If there were a "magic" item on a node, it never must be removed
automatically, but only on user request, right?


The "magic id" (again, only for PubSub services, not for individual nodes) is
obvious, I’d simply use the same the XEP-0084 uses. That could even work
magically with client code.


Nice!

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

Re: [Standards] XEP Dependencies

[Dave Cridland]

On 8 February 2018 at 15:35, Sam Whited  wrote:
> On Thu, Feb 8, 2018, at 09:23, Tedd Sterr wrote:
>> After noticing that XEP-0137 depends on "Stream Initiation" which is now
>> deprecated, I checked through all XEPs for their dependencies and found
>> the following:
>
> Thanks, this is a great help! We should probably be doing this periodically.
>

Indeed, great work.

>
>> * XEP-0159 (Spim-Blocking Control) depends on: XEP-0016
>
> This appears to be the only one that's not also already deprecated, so I've 
> added deprecating it to the council's agenda.
>

I think you meant XEP-0137 (SI-PUB), which is Draft.

The others are Deferred, which means they've Expired - we do not,
typically, clean-up Deferred XEPs.

> Thanks again!
>
> —Sam
> ___
> 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 Dependencies

[Sam Whited]

On Thu, Feb 8, 2018, at 09:23, Tedd Sterr wrote:
> After noticing that XEP-0137 depends on "Stream Initiation" which is now 
> deprecated, I checked through all XEPs for their dependencies and found 
> the following:

Thanks, this is a great help! We should probably be doing this periodically.


> * XEP-0159 (Spim-Blocking Control) depends on: XEP-0016

This appears to be the only one that's not also already deprecated, so I've 
added deprecating it to the council's agenda.

Thanks again!

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

[Standards] XEP Dependencies

[Tedd Sterr]

After noticing that XEP-0137 depends on "Stream Initiation" which is now 
deprecated, I checked through all XEPs for their dependencies and found the 
following:


== Strong Dependencies (the XEP is pointless without them) ==

* XEP-0105 (Tree Transfer Stream Initiation Profile) depends on: XEP-0095, 
XEP-0096

* XEP-0135 (File Sharing) depends on: XEP-0096

* XEP-0137 (Publishing Stream Initiation Requests) depends on: XEP-0095

* XEP-0159 (Spim-Blocking Control) depends on: XEP-0016

* XEP-0241 (Encryption of Archived Messages) depends on: XEP-0136


== Weak Dependencies (the XEP could probably be reworked to not require them) ==

* XEP-0103 (URL Address Information) depends on: XEP-0095

* XEP-0347 (Internet of Things - Discovery) depends on: XEP-0323, XEP-0324, 
XEP-0325, XEP-0326

* XEP-0169 (Twas The Night Before Christmas) depends on: XEP-0090, XEP-0112


== Mistakes (dependency listed, but apparently not used) ==

* XEP-0264 (Jingle Content Thumbnails) depends on: XEP-0096





XEP-0016 (Privacy Lists)  [deprecated]

XEP-0090 (Legacy Entity Time)  [obsolete]

XEP-0095 (Stream Initiation)  [deprecated]

XEP-0096 (SI File Transfer)  [deprecated]

XEP-0112 (User Physical Location)  [obsolete]
XEP-0136 (Message Archiving)  [deprecated]

XEP-0323 (Internet of Things - Sensor Data)  [retracted]

XEP-0324 (Internet of Things - Provisioning)  [retracted]

XEP-0325 (Internet of Things - Control)  [retracted]

XEP-0326 (Internet of Things - Concentrators)  [retracted]

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

Re: [Standards] Adding logo to MUC and PubSub node

[Jonas Wielicki]

On Donnerstag, 8. Februar 2018 14:34:12 CET W. Martin Borgert wrote:
> Quoting Daniel Gultsch :
> > polling is a terrible idea traffic wise and very nontransparent for the
> > user.
> > 
> > I don't have an opinion on pubsub.
> 
> I had another idea before coming up with the configuration variable,
> but I find it very ugly, but maybe others might find some beauty
> (or pragmatism) in it:
> 
> A PubSub node could have a "magic" node

We need to get this terminology straight. When you say "PubSub node", do you 
in fact mean a pubsub node (i.e. a specific @node value on a specific pubsub 
service with JID X) or a PubSub service with JID X?

I think specifying avatars for each PubSub *node* could be tricky. For 
services (which I assume you meant) see below.

> , i.e. with the magic id
> "pubsub_logo". This node contains the logo, it can be upgraded and
> notification to users would be immediate. But a "magic id"? Like
> "favicon.ico"?

The "magic id" (again, only for PubSub services, not for individual nodes) is 
obvious, I’d simply use the same the XEP-0084 uses. That could even work 
magically with client code.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Adding logo to MUC and PubSub node

[W. Martin Borgert]

Quoting Daniel Gultsch :

polling is a terrible idea traffic wise and very nontransparent for the user.

I don't have an opinion on pubsub.


I had another idea before coming up with the configuration variable,
but I find it very ugly, but maybe others might find some beauty
(or pragmatism) in it:

A PubSub node could have a "magic" node, i.e. with the magic id
"pubsub_logo". This node contains the logo, it can be upgraded and
notification to users would be immediate. But a "magic id"? Like
"favicon.ico"?

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

Re: [Standards] Adding logo to MUC and PubSub node

[Evgeny Khramtsov]

Thu, 8 Feb 2018 14:21:49 +0100
Daniel Gultsch  wrote:

> 2018-02-08 13:43 GMT+01:00 Evgeny Khramtsov :
> > Thu, 8 Feb 2018 13:17:14 +0100
> > Daniel Gultsch  wrote:
> >  
> >> at least for MUC I would prefer vCard + hash in presence from the
> >> bare muc jid. (as discussed in our 34C3 meeting and/or various
> >> discussions we had prior to this)  
> >
> > What was the conclusion? (If any)  
> 
> 
> The question I had for the room was basically if any client would
> break on receiving presence from the bare jid and everyone (in the
> room) agreed that *their* client wouldn't break.
> 
> On whether or not this is a good idea; I can't remember anyone voice
> strong objections.

Good. Then I will implement this in ejabberd.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Adding logo to MUC and PubSub node

[Daniel Gultsch]

2018-02-08 13:43 GMT+01:00 Evgeny Khramtsov :
> Thu, 8 Feb 2018 13:17:14 +0100
> Daniel Gultsch  wrote:
>
>> at least for MUC I would prefer vCard + hash in presence from the bare
>> muc jid. (as discussed in our 34C3 meeting and/or various discussions
>> we had prior to this)
>
> What was the conclusion? (If any)


The question I had for the room was basically if any client would
break on receiving presence from the bare jid and everyone (in the
room) agreed that *their* client wouldn't break.

On whether or not this is a good idea; I can't remember anyone voice
strong objections.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Adding logo to MUC and PubSub node

[Evgeny Khramtsov]

Thu, 8 Feb 2018 13:17:14 +0100
Daniel Gultsch  wrote:

> I don't have an opinion on pubsub.

I guess that's not a problem for PubSub service to send
notifications? :) A dedicated and well-known node should be enough for
this.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Adding logo to MUC and PubSub node

[Evgeny Khramtsov]

Thu, 8 Feb 2018 13:17:14 +0100
Daniel Gultsch  wrote:

> at least for MUC I would prefer vCard + hash in presence from the bare
> muc jid. (as discussed in our 34C3 meeting and/or various discussions
> we had prior to this)

What was the conclusion? (If any)
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Adding logo to MUC and PubSub node

[Daniel Gultsch]

at least for MUC I would prefer vCard + hash in presence from the bare
muc jid. (as discussed in our 34C3 meeting and/or various discussions
we had prior to this)

polling is a terrible idea traffic wise and very nontransparent for the user.

I don't have an opinion on pubsub.

2018-02-07 22:16 GMT+01:00 W. Martin Borgert :
> Hi,
>
> this is an idea mainly for the "social network" aspect of XMPP:
> A logo for a MUC or for a PubSub node, similar to a user avatar.
>
> Such a logo, emblem, or symbol can be a good indicator for users
> to find the right MUC or PubSub node in a social network
> application or graphical XMPP client.
>
> How about introducing two configuration variables, one in
> https://xmpp.org/extensions/xep-0045.html#registrar-formtype-owneronfig:
>
> var='muc#muc_logo'
>
> And the second one in
> https://xmpp.org/extensions/xep-0060.html#owner-configure:
>
> var='pubsub#node_logo'
>
> The value should be a  element from
> https://xmpp.org/extensions/xep-0221.html.
>
> IMHO, the value should be restricted to
>  1. images, or would a sound make sense? Maybe...
>  2. inline data, so that a link to a web resource cannot be
> abused for snitching IP addresses
>
> What do you think?
>
> TIA & Cheers
> ___
> 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] Adding logo to MUC and PubSub node

[Jonas Wielicki]

On Donnerstag, 8. Februar 2018 13:01:17 CET W. Martin Borgert wrote:
> Quoting Timothée Jaussoin :
> > In the end I don't think that it's a big issue to have those info
> > requested manually, having a cache of a few hours on the clients is
> > an OK solution for me at the moment.
> 
> Maybe a refresh or poll rate of e.g. 12..24 hours can "officially"
> be suggested? Not really nice, but better than not having logos or
> invent something complicated that will never be implemented...

I think an Informational XEP would be the appropriate mean for this. It is 
really just a combination of protocols which makes sense, plus the refresh 
rule.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Adding logo to MUC and PubSub node

[W. Martin Borgert]

Quoting Timothée Jaussoin :
In the end I don't think that it's a big issue to have those info  
requested manually, having a cache of a few hours on the clients is

an OK solution for me at the moment.


Maybe a refresh or poll rate of e.g. 12..24 hours can "officially"
be suggested? Not really nice, but better than not having logos or
invent something complicated that will never be implemented...

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

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Florian Schmaus]

On 08.02.2018 11:39, Guus der Kinderen wrote:
> Thank you for all feedback.
> 
> The general consensus appears to be in favor of this change, but that a
> stream error definition should be added.
> 
> None of the other RFC-6120-defined conditions appear to be fitting here,
> so I suggest that `undefined-condition` is used. 

After a quick look at RFC 6120 § 4.9.3 I also found only
undefined-condition suitable.

> Additionally, we should add an application-specific condition element. I
> suggest to add a single `mismatch` element, qualified by the namespace
> as defined for this feature in the XEP.

It may be a good idea to include the received 'h' value and the send
stanza count in that element. This probably helps debugging. And an
optional human readable text is also always a good idea.

Hence my suggestion would be something like:

 



  You acknowledged 10 stanzas, but I only send you 8 so far.
  Something is odd. Please go fix it.




> If we do more explicitly define the steam error, then it would be
> fitting to also further specify the stream termination that's now
> defined in the last lines of section 3:
> 
> Note that a client SHALL only make at most one attempt to enable
> stream management. If a server receives a second  element
> it SHOULD respond with a stream error, thus terminating the client
> connection.
> 
> 
> What would be a fitting error condition here?

We have XEP-0198 § 6's example:


  


unexpected-request seems fitting, not sure if we want to define an
application specific condition element, e.g. duplicate-enable, in this case.

> Lastly, section 5 defines another stream termination here:
> 
> If the former stream is resumed and the server still has the stream
> for the previously-identified session open at this time, the old
> stream SHOULD be terminated.
> 
> 
> Is this intended to be a termination without stream error? That might
> cause confusion in the client being terminated.

There shouldn't be an old client session any more, since the old client
has resumed the session. It is nevertheless sensible that the server
terminates the former stream.

How this is done is currently underspecified. I would send a stream
error, ending stream tag and then disconnect the transport layer
connection. I believe that in this case 'conflict' (RFC 6120 § 4.9.3.3)
is an appropriate stream error condition.

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

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Guus der Kinderen]

Thank you for all feedback.

The general consensus appears to be in favor of this change, but that a
stream error definition should be added.

None of the other RFC-6120-defined conditions appear to be fitting here, so
I suggest that `undefined-condition` is used.

Additionally, we should add an application-specific condition element. I
suggest to add a single `mismatch` element, qualified by the namespace as
defined for this feature in the XEP.

If we do more explicitly define the steam error, then it would be fitting
to also further specify the stream termination that's now defined in the
last lines of section 3:

Note that a client SHALL only make at most one attempt to enable stream
> management. If a server receives a second  element it SHOULD
> respond with a stream error, thus terminating the client connection.


What would be a fitting error condition here?

Lastly, section 5 defines another stream termination here:

If the former stream is resumed and the server still has the stream for the
> previously-identified session open at this time, the old stream SHOULD be
> terminated.


Is this intended to be a termination without stream error? That might cause
confusion in the client being terminated.

Regards,

  Guus

On 7 February 2018 at 20:57, Ruslan N. Marchenko  wrote:

> Am Mittwoch, den 07.02.2018, 08:40 +0100 schrieb Guus der Kinderen:
>
>
> I propose that the XEP is updated with an instruction to, upon detection
> of an invalid acknowledgement, terminate the stream with stream error.
>
> Thoughts?
>
>
> I was always pretty sure this is actually de-facto behaviour. Ack
> non-existing stanza means SM is out of sync or there's stream injection -
> both non-recoverable and/or dangerous cases falling in SM misuse category.
> No harm making it explicit though.
>
> --RR
>
> ___
> 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-0060: max-nodes-exceeded error is not described.

[Christian Schudt]

Hi,

 

Openfire does implement it.

 

-- Christian

 

Gesendet: Donnerstag, 08. Februar 2018 um 03:26 Uhr
Von: "Peter Saint-Andre" 
An: standards@xmpp.org
Betreff: Re: [Standards] XEP-0060: max-nodes-exceeded error is not described.

On 2/7/18 2:04 AM, Christian Schudt wrote:
> Hi,
>  
> please consider this issue:
> https://github.com/xsf/xeps/issues/581
>  
> I kindly ask the authors of XEP-0060 to describe the
> "max-nodes-exceeded" error in the specification or to remove it from the
> XML schema, if it should not be used.
>  
> Although one can guess, when this error should be used, it's still not
> clear, if it's a defined error or not.

One can guess that this error could be returned if a node creation
request would cause some limit to be exceeded (e.g., a node creator is
not allowed to create more than X nodes on the service).

Do any existing implementations include such a limit? Should they? If
so, then defining this error case would be helpful.

Peter


___
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
___