Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix typo: is is #1401

Closed
wants to merge 4 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion xep-0155.xml
Original file line number Diff line number Diff line change
Expand Up @@ -669,7 +669,7 @@ PENDING o---------------+
</section2>
<section2 topic='Unavailable Presence' anchor='impl-unavail'>
<p>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).</p>
<p>However, the receiving party MAY assume that the other client will <em>not</em> be able to continue the session. <note>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.</note> In that case it MUST explicitly terminate the session (see <link url='#terminate'>Terminating a Session</link>) -- 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;.)</p>
<p>However, the receiving party MAY assume that the other client will <em>not</em> be able to continue the session. <note>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.</note> In that case it MUST explicitly terminate the session (see <link url='#terminate'>Terminating a Session</link>) -- 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;.)</p>
</section2>
<section2 topic='Mapping to SIP' anchor='impl-sip'>
<p>When mapping instant messaging flows to SIP, implementations SHOULD adhere to &rfc7572;.</p>
Expand Down
2 changes: 1 addition & 1 deletion xep-0220.xml
Original file line number Diff line number Diff line change
Expand Up @@ -377,7 +377,7 @@ example example
<section2 topic="Outbound Connection">
<p>On an outbound connection there are two different tasks:</p>
<ol>
<li>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.</li>
<li>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.</li>
<li>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.</li>
</ol>

Expand Down
2 changes: 1 addition & 1 deletion xep-0493.xml
Original file line number Diff line number Diff line change
Expand Up @@ -334,7 +334,7 @@ for compatibility with OAuth 2.1 when it arrives.</p>

<p>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.</p>

Expand Down
2 changes: 1 addition & 1 deletion xep.ent
Original file line number Diff line number Diff line change
Expand Up @@ -292,7 +292,7 @@ THE SOFTWARE.
<!ENTITY ITU "<span class='ref'><link url='http://www.itu.int/'>International Telecommunication Union (ITU)</link></span> <note>The International Telecommunication Union develops technical and operating standards (such as H.323) for international telecommunication services. For further information, see &lt;<link url='http://www.itu.int/'>http://www.itu.int/</link>&gt;.</note>" >
<!ENTITY OASIS "<span class='ref'><link url='http://www.oasis-open.org/'>OASIS</link></span> <note>OASIS is a not-for-profit, international consortium that drives the development, convergence and adoption of e-business standards. For further information, see &lt;<link url='http://www.oasis-open.org/'>http://www.oasis-open.org/</link>&gt;.</note>" >
<!ENTITY OMA "<span class='ref'><link url='http://www.openmobilealliance.org/'>Open Mobile Alliance (OMA)</link></span> <note>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 &lt;<link url='http://www.openmobilealliance.org/'>http://www.openmobilealliance.org/</link>&gt;.</note>" >
<!ENTITY SFSCA "<span class='ref'><link url='http://cert.startcom.org/'>StartCom Free SSL Certification Authority</link></span> <note> 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 &lt;<link url='http://cert.startcom.org/'>http://cert.startcom.org/</link>&gt;.</note>" >
<!ENTITY SFSCA "<span class='ref'><link url='http://cert.startcom.org/'>StartCom Free SSL Certification Authority</link></span> <note> 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 &lt;<link url='http://cert.startcom.org/'>http://cert.startcom.org/</link>&gt;.</note>" >
<!ENTITY XMPPWG "<span class='ref'><link url='https://datatracker.ietf.org/wg/xmpp/charter/'>XMPP Working Group</link></span> <note>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 &lt;<link url='https://datatracker.ietf.org/wg/xmpp/charter/'>https://datatracker.ietf.org/wg/xmpp/charter/</link>&gt;.</note>" >
<!ENTITY W3C "<span class='ref'><link url='http://www.w3.org/'>World Wide Web Consortium (W3C)</link></span> <note>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 &lt;<link url='http://www.w3.org/'>http://www.w3.org/</link>&gt;.</note>" >

Expand Down
Loading