Add information about CORS header usage and requirements
To make connection discovery work in web clients (including those hosted on a different domain) the host service SHOULD set appropriate CORS headers for Web Host Metadata files. The exact headers and values are out of scope of this document but may include: Access-Control-Allow-Origin, Access-Control-Allow-Methods and Access-Control-Allow-Headers.
+Due care has to be exercised in limiting the scope of Access-Control-Allow-Origin response header to Web Host Metadata files only.
+Access-Control-Allow-Origin header with a value of * allows JavaScript code running on a different domain to read the content of Web Host Metadata files. Special value * ensures that the request will only succeed if it is invoked without user credentials (e.g. cookies, HTTP authentication).
+It is possible that advertisement of alternative connection methods can introduce security vulnerabilities, since a connecting entity (usually a client) might deliberately seek to connect using the method with the weakest security mechanisms (e.g., no channel encryption or relatively weak authentication). Care needs to be taken in determining which alternative connection methods are appropriate to advertise.
Entities that use these connection methods MUST conform to the security considerations of each method, for example by preferring to use 'https' or 'wss' URLs that are protected using Transport Layer Security (TLS).
diff --git a/xep-0167.xml b/xep-0167.xml index 66d7a768..b341810e 100644 --- a/xep-0167.xml +++ b/xep-0167.xml @@ -1592,7 +1592,7 @@ Romeo Juliet to='romeo@montague.lit/orchard' type='set'>Fix use of incorrect namespace in examples
If the host supports Shared XML Editing over XMPP, it MUST return features of "urn:xmpp:sxe:0" and "urn:xmpp:jingle:transports:sxe" &NSNOTE;:
Namespace bump
+Namespace bump from mam:1 to mam:2
Added method for server to communicate the archive id
Incorporated editorial clarifications based on implementation feedback
Clarifications on the topics of message ordering, message deletion and use of the protocol for synchronization
diff --git a/xep-0333.xml b/xep-0333.xml index 31c31db6..86582e12 100644 --- a/xep-0333.xml +++ b/xep-0333.xml @@ -156,7 +156,7 @@If the sender determines that the recipient's client supports the Chat Markers protocol then it MAY send a Chat Marker or markable message to that full JID.
To prevent looping, an entity MUST NOT send a Chat Maker to mark up to a Chat Marker.
+To prevent looping, an entity MUST NOT send a Chat Marker to mark up to a Chat Marker.
Clients SHOULD use &xep0136; or &xep0313; to support offline updating of Chat Markers. Chat Markers SHOULD be archived, so they can be fetched and set regardless of whether the other users in a chat are online.
Messages MUST have an 'id' to use Chat Markers.
Messages MUST include the 'markable' element to use Chat Markers.
-Chat Markers MUST only move forward. If a Chat Maker is received for an earlier message than the current Chat Marker, it MUST be ignored by the client. +
Chat Markers MUST only move forward. If a Chat Marker is received for an earlier message than the current Chat Marker, it MUST be ignored by the client.
Chat Markers for unknown messages MUST be ignored by the client. A client MAY store the Chat Marker incase the associated message is retrieved later.
diff --git a/xep-0410.xml b/xep-0410.xml index f2e05a9b..dd444b71 100644 --- a/xep-0410.xml +++ b/xep-0410.xml @@ -29,6 +29,12 @@