[Standards] Re: Remove requirement to send disco#info feature in XEP-0030

[Kevin Smith]

I agree that a note would be helpful, but we're only noting that bugged 
implementations exist, I don't think that even adding a SHOULD here 
falls within the spirit of the Final requirements. So I think the right 
thing to do is to add a note saying such bugs exist, but not change 
normative language.


/K


-- Original Message --
From "Dave Cridland" 
To "XMPP Standards" 
Date 12/03/2024 09:59:33
Subject [Standards] Re: Remove requirement to send disco#info feature in 
XEP-0030


As others have said, it's a wart. Any protocol has lots of them; XMPP 
has always had its fair share. (You mention XEP-0045 briefly, and we're 
all familiar that it's essentially a collection of warts at this 
stage). This one is not, as far as I can see, harmful in any meaningful 
way.


As Tedd Sterr notes, removing the reporting of disco#info support via 
disco#info might leave no features at all, which might - small chance - 
mean that implementations hit bugs.


I see no benefit to interoperability to remove it at this time.

However, I could see the benefit of adding a note to the effect of:

"Some entities are known not to advertise the 
"http://jabber.org/protocol/disco#info; feature within their responses, 
contrary to this specification. Entities receiving otherwise valid 
responses which do not include this feature SHOULD infer the support."


Dave.

On Sun, 10 Mar 2024 at 16:27, Jonas Schäfer  
wrote:

Dear community,

it's been a while I spoke up here.

I would like to discuss the removal of the following part-sentence 
from

XEP-0030 (in Final status!):

> every entity MUST support at least the
> 'http://jabber.org/protocol/disco#info' feature

Announcing that feature is redundant: An entity which replies with a 
properly
constructed `http://jabber.org/protocol/disco#info"/>` 
element
is bound to (and has always been bound to) have implemented XEP-0030 
to the

best of its knowledge.

As this is a Final(!) status XEP, here is my estimate of the impact 
this

change has:

- Implementations which required the presence of this feature on the
  receiving side would now become non-compliant: They might assume
  that the remote entity did not really support XEP-0030 and fail with
  an error.

  Such implementations would need to be adapted in order to be able to
  interoperate with implementations which follow a revised version of
  XEP-0030.

I don't see any other impact. I also strongly suspect that the set of
implementations which follow XEP-0030 to the letter is rather slim (I 
only
know of a single one, which would be the Rust XMPP library xmpp-rs 
[1]).


The reason why this came up: There have in the past been cases ([2] 
and
another, not-yet-filed issue against Prosody IM where the disco#info 
feature
is missing from MUCs) where implementations didn't emit this feature. 
The
seeming pointlessness and lack of information conveyed by this feature 
var
make it easy to overlook and low-priority to fix. The fact that this 
has gone
undiscovered for at least one Prosody IM release cycle further 
supports the
assumption that the number of implementations which rely on that part 
of the

spec is rather small.

Your input is welcome.

kind regards,
Jonas Schäfer
(these days without "special" role in the standards process)

   [1]: And there exists at least one fork which removed that check:
https://gitlab.com/nesium/xmpp-rs/-/commit/1ddb050
   [2]: 
https://issues.prosody.im/1664___

Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Remove requirement to send disco#info feature in XEP-0030

[Kevin Smith]

-- Original Message --
From "Jonas Schäfer" 
To standards@xmpp.org
Date 10/03/2024 16:27:07
Subject [Standards] Remove requirement to send disco#info feature in 
XEP-0030



Dear community,

it's been a while I spoke up here.

I would like to discuss the removal of the following part-sentence from
XEP-0030 (in Final status!):


 every entity MUST support at least the
 'http://jabber.org/protocol/disco#info' feature


Announcing that feature is redundant: An entity which replies with a properly
constructed `http://jabber.org/protocol/disco#info"/>` element
is bound to (and has always been bound to) have implemented XEP-0030 to the
best of its knowledge.

As this is a Final(!) status XEP, here is my estimate of the impact this
change has:

- Implementations which required the presence of this feature on the
  receiving side would now become non-compliant: They might assume
  that the remote entity did not really support XEP-0030 and fail with
  an error.

  Such implementations would need to be adapted in order to be able to
  interoperate with implementations which follow a revised version of
  XEP-0030.

I don't see any other impact. I also strongly suspect that the set of
implementations which follow XEP-0030 to the letter is rather slim (I only
know of a single one, which would be the Rust XMPP library xmpp-rs [1]).

The reason why this came up: There have in the past been cases ([2] and
another, not-yet-filed issue against Prosody IM where the disco#info feature
is missing from MUCs) where implementations didn't emit this feature. The
seeming pointlessness and lack of information conveyed by this feature var
make it easy to overlook and low-priority to fix. The fact that this has gone
undiscovered for at least one Prosody IM release cycle further supports the
assumption that the number of implementations which rely on that part of the
spec is rather small.

It seems to me that, although this has always seemed like a strange 
wart, the fact that it might cause implementations to need to be updated 
(whether such implementations are known of by The Internet or not), 
making the change is inconsistent with the requirements of Final 
(XEP-0001) so shouldn't be made.


/K

___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

[Kevin Smith]

-- Original Message --
From "Daniel Gultsch" 
To standards@xmpp.org
Date 11/03/2024 09:14:36
Subject [Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))


On Sun, Mar 10, 2024 at 4:18 PM 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: https://xmpp.org/extensions/xep-0360.html

 This Last Call begins today and shall end at the close of business on
 2024-03-25.

 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?


I’m honestly not convinced that the problem the XEP introduces "This
leads to the unfortunate situation where some submitted XEPs erroneous
refer to non-Stanza top level stream elements as 'Stanzas'." exists.
Or if introducing a new term fixes the issue. We have terminology
("element", "stream element") for that. I briefly checked with some
XEPs (Bind 2, SM, CSI) and they all seem to be fine without this new
term.


Also - and this is probably something that might have changed since
this XEP was first introduced - we don’t have that many XEPs that use
custom stream elements after bind (after routing is enabled). CSI and
SM seem to be the only major one. We didn’t see an influx in them.

And XEPs like Bind2 an SASL2 are fairly normal in their usage of
stream elements I would say.



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


I guess. But my argument is mostly that the problem isn’t an actual problem.


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


No. If I were to write a new XEP I would rather not use the word nonza.


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


No


 5. Is the specification accurate and clearly written?


Yes.

I'm largely with Daniel on this.

/K
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Proposed XMPP Extension: PubSub Server Information

[kevin . smith]

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: PubSub Server Information
Abstract:
This document defines a data format whereby basic information of an
XMPP domain can be expressed and exposed over pub-sub.

URL: https://xmpp.org/extensions/inbox/pubsub-server-info.html

The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] UPDATED: XEP-0483 (HTTP Online Meetings)

[kevin . smith]

Version 0.2.0 of XEP-0483 (HTTP Online Meetings) has been released.

Abstract:
This specification defines a protocol extension to request URLs from
an external HTTP entity usable to initiate and invite participants to
an online meeting.

Changelog:
* Use XEP-0482 to send the meeting link to another party (do)

URL: https://xmpp.org/extensions/xep-0483.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 -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] ACTIVE: XEP-0458 (Community Code of Conduct)

[kevin . smith]

Version 1.0.0 of XEP-0458 (Community Code of Conduct) has been
released.

Abstract:
This document describes the XMPP Standard Foundation's Code of
Conduct.

Changelog:
Changed status to Active per Board vote on 2024-01-05. (psa)

URL: https://xmpp.org/extensions/xep-0458.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 -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All

[kevin . smith]

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Host Meta 2 - One Method To Rule Them All
Abstract:
This document defines an XMPP Extension Protocol for extending
XEP-0156 by modifying the JSON Web Host Metadata Link format to
support discovering all possible XMPP connection methods, for c2s and
s2s

URL: https://xmpp.org/extensions/inbox/host-meta-2.html

The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] NEW: XEP-0484 (Fast Authentication Streamlining Tokens)

[kevin . smith]

Version 0.1.0 of XEP-0484 (Fast Authentication Streamlining Tokens)
has been released.

Abstract:
This specification defines a token-based method to streamline
authentication in XMPP, allowing fully authenticated stream
establishment within a single round-trip.

Changelog:
* Promoted to Experimental. (XEP Editor: kis)

URL: https://xmpp.org/extensions/xep-0484.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 -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] NEW: XEP-0483 (HTTP Online Meetings)

[kevin . smith]

Version 0.1.0 of XEP-0483 (HTTP Online Meetings) has been released.

Abstract:
This specification defines a protocol extension to request URLs from
an external HTTP entity usable to initiate and invite participants to
an online meeting.

Changelog:
* Promoted to Experimental. (XEP Editor: kis)

URL: https://xmpp.org/extensions/xep-0483.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 -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] UPDATED: XEP-0474 (SASL SCRAM Downgrade Protection)

[kevin . smith]

Version 0.3.0 of XEP-0474 (SASL SCRAM Downgrade Protection) has been
released.

Abstract:
This specification provides a way to secure the SASL and SASL2
handshakes against method and channel-binding downgrades.

Changelog:
* Rework all explanations explaining why this specification is needed
* Simplify protocol (tm)

URL: https://xmpp.org/extensions/xep-0474.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 -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] UPDATED: XEP-0458 (Community Code of Conduct)

[kevin . smith]

Version 0.4.0 of XEP-0458 (Community Code of Conduct) has been
released.

Abstract:
This document describes the XMPP Standard Foundation's Code of
Conduct.

Changelog:
Address Last Call feedback; complete a copy edit and apply
clarifications in several places. (psa)

URL: https://xmpp.org/extensions/xep-0458.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 -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] UPDATED: XEP-0402 (PEP Native Bookmarks)

[kevin . smith]

Version 1.1.4 of XEP-0402 (PEP Native Bookmarks) has been released.

Abstract:
This specification defines a syntax and storage profile for keeping a
list of chatroom bookmarks on the server.

Changelog:
Recommend setting pubsub#max_items to 'max' instead of some arbitrary
large number (egp)

URL: https://xmpp.org/extensions/xep-0402.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 -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] UPDATED: XEP-0198 (Stream Management)

[kevin . smith]

Version 1.6.1 of XEP-0198 (Stream Management) has been released.

Abstract:
This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including
features for stanza acknowledgements and stream resumption.

Changelog:
Clarify SASL2 and BIND2 interaction. (tm)

URL: https://xmpp.org/extensions/xep-0198.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 -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Proposed XMPP Extension: HTTP Online Meetings

[kevin . smith]

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: HTTP Online Meetings
Abstract:
This specification defines a protocol extension to request URLs from
an external HTTP entity usable to initiate and invite participants to
an online meeting.

URL: https://xmpp.org/extensions/inbox/xep-http_online_meetings.html

The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
___
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] Proposed XMPP Extension: Communicate & Ask to AI

[kevin . smith]

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Communicate & Ask to AI
Abstract:
This document defines a protocol for asking questions to an artificial
intelligence or requesting it to make predictions.

URL: https://xmpp.org/extensions/inbox/xep-ai.html

The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
___
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] UPDATED: XEP-0458 (Community Code of Conduct)

[kevin . smith]

Version 0.3 of XEP-0458 (Community Code of Conduct) has been released.

Abstract:
This document describes the XMPP Standard Foundation's Code of Conduct

Changelog:
Address substantive feedback from JC Brand; add Peter Saint-Andre as
co-author to help address future feedback. (psa)

URL: https://xmpp.org/extensions/xep-0458.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] UPDATED: XEP-0424 (Message Retraction)

[kevin . smith]

Version 0.4.0 of XEP-0424 (Message Retraction) has been released.

Abstract:
This specification defines a method for indicating that a message
should be retracted.

Changelog:
* Remove the dependency on XEP-0422 Message Fastening.
* Use 'id' attribute on 'retracted' element instead of a child
element.
* Clarify business rlies regarding which 'id' to use to refer to the
retracted message. (jcb)

URL: https://xmpp.org/extensions/xep-0424.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] UPDATED: XEP-0377 (Spam Reporting)

[kevin . smith]

Version 0.3.1 of XEP-0377 (Spam Reporting) has been released.

Abstract:
This document specifies a mechanism by which users can report spam and
other abuse to a server operator or other spam service.

Changelog:
Add XML Schema. (egp)

URL: https://xmpp.org/extensions/xep-0377.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] OBSOLETED: XEP-0459 (XMPP Compliance Suites 2022)

[kevin . smith]

Version 1.1.0 of XEP-0459 (XMPP Compliance Suites 2022) has been
released.

Abstract:
This document defines XMPP application categories for different use
cases (Core, Web, IM, and Mobile), and specifies the required XEPs
that client and server software needs to implement for compliance with
the use cases.

Changelog:
Replace deprecated XEP-0411 with XEP-0402 in Advanced Group Chat.
(egp)

URL: https://xmpp.org/extensions/xep-0459.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] UPDATED: XEP-0333 (Chat Markers)

[kevin . smith]

Version 0.4.1 of XEP-0333 (Chat Markers) has been released.

Abstract:
This specification describes a solution of marking the last received,
displayed and acknowledged message in a chat.

Changelog:
Changed discovery example to use client JIDs. (gdk)

URL: https://xmpp.org/extensions/xep-0333.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] Proposed XMPP Extension: MUC Token Invite

[kevin . smith]

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: MUC Token Invite
Abstract:
This specification provides a way to generate tokens to invite users
to a MUC room.

URL: https://xmpp.org/extensions/inbox/muc-token-invite.html

The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
___
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] UPDATED: XEP-0458 (Community Code of Conduct)

[kevin . smith]

Version 0.2.1 of XEP-0458 (Community Code of Conduct) has been
released.

Abstract:
This document describes the XMPP Standard Foundation's Code of Conduct

Changelog:
Add anchors to every section, for easier linking.  Also fix a typo.
(egp)

URL: https://xmpp.org/extensions/xep-0458.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] Re: UPDATED: XEP-0453 (DOAP usage in XMPP)

[Kevin Smith]

-- Original Message --

From "Melvin Keskin" 

To "XMPP Standards" 
Date 04/07/2023 17:51:04
Subject [Standards] Re: UPDATED: XEP-0453 (DOAP usage in XMPP)


Hi,

Thanks for the update! Only the year is wrong. We are not yet in 2024


Thanks.
You wouldn't believe that I checked that before pushing. Next time 
something gets published, that'll be fixed.


/K
___
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] Proposed XMPP Extension: Reporting Account Affiliations

[kevin . smith]

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Reporting Account Affiliations
Abstract:
This specification documents a way for an XMPP server to report to
other entities the relationship it has with a user on its domain.

URL: https://xmpp.org/extensions/inbox/xep-reporting-account-
affiliations.html

The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
___
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] UPDATED: XEP-0453 (DOAP usage in XMPP)

[kevin . smith]

Version 0.1.2 of XEP-0453 (DOAP usage in XMPP) has been released.

Abstract:
This specification defines how XMPP projects can provide a machine-
readable description of their abilities, and how external entities can
interact with it.

Changelog:
Fix XMLNS typo (spw)

URL: https://xmpp.org/extensions/xep-0453.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] UPDATED: XEP-0317 (Hats)

[kevin . smith]

Version 0.2.0 of XEP-0317 (Hats) has been released.

Abstract:
This specification defines a more extensible model for roles and
affiliations in Multi-User Chat rooms.

Changelog:
Select a syntax for hats. (mw)

URL: https://xmpp.org/extensions/xep-0317.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] Re: Controlling XEP-0060 publish-options behaviour

[Kevin Smith]

-- Original Message --

From "Matthew Wild" 

To "XMPP Standards" 
Date 28/06/2023 12:26:02
Subject [Standards] Controlling XEP-0060 publish-options behaviour


Or, we can add a new element:

  
 
 [form here]
  


WFM.

/K
___
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] Re: Wrapping up the XMPP Lemmy Experiment

[Kevin Smith]

-- Original Message --

From "Matthew Wild" 

To "XMPP Standards" 
Date 06/06/2023 13:40:29
Subject [Standards] Re: Wrapping up the XMPP Lemmy Experiment


Thanks Sam, for taking the lead on this initiative.


Yes, thanks for trying a thing.

/K
___
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] NEW: XEP-0479 (XMPP Compliance Suites 2023)

[kevin . smith]

Version 0.1.0 of XEP-0479 (XMPP Compliance Suites 2023) has been
released.

Abstract:
This document defines XMPP application categories for different use
cases (Core, Web, IM, and Mobile), and specifies the required XEPs
that client and server software needs to implement for compliance with
the use cases.

Changelog:
Promote to Experimental. (XEP Editor: ks)

URL: https://xmpp.org/extensions/xep-0479.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] NEW: XEP-0478 (Stream Limits Advertisement)

[kevin . smith]

Version 0.1.0 of XEP-0478 (Stream Limits Advertisement) has been
released.

Abstract:
This specification defines a way for an XMPP entity to announce the
limits it will enforce for data received on a stream.

Changelog:
Promote to Experimental. (XEP Editor: ks)

URL: https://xmpp.org/extensions/xep-0478.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] NEW: XEP-0482 (Call Invites)

[kevin . smith]

Version 0.1.0 of XEP-0482 (Call Invites) has been released.

Abstract:
This document defines how to invite someone to a call and how to
respond to the invite.

Changelog:
Promoting to Experimental. (XEP Editor: ks)

URL: https://xmpp.org/extensions/xep-0482.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] NEW: XEP-0481 (Content Types in Messages)

[kevin . smith]

Version 0.1.0 of XEP-0481 (Content Types in Messages) has been
released.

Abstract:
This specification describes a generic method whereby content in
messages can be tagged as having a specific Internet Content Type. It
also provides a method for sending the same content using different
content types, as a fall-back mechanism when communicating between
clients having different content type support.

Changelog:
Promoting to Experimental. (XEP Editor: ks)

URL: https://xmpp.org/extensions/xep-0481.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] NEW: XEP-0480 (SASL Upgrade Tasks)

[kevin . smith]

Version 0.1.0 of XEP-0480 (SASL Upgrade Tasks) has been released.

Abstract:
This specification provides a way to upgrade to newer SASL mechanisms
using SASL2 tasks.

Changelog:
Promote to Experimental. (XEP Editor: ks)

URL: https://xmpp.org/extensions/xep-0480.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] UPDATED: XEP-0313 (Message Archive Management)

[kevin . smith]

Version 1.1.0 of XEP-0313 (Message Archive Management) has been
released.

Abstract:
This document defines a protocol to query and control an archive of
messages stored on a server.

Changelog:
* Clarify archive metadata response in the case of an empty archive.
* Clarify query response in the case of no matching results. (mw)

URL: https://xmpp.org/extensions/xep-0313.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] UPDATED: XEP-0223 (Persistent Storage of Private Data via PubSub)

[kevin . smith]

Version 1.1.1 of XEP-0223 (Persistent Storage of Private Data via
PubSub) has been released.

Abstract:
This specification defines best practices for using the XMPP publish-
subscribe extension to persistently store private information such as
bookmarks and client configuration options.

Changelog:
Add notes about checking event origin (in reaction to CVE-2023-28686).
(ka)

URL: https://xmpp.org/extensions/xep-0223.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

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

[kevin . smith]

Version 1.25.0 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:
*
*
*
*  (mw, pep)

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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] UPDATED: XEP-0472 (Pubsub Social Feed)

[kevin . smith]

Version 0.2.0 of XEP-0472 (Pubsub Social Feed) has been released.

Abstract:
This specification defines a way of publishing social content over
XMPP.

Changelog:
* Change the pubsub#type to be consistent with other XEPs
* Add a Discovery section (tj)

URL: https://xmpp.org/extensions/xep-0472.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] UPDATED: XEP-0356 (Privileged Entity)

[kevin . smith]

Version 0.4.1 of XEP-0356 (Privileged Entity) has been released.

Abstract:
This specification provides a way for XMPP entities to have a
privileged access to some other entities data

Changelog:
Fixed some typos (gh/@bodqhrohro)

URL: https://xmpp.org/extensions/xep-0356.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] UPDATED: XEP-0356 (Privileged Entity)

[kevin . smith]

Version 0.4.1 of XEP-0356 (Privileged Entity) has been released.

Abstract:
This specification provides a way for XMPP entities to have a
privileged access to some other entities data

Changelog:
Fixed some typos (gh/@bodqhrohro)

URL: https://xmpp.org/extensions/xep-0356.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] UPDATED: XEP-0428 (Fallback Indication)

[kevin . smith]

Version 0.2.0 of XEP-0428 (Fallback Indication) has been released.

Abstract:
This specification proposes a mechanism by which message bodies or
parts thereof can be marked as being for fallback purposes, and
therefore to be ignored by anything that understands the original
intent of the message.

Changelog:
* Add 'for' attribute such that entities can discover what the
fallback is for.
* Allow to specify that only one of  or  is meant as a fallback.
* Allow to specify the part of respective text that is meant as
fallback where applicable.
* Don't use encryption example, which should use XEP-0380 instead.
(lmw)

URL: https://xmpp.org/extensions/xep-0428.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] UPDATED: XEP-0388 (Extensible SASL Profile)

[kevin . smith]

Version 0.4.0 of XEP-0388 (Extensible SASL Profile) has been released.

Abstract:
This document describes a replacement for the SASL profile documented
in RFC 6120 which allows for greater extensibility.

Changelog:
* Bump namespace
* Add reference to  and
* Update security considerations and business rules
* Clarify  and tasks
* Add expansion point to inline stream resumption and BIND2 (and
possibly others)
* Add optional  element
* Move from Deferred to Experimental (tm)

URL: https://xmpp.org/extensions/xep-0388.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] UPDATED: XEP-0386 (Bind 2)

[kevin . smith]

Version 0.4.0 of XEP-0386 (Bind 2) has been released.

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

Changelog:
Various changes, made in parallel with working client and server
implementation experience, and SASL2 updates.
More tightly define the integration with XEP-0388 and several session
feature XEPs: XEP-0198, XEP-0280, XEP-0352.
Replace the custom latest-id element with the new metadata element
from XEP-0313, which also provides richer information.
Drop unread tracking, as this is a deep topic not directly related to
resource binding. Instead the details of integration with other
extensions have been better defined and demonstrated, to allow such
functionality when it is fully defined and exists.
Adjust proposed namespace on aesthetic grounds and consistency with
SASL2's approach. As this protocol may become part of the new
preferred connection flow for a long time to come, it makes no sense
to include the redundant and potentially confusing '2' when there is
no conflict without it. Similarly, the '.0' has been dropped from the
XEP's title, as it isn't really a version number.
Allow the client some influence over the resulting resource
identifier, and define a standard format for these combined
identifiers.
Specify that servers should terminate old sessions from a client when
it binds a new resource. (mw)

URL: https://xmpp.org/extensions/xep-0386.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] UPDATED: XEP-0359 (Unique and Stable Stanza IDs)

[kevin . smith]

Version 0.7.0 of XEP-0359 (Unique and Stable Stanza IDs) has been
released.

Abstract:
This specification describes unique and stable IDs for messages.

Changelog:
Add security consideration regarding spoofability and reference
example (fs)

URL: https://xmpp.org/extensions/xep-0359.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

[Standards] UPDATED: XEP-0292 (vCard4 Over XMPP)

[kevin . smith]

Version 0.12.0 of XEP-0292 (vCard4 Over XMPP) has been released.

Abstract:
This document specifies an XMPP extension for use of the vCard4 XML
format in XMPP systems, with the intent of obsoleting the vcard-temp
format.

Changelog:
Removes raw-IQ mode and specifies the reuse of PEP (spw)

URL: https://xmpp.org/extensions/xep-0292.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 -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2023

[Kevin Smith]

-- Original Message --
From "Melvin Keskin" 
To "XMPP Standards" 
Date 26/01/2023 11:52:39
Subject Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 
2023



Hi,

I would like to propose the removal of "The /me Command" from the IM
Compliance Suite. In my opinion, it is neither necessary (users can
type their name instead) nor a substantial functionality that many
users (outside of our geek bubble) need for chatting.

It does not mean that clients should not support it but I think it
should not be listed as an (implicitly important) feature clients must
support in order to comply with the compliance suite of 2023.
As a counter-argument, it is widely used, and by not supporting it a 
client will present weird messages to its users when presented.
If this was an onerous XEP to implement, the argument might be 
different, but this isn't hard to implement, and by not having it

'weird things' happen.

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

[Standards] Proposed XMPP Extension: XMPP Compliance Suites 2023

[kevin . smith]

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: XMPP Compliance Suites 2023
Abstract:
This document defines XMPP application categories for different use
cases (Core, Web, IM, and Mobile), and specifies the required XEPs
that client and server software needs to implement for compliance with
the use cases.

URL: https://xmpp.org/extensions/inbox/cs-2023.html

The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] UPDATED: XEP-0474 (SASL SCRAM Downgrade Protection)

[kevin . smith]

Version 0.2.0 of XEP-0474 (SASL SCRAM Downgrade Protection) has been
released.

Abstract:
This specification provides a way to secure the SASL and SASL2
handshakes against method and channel-binding downgrades.

Changelog:
* Add description of attack model
* Add section defining IETF interaction (tm)

URL: https://xmpp.org/extensions/xep-0474.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-0461 (Message Replies)

[kevin . smith]

Version 0.2.0 of XEP-0461 (Message Replies) has been released.

Abstract:
This document defines a way to indicate that a message is a reply to a
previous message.

Changelog:
Fix example character counting. Add disco feature. Relax the 'to'
attribute constraints. (nc)

URL: https://xmpp.org/extensions/xep-0461.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-0444 (Message Reactions)

[kevin . smith]

Version 0.1.1 of XEP-0444 (Message Reactions) has been released.

Abstract:
This specification defines a way for adding reactions to a message.

Changelog:
Add the XML Schema (egp)

URL: https://xmpp.org/extensions/xep-0444.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-0426 (Character counting in message bodies)

[kevin . smith]

Version 0.3.0 of XEP-0426 (Character counting in message bodies) has
been released.

Abstract:
This document describes how to correctly count characters in message
bodies. This is required when referencing a position in the body.

Changelog:
Added section about subsequences. (lmw)

URL: https://xmpp.org/extensions/xep-0426.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-0353 (Jingle Message Initiation)

[kevin . smith]

Version 0.5.0 of XEP-0353 (Jingle Message Initiation) has been
released.

Abstract:
This specification provides a way for the initiator of a Jingle
session to propose sending an invitation in an XMPP message stanza,
thus taking advantage of message delivery semantics instead of sending
IQ stanzas to all of the responder's online resources or choosing a
particular online resource.

Changelog:

  Recommend usage of UUID v4 for id attributes.
 (tm)

URL: https://xmpp.org/extensions/xep-0353.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] XEP-0444 Schema PR

[Kevin Smith]

Natalie, Marvin,

https://github.com/xsf/xeps/pull/1261 has been submitted to add a schema 
- are you ok with the change?


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

Re: [Standards] XEP-0444 update: restrict reactions

[Kevin Smith]

-- Original Message --
From "Mathieu Pasquet" 
To "Kevin Smith" ; "XMPP Standards" 


Date 06/01/2023 15:44:50
Subject Re: [Standards] XEP-0444 update: restrict reactions


Hi,

On 06.01.2023 11:01, Kevin Smith wrote:

My earlier iteration of the PR did include a mechanism to fetch the available 
emojis (and rules, eg 1 emoji per reacter per message), but after discussion 
with Marvin (author), we decided that it's a bad idea, since, as you said, most 
instances are probably happy to accept any reactions.

I guess the question is "Do we want 'normal' services to be able to have limited 
emoji sets?". If we do, then requiring users to keep sending reactions and getting 
errors back until they find one that's supported is clearly not a reasonable approach. If 
we don't, are we happy that the experience interacting with transports is basically going 
to suck?


Is it going to suck that bad, if the transport replies with an error
message containing the set of allowed emoji?
Well, given there's no reason for it (it would be trivial to advertise 
that emoji are restricted in disco), why would we choose a poor UX (ever 
if you think 'suck' is too strong, I don't think anyone is going to 
argue that it's good UX for the client to allow you to do something, and 
then after you've done it say "I shouldn't have let you do that") when 
we can trivially have a better one.


If clients want to ignore the restriction and allow users to choose an 
emoji and just see if it works, there's nothing stopping them doing so, 
but by having disco and some fetch iq, we allow clients that want to 
present a good UX to do so.



I do see the value on communicating a restricted set if clients have
inline interface only showing preconfigured emoji (like signal does),
requiring the user to click on the button for additional emojis each
time if the ones allowed by the gateway are not in there.
Right. Having a mechanism to query this allows such a client to be 
produced, but doesn't enforce it - and adding an extra feature to disco 
and an extra IQ is very little effort in any client, server, library, 
transport or bot I've worked on.


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

Re: [Standards] XEP-0444 update: restrict reactions

[Kevin Smith]

-- Original Message --
From "Nicolas Cedilnik" 
To standards@xmpp.org
Date 06/01/2023 06:12:36
Subject Re: [Standards] XEP-0444 update: restrict reactions


Thanks for the feedback.

I suspect that in most instances, you're happy to accept any reactions, and 
forcing a poll of available ones before that would be unhelpful,

My earlier iteration of the PR did include a mechanism to fetch the available 
emojis (and rules, eg 1 emoji per reacter per message), but after discussion 
with Marvin (author), we decided that it's a bad idea, since, as you said, most 
instances are probably happy to accept any reactions.
I guess the question is "Do we want 'normal' services to be able to have 
limited emoji sets?". If we do, then requiring users to keep sending 
reactions and getting errors back until they find one that's supported 
is clearly not a reasonable approach. If we don't, are we happy that the 
experience interacting with transports is basically going to suck?

blindly sending and seeing if they stick.


This is the current behavior described in this patch indeed. At the very least, this PR clarifies 
what clients should do when they receive an error after sending a reactions payload. I believe that 
the default behavior would be "revert to previous reactions state" but we made it 
"reset reactions to null" instead.


Would it work to advertise a disco feature of 'limited-reactions' so that e.g. 
a MUC that's going to filter such things could advertise the feature, and 
clients would know they need to fetch first, and otherwise wouldn't need to 
bother?


Outside of a gateway context, this is probably something that should be 
configurable by room admins,
I'm not sure that's true, I could see this being a system-wide config, 
but I don't think it's directly relevant to how they're advertised.



 so wouldn't it be better as a muc#config field? Clients supporting it can adapt 
their UIs accordingly, and clients that don't can at least not display a bogus 
reaction state by taking into accounts the  they receive when 
trying to send a forbidden reaction payload.
That wouldn't help things that aren't MUC rooms, and I don't see why 
entire services mightn't limit the available emoji, if rooms might.


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

Re: [Standards] XEP-0444 update: restrict reactions

[Kevin Smith]

-- Original Message --
From "Nicolas Cedilnik" 
To standards@xmpp.org
Date 30/12/2022 13:25:25
Subject [Standards] XEP-0444 update: restrict reactions


Hello all,

About https://github.com/xsf/xeps/pull/1249

My main reason for submitting a patch to this XEP is that most other walled garden IM 
networks are not as permissive when it comes to emoji reactions: most only allow 1 emoji 
per message per "reacter", some restrict the available emojis to a small subset 
of emojis. However, I think that it could also be useful in MUCs, where implementations 
may want to allow admins to use such restrictions.

My first draft had many issues, and after discussion on the github PR thread with marvin, I 
changed it to just mentioning that clients that send a reaction and then receive a  in return, should reflect that in their UI - removing all reactions 
from themselves to this message.

However, after further OOB discussion with marvin, we thought it might useful to add an 
additional "emoji correction" mechanism, in the form of a  element 
in the error payload.

With XMLove,


I suspect that in most instances, you're happy to accept any reactions, 
and forcing a poll of available ones before that would be unhelpful, as 
would blindly sending and seeing if they stick. Would it work to 
advertise a disco feature of 'limited-reactions' so that e.g. a MUC 
that's going to filter such things could advertise the feature, and 
clients would know they need to fetch first, and otherwise wouldn't need 
to bother?


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

Re: [Standards] Channel binding and token authentication

[Kevin Smith]

-- Original Message --
From: "Matthew Wild" 
To: "XMPP Standards" 
Sent: 26/09/2022 18:24:37
Subject: [Standards] Channel binding and token authentication


Does anyone have objections to proceeding with the definition of one
or more HT-*-NONE mechanisms for token authentication?


Seems entirely sensible to me.

/K

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

Re: [Standards] MIX-PAM: Change of annotate setting with second roster get

[Kevin Smith]

-- Original Message --
From: "Steve Kille" 
To: "'XMPP Standards'" 
Sent: 15/07/2022 09:16:58
Subject: Re: [Standards] MIX-PAM: Change of annotate setting with second 
roster get


My preference for resolving the issue raised  is that the client should 
indicate its preference in ALL roster IQs.So if the client sends an IQ 
without the annotate, it will be taken as an indication to stop sending the 
additional MIX information.
I can't really see a reason a client would need to send a second roster 
get, but if they do it makes sense to me for the server to reset the 
state to whatever's in that request (i.e. I agree).


/K

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

Re: [Standards] Moving server-side MAM search forwards

[Kevin Smith]

-- Original Message --
From: "Matthew Wild" 
To: "XMPP Standards" 
Sent: 13/06/2022 15:03:38
Subject: Re: [Standards] Moving server-side MAM search forwards


On Mon, 13 Jun 2022 at 14:49, Dave Cridland  wrote:

 On Sun, 12 Jun 2022 at 18:02, Matthew Wild  wrote:


 What I'm trying to prevent is leaking implementation-defined esoteric
 syntax to end users. That at least one implementation is already
 exposing Lucene's special query syntax via this XEP is enough to
 convince me that simple searches are worth pushing for.


 Right, exposing something like Lucene is clearly insane on many levels.

 I'm not convinced that exposing any sort of syntax is bad, though - allowing 
the kind of syntax that websearch_to_tsvector allows seems harmless. But if 
we're faced with people that genuinely think exposing a search language, rather 
than interpreting an end-user search string, is sensible then we have clearly 
lost anyway.


Yes, I agree that websearch_to_tsvector() would be absolutely fine
too. However it's not permitted by my proposed text mainly because I'm
not sure how to codify that in a XEP without beginning to dictate the
actual search syntax. Which is something I don't really want to do,
because this isn't a Postgres-driven XEP and there may be (completely
acceptable) syntax differences in other equivalent implementations.

If "simple searches" are not going to fly, maybe we could instead
settle for some non-normative text advising implementations against
exposing "implementation-specific syntax", or something along those
lines. In addition to mandating  for anything more advanced than
the simple search defined in my current proposal.


If the core thing we're trying to do is ensure that implementers realise 
it's not reasonable to expose an unintuitive search syntax (e.g. 
Lucene's, with which I'm not sufficiently familiar to really comment), 
would some text explaining that the purpose is to expose a search field 
that a user can just type things into as they would a web search engine, 
not to expose a structured query language, suffice? We have plenty of 
evidence from the web that users can be presented with fields that can 
support complex queries without being inconvenienced, where the simple 
queries work as you'd expect.


/K

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

Re: [Standards] Moving server-side MAM search forwards

[Kevin Smith]

Hi Matt,

-- Original Message --
From: "Matthew Wild" 
To: "XMPP Standards" 
Sent: 03/06/2022 10:50:03
Subject: [Standards] Moving server-side MAM search forwards


  1) Add a "simple" search type, which is recommended to be
implemented as a baseline for interoperability. For simple searches,
the server promises that no search terms or symbols will be
interpreted as special syntax - what you search is what you get.

  2) Extend the existing ("advanced") search field with a
recommendation that the server includes a  element (already
defined in XEP-0004) to explain the supported syntax to the user, and
an (entirely optional) machine-readable hint that can be used to
indicate to a client that a commonly-used syntax is supported.


If it's not a silly question - do we *need* a simple type as well as the 
default search? I think using  to describe syntax makes sense, 
but I'm not entirely sold on the need for the simple search (less so for 
it to be the recommendation) - almost all the search fields people use 
daily have special syntax (search engines, mail clients, chat clients, 
OS file search...) and by being well-crafted I strongly suspect most 
users have never clicked the syntax expansion and never realised there 
was an advanced syntax (and never suffered for it). Given that even the 
proposed simple search allows implementation-specific magic to be 
performed, would we not be better off by sticking to the one field, and 
providing helpful hints on it (maybe just ) rather than needing 
to somehow bifurcate the search UI?


/K

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

Re: [Standards] XEP-0004 Partial form submission

[Kevin Smith]

On 2 Feb 2022, at 16:11, Daniel Gultsch  wrote:
> I wanted to bring everyone's attention to a proposed modification of
> XEP-0004 that allows partial form submission.
> 
> While this has originally been proposed in '[Standards] Proposed
> XEP-0060 Changes' we (Council) wanted to have the exact wording
> discussed by a wider audience.
> 
> The PR in question: https://github.com/xsf/xeps/pull/1153/files
> 
> Any feedback is appreciated.

I think the intention of the change is reflecting what everyone’s doing anyway, 
so from that point of view seems fine.

The SHOULD could maybe benefit from an example of where it might be 
inappropriate, as it sometimes is - e.g. if one of the newly provided values 
conflicts somehow with an elided value the sensible thing could be for the 
server to reset the elided value to default (or another value). This could also 
be done by not making in normative, but just stating the intention that the 
client isn’t trying to change elided values.

In general, I think that when adding more restrictive language to a Final XEP 
it’s worth including a note about the change (or a namespace bump, which seems 
terribly inappropriate here).

/K

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

Re: [Standards] [XEP-0030] we can't get basic information on a bare JID without presence subscription

[Kevin Smith]

Bordering on off-topic, but:

-- Original Message --
From: "Florian Schmaus" 
To: standards@xmpp.org
Sent: 19/01/2022 11:20:56
Subject: Re: [Standards] [XEP-0030] we can't get basic information on a 
bare JID without presence subscription



On 19/01/2022 11.17, Daniel Gultsch wrote> Or in other words. Without presence 
subscription you get only the

 (and related features) and
with presence subscription you also get  and features related to the account.


Returning different results to disco#info (and disco#items) depending on who 
queries seems like something that has the potential to great damage. I also 
think that this is nothing we currently endorse, specify or see in the wild.
Just for what it's worth, at least providing different disco#items based 
on access to people is definitely done in the wild, e.g. for MUC rooms 
to only be listed to people who have access to them.


/K

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

Re: [Standards] Proposed XEP-0060 Changes

[Kevin Smith]

On 15 Dec 2021, at 14:41, Dave Cridland  wrote:
> So, summary: I'd replace the opening text to 8.2.4 with:
> 
> "If the owner wishes to change the configuration, they submit a completed 
> configuration form. The server MUST treat any fields not included as though 
> they are supplied with the default values from the configuration form (see 
> 8.2.2)."
> 
> Honestly I think the MUST there is a bit overkill, but I think the rest is OK.

I think what we’re trying to say is (not a prose suggestion): “Accept a form 
with missing fields, and process missing fields as if the client isn’t trying 
to modify them”, is that right?

I think a small amount of vagueness here is of value, because one might imagine 
a form where setting one field means another must have a value - a helpful 
server might autogenerate the second value when the first is enabled, but a 
MUST synthesise the fields as if they were specified prevents that.

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

Re: [Standards] Process Wonkery

[Kevin Smith]

On 30 Sep 2021, at 09:56, Dave Cridland  wrote:
> 
> All,
> 
> Kev Smith noted that we have been a bit weird about handling updates to XEPs 
> from authors during the Proposal phase (that is, Proposed state, from Last 
> Call through to completion of a vote to Stable).

Ta.

> 1) When can authors update XEPs?
> 
> XEP-0001 is fairly unspecific about when updates to a XEP can be published 
> (ie, when PRs can be merged). More or less, it says they should be, but from 
> Stable onward only with Approving Body permission.
> 
> This means that during a Last Call updates can be made, changing the XEP 
> while people are reviewing it, which seems potentially awkward to me.
> 
> Once a XEP has gone before Council, we have developed a habit of discussing 
> PRs before a merge to see if they'll clear Council objections - this 
> streamlines the logistics but is clearly not what the process demands.
> 
> The timeline for a Proposed XEP currently looks like:
> 
> t=0 Last Call Starts
> t=2w Last Call Ends, Advancement vote in Council
> 
> I'd be interested in views on whether we should require authors hold updates 
> to the XEP during Last Call, which would lead to:
> 
> t=0 Last Call Starts
> t=2w Last Call Ends, Update Window
> t=n Update Window Closes, Advancement vote in Council
> 
> Opinions welcome from Authors, Council people (past and present), and others 
> in the community.

This sounds appealing at first glance - however, I think there’s two types of 
changes an Author could be making during the LC window: those addressing LC 
feedback and those unrelated to LC feedback. Changes unrelated to LC feedback 
might not be optimal (but if they need to be made, making them while the LC 
window is open actually makes more sense than holding them and potentially 
invalidating LC feedback. Changes to address LC feedback make more sense made 
*in* the LC window when people can then comment on whether they address their 
issues. So I think this comes down to ‘worthwhile changes might as well be made 
ASAP, including in LC, and “bad” changes are best not made during LC (or 
ever)”, so it’s not clear to me that the change would actually help. I think 
the existing process, whereby Council will reject advancement if LC feedback 
hasn’t been addressed, would also apply if the Author is making undesirable 
changes during or after LC (or another LC could be issued, or whatever).

> 2) Who are Authors anyway?
> 
> Authors have special rights with XEPs, especially Experimental - they can 
> more or less change them at whim, and although the intent here is that they 
> capture community consensus, there is no oversight. Additionally, there's a 
> bit of kudos involved in having one's name at the top of a XEP.
> 
> In practice, Council has added (and removed?) Authors, and we added an 
> "escape" to XEP-0001 in the form of Document Shepherds.

(I can’t remember Council ever removing an Author, although Authors have 
removed themselves. My memory may be imperfect)

> What I'd like to propose here is that XEP-0001 properly captures who Authors 
> are (initially, the original Submitters listed on the document, all of whom 
> must agree to the IPR policy)

That seems reasonable

> , how new ones are added (by Council approval, in consultation with the 
> existing Authors if possible),

I think Authors should be free to add additional authors, as they’ve previously 
done.

> and how dormant/inactive Authors are removed (here be tygers; I'd like to 
> propose maybe marking them as emeritus or something less latinate).

Although I’m not convinced it’s a good idea, we could move to recording who has 
authored each change to a XEP, and instead of having an Authors list being 
responsible for the XEP, have a Maintainers list or whatever, and have Council 
able to manipulate the Maintainers list, but not the authors list (which is 
then simply a factual record).

> I'm not bound to this approach, but I think done correctly, this can obviate 
> the need for Document Shepherds entirely, so this might - astonishingly - 
> simplify our process.

I’m not sure it simplifies the process significantly, as you still need to have 
someone in the Document Shepherd role, as it currently stands, whatever name 
one gives it.

Regardless, nothing here is remotely a hill worth dying on, and at least some 
sort of codification of what we’re doing (or changing what we’re doing to match 
our process) makes sense to me.

/K

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

Re: [Standards] LAST CALL: XEP-0459 (XMPP Compliance Suites 2022)

[Kevin Smith]

On 29 Sep 2021, at 17:32, Georg Lukas  wrote:
> 
> Sorry this is so late, and thanks to Sonny for taking up the hard task
> of fighting this through the Council.
> 
> * Jonas Schäfer  [2021-09-07 16:04]:
>> This message constitutes notice of a Last Call for comments on
>> XEP-0459 [...] XMPP Compliance Suites 2022
> 
> 1. As part of the work on XEP-0313, two XEPs got split out:
> 
> - XEP-0441: Message Archive Management Preferences

I think preferences just aren’t generally useful enough to be needed in the 
suite.

> - XEP-0442: Pubsub Message Archive Management

I think we’re probably the only people doing pubsub MAM, and I wouldn’t argue 
that it’s going to be useful in the compliance suites - we had some quite 
specific requirements, otherwise we’d probably not have bothered.

> I think that at least XEP-0441 belongs into Advanced IM to keep the
> same functionality as before.

I don’t think there’s a particular reason to keep the same functionality as 
before - they were split out of 313 precisely because they’re not as widely 
needed as the rest of it.

> 2. As editor of earlier Compliance Suites, I used to review the
> https://xmpp.org/extensions/xep-0459.html#future section to see which
> XEPs have matured over the previous year and could be added into one of
> the Suites.
> 
> I might be slightly biased, but I would like to propose the following
> three for Advanced IM Client and Server:
> 
> - XEP-0379: Pre-Authenticated Roster Subscription
> - XEP-0401: Easy User Onboarding
> - XEP-0445: Pre-Authenticated In-Band Registration
> 
> In parallel, I'd like to ask The Editor about issuing Last Calls for
> 0379 and 0445, and Marc to step in and ask for LCing 0401.

If the suites were framed as current advice on what to implement, then advising 
these if you want to do registration would seem reasonable to me, but as long 
as it’s “compliance” suites, I don’t think mandating registration approaches is 
helpful - it means any systems that don’t need registration can’t be compliant, 
and that reduces the value in the specs.

> 3. It is also good to check https://xmpp.org/extensions/ for new
> additions. From there, I suggest adding the following new XEPs to the
> "Future Development" section:
> 
> - XEP-0453: DOAP usage in XMPP

Not arguing it’s not useful, but ISTM how projects advertise themselves 
shouldn’t be a part of (future) compliance.

> - XEP-0455: Service Outage Status
> - for E2EE: XEP-0450: Automatic Trust Management (ATM)

Are we sure 450’s in a state where it’s sensible to call it out?

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

Re: [Standards] XEP-0372 references pointing to different elements in same stanza

[Kevin Smith]

> On 9 Sep 2021, at 18:06, Florian Schmaus  wrote:
> 
> On 13/08/2021 14.00, JC Brand wrote:>  from="sch...@springfield.city">
>> Attention Bart Simpson
>> Please hand in your homework before the end of the 
>> day
>> 
>> 
> 
> Why is there a number sign ('#') before the element name? What if there is 
> another first-level stanza child element with a local name 'subject' but a 
> different namespace?

It’s not the element name, it’s just (possibly unfortunately) the same in that 
example. It’s the id. 

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

Re: [Standards] XEP-0372 references pointing to different elements in same stanza

[Kevin Smith]

On 13 Aug 2021, at 13:00, JC Brand  wrote:
> 
> Hi everyone
> 
> In XEP-0372, when references are used for "mentions", there is an implicit 
> assumption that the referenced text is in the  tag.
> 
> There are however other elements where mentions could also occur, such as 
> ,  and , and some stanzas could have multiple possible 
> elements whose text might be referenced.
> 
> XEP-0372 provides an "anchor" attribute for the  tag, which can be 
> used to refer to other addressable entities, to handle the case where the 
> reference points to something in another stanza.
> 
> I think this "anchor" attribute can also be used to disambiguate the 
> references in a stanza that has multiple text-containing elements. In this 
> case, instead of letting the anchor point to an XMPP URI, it would only point 
> to a fragment, meaning that the fragment is inside the same stanza.
> 
> In HTML the fragment of a URI points to an element with the same id attribute 
> value as the fragment itself, but apparently this isn't a general requirement 
> for URIs. In this case, for simplicity, I would however stick to that 
> convention.
> 
> So, if you have a stanza with for example, both "subject" and "body" tags, we 
> can have references for both, and use the "anchor" attribute as follows (I 
> hope this comes out formatted properly once sent):
> 
>  >
> Attention Bart Simpson
> Please hand in your homework before the end of the 
> day
> 
> 
> 
> I think this is an elegant solution that uses the existing mechanics, and the 
> only further requirement would be to clarify in the XEP that the anchor 
> attribute can be used in this way.
> 
> I'd be happy to hear your thoughts and feedback.

This doesn’t sound terrible to me. Anything we do here will be a bit icky, but 
at least this is trivial to implement and doesn’t require pulling in an xpath 
library, and isn’t trying to recreate xpath with a different syntax (which was 
what I first thought it would lead to).

/K

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

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

[Kevin Smith]

To summarise what I’ve said before:

MUC in MAM kinda sucks, but groupchat doesn’t (necessarily) mean MUC.
Sometimes people want groupchat messages in their archive because they want 
their archive to represent all those messages they received on any client, 
either for online searching, or offline sync, and MAM is the only mechanism we 
have for this.
If we were to disallow groupchat in MAM completely, it would make existing 
deployed workflows unavailable.
There are countless pitfalls to having MUC (rather than groupchat) in MAM, but 
prohibiting it just isn’t much of an option. I don’t much like where we are 
more than anyone else, but it *is* where we are, and I don’t think anyone has 
the time machine yet to go back and fix MUC preemptively.

After discussion with Georg yesterday, I’ve submitted a new version of MAM that 
uses Dave’s suggested approach.

/K

> On 8 Sep 2021, at 09:00, Georg Lukas  wrote:
> 
> * Kevin Smith  [2021-09-07 18:41]:
>> At the risk of repeating myself, I think that storing groupchat messages in 
>> the user archives is helpful, and people do this in the wild.
> 
> Right, I remember hearing that before, and IIRC the reason for that was
> to allow for server-side message search?
> 
> Now I have multiple practical questions regarding how this is supposed
> to work.
> 
> First, how and when are groupchat messages from MAM delivered to a
> client? I can understand that it will mostly work well when querying for
> the room JID. But what happens on a query that's only filtered by
> `start` or `after-id`? Will the server intermix all groupchat messages
> with all direct messages? Will it only send groupchats from the rooms
> that some client of that user is currently joined? Only the rooms that
> the querying client is joined? ...was joined in the past? Groupchats
> have typically a much higher singal-to-noise ratio and could
> significantly delay the loading of the really important messages here ;)
> Should there be a difference between "channels" (public semi-anon rooms)
> and "group chats" (closed non-anon rooms)?
> 
> 
> Second, how does the MAM service ensure that the MUC history is complete
> and does not contain holes, e.g. because all of the user's client left
> the room at a certain time, or due to s2s outages? Or is there no such
> guarantee, rendering the archive less than useful? Will the personal
> archive re-populate MUC history when a client does a MAM query on the
> MUC archive? Should the personal archive do MAM requests on its own?
> 
> 
> Third, how is deduplication supposed to work? Will the user's archive
> add its own  and only allow querying by that? How is a client
> going to consolidate MUC messages based on their MUC-assigned stanza-ids
> with ones from the personal archive - or is the client supposed to
> ignore the MUC-assigned IDs?
> 
> 
> Fourth, a personal MAM archive MAY exclude groupchat messages if these
> are already archived on the MUC JID. There is no explicit signalling for
> this, so I assume the most straight-forward implementation would be to
> check all passing messages for the presence of a stanza-id field added
> by the MUC JID, and to prevent storage of these. Let's ignore that a MUC
> service or a room might change its archival preferences over the time,
> we are still lacking a mechanism for the client to decide which JID to
> query to obtain a MUC history. Should it first query the personal
> archive and only fall back to the MUC archive if it receives an error?
> An empty result set?
> 
> 
>> So if there *was* somehow agreement for forbidding it, it would need a
>> namespace bump, because it used to be allowed (and, indeed,
>> recommended).
> 
> Well, given that a server MAY exclude groupchat messages if history is
> accessible through other means, and given that 0045 includes a mechanism
> for fetching history, I would say that a namespace bump is not needed ;-)
> 
> 
> Georg
> ___
> 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] LAST CALL: XEP-0313 (Message Archive Management)

[Kevin Smith]

On 7 Sep 2021, at 16:22, Georg Lukas  wrote:
>> §6.1.1: the business rules for user archives are inadequate:
>> 
>> MUC messages in user archive: I think that implementation practice has
>> clearly shown that storing MUC messages in the user archive is a Bad
>> Idea, and nobody is doing it anyway. Also the server is probably not in
>> a position to track a user's MUC activity and query all MUCs for whether
>> they implement some sort of message storage. This part should be
>> converted into "SHOULD NOT" or "MUST NOT".
> 
> After some discussion it was suggested to change the scope of this from
> "should not store" to "should not return by default", which is also fine
> with me.

At the risk of repeating myself, I think that storing groupchat messages in the 
user archives is helpful, and people do this in the wild.

So if there *was* somehow agreement for forbidding it, it would need a 
namespace bump, because it used to be allowed (and, indeed, recommended).

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

Re: [Standards] XEP-0227 update

[Kevin Smith]

Thanks Matt, a couple of comments:

On not namespace bumping:
227 already said you had to cope with unexpected elements, so simply including 
the new elements in their new namespaces seems ok to me. (Although this may 
generate warnings. *shrug*)

PEP:
Do you mean PEP as in 163, or full pubsub-on-a-JID? I assume the latter - is it 
worth being explicit?
What needs to happen if you can’t process the config fully on import (because 
of features the exporting server supports and you don’t).

But otherwise looks good, thanks.

/K

> On 2 Jun 2021, at 16:59, Matthew Wild  wrote:
> 
> Hi folks,
> 
> This somewhat forgotten XEP used to be the way to migrate data between
> XMPP services. Unfortunately it didn't keep up with the times, and
> many servers gained tools for importing directly from the native
> formats of other servers (Prosody has an ejabberd importer, ejabberd
> has a Prosody importer).
> 
> Even if it never again becomes the standard format for server software
> migrations (XML is not an ideal format when you're dealing with
> massive amounts of data), as part of the XMPP account portability
> project[1] I want to once again bring XEP-0227 up to date with what
> data commonly constitutes an XMPP account.
> 
> I've prepared an update that adds some of the missing features:
> 
>  - SCRAM hashes (it previously recommended inclusion of plaintext passwords)
>  - PEP nodes (configuration and items)
>  - Message archives
> 
> I'd appreciate feedback, and also I'd be curious of any wishlist items
> that anyone else may have.
> 
> The draft PR is at: https://github.com/xsf/xeps/pull/1064 and a
> rendered version is available at
> https://matthewwild.co.uk/uploads/xeps/xep-0227.html
> 
> Regards,
> Matthew
> 
> [1]: https://docs.modernxmpp.org/projects/portability/
> ___
> 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 Modernization Roundtable Results

[Kevin Smith]

On 22 Jun 2021, at 19:05, Sam Whited  wrote:
> Sorry, my notes were getting rapid right at the end and we didn't
> discuss it all that long. The last thing was basically just "maybe we
> should have a discussion about bind2; having it would fix the
> carbons/mam race condition and it's probably higher priority than a lot
> of the other stuff."

Thanks for making the notes :)

/K

> 
> —Sam
> 
> On Tue, Jun 22, 2021, at 13:23, Kevin Smith wrote:
>> On 22 Jun 2021, at 17:51, Sam Whited  wrote:
>>> * MattJ: bind2 needs new author
>> 
>> I was under the impression no-one had much interest in me driving
>> bind2 and the associated bits forward. If I update bind2, are there
>> people ready to implement it? Have people implemented what’s there
>> already?
>> 
>>> Carbons/MAM race condition
>> 
>> 
>> What’s the race condition? I thought that enabling carbons
>> automatically removed the race condition here.
>> 
>> /K
>> 
>> ___
>> Standards mailing list Info:
>> https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards-
>> unsubscr...@xmpp.org
>> ___
>> 
> 
> 
> -- 
> Sam Whited
> ___
> 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 Modernization Roundtable Results

[Kevin Smith]

On 22 Jun 2021, at 17:51, Sam Whited  wrote:
>* MattJ: bind2 needs new author

I was under the impression no-one had much interest in me driving bind2 and the 
associated bits forward. If I update bind2, are there people ready to implement 
it? Have people implemented what’s there already?

> Carbons/MAM race condition


What’s the race condition? I thought that enabling carbons automatically 
removed the race condition here.

/K

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

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Kevin Smith]

On 11 Jun 2021, at 21:57, Ralph Meijer  wrote:
> 
> 
> 
> On June 11, 2021 10:12:31 PM GMT+02:00, Dave Cridland  
> wrote:
>> On Fri, 11 Jun 2021 at 17:10, Kevin Smith  wrote:
>> 
>> * "No person has any automatic right to join a chatroom, or write a XEP."
>> in §3 ought to be something else, since writing a XEP doesn't need the
>> XSF's permission as such.
>> 
>> I'm not sure what this can be, but I accept that writing private extensions
>> using the XEP format and publishing them independently might be considered
>> "writing a XEP", and that's not within the XSF's purview.
> 
> I don't agree here. Hairsplitting below.
> 
> Yes, people are free to create XMPP extensions (lowercase), and I believe it 
> is one of the better strengths that people can do so without permission from 
> anyone, as long as they use namespaces in a certain way to not conflict with 
> others. This is part of the distributed "DNA" of XMPP, and emphasizes that 
> the XSF is just one moving part in our community and not the end all and be 
> all of things XMPP.
> 
> However, I also strongly believe that using the term XEP implies that it is 
> part of the XSF XEP series, and that an XMPP extension in whatever format 
> only becomes a XEP when it is accepted as Experimental, becoming part of the 
> series and receiving a number.
> 
> I think XEP-0001 is clear on the above and the custom of calling things in 
> the inbox as proto-XEP affirms this.

I think I’ve already possibly caused more noise on this one than it was worth, 
but my concern wasn’t that the statement is ambiguous for people who Know 
What’s Up, but that an absolute novice to the ecosystem might see it as a 
statement that they can’t write their own extensions, and just move onwards 
without giving XMPP a second chance. It seems like a simple text tweak might be 
unecessary, but also not harmful.

I’ll drop this one now, smarter people than me can judge it.

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

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Kevin Smith]

> On 11 Jun 2021, at 21:12, Dave Cridland  wrote:
> 
> 
> 
> On Fri, 11 Jun 2021 at 17:10, Kevin Smith  <mailto:kevin.sm...@isode.com>> wrote:
> I’m just picking at replies here - as I said in the chatroom I think this is 
> a generally positive direction and want to thank the people involved.
> (I did make two suggestions there)
> 
> 
> For the record (and my notes), I'll paraphrase these here:
> 
> * "No person has any automatic right to join a chatroom, or write a XEP." in 
> §3 ought to be something else, since writing a XEP doesn't need the XSF's 
> permission as such.
> 
> I'm not sure what this can be, but I accept that writing private extensions 
> using the XEP format and publishing them independently might be considered 
> "writing a XEP", and that's not within the XSF's purview.

I think I suggested some text at the time that was something like “No person 
has any automatic right to have XEP submissions considered” or such. I’m just 
concerned (perhaps for no good reason) that that ‘write a XEP’ might confuse 
people wrt. their right (from our IPR policy) to modify XEPs etc. I believe I 
expressed that I thought tweaking this would be a benefit, but not crucial.

> 
> * There's limitations on what the XSF (via the Board) can sanction a member 
> for; in particular removal of any rights stipulated in the bylaws.
> 
> The ramifications of this one are really interesting. Is ejecting a member 
> from the members mailing list allowed? Probably, but that may mean they're 
> not notified about a meeting, which is a bylaw right (or a responsibility of 
> the XSF at least). Members can be removed, but with difficulty. I wouldn't 
> want this to be made any easier, either.

Squelching would presumably be allowed, but not removing their ability to see 
notices or XSF business.

> It may be as simple as noting that XSF Members, while held to a higher 
> standard as regards the Code of Conduct, have certain immunities with regards 
> to potential sanctions, and so members may have to take that into account 
> when voting them in.

That seems quite sensible.

>> On 11 Jun 2021, at 15:18, Dave Cridland > <mailto:d...@cridland.net>> wrote:
>> 
>> > The Conduct Team will always hand its recommendation on Sanctions or
>> > other Actions to the Board. The Board will discuss and vote on these
>> > "in camera" (ie, not in public and not minuted).
>> 
>> It seems like there's not much point having a conduct team if the board
>> also has to relitigate their decisions. I'd just allow the board to
>> delegate this authority fully (which presumably they could do anyways
>> and this document doesn't curtail board power?)
>> 
>> 
>> I was in two minds about this, so thanks for raising it.
>> 
>> I went for Board ratification of decisions mostly for the ease of managing 
>> the authority, but also in part because then the Conduct Team becomes an 
>> investigatory and deliberatory team instead of both judge and jury.
>> 
>> But you're right in that this might end up with Board relitigating the 
>> decisions rather than just providing the final go-ahead decision and acting 
>> as a blame deflector.
> 
> I think that if we were to find that the Board consistently disagrees with 
> decisions made by the Conduct Team, the Board would likely have to look at 
> who they’d put on the Conduct Team.
> 
> If the Board has to approve the Conduct Team’s decision by really looking at 
> it and considering if it’s reasonable, is that not basically going through 
> the appeals procedure pre-emptively?
> 
> 
> I don't think so.
> 
> Where there are valid appeals, this may mean the Conduct Team hasn't done its 
> job right in finding the facts, or it may mean that despite their best 
> efforts, there was information they were unaware of.



I think, from your response, that my point wasn’t clear. If the Board were to 
be required to do a full analysis of whether the Conduct Team’s decision was 
correct in the first place, there seems there'd be little point in having an 
appeals process of going to Board to check the Conduct Team’s decision - 
they’ll already have done so.


> I’m not sure I have a strong sensible opinion on this one, it seems 
> non-trivial.
> 
> Notwithstanding the above, it's not necessary for the Board to make the final 
> decision - I did it that way based on a virtual coin-flip, but fully 
> delegating the authority seems fair too.
> 
> Or indeed partially - we could involve Board when sanctions or public 
> statements are felt to be needed by the Conduct Team, but otherwise let them 
> get on with it and just report.
> 
> Honestly, I haven't even decided 

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Kevin Smith]

I’m just picking at replies here - as I said in the chatroom I think this is a 
generally positive direction and want to thank the people involved.
(I did make two suggestions there)

> On 11 Jun 2021, at 15:18, Dave Cridland  wrote:
> 
> > The Conduct Team will always hand its recommendation on Sanctions or
> > other Actions to the Board. The Board will discuss and vote on these
> > "in camera" (ie, not in public and not minuted).
> 
> It seems like there's not much point having a conduct team if the board
> also has to relitigate their decisions. I'd just allow the board to
> delegate this authority fully (which presumably they could do anyways
> and this document doesn't curtail board power?)
> 
> 
> I was in two minds about this, so thanks for raising it.
> 
> I went for Board ratification of decisions mostly for the ease of managing 
> the authority, but also in part because then the Conduct Team becomes an 
> investigatory and deliberatory team instead of both judge and jury.
> 
> But you're right in that this might end up with Board relitigating the 
> decisions rather than just providing the final go-ahead decision and acting 
> as a blame deflector.

I think that if we were to find that the Board consistently disagrees with 
decisions made by the Conduct Team, the Board would likely have to look at who 
they’d put on the Conduct Team.

If the Board has to approve the Conduct Team’s decision by really looking at it 
and considering if it’s reasonable, is that not basically going through the 
appeals procedure pre-emptively?

I’m not sure I have a strong sensible opinion on this one, it seems non-trivial.

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

Re: [Standards] Incorrect example in XEP-0198?

[Kevin Smith]

On 7 May 2021, at 13:30, Matthew Wild  wrote:
> 
> On Fri, 7 May 2021 at 12:10, Edwin Mons  wrote:
>> 
>> Hi all,
>> 
>> I was looking at XEP-0198, and noticed something odd in Example 6.
>> Shouldn't that have been a stream error instead, as the text above
>> states? If so, will send out a PR.
> 
> Which is correct? The text or the example? While I was originally
> inclined to agree that this should be a stream error, it should be
> noted that section 6 "Error Handling" states:
> 
>  "If an error occurs with regard to an  or 
> element, the server MUST return a  element."
> 
> and
> 
>  "Stream management errors SHOULD be considered recoverable; however,
> misuse of stream management MAY result in termination of the stream."
> 
> It's relevant in the context that a stream error will terminate the
> session (such that it can't be resumed).
> 
> I don't feel strongly either way.

The text in question mentions wanting the connection terminated, which suggests 
stream error is right (which also seems logically sound to me).

"If a server receives a second  element it SHOULD respond with a 
stream error, thus terminating the client connection.”

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

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

[Kevin Smith]

On 20 Apr 2021, at 11:22, Kevin Smith  wrote:
> 
> Somewhat belatedly...
> 
>> On 16 Mar 2021, at 20:20, Jonas Schäfer (XSF Editor)  
>> wrote:
>> 
>> This message constitutes notice of a Last Call for comments on
>> XEP-0313.
>> 
>> Title: Message Archive Management
>> Abstract:
>> This document defines a protocol to query and control an archive of
>> messages stored on a server.
>> 
>> URL: https://xmpp.org/extensions/xep-0313.html
>> 
>> This Last Call begins today and shall end at the close of business on
>> 2021-03-30.
>> 
>> 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?
> 
> Yes.
> 
>> 2. Does the specification solve the problem stated in the introduction
>> and requirements?
> 
> Broadly.
> 
>> 3. Do you plan to implement this specification in your code? If not,
>> why not?
> 
> Multiple codebases (me or the the team)
> 
>> 4. Do you have any security concerns related to this specification?
> 
> Not that aren’t covered.
> 
>> 5. Is the specification accurate and clearly written?
> 
> Broadly, and I suspect all the comments below are likely in bits of thte spec 
> that I wrote, but after reviewing it again …
> 
> 4.1 - what to do with unexpected fields (this is mentioned later when talking 
> about returning available fields, but probably bears mentioning up front).
> 4.1.1 jid matching rules aren’t mentioned here, bare JID matching is 
> mentioned later but a forward reference probably wouldn’t hurt, and domain 
> matching isn’t mentioned (because it’s not intended, but calling that out is 
> probably sane, given matching rules in other XEPs typically include domain 
> matching)
> 
> 4.1.2 - Archives might use greater precision timestamps internally - in this 
> case is it the start or end of the period represented by a given timestamp 
> that’s matched? We probably need to say what happens if e.g. there are four 
> messages within a given timestamp and a client queries with that stamps as 
> the start, or if it queries with it as the end.
> 
> 4.1.3 - "If the client already knows the UID of one or more messages it wants 
> to fetch, it can use the 'ids' field:” - worth mentioning the type are 
> defined later, here, I think.
> 
> 4.1.4 - Clark notation is applied inconsistently.
> 
> 4.3.3/4.3.4 - a quick description of the interaction between  and 
> flipping pages might be in order. Particularly when … is not 
> empty. I think this is easily confused when implementing.
> 
> 6.1.2 - "A MUC archives allows” typo
> 
> 6.1.2 - "The archiving entity MUST strip any pre-existing  element from 
> MUC messages (as MUC rooms are not required to do this)” - this probably 
> means in the MUC namespace.
> 
> 7 -  "If a server or other entity hosts archives and supports MAM queries, it 
> MUST advertise the 'urn:xmpp:mam:2'  and 
> 'urn:xmpp:mam:2#extended'  features” I think it only 
> advertises extended if it supports the extended queries.
> 
> 9.1 - misses the extended namespace

And (lastly?) is it reasonable for an archive to have a limit on the allowed 
size of the ‘ids’ field? The ‘ids’ requests are a little problematic because 
the server has to find where all the messages sit in the archive before it can 
construct a result page - this gets somewhat expensive if the client is allowed 
to query arbitrarily many in a single request.

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

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

[Kevin Smith]

Somewhat belatedly...

> On 16 Mar 2021, at 20:20, Jonas Schäfer (XSF Editor)  
> wrote:
> 
> This message constitutes notice of a Last Call for comments on
> XEP-0313.
> 
> Title: Message Archive Management
> Abstract:
> This document defines a protocol to query and control an archive of
> messages stored on a server.
> 
> URL: https://xmpp.org/extensions/xep-0313.html
> 
> This Last Call begins today and shall end at the close of business on
> 2021-03-30.
> 
> 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?

Yes.

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

Broadly.

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

Multiple codebases (me or the the team)

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

Not that aren’t covered.

> 5. Is the specification accurate and clearly written?

Broadly, and I suspect all the comments below are likely in bits of thte spec 
that I wrote, but after reviewing it again …

4.1 - what to do with unexpected fields (this is mentioned later when talking 
about returning available fields, but probably bears mentioning up front).
4.1.1 jid matching rules aren’t mentioned here, bare JID matching is mentioned 
later but a forward reference probably wouldn’t hurt, and domain matching isn’t 
mentioned (because it’s not intended, but calling that out is probably sane, 
given matching rules in other XEPs typically include domain matching)

4.1.2 - Archives might use greater precision timestamps internally - in this 
case is it the start or end of the period represented by a given timestamp 
that’s matched? We probably need to say what happens if e.g. there are four 
messages within a given timestamp and a client queries with that stamps as the 
start, or if it queries with it as the end.

4.1.3 - "If the client already knows the UID of one or more messages it wants 
to fetch, it can use the 'ids' field:” - worth mentioning the type are defined 
later, here, I think.

4.1.4 - Clark notation is applied inconsistently.

4.3.3/4.3.4 - a quick description of the interaction between  and 
flipping pages might be in order. Particularly when … is not 
empty. I think this is easily confused when implementing.

6.1.2 - "A MUC archives allows” typo

6.1.2 - "The archiving entity MUST strip any pre-existing  element from MUC 
messages (as MUC rooms are not required to do this)” - this probably means in 
the MUC namespace.

7 -  "If a server or other entity hosts archives and supports MAM queries, it 
MUST advertise the 'urn:xmpp:mam:2' and 'urn:xmpp:mam:2#extended' features” I 
think it only advertises extended if it supports the extended queries.

9.1 - misses the extended namespace

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

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

[Kevin Smith]

> On 24 Mar 2021, at 16:02, Jonas Schäfer (XSF Editor)  
> wrote:
> 
> 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
> 2021-04-06.
> 
> 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?

Yes.

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

It’s probably as good as it’s going to get - it’s a (needed) bandaid for our 
routing rather than a fix, but I think we all appreciate at this point that a 
true fix is not straightforward.

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

Yes.

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

I think the private element is a little risky where a remote user can change 
routing behaviour without the recipient knowing because the server has to strip 
the private element. ("and the receiving server SHOULD remove the  
element before delivering to the recipient.”). I don’t immediately remember why 
the removing of private was necessary, and it seems like it’s probably 
undesirable?

> 5. Is the specification accurate and clearly written?

It’s probably as good as it’s going to get.

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

Re: [Standards] XML Element Ordering

[Kevin Smith]

On 23 Feb 2021, at 09:30, Dave Cridland  wrote:
> 
> 
> 
> On Mon, 22 Feb 2021 at 19:02, Florian Schmaus  <mailto:f...@geekplace.eu>> 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> 
> > <mailto:kevin.sm...@isode.com <mailto:kevin.sm...@isode.com>>> wrote:
> > 
> > On 17 Feb 2021, at 18:42, Florian Schmaus  > <mailto:f...@geekplace.eu>
> > <mailto:f...@geekplace.eu <mailto:f...@geekplace.eu>>> wrote:
> >  >
> >  > On 2/16/21 4:14 PM, Jonas Schäfer wrote:
> >  >> I think this is the best place in the thread to reply with all
> > my thoughts.
> >  >> Vote change to -0 (or +1 with additional fixes) instead of -1
> > inline.
> >  >> On Sonntag, 14. Februar 2021 21:12:17 CET Florian Schmaus wrote:
> >  >>> Eventually, this is a situation where we cannot avoid that somebody
> >  >>> needs to change their code. We need to weigh in the effects of
> > the three
> >  >>> options:
> >  >>>A: clearly state that the order is not guaranteed
> >  >>>B: clearly state that the order is guaranteed
> >  >>>C: state that it should be sent in order, but recipients
> > must be able
> >  >>> to process in any order
> >  >> You are right. You were also right about what you said in reply
> > to my other
> >  >> email about OrderedMap existing in Python (even being the
> > default since some
> >  >> versions).
> >  >> However, here is a specific thing I do not want to see in XMPP:
> >  >> 
> >  >> 
> >  >> 
> >  >> 
> >  >> 
> >  >> with the relative order of foo vs. bar elements (mind, the order
> > of the bar
> >  >> elements to each other mattering is ok!) mattering.
> >  >
> >  >
> >  > I am with you here, with one additional constraint: I think it is
> > relevant where those elements are placed in the stanza.
> >  >
> >  > Element ordering is something that is often overlooked in XMPP
> > land. My stance is that the order of extension elements *which are
> > direct children of a stanza* should be irrelevant (and probably can
> > be unstable, e.g., because it was modified by a hop). However,
> > extension elements are free to impose order constraints of their
> > sub-elements. As it was previously pointed out, we already have such
> > elements.
> >  >
> >  > I wonder if we have consensus for
> >  >
> >  > """
> >  > The XML element order is irrelevant for elements that a direct
> > children of a stanza, and for all other elements unless explicitly
> > specified.
> >  > “""
> > 
> > I think the reverse of part two is true, actually.
> > 
> > I think the order of stanza children isn’t relevant (extensions can
> > be put in any order),
> 
> At least we agree on something. :)
> 
> > but within an extension the order should be
> > maintained unless otherwise explicitly stated.
> > 
> > /K
>  > 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 - in rare cases - remove
>  > them too, but that's really because those extensions are specifically
>  > designed for it, like  or security labelling.
>  >
>  > Otherwise, I don't really understand why anyone would think reordering
>  > things inside a stanza would be a good idea by default. The fact it
>  > doesn't usually cause a problem is neither an indicator that it cannot,
>  > nor an indicator that it should, and given XML has *always* had order as
>  > a significant thing, I don't understand why "we've never explicitly said
>  > you can't" should be taken as an indicator that therefore you can.
>  >
>  > So broadly, Florian, not consensus from me.
> 
> I had my fancy XMPP client developer goggles on when I wrote this. It 
> occurred to me that you and Kev are talking about maintain

Re: [Standards] XML Element Ordering

[Kevin Smith]

On 17 Feb 2021, at 18:42, Florian Schmaus  wrote:
> 
> On 2/16/21 4:14 PM, Jonas Schäfer wrote:
>> I think this is the best place in the thread to reply with all my thoughts.
>> Vote change to -0 (or +1 with additional fixes) instead of -1 inline.
>> On Sonntag, 14. Februar 2021 21:12:17 CET Florian Schmaus wrote:
>>> Eventually, this is a situation where we cannot avoid that somebody
>>> needs to change their code. We need to weigh in the effects of the three
>>> options:
>>>A: clearly state that the order is not guaranteed
>>>B: clearly state that the order is guaranteed
>>>C: state that it should be sent in order, but recipients must be able
>>> to process in any order
>> You are right. You were also right about what you said in reply to my other
>> email about OrderedMap existing in Python (even being the default since some
>> versions).
>> However, here is a specific thing I do not want to see in XMPP:
>> 
>> 
>> 
>> 
>> 
>> with the relative order of foo vs. bar elements (mind, the order of the bar
>> elements to each other mattering is ok!) mattering.
> 
> 
> I am with you here, with one additional constraint: I think it is relevant 
> where those elements are placed in the stanza.
> 
> Element ordering is something that is often overlooked in XMPP land. My 
> stance is that the order of extension elements *which are direct children of 
> a stanza* should be irrelevant (and probably can be unstable, e.g., because 
> it was modified by a hop). However, extension elements are free to impose 
> order constraints of their sub-elements. As it was previously pointed out, we 
> already have such elements.
> 
> I wonder if we have consensus for
> 
> """
> The XML element order is irrelevant for elements that a direct children of a 
> stanza, and for all other elements unless explicitly specified.
> “""

I think the reverse of part two is true, actually.

I think the order of stanza children isn’t relevant (extensions can be put in 
any order), but within an extension the order should be maintained unless 
otherwise explicitly stated.

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

Re: [Standards] Important change of process for changes to XEPs under control of the XMPP Council

[Kevin Smith]

On 17 Feb 2021, at 16:49, Peter Saint-Andre  wrote:
> 
> On 2/17/21 9:42 AM, Jonas Schäfer wrote:
>> Change proposals to XEPs which 
>> are under the control of Council do not get put on the Council agenda before 
>> there has been a thread on the standards mailing list.
> 
> This seems reasonable.
> 
> By "XEPs which are under the control of Council" do we mean specs that
> have a status of Draft, Final, or Active (well, I suppose also
> Deprecated and Obsolete)?

I believe that to be the case. It came from a discussion about Council not 
wanting to decide which things should be taken to list before they vote on 
them, so this forces the issue.

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

Re: [Standards] Council Minutes 2021-02-03

[Kevin Smith]

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 me how you tell if whitespace is 
> truly insignificant - those are all OK, though unexpected.


Well, kinda ok. Not all namespace prefixing is legal in 6120, and preserving it 
is a SHOULD.

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

Re: [Standards] Explicitly require SRV RRs / XEP-0156 in compliance suites?

[Kevin Smith]

On 10 Feb 2021, at 09:31, Florian Schmaus  wrote:
> The purpose of the compliance suites is to incentivize implementing certain 
> features *and* go guide new developers towards things worth implementing. 
> Hence, do we really want that clients can claim XEP-0423's "Core Client" 
> compliance level (2000) without supporting SRV?

As long as 6120 is in the compliance suites they cannot do this because, as 
Dave notes, that’s part of 6120. It doesn’t need a MUST to make that so.

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

Re: [Standards] Proposed XMPP Extension: DOAP usage in XMPP

[Kevin Smith]

On 13 Jan 2021, at 17:29, Dave Cridland  wrote:
> 
> 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 4.2 contains new bits of XML and - presumably - 
> would be developed via a Standards Track process.
> 
> Procedural: It's something the XSF should do (ie, receive the DOAP files and 
> process them somehow).
> 
> I think there are arguments for all of these, and I've not made up my mind.
> 
> What do people think?

I think Informational is best. It isn’t really part of the XSF procedures, so 
Procedural seems off. It’s also not part of the standards that we are producing 
for the sake of XMPP interoperability, so Standards Track seems like it would 
be confusing. That leaves Informational, and I can’t see any argument against 
that particularly.

(Passing no judgement on whether it *should* be a XEP, merely that if it is to 
be a XEP I think Informational makes sense)

/K

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

Re: [Standards] MUC Mention Notifications

[Kevin Smith]

On 23 Dec 2020, at 15:16, Marvin W  wrote:
> 
> Hi there,
> 
> I actually was working on something with partially overlapping goals,
> that is
> a) being notified for relevant groupchat messages via push
> notifications. This is mostly relevant for iOS push notifications (at
> least as far as I understood during last summit).
> b) signal to recipient that a message is important to notify about (for
> example, when out of office, still notify for the really important
> things). This is a feature some of you may know from Slack.
> 
> I was first thinking to base this around mentions as well, but that
> would mostly work for a, not b (at least not how b is realized in Slack).
> 
> I thus was to suggest a much more generic approach, that is to add a new
> element  to the message
> (completely independent of any use of mentions/references). Jid could be
> left out in direct chats, in MUCs can point to the real jid, member jid
> or room jid (equivalent to @channel mentioning), also there might be
> value in an optional priority="high" attribute to signal higher message
> priority.
> 
> Your usecase of delivering messages to non-present MUC users seems to
> fit into this schema. Also, adding server-side meaning to something that
> is mostly formatting (mentions) seems a little bit weird to me.
> 
> Another advantage of the  element approach is that it also works
> for server-side processing in e2ee message (without leaking relevant
> message details) as long as the  is not e2e encrypted (which it
> shouldn't be as it's also meant to be processed by servers).

I like this, I think this is a useful discussion to be having.

I think there’s merit in something combining these two approaches. I think the 
idea of being able to specify that it’s meant to generate a notification is 
useful (and I can see why Slack’s ‘also say I want to override notification 
silencing’ would be useful - although for that to work as in Slack the sender 
has to be able to discover that the recipient has disabled notifications, and I 
suggest that a ‘please notify even if notifications are turned off’ flag would 
be useful if we go that route, as this processing is going to be 
recipient-side). Also useful is everything-under-the-Sun’s ability to @everyone 
and @groups, which a notify mechanism nicely addresses. Also useful is 
referencing a particular bit of the message to be the markup, like in 
references(mentions). 

/K

> Marvin
> 
> 
> On 18.12.20 18:00, JC Brand wrote:
>> Hi all
>> 
>> I've submitted a PR for a new protoXEP: MUC Mention Notifictions
>> 
>> https://github.com/xsf/xeps/pull/1022
>> 
>> The goal is to document how someone who's affiliated, but not currently
>> present in a MUC might receive notifications when he/she is mentioned
>> inside that MUC.
>> 
>> For the concept of "mentions", XEP-0372 references are used.
>> 
>> To enable this feature, I've opted for a configuration setting in the MUC.
>> 
>> Apparently Tigase already has a similar feature to this protoXEP and
>> relies on letting the user opt-in when registering a nickname with the MUC.
>> 
>> Maybe someone from Tigase can comment on the particulars of that. My
>> understanding is that this necessitates the ability to self-register in
>> a MUC, which IMO adds a hurdle to adoption of this feature.
>> 
>> Regards
>> JC
>> 
>> 
>> ___
>> 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
> ___

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

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

[Kevin Smith]

On 8 Dec 2020, at 22:13, Sam Whited  wrote:
> I still think the data on the wire should describe the other data on the
> wire, not some higher- level "decoded” representation

Agree 100%. References et al. need to calculate how the data are going to be 
encoded on the wire, not some high level abstraction. Decoding TLS is very 
expensive and I shouldn’t have to do that before I’m able to work out what the 
text being referenced is.

;)

/K



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

Re: [Standards] Stickers

[Kevin Smith]

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, though.

I think we used to believe that. In the face of carbons and MAM, I it’s no 
longer true (and maybe it never was).

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

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

[Kevin Smith]

On 4 Dec 2020, at 16:41, Sam Whited  wrote:
> Bytes are the only way to not make assumptions about the libraries,
> languages, etc. being used.

Except that bytes are making significant assumptions about the libraries and 
languages being used. It’s assuming that what you get out of your parser 
corresponds to the same bytes that were on the stream, which seems particularly 
unlikely in languages that aren’t C at heart (C, C++, Go…).

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

Re: [Standards] [Council] XMPP Council Agenda 2020-10-07

[Kevin Smith]

On 7 Oct 2020, at 12:38, Dave Cridland  wrote:
> Can we put Reactions on the agenda for adoption

I think the previous stance of Council - that it shouldn’t go around accepting 
previously rejected XEPs just because the originally objecting Council member 
is no longer on Council unless the presented objections have also been 
addressed (or some other state change causes there to be a materially different 
consideration) is sound, and should be followed.

In the case of Reactions, I was the originally objecting Council member so with 
my currently somewhat tatty Old Council hat on suggest that people with their 
shiny Current Council hats reconsider the submission. I don’t actually think 
that the situation has materially changed other than that a way forward has 
been presented in terms of Fastening and MAM-FC to address the concerns, but 
not adopted, and so my original objections still stand, but it would be worth 
Council having a consider of whether they agree with them sufficiently to 
persist the block themselves, rather than just because I did. That is “please 
consider my vote, which I don’t have, to be -0 with significant objections but 
no veto”.

Ideally without calling me dumb.

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

Re: [Standards] XEP-0430 updates

[Kevin Smith]

On 7 Oct 2020, at 03:35, Tedd Sterr  wrote:
> 
> > * There is a reference to MAM-FC, which I'll remove on the basis that I 
> > don't
> >   see any interest in trying to solve that problem generically from anyone 
> > but me
> 
> General solutions should be preferred where possible, though that can 
> sometimes result in more complexity than necessary in an attempt to stay as 
> general possible (not to imply this is.)
> Aside from one vocal opposition, is there active disinterest or is it 
> 'Silence Is Acceptance' and there simply isn't enough to complain about yet?

MAM-FC is on the list-to-implement-when-the-chance-arises for us.

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

Re: [Standards] PR#983: XEP-0060: Disallow '=' and '; ' in NodeIDs to allow use in URIs and refer to PRECIS Stringprep

[Kevin Smith]

On 22 Sep 2020, at 17:05, Jonas Schäfer  wrote:
> 
> Re: https://github.com/xsf/xeps/pull/983
> 
> I have a very simple technical question: Why do this instead of ensuring that 
> special characters are URL-encoded for the node ID in the PubSub URIs? This 
> seems to be fixing the issue at the wrong end, introducing an arbitrary and 
> new 
> restriction due to a potential issue in a downstream usage.

This (Jonas’s comment) sounds right to me. Bits of URIs need to be 
appropriately encoded AFAICS.

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

Re: [Standards] MUC-PMs or direct messages in non-anon rooms (XEP-0045)

[Kevin Smith]

On 5 Aug 2020, at 16:47, Georg Lukas  wrote:
> 
> Hi,
> 
> MUC-PMs are prone to errors, have weird interactions with Carbons, MAM
> and other specs and require the recipient to be in the room at the time
> of delivery. While I don't want to abolish them altogether, there is a
> compelling IM use case for direct messages to replace PMs: non-anonymous
> MUCs (which have gained significant popularity in times of OMEMO).
> 
> Late last year, I tried to sneak in normative language into XEP-0045 to
> RECOMMEND this behavior:
> 
>> Private messages are meant to hide a user's real JID from occupants
>> they are talking to. In non-anonymous rooms, a client SHOULD NOT
>> resort to private messages, but instead make use of direct messages to
>> the other occupant's real bare JID. However, if the user knows the
>> other JID for other reasons, e.g.  because they are a room admin,
>> private messages SHOULD be used anyway.
> 
> https://github.com/xsf/xeps/pull/854
> 
> However, Council was not amused by the strict wording:
> https://mail.jabber.org/pipermail/standards/2019-November/036630.html
> 
> One of the problems brought up was that direct messages might be
> blocked, whereas PMs will pass through because of the previous directed
> presence to the MUC. I'm not sure if there is a(n easy) way to solve
> this problem, but I still think it's worth discouraging IM clients from
> sending PMs in non-anonymous MUCs.
> 
> I've seen it multiple times that users were confused why a "chat with
> ge0rg" opened from a MUC is different from a "chat with ge0rg" opened
> from the roster. It would be great to unify those.
> 
> Are there any other corner cases that need to be considered?
> 
> Is it worth trying to get this as a normative change, or rather as
> informative guidance for IM client developers?

I would love to be able to tell clients that they should use real JIDs when 
available, but with the current state that would break things (as we found out 
when we made that change (I note that the change is still in, although it has 
broken things. Jury’s out on whether to revert it). I think that if we were to 
add a little ‘deanonymising’ protocol exchange, that might be enough to detect 
the situations where it’ll fail, so a client could fall back to PMs.

The ones off the top of my head (of which I’ve seen (1) in the wild), although 
I suspect there are others:

1) The other user may not allow messages from users they don’t share presence 
with. So things will bounce.
2) The user may not be able to route to the other user’s server, only through 
the MUC (unusual but not impossible either in odd network failures, or trunking 
configurations).
3) A malicious MUC might cause a user to send messages somewhere they shouldn’t 
by advertising the wrong real JID. How much this is an imagined threat, I’m not 
sure, but e.g. causing audit logging of someone trying to send messages 
somewhere they shouldn’t might get people in hot water.

I agree this is a problem worth solving. I believe the issues (at least the 
first) are significant enough that telling people to do it anyway is 
insufficient.

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

Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)

[Kevin Smith]

Hi Jonas,

I agree with Sam that it is very desirable for PRs to be accepted on github, 
for the sake of contribution to the XSF - I *really* would not like to see the 
repo move. If it’s at all practical for us to stay there, I think that is the 
best option.

That said, if there is no other practical alternative to moving, I consider 
having a working Editor process/team to be the more important consideration. 
Contributions on GitHub that are never processed because we have no Editors 
willing to work with that tooling is worse than fewer contributions on GitLab 
that are handled. We are a volunteer org.

/K

> On 14 Jun 2020, at 17:00, Jonas Schäfer  wrote:
> 
> On Sonntag, 14. Juni 2020 17:17:44 CEST Sam Whited wrote:
>> Ahh, I see, this is a Docker Hub issue. I completely agree that Docker
>> Hub has not been a success. It is also quite easy to build Docker
>> images with other CI platforms though while remaining on GitHub (ie. I
>> think you already submitted a PR to use a GitLab CI build). I've built
>> Docker images with GitHub actions (my preferred solution), Sourcehut
>> builds (would be my preferred solution, except that it's still very
>> *very* alpha and I'd hate for people to have yet another account just
>> for CI), and GitLab CI in fact (which I was not a fan of but I'm not
>> the one configuring it or having to deal with it for now so that
>> doesn't really matter).
> 
> That’s a good suggestion which did not occur to me, thank you.
> 
> I’ll evaluate if we can integrate GitLab CI with GitHub sufficiently to 
> achieve the goals. This evaluation will at first happen independently of the 
> XSF repositories.
> 
> kind regards,
> Jonas___
> 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] Council Minutes 2020-05-27

[Kevin Smith]

On 1 Jun 2020, at 19:52, Kevin Smith  wrote:
> 
> I think all the discussed ideas have merit, although possibly not for the 
> obvious reasons:
> 
> I think there is merit in being able to mark some bits of a message as 
> skipping styling. This is conceptually a hack (IMO), but it’s a hack that has 
> mileage and we should follow this train of thought through.
> 
> I think there is merit in “This message does not contain styling, don’t 
> bother parsing for it” for multiple reasons, performance being as obvious 
> one, but possibly more usefully it’s very simple for an entity that will 
> never send styling (e.g. a bot) to shove this on all messages and not have to 
> (implement support to) parse the outgoing message, work out where the 
> style-breaking-character-hack needs to be applied, and apply them.
> 
> I think there is merit in “This message *does* contain styling, and you can 
> skip the markups, because I’ll have hacked them away from where they 
> shouldn’t be applied”. This is opt-in where the opt-in is actually providing 
> value, I think.

And that can be applied to screenreaders, or whatever accessibility services, 
so it can try to avoid reading out the markup. It doesn’t make the world 
perfect, but it means that for that part of the world that does implement 393 
including the (currently hypothetical) opt-in, at least screen reader-aware 
clients can have a better time of it when incoming messages are marked with the 
opt-in annotation.

So I’m not pretending that clients won’t send without such an opt-in, or that a 
receiver should assume it’s not marked up because it doesn’t see the opt-in, 
but I don’t think it’s worthless to have it.

/K

> 
> /K
> 
>> On 1 Jun 2020, at 18:05, Sam Whited > <mailto:s...@samwhited.com>> wrote:
>> 
>> Sorry, last rapid reply to my own email, I promise:
>> 
>> Apparently there is U+2060: word joiner which is the exact same thing as
>> a ZWSP except that it implies no line breaks. This has just about
>> exactly the semantics we want, and seems like it would be a good
>> candidate for how you disable styling on a specific piece of text.
>> 
>> I think I would prefer to have this over something that has to be
>> namespaced and registered. It's more flexible, would make it easier to
>> implement eg. a toolbar with bold and italic buttons (things get styled
>> by default if you type them, if you highlight the whole thing and remove
>> the styling it could cycle through just removing the styling but leaving
>> the *'s, or removing the *'s etc.
>> 
>> What do others think?
>> 
>> —Sam
>> 
>> On Mon, Jun 1, 2020, at 12:59, Sam Whited wrote:
>>> On Mon, Jun 1, 2020, at 11:58, Marvin W wrote:
>>>> PS: As a sending client you can already opt-out using a hack: By
>>>>prepending the opening (and, if needed, closing) styling
>>>>directive with zero-width space (U+200B)
>>> 
>>> I hadn't actually thought of this. I'll need to think about it more,
>>> but we might recommend this in the spec since this is the exact use
>>> case zero width spaces are for (things that are word boundaries but
>>> where spaces don't necessarily go, between characters that shouldn't
>>> be put together in connected scripts, etc. My only concern would be
>>> that they also have the meaning "you can add a soft break here" which
>>> is probably *not* what you want in this case.
>>> 
>>> I'll think about it more, but this is definitely at least close to the
>>> point of a zero-width space and might be worth documenting.
>>> 
>>> —Sam
>>> 
>>> 
>>> --
>>> Sam Whited
>> 
>> -- 
>> Sam Whited
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards 
>> <https://mail.jabber.org/mailman/listinfo/standards>
>> Unsubscribe: standards-unsubscr...@xmpp.org 
>> <mailto:standards-unsubscr...@xmpp.org>
>> ___
> 
> ___
> 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] Council Minutes 2020-05-27

[Kevin Smith]

I think all the discussed ideas have merit, although possibly not for the 
obvious reasons:

I think there is merit in being able to mark some bits of a message as skipping 
styling. This is conceptually a hack (IMO), but it’s a hack that has mileage 
and we should follow this train of thought through.

I think there is merit in “This message does not contain styling, don’t bother 
parsing for it” for multiple reasons, performance being as obvious one, but 
possibly more usefully it’s very simple for an entity that will never send 
styling (e.g. a bot) to shove this on all messages and not have to (implement 
support to) parse the outgoing message, work out where the 
style-breaking-character-hack needs to be applied, and apply them.

I think there is merit in “This message *does* contain styling, and you can 
skip the markups, because I’ll have hacked them away from where they shouldn’t 
be applied”. This is opt-in where the opt-in is actually providing value, I 
think.

/K

> On 1 Jun 2020, at 18:05, Sam Whited  wrote:
> 
> Sorry, last rapid reply to my own email, I promise:
> 
> Apparently there is U+2060: word joiner which is the exact same thing as
> a ZWSP except that it implies no line breaks. This has just about
> exactly the semantics we want, and seems like it would be a good
> candidate for how you disable styling on a specific piece of text.
> 
> I think I would prefer to have this over something that has to be
> namespaced and registered. It's more flexible, would make it easier to
> implement eg. a toolbar with bold and italic buttons (things get styled
> by default if you type them, if you highlight the whole thing and remove
> the styling it could cycle through just removing the styling but leaving
> the *'s, or removing the *'s etc.
> 
> What do others think?
> 
> —Sam
> 
> On Mon, Jun 1, 2020, at 12:59, Sam Whited wrote:
>> On Mon, Jun 1, 2020, at 11:58, Marvin W wrote:
>>> PS: As a sending client you can already opt-out using a hack: By
>>>prepending the opening (and, if needed, closing) styling
>>>directive with zero-width space (U+200B)
>> 
>> I hadn't actually thought of this. I'll need to think about it more,
>> but we might recommend this in the spec since this is the exact use
>> case zero width spaces are for (things that are word boundaries but
>> where spaces don't necessarily go, between characters that shouldn't
>> be put together in connected scripts, etc. My only concern would be
>> that they also have the meaning "you can add a soft break here" which
>> is probably *not* what you want in this case.
>> 
>> I'll think about it more, but this is definitely at least close to the
>> point of a zero-width space and might be worth documenting.
>> 
>> —Sam
>> 
>> 
>> --
>> Sam Whited
> 
> -- 
> Sam Whited
> ___
> 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] form field types: text-multi vs list-multi with

[Kevin Smith]

Flo,

I think you’ve carefully (and silently) snipped out the most relevant half of 
my message, so I repeat what I said before.

1) I think we can not reasonably update XEP-0004 to change the meaning of 
text-multi at this point (and, as I said, it is not clear to me if anyone is 
suggesting that or not).
2) If XEPs want to change the meaning of text-multi for specific cases in a 
negotiated scope, they can do so.

i.e. (2)-> if MAM uses text-multi differently, in MAM-namespaced queries, it’s 
reasonable to do so. This is consistent with what XEP-0122 does in allowing 
 to change the semantics for list-multi/list-single that were defined in 
XEP-0004. It would be functionally equivalent to saying that MAM uses a 
text-multi field with one id per line.

/K

> On 13 May 2020, at 13:50, Florian Schmaus  wrote:
> 
> On 5/13/20 1:50 PM, Kevin Smith wrote:
>> On 13 May 2020, at 03:40, Peter Saint-Andre  wrote:
>>> 
>>> We might want to face reality
>>> and allow text-multi to treat each line as semantically independent.
>> 
>> Sadly, I don’t think it would just be ‘facing reality’ to say that 
>> text-multi isn’t multi-line text - there are implementations (every library 
>> I’ve worked with, I think) that treats text-multi as a multi-line string 
>> (i.e. in support of what xep4 requires).
> As soon as such a library where to implement e.g. PubSub collection
> nodes, it has to expose the individual values of a text-multi field in a
> robust way. And it is not like doing so would mean that you have to
> loose support for what xep4 requires.
> 
> Because surely those libraries could be easily extended to expose the
> text-multi values, in addition to a single multi-line string, as a list
> of strings.
> 
> 
>> I am sympathetic to the argument that we’ve gotten into a mess, but I don’t 
>> think getting out of it (given that 4 is Final) would be as simple as xep 4 
>> changing semantics for text-multi - it’s not clear to me if that’s what 
>> being suggested, but if it is I think it would be painful.
> 
> I do not see where we change the semantics of text-multi here.
> 
> XMPP (and protocols in general) often gets criticized for being
> over-engineerd and complex. And, while I do not like those who scream
> "over-engineerd and complex" every two seconds, this discussion appears
> to be a prime example what can go wrong.
> 
> We have currently two options to carry multiple values from A to B in
> xep4 data forms:
> - one that requires one XEP
>  text-multi: xep4
> - another one that requires *two* XEPs
>  list-multi + , xep4 + xep122
> 
> Obviously text-multi, requiring only one XEP, is desirable. In fact, it
> so natural that existing XEPs and ProtoXEPs in inbox/ use it for exact
> that case.
> 
> Yet, there are attempts to argument that text-multi can not be used
> because of some implementations do not allow for it. But I fail to see
> how that can be an argument: implementations can be adjusted.
> Furthermore, it appears *trivial* to extend those existing
> implementations to allow for it. And that would not even break backwards
> compatibility, and hence does not even need to be negotiated.
> 
> Fields of the type text-multi contain as a list of textual values. Even
> if the initial motivation was to allow for portable multi-line strings,
> I do not see any reason why we should not continue to use it to
> transport multiple textual values (e.g., the IDs of the MAM messages we
> want to retrieve).
> 
> MAM currently is a shining star of a reasonably well-designed and simple
> protocol. I hope we keep it that way.
> 
> - Florian
> 
> ___
> 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] form field types: text-multi vs list-multi with

[Kevin Smith]

On 13 May 2020, at 03:40, Peter Saint-Andre  wrote:
> 
> We might want to face reality
> and allow text-multi to treat each line as semantically independent.

Sadly, I don’t think it would just be ‘facing reality’ to say that text-multi 
isn’t multi-line text - there are implementations (every library I’ve worked 
with, I think) that treats text-multi as a multi-line string (i.e. in support 
of what xep4 requires).

I am sympathetic to the argument that we’ve gotten into a mess, but I don’t 
think getting out of it (given that 4 is Final) would be as simple as xep 4 
changing semantics for text-multi - it’s not clear to me if that’s what being 
suggested, but if it is I think it would be painful.

That said, XEPs building on top of XEPs by modifying or expanding underlying 
semantics (or syntax) by negotiation /is/ ok.

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

Re: [Standards] Proposed XMPP Extension: Quick Response

[Kevin Smith]

On 22 Apr 2020, at 08:10, Daniel Gultsch  wrote:
> 
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>> 
>> Title: Quick Response
>> Abstract:
>> Quickly respond to automated messages.
>> 
>> URL: https://xmpp.org/extensions/inbox/quick-response.html
>> 
>> The Council will decide in the next two weeks whether to accept this
>> proposal as an official XEP.
> 
> To make it quick I’ll vote yes in our Council meeting this afternoon.
> I think it's good enough and interesting enough for an experimental
> XEP.

I have very mixed feelings on the protoXEP. It seems like a non-extensible 
solution to a fraction of a larger problem, which is not great. Equally, 
sometimes just solving the problem at hand is better than not solving a 
bigger/more general problem.

The appeal of the feature is obvious.

> Personally I’m finding myself broadly agreeing with what Matthew wrote.
> * UX of data forms is horrible for 'simple' things like this
> * We should consider joining response and action; (That will probably
> mean getting rid of response)
> * We should consider sending the action-accepts as IQs. Having just
> implemented Jingle Message Initiation the uncertainty that comes with
> messages (I’m finding myself trying to track them via receipts) is not
> ideal for 'triggering actions' - Certainly I would like to know
> whether my merge action has actually been merged.
> 
> Getting rid of response and making action responses (just the
> responses) IQ, will probably also give a hint at the direction people
> want to take the UI in. (Meaning no; you won't see your response as a
> message; but instead button turns into spinning wheel while IQ is in
> flight; and gets a checkmark or becomes gray one success)

I think it needs to be messages because you expect this to be part of the 
normal chat flow, and therefore to end up in your archive.

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

Re: [Standards] XEP-0313 for transports

[Kevin Smith]

On 26 Feb 2020, at 17:24, Jonas Schäfer  wrote:
> 
> On Mittwoch, 26. Februar 2020 16:40:06 CET Ivan Vučica wrote:
>> Hi,
>> 
>> Sometimes, protocols backing transports may support querying for an
>> archive similar to how it's done with XEP-0313.
>> 
>> tl;dr Can querying archives on non-own, non-MUC, non-pubsub JID for
>> 1:1 chats be standardized? Can it be standardized that server
>> implementations don't have to support date-based queries?
>> 
>> 
>> 
>> 1. XEP-0313 is specified for archives maintained by the user's own
>> server. Section 3.3 doesn't specify that a client can query a remote
>> JID for the archive, which would be useful for transports. It does
>> specify it for MUC and pubsub, but not for 1:1.
>> 
>> Here I'm mainly interested: Are there clients that would query a
>> remote JID for the archive today, despite XEP-0313 not requiring
>> servers nor clients to support this? Under which conditions would they
>> do this?
> 
> Ugh. No, I don’t think any client would query a remote JID for 1:1 archives. 

Why not? MAM’s just a mechanism for querying archives for messages, surely it 
shouldn’t matter where the archive is?

As concrete examples of when it might make sense to query non-MUC, non-private 
archives:
* An appropriately privileged user querying the archives of other organisation 
members (e.g. HR in case of harassment cases)
* A system that presents a single outgoing JID that is controlled by several 
users (e.g. shift workers handling a support address)

While it might not be a standard personal IM-client feature, I don’t think that 
means it’s not valid, or that we need to disallow it.

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

Re: [Standards] Council Minutes 2020-02-26

[Kevin Smith]

On 4 Mar 2020, at 15:00, Dave Cridland  wrote:
> 
> 
> 
> On Wed, 4 Mar 2020 at 10:23, Daniel Gultsch  > wrote:
> Am So., 1. März 2020 um 01:14 Uhr schrieb Tedd Sterr  >:
> > 4b) Advance XEP-0198 (Stream Management) - 
> > https://xmpp.org/extensions/xep-0198.html 
> > 
> > Georg is unsure, but it's doing its job, expect for the unclear resume host 
> > connection mechanism.
> > Dave noted a comment on s2s, possibly from MattJ, which he has yet to 
> > consider, but s2s is under-specified at best.
> > Jonas doesn't think it's possible to move forward if there are zero s2s 
> > implementations; Dave doesn't think any were explicitly mentioned, which 
> > would itself be a procedural reason for not advancing.
> > Zash mentions that mod_smacks for Prosody does support XEP-0198 in s2s, 
> > though not resumption, and it's disabled by default - Dave thinks it's 
> > unclear what resumption would do for s2s.
> >
> > Jonas: [on-list] (yet to catch up on the thread)
> > Daniel: -1 (people have brought up valid, but fixable, concerns)
> > Zash: -1 (haven't read that thread yet)
> > Dave: -1 (lack of clarity on s2s implementations)
> > Georg: -1
> 
> 
> Do we have a way forward with this that isn’t just ignoring it?
> Are any of the authors who are still active in the community (looking
> at you Matt and Dave) willing to incorporate whatever the consensus is
> on how to proceed?
> 
> 
> Sure.
>  
> Do we want to eliminate s2s from the XEP?
> 
> 
> I don't know. Mostly, I don't know if anyone implements it. I'm pretty sure 
> M-Link does on S2S, because I think I put it there - but whether anything 
> else does I don't know.
>  
> Are server developers interested in implementing 198 s2s?
> 
> 
> I might, in Metre. But I'd definitely only do acks, not resumption - I don't 
> think there's any value on resumption for S2S.

I think there is value actually (despite M-Link not doing it) because it, in 
principle, allows retransmission of stanzas without duplication.

/K

>  
> Personally I would hope for the latter. But I’m not a server
> developer; Maybe it's more complicated or unnecessary as it seems.
> 
> 
> >
> > 4c) Advance XEP-0368 (SRV records for XMPP over TLS) - 
> > https://xmpp.org/extensions/xep-0368.html 
> > 
> > Travis Burtrum promised to make some changes to XEP-0368, mostly clerical, 
> > and changing a SHOULD to a MAY.
> >
> > Jonas: -1 (changes need to be made)
> > Georg: -1 (liked the proposed wording)
> > Zash: [on-list]
> > Daniel: [on-list] (not caught up on that)
> 
> -1. I think there is consensus for some changes.
> ___
> 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 
> 
> ___

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