From 8dd1a2d904076eea657f4e3995bb7dba957cbe79 Mon Sep 17 00:00:00 2001 From: Kim Alvefur Date: Sun, 24 Nov 2024 12:59:30 +0100 Subject: [PATCH 1/4] Typo: is is -> is --- xep.ent | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep.ent b/xep.ent index 322bc7a3..cd540c5e 100644 --- a/xep.ent +++ b/xep.ent @@ -292,7 +292,7 @@ THE SOFTWARE. International Telecommunication Union (ITU) The International Telecommunication Union develops technical and operating standards (such as H.323) for international telecommunication services. For further information, see <http://www.itu.int/>." > OASIS OASIS is a not-for-profit, international consortium that drives the development, convergence and adoption of e-business standards. For further information, see <http://www.oasis-open.org/>." > Open Mobile Alliance (OMA) The Open Mobile Alliance is the focal point for the development of mobile service enabler specifications, which support the creation of interoperable end-to-end mobile services. For further information, see <http://www.openmobilealliance.org/>." > -StartCom Free SSL Certification Authority The StartCom Free SSL Certification Authority is a certification authority that offers free or low-cost X.509 certificates to Internet user and server administrators. It is is also the root CA for the XMPP Intermediate Certification Authority run by the XMPP Standards Foundation. For further information, see <http://cert.startcom.org/>." > +StartCom Free SSL Certification Authority The StartCom Free SSL Certification Authority is a certification authority that offers free or low-cost X.509 certificates to Internet user and server administrators. It is also the root CA for the XMPP Intermediate Certification Authority run by the XMPP Standards Foundation. For further information, see <http://cert.startcom.org/>." > XMPP Working Group The XMPP Working Group was created by the Internet Engineering Task Force to define an adaptation of the base Jabber protocols that could be considered an IETF-approved instant messaging and presence technology. For further information, see <https://datatracker.ietf.org/wg/xmpp/charter/>." > World Wide Web Consortium (W3C) The World Wide Web Consortium defines data formats and markup languages (such as HTML and XML) for use over the Internet. For further information, see <http://www.w3.org/>." > From 0769f9b42e3b20c4f664ebd400c12cf0c9ea37f8 Mon Sep 17 00:00:00 2001 From: Kim Alvefur Date: Sun, 24 Nov 2024 13:00:08 +0100 Subject: [PATCH 2/4] XEP-0155: Typo: is is -> is --- xep-0155.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0155.xml b/xep-0155.xml index c5f1623f..75715987 100644 --- a/xep-0155.xml +++ b/xep-0155.xml @@ -669,7 +669,7 @@ PENDING o---------------+

If a party receives an XMPP presence stanza of type "unavailable" from the full JID &LOCALFULL; of the other party (i.e., the resource with which it has had an active session) during a session, the receiving party SHOULD assume that the other client will still be able to continue the session (perhaps it simply became "invisible", or it is persisting the state of the negotiated session until it reconnects and receives "offline" messages).

-

However, the receiving party MAY assume that the other client will not be able to continue the session. In general, if a party is not subscribing to the other party's presence then it will never assume the other party is is unable to continue a session. In that case it MUST explicitly terminate the session (see Terminating a Session) -- since its assumption could be incorrect. If after terminating the session the receiving party later receives available presence (i.e., a &PRESENCE; stanza with no 'type' attribute) from that same resource or another resource associated with the other party and the receiving party desires to restart the session, then it MUST initiate a new session (including a newly-generated ThreadID) with the other party. It MUST NOT renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in &xep0085;.)

+

However, the receiving party MAY assume that the other client will not be able to continue the session. In general, if a party is not subscribing to the other party's presence then it will never assume the other party is unable to continue a session. In that case it MUST explicitly terminate the session (see Terminating a Session) -- since its assumption could be incorrect. If after terminating the session the receiving party later receives available presence (i.e., a &PRESENCE; stanza with no 'type' attribute) from that same resource or another resource associated with the other party and the receiving party desires to restart the session, then it MUST initiate a new session (including a newly-generated ThreadID) with the other party. It MUST NOT renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in &xep0085;.)

When mapping instant messaging flows to SIP, implementations SHOULD adhere to &rfc7572;.

From 9c215039d4ecd46b634e4c6d47a37da1a1ed120e Mon Sep 17 00:00:00 2001 From: Kim Alvefur Date: Sun, 24 Nov 2024 13:00:46 +0100 Subject: [PATCH 3/4] XEP-0220: Typo: is is -> is --- xep-0220.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0220.xml b/xep-0220.xml index 626d6fa7..96ad1211 100644 --- a/xep-0220.xml +++ b/xep-0220.xml @@ -377,7 +377,7 @@ example example

On an outbound connection there are two different tasks:

    -
  1. Request authorization to send stanzas from a Sender Domain to a Target Domain, i.e., act as an Initiating Server in relation to a Receiving Server; this is is described under Section 2.1.1.
    2. +
  2. Request authorization to send stanzas from a Sender Domain to a Target Domain, i.e., act as an Initiating Server in relation to a Receiving Server; this is described under Section 2.1.1.
  3. Generate verification requests about the validity of dialback keys, i.e., act as a Receiving Server in relation to an Authoritative Server; this is described under Section 2.1.2.
From fd81a75e607aa7ce2a708f5db9f1cf1b2b934a27 Mon Sep 17 00:00:00 2001 From: Kim Alvefur Date: Sun, 24 Nov 2024 13:01:10 +0100 Subject: [PATCH 4/4] XEP-0493: Typo: is is -> is --- xep-0493.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0493.xml b/xep-0493.xml index 69cad5cc..5e3d95a5 100644 --- a/xep-0493.xml +++ b/xep-0493.xml @@ -334,7 +334,7 @@ for compatibility with OAuth 2.1 when it arrives.

Note well that this specification is about an XMPP account owner granting (i.e. authorizing) an application access to their account. It is not about -the account owner asserting any particular identity to the application, nor is +the account owner asserting any particular identity to the application, nor is it designed to assert the identity of the application towards the XMPP service.