From a20276973bb012b52043b4a69ccaa622e71f492e Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 14 Feb 2007 02:57:53 +0000 Subject: [PATCH] xhtml fixes git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@535 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0071.xml | 18 ++-- xep-0077.xml | 2 +- xep-0079.xml | 6 +- xep-0129.xml | 286 ++++++++++++++++++++++++++++----------------------- xep-0130.xml | 46 ++++----- xep-0139.xml | 6 +- xep-0162.xml | 2 +- xep-0163.xml | 2 +- xep-0171.xml | 4 +- xep-0204.xml | 6 +- 10 files changed, 206 insertions(+), 172 deletions(-) diff --git a/xep-0071.xml b/xep-0071.xml index 480eebe9..6fba2cd7 100644 --- a/xep-0071.xml +++ b/xep-0071.xml @@ -169,12 +169,12 @@

In the past, there have existed several incompatible methods within the Jabber community for exchanging instant messages that contain lightweight text markup. The most notable such methods have included derivatives of &w3xhtml; as well as of &rtf;.

Although it is sometimes easier for client developers to implement RTF support (this is especially true on certain Microsoft Windows operating systems), there are several reasons (consistent with the &xep0134;) for the &XSF; to avoid the use of RTF in developing a protocol for lightweight text markup. Specifically:

-
    +
    1. RTF is not a structured vocabulary derived from SGML (as is &w3html;) or, more relevantly, from XML (as is XHTML 1.0).
    2. RTF is under the control of the Microsoft Corporation and thus is not an open standard maintained by a recognized standards development organization; therefore the XSF is unable to contribute to or influence its development if necessary, and any protocol the XSF developed using RTF would introduce unwanted dependencies.

    Conversely, there are several reasons to prefer XHTML for lightweight text markup:

    -
      +
      1. XHTML is a structured format that is defined as an application of &w3xml;, making it especially appropriate for sending over Jabber/XMPP, which is at root a technology for streaming XML (see &xmppcore;).
      2. XHTML is an open standard developed by the &W3C;, a recognized standards development organization.
      @@ -182,7 +182,7 @@

      HTML was originally designed for authoring and presenting stuctured documents on the World Wide Web, and was subsequently extended to handle more advanced functionality such as image maps and interactive forms. However, the requirements for publishing documents (or developing transactional websites) for presentation by dedicated XHTML clients on traditional computers or small-screen devices are fundamentally different from the requirements for lightweight text markup of instant messages; for this reason, only a reduced set of XHTML features is needed for XHTML-IM. In particular:

      -
        +

        1. IM clients are not XHTML clients: their primary purpose is not to read pre-existing XHTML documents, but to read and generate relatively large numbers of fairly small instant messages.

        2. The underlying context for XHTML content in Jabber/XMPP instant messaging is provided not by a full XHTML document, but by an XML stream, and specifically by a message stanza within that stream. Thus the <head/> element and all its children are unnecessary. Only the <body/> element and some of its children are appropriate for use in instant messaging.

        3. The XHTML content that is read by one's IM client is normally generated on the fly by one's conversation partner (or, to be precise, by his or her IM client). Thus there is an inherent limit to the sophistication of the XHTML markup involved. Even in normal XHTML documents, fairly basic structural and rendering elements such as definition lists, abbreviations, addresses, and computer input handling (e.g., <kbd/> and <var/>) are relatively rare. There is little or no foreseeable need for such elements within the context of instant messaging.

          4. @@ -208,7 +208,7 @@ ]]>

          Technically speaking, there are three aspects to the approach taken herein:

          -
            +
            1. Definition of the <html/> "wrapper" element, which functions as an XMPP extension within XMPP <message/> stanzas.
            2. Definition of the XHTML-IM Integration Set itself in terms of supported XHTML 1.0 modules, using the concepts defined in &w3xhtmlmod;.
            3. A recommended "profile" regarding the specific XHTML 1.0 elements and attributes to be supported from each XHTML 1.0 module.
              4. @@ -334,7 +334,7 @@

              A full list of recommended style properties is provided below.

              CSS1 defines 42 "atomic" style properties (which are categorized into font, color and background, text, box, and classification properties) as well as 11 "shorthand" properties ("font", "background", "margin", "padding", "border-width", "border-top", "border-right", "border-bottom", "border-left", "border", and "list-style"). Many of these properties are not appropriate for use in text-based instant messaging, for one or more of the following reasons:

              -
                +
                1. The property applies to or depends on the inclusion of images other than those handled by the XHTML Image Module (e.g., the "background-image", "background-repeat", "background-attachment", "background-position", and "list-style-image" properties).
                2. The property is intended for advanced document layout (e.g., the "line-height" property and most of the box properties, with the exception of "margin-left", which is useful for indenting text, and "margin-right", which can be useful when dealing with images).
                3. The property is unnecessary since it can be emulated via user input or recommended XHTML stuctural elements (e.g., the "text-transform" property can be emulated by the user's keystrokes or use of the caps lock key)
                  4. @@ -514,7 +514,7 @@

                  The following rules apply to the generation and processing of XHTML content by Jabber clients or other XMPP entities.

                  -
                    +

                    1. XHTML-IM content is designed to provide a formatted version of the XML character data provided in the &BODY; of an XMPP &MESSAGE; stanza; if such content is included in an XMPP message, the <html/> element MUST be a direct child of the &MESSAGE; stanza and the XHTML-IM content MUST be understood as a formatted version of the message body. XHTML-IM content MAY be included within XMPP &IQ; stanzas (or children thereof), but any such usage is undefined. In order to preserve bandwidth, XHTML-IM content SHOULD NOT be included within XMPP &PRESENCE; stanzas; however, if it is so included, the <html/> element MUST be a direct child of the &PRESENCE; stanza and the XHTML-IM content MUST be understood as a formatted version of the XML character data provided in the &STATUS; element.

                    2. The sending client MUST ensure that, if XHTML content is sent, its meaning is the same as that of the plaintext version, and that the two versions differ only in markup rather than meaning.

                    3. XHTML-IM is a reduced set of XHTML 1.0 and thus also of XML 1.0. Therefore all opening tags MUST be completed by inclusion of an appropriate closing tag.

                      4. @@ -625,7 +625,7 @@

                      This could be rendered as follows:

                      Here's my .plan for today:

                      -
                        +
                        1. Add the following examples to XEP-0071:
                          • ordered and unordered lists
                            • @@ -783,11 +783,11 @@ That seems fine to me. -//JSF//DTD Instant Messaging with XHTML//EN ]]>

                            The fields of this FPI are as follows:

                            -
                              +
                              1. The leading field is "-", which indicates that this is a privately-defined resource.
                              2. The second field is "JSF" (an abbreviation for Jabber Software Foundation, the former name for the XMPP Standards Foundation), which identifies the organization that maintains the named item.
                              3. The third field contains two constructs: -
                                  +
                                  1. The public text class is "DTD", which adheres to ISO 8879 Clause 10.2.2.1.
                                  2. The public text description is "Instant Messaging with XHTML", which contains but does not begin with the string "XHTML" (as recommended for an XHTML 1.0 Integration Set).
                                  diff --git a/xep-0077.xml b/xep-0077.xml index 6ebd7e57..e5403f64 100644 --- a/xep-0077.xml +++ b/xep-0077.xml @@ -143,7 +143,7 @@

                                  In-band registration must make it possible for an entity to register with a host, cancel an existing registration with a host, or change a password with a host. By "host" is meant either of the following:

                                  -
                                    +
                                    1. an instant messaging server, such as described in XMPP IM and identified by the "server/im" &xep0030; category+type
                                    2. an add-on service, such as a gateway (see &xep0100;) or a &xep0045; service
                                    diff --git a/xep-0079.xml b/xep-0079.xml index 18e10676..a913ac90 100644 --- a/xep-0079.xml +++ b/xep-0079.xml @@ -157,7 +157,7 @@

                                    The following use case flow describes the interaction between the sender and a server. As illustrated below, this interaction is actually rather simple:

                                    -
                                      +
                                      1. Sender determines support (E1)
                                      2. Sender specifies appropriate rules and sends message to server (E1,E2)
                                      3. Sender awaits any protocol-specific responses (UCE)
                                        4. @@ -260,7 +260,7 @@

                                        Server operation is where the bulk of the work is performed. Upon receiving a message with an AMP extension, the server performs the following flow:

                                        -
                                          +
                                          1. Validate the semantics (E1, E2).
                                          2. Determine the default behavior.
                                          3. Process rules until condition is met. @@ -328,7 +328,7 @@

                                            In the following sections, the terms "content" and "contents" refers to the XML character data contained by the <rule/> element.

                                            The "deliver" condition is used to ensure delivery (or non-delivery) in one of five ways:

                                            -
                                              +
                                              1. Directly to the specified address or account over XMPP
                                              2. Delayed to offline storage (for later delivery via XMPP)
                                              3. Forwarded to an alternate address or account over XMPP
                                                4. diff --git a/xep-0129.xml b/xep-0129.xml index f6efcf3e..bbebeeb9 100644 --- a/xep-0129.xml +++ b/xep-0129.xml @@ -7,11 +7,11 @@
                                                WebDAV File Transfers - This document specifies best practices for completing Jabber file transfers using WebDAV. + This document a method for completing Jabber file transfers using WebDAV. &LEGALNOTICE; 0129 - Deferred - Informational + Experimental + Standards Track Standards XMPP Core @@ -22,24 +22,30 @@ - webdav-filexfer + TO BE ASSIGNED &dizzyd; &stpeter; + + 0.3 + 2007-02-02 + psa +

                                                Incorporated WedDAV feedback.

                                                 +                                                 0.2 2004-04-13 psa - Added information about service discovery. +

                                                Added information about service discovery.

                                                                                                 0.1 2004-03-12 - psa - Initial version. + psa/ds +

                                                Initial version.
                                                -

                                                &xep0096; defines mechanisms for transferring files between Jabber users, and defines the preferred approach for file transfers in Jabber applications. Unfortunately, the mechanisms defined therein require that both the sender and recipient be online at the same time. However, sometimes it is desirable for the sender to initiate a file transfer while the recipient is offline. One way to make this possible is for the sender to upload the file to a unique URL, then inform the recipient of the URL. The sender could do this by uploading the file to his or her own web server, but not everyone has their own web server. Fortunately, there is a well-defined protocol for such file management operations: a set of HTTP extensions known as WebDAV and defined in &rfc2518;.

                                                +

                                                &xep0096; defines mechanisms for transferring files between Jabber users, and defines the preferred approach for file transfers in Jabber applications. Unfortunately, the mechanisms defined therein require that both the sender and recipient be online at the same time. However, sometimes it is desirable for the sender to initiate a file transfer while the recipient is offline. One way to make this possible is for the sender to upload the file to a unique URL, then inform the recipient of the URL. The sender could do this by uploading the file to his or her own web server, but not everyone has their own web server. Fortunately, there is a well-defined protocol for such file management operations: a set of HTTP extensions known as WebDAV and defined in &rfc2518; (see also the revision-in-progress, &rfc2518bis;).

                                                The use case in which the recipient is offline is the main driver behind this document. Another WebDAV use case presents itself in environments that use, or even require, WebDAV for file transfers using other protocols (e.g., files attached to email messages). The usual rationale for such deployments is virus-checking: the file is put onto the WebDAV server (either by an end-user or a script that, for example, strips attached files off email messages) and then checked for viruses; only after the virus check successfully completes is the recipient allowed to retrieve the file. A further benefit of such deployments is that it enables the sender to provide the file to multiple recipients. Thus the approach defined herein provides the added benefit of being usable in generic WebDAV environments as well.

                                                 @@ -50,12 +56,123 @@
                                              - -

                                              This document inherits terms from RFC 2518, &rfc2616;, and &rfc2617;.

                                              -                                               +

                                              This document inherits terms from RFC 2518, &rfc2616;, and &rfc2617;.

                                              +                                               + +

                                              The client SHOULD attempt to PUT the file on the server. Alternatively, the client MAY first attempt one or more HEAD requests to determine a unique URL. The PUT request MUST include an "If-None-Match" header as well as an "Authorization" header that specifies appropriate authentication information.

                                              + +

                                              Prior to storing the file, the server MUST verify the user's authentication credentials via any supported method. When the file is stored, the server also MUST set the owner "live" property to ensure that only the user that originally posted this file is allowed to modify the file in any way. Other users MAY be allowed to see properties and retrieve the file (upon authentication) but MUST NOT be able to DELETE, MOVE, PROPPATCH, etc.

                                              + +

                                              In the absence of any other authorization method (e.g., SAML) in use by the deployed WebDAV server, the client MUST perform a PROPPATCH request to set the list of Jabber IDs authorized to retrieve this file, and the server MUST NOT allow access until this configuration is completed.

                                              + + + + + juliet@capulet.com + benvolio@montague.net/home + mercutio@capulet.com + + + + ]]> +

                                              Note: The semantics of the JID list defined above are:

                                              +
                                                +
                                              • If a JID is a bare JID (no resource), any fully-qualified form of that JID may access this resource (in the example above, this means that any resource of juliet@capulet.com may access this URL).
                                                • +
                                              • If a JID includes a resource identifier, only that specific JID may access this URL (in the example above, this means that only the JID benvolio@montague.net/home may access this URL; benvolio@montague.net/other may NOT).
                                                • +
                                              • If both a full JID and a bare JID are specified in a single JID list, the bare JID takes precedence.
                                                • +
                                              +

                                              The server responds when the properties have been updated. This is typically a 207 (MultiPart) response, which means that the body can contain multiple status codes, as shown in the following example.

                                              + + + http://files.shakespeare.lit/uniqueurl + + + HTTP/1.1 200 OK + + + + ]]> +

                                              Now that the file is available via WebDAV and the client has specified what Jabber IDs may access the URL, the sender sends a message to the target user(s) containing the URL of the file, encoded using &xep0066; to ensure backwards compatibility. (The example below shows the file being sent to multiple users using the &xep0033; protocol.)

                                              + + +
                                              +
                                              +
                                              + + + http://files.shakespeare.lit/uniqueurl + + + ]]> +

                                              When the target recipients have received the message, they may then perform an HTTP GET to download the file (the following request is from juliet@capulet.com).

                                              + +

                                              The server then checks to ensure that the provided JID is on the jidlist property. If not, the server MUST return an HTTP 403 (Forbidden) error; if so, the server attempts to authorize the user via &xep0070;:

                                              + + e0ffe42b28561960c6b12b944a092794b9683a38 + + Someone (maybe you) has requested the following file: + + https://files.shakespeare.lit:9345/missive.html. + + The transaction identifier is: + + a7374jnjlalasdf82 + + If you wish to confirm the request, please reply + to this message by typing "OK". If not, please + reply with "No". + + + + ]]> +

                                              If the XEP-0070 verification is successful, the server then allows the file to be retrieved:

                                              + -

                                              In order to discover a WebDAV server that supports this protocol, a client SHOULD use &xep0030;. Support for this protocol MUST be advertised by means of a service discovery feature named "http://jabber.org/protocol/webdav-filexfer". An example of the discovery flow is shown below.

                                              +

                                              In order to discover a WebDAV server that supports this protocol, a client SHOULD use &xep0030;. Support for this protocol MUST be advertised by means of a service discovery feature named "http://www.xmpp.org/extensions/xep-0129.html#ns" (see Protocol Namespaces). An example of the discovery flow is shown below.

                                              ... - + ... ]]>

                                              The user now knows that the "files.shakespeare.lit" service supports this protocol.

                                               - -

                                              The client MUST generate a unique URL and execute an HTTP HEAD request to see if that URL exists; this action SHOULD be repeated until the WebDAV server returns a 404 Not Found.

                                              - -

                                              Because the WebDAV server supports &xep0070;, the initial request fails (since the user did not provide Jabber authentication).

                                              - -

                                              In this case, the client then re-requests the HEAD with the appropriate credentials. Of course, the client could have avoided this by just providing the Authorization header on the initial request.

                                              - -

                                              Upon receipt of the HEAD request, the server then proceeds to verify the request using the x-xmpp-auth mechanism defined in XEP-0070. If the verification successfully completed, the server MAY cache further operations on this particular URL for the duration of the HTTP connection. It is recommended that clients keep the HTTP connection open, in accordance with HTTP/1.1 semantics.

                                              - -

                                              In the "happy" path, the server responds that the requested URL was not found.

                                              - -

                                              Now the client can PUT the file on the server, with the unique URL. To protect against someone else using the same URL in the timeframe between the HEAD and the PUT, the client MUST include an If-None-Match:* header to ensure that the server will not allow another URL to be overwritten.

                                              - -

                                              Prior to storing the file, the server MUST verifies the user's authorization (as detailed above). When the file is stored, the server also MUST set the owner "live" property to ensure that only the user that originally posted this file is allowed to modify the file in any way. Other users MAY be allowed to see properties and retrieve the file (upon authentication) but MUST NOT be able to DELETE, MOVE, PROPPATCH, etc.

                                              - -

                                              In the absence of any other authorization method (e.g., SAML) in use by the deployed WebDAV server, the client MUST perform a PROPPATCH request to set the list of Jabber IDs authorized to retrieve this file, and the server MUST NOT allow access until this configuration is completed.

                                              - - - - - juliet@capulet.com - benvolio@montague.net/home - mercutio@capulet.com - - - - ]]> -

                                              Note: The semantics of the JID list defined above are:

                                              -
                                                -
                                              • If a JID is a bare JID (no resource), any fully-qualified form of that JID may access this resource (in the example above, this means that any resource of juliet@capulet.com may access this URL).
                                                • -
                                              • If a JID includes a resource identifier, only that specific JID may access this URL (in the example above, this means that only the JID benvolio@montague.net/home may access this URL; benvolio@montague.net/other may NOT).
                                                • -
                                              • If both a full JID and a bare JID are specified in a single JID list, the bare JID takes precedence.
                                                • -
                                              -

                                              The server responds when the properties have been updated. The book "WebDAV: Next-Generation Collaborative Web Authoring" (Prentice Hall, 2004) suggests that this is typically a 207 (MultiPart) response, which means that the body can contain multiple status codes, as shown in the following example.

                                              - - - http://files.shakespeare.lit/uniqueurl - - - HTTP/1.1 200 OK - - - - ]]> -

                                              Now that the file is available via WebDAV and the client has specified what Jabber IDs may access the URL, the sender sends a message to the target user(s) containing the URL of the file, encoded using &xep0066; to ensure backwards compatibility. (The example below shows the file being sent to multiple users using the &xep0033; protocol.)

                                              - - -
                                              -
                                              -
                                              - - - http://files.shakespeare.lit/uniqueurl - - - ]]> -

                                              When the target recipients have received the message, they may then perform an HTTP GET to download the file.

                                              - -

                                              The server then checks to ensure that the provided JID is on the jidlist property, and then authorizes the user via XEP-0070; if a JID not on the jidlist attempts to access the file, the server MUST return an HTTP 403 (Forbidden) error. On completion, the server then allows the file to be retrieved.

                                              - - -

                                              See RFC 2518, XMPP Core, and XEP-0070 for security considerations related to those protocols, which are used by the profile defined herein. The initiating client MUST ensure that appropriate access controls are specified, normally by performing a PROPPATCH request to set the list of Jabber IDs authorized to retrieve the file. The server MUST NOT allow access to the file until access controls have been specified. In addition, the server MUST NOT allow access to the file by any unauthorized entity.

                                              +

                                              See RFC 2518, XMPP Core, and XEP-0070 for security considerations related to those protocols, which are used by the profile defined herein. The initiating client MUST ensure that appropriate access controls are specified, normally by performing a PROPPATCH request to set the list of Jabber IDs authorized to retrieve the file. The server MUST NOT allow access to the file until access controls have been specified. In addition, the server MUST NOT allow access to the file by any unauthorized entity.

                                              This document requires no interaction with &IANA;.

                                               -

                                              Upon advancement of this document to a status of Active, the ®ISTRAR; shall add the string "http://jabber.org/protocol/webdav-filexfer" to its registry of service discovery features.

                                              + +

                                              Until this specification advances to a status of Draft, its associated namespace shall be "http://www.xmpp.org/extensions/xep-0129.html#ns"; upon advancement of this specification, the ®ISTRAR; shall issue one or more permanent namespaces in accordance with the process defined in Section 4 of &xep0053;.

                                              +                                               +                                               + + + + + + + + + + + + + + + + + ]]> + + +

                                              Thanks to Lisa Dusseault and Julian Reschke for their feedback.

                                               diff --git a/xep-0130.xml b/xep-0130.xml index 907d4ffe..d26096b5 100644 --- a/xep-0130.xml +++ b/xep-0130.xml @@ -220,14 +220,14 @@

                                              This protocol is designed so that an IM User can:

                                              -
                                                +
                                                1. Request the user's current Waiting List
                                                2. Add a Contact to a local WaitingList (based on some URI associated with the Contact)
                                                3. Receive notification from a local WaitingListService if the Contact has (or subsequently creates) an IM account
                                                4. Remove a Contact from the Waiting List

                                                In addition, this protocol is designed so that a ServiceProvider can:

                                                -
                                                  +
                                                  1. Request the service's current WaitingList
                                                  2. Add a Contact to a WaitingList at an InteroPartner (based on some URI associated with the Contact)
                                                  3. Receive notification from the InteropPartner if the Contact has (or subsequently creates) an IM account
                                                    4. @@ -238,21 +238,21 @@

                                                    Before adding or removing Contacts from its WaitingList, an IM User SHOULD retrieve its current WaitingList. The activity flow is as follows:

                                                    -
                                                      +
                                                      1. IM User discovers WaitingListService hosted by ServiceProvider [A1]; it is RECOMMENDED to do this immediately after logging in.
                                                      2. IM User requests current WaitingList from WaitingListService.
                                                      3. WaitingListService returns WaitingList to IM User, including any items for which JIDs have been discovered. [A2]
                                                      -
                                                        +
                                                        1. ServiceProvider does not host a WaitingListService: -
                                                            +
                                                            1. Use Case Ends unsuccessfully.
                                                          1. IM User does not have a Waiting List: -
                                                              +
                                                              1. WaitingListService returns ¬found; error to IM User.
                                                              2. Use Case Ends unsuccessfully.
                                                              @@ -263,7 +263,7 @@

                                                              An IM User may know a URI for a Contact (e.g., a phone number or email address) but not the Contact's JID. In order to subscribe to the Contact's presence or otherwise communicate with the Contact over an instant messaging system, the IM User first needs to discover the Contact's JID based on a URI for the Contact. However, the Contact may not yet have an IM account. Because the IM User may therefore need to wait until the Contact creates an account, the IM User needs to add the Contact to a WaitingList. The activity flow is as follows:

                                                              -
                                                                +
                                                                1. IM User completes IM User Retrieves Current WaitingList use case.
                                                                2. IM User requests addition of Contact to WaitingList based on Contact's URI.
                                                                3. WaitingListService determines that the URI scheme is supported. [A1]
                                                                  4. @@ -281,21 +281,21 @@
                                                                -
                                                                  +
                                                                  1. The URI scheme is not supported: -
                                                                      +
                                                                      1. WaitingListService sends &badrequest; error to IM User and does not add contact to WaitingList.
                                                                      2. Use Case Ends unsuccessfully.
                                                                    1. The information provided is not a valid URI: -
                                                                        +
                                                                        1. WaitingListService sends ¬acceptable; error to IM User and does not add contact to WaitingList.
                                                                        2. Use Case Ends unsuccessfully.
                                                                      1. URI belongs to person served by ServiceProvider: -
                                                                          +
                                                                          1. WaitingListService determines that Contact is an IM User registered with ServiceProvider [A7].
                                                                          2. WaitingListService informs IM User of Contact's JID. [A9]
                                                                          3. IM User completes IM User Removes Contact from WaitingList use case.
                                                                            4. @@ -303,7 +303,7 @@
                                                                        1. URI does not belong to a person served by InteropPartner: -
                                                                            +
                                                                            1. InteropPartner sends ¬found; error to WaitingListService.
                                                                            2. If all InteropPartners queried return ¬found; error, WaitingListService sends ¬found; error (or local equivalent) to IM User.
                                                                            3. IM User completes IM User Removes Contact from WaitingList use case.
                                                                              4. @@ -311,7 +311,7 @@
                                                                          1. Contact is not an IM User registered with InteropPartner: -
                                                                              +
                                                                              1. InteropPartner records and acknowledges WaitingListService's request for JID associated with URI.
                                                                              2. OPTIONALLY, InteropPartner invites Contact to register as an IM User.
                                                                              3. Contact registers.
                                                                                4. @@ -322,14 +322,14 @@
                                                                            1. InteropPartner refuses to provide service to ServiceProvider: -
                                                                                +
                                                                                1. InteropPartner's WaitingListService sends ¬authorized; error to ServiceProvider's WaitingListService.
                                                                                2. If all other InteropPartners also return errors, WaitingListService returns ¬found; error to IM User.
                                                                                3. Use Case Ends unsuccessfully.
                                                                              1. Contact is not an IM User registered with ServiceProvider: -
                                                                                  +
                                                                                  1. WaitingListService records IM User's request for JID associated with URI.
                                                                                  2. OPTIONALLY, WaitingListService invites Contact to register as an IM User.
                                                                                  3. Contact registers.
                                                                                    4. @@ -339,20 +339,20 @@
                                                                                1. Contact's URI is not handled by any ServiceProvider: -
                                                                                    +
                                                                                    1. WaitingListService informs all IM Users who requested JID associated with Contact's URI that no InteropPartner services Contact's URI.
                                                                                    2. IM User completes IM User Removes Contact from WaitingList use case.
                                                                                    3. Use Case Ends unsuccessfully.
                                                                                  1. IM User completes IM User Removes Contact from WaitingList use case. -
                                                                                      +
                                                                                      1. ServiceProvider's WaitingListService removes item from WaitingList.
                                                                                      2. Use Case Ends unsuccessfully.
                                                                                    1. All Users Remove Contact from Their WaitingLists -
                                                                                        +
                                                                                        1. ServiceProvider's WaitingListService removes item from WaitingList at InteropPartner's WaitingListService.
                                                                                        2. Use Case Ends unsuccessfully.
                                                                                        @@ -363,7 +363,7 @@

                                                                                        An IM User should remove a contact from the WaitingList after the IM User Adds Contact to WaitingList use case ends (either successfully or unsuccessfully), and may remove a contact from the WaitingList at any other time.

                                                                                        -
                                                                                          +
                                                                                          1. IM User sends removal request to WaitingListService.
                                                                                          2. WaitingListService removes IM User's request for JID associated with URI.
                                                                                          3. WaitingListService informs IM User of successful removal [A1].
                                                                                            4. @@ -375,15 +375,15 @@
                                                                                          -
                                                                                            +
                                                                                            1. IM User never requested JID associated with URI: -
                                                                                                +
                                                                                                1. WaitingListService sends ¬found; error to IM User.
                                                                                                2. Use Case Ends.
                                                                                              1. Contact URI is served by WaitingListService or IM User was not the only person who requested the JID: -
                                                                                                  +
                                                                                                  1. Use Case Ends.
                                                                                                  @@ -900,7 +900,7 @@ -
                                                                                                    +

                                                                                                    1. Protocols and mechanisms for inviting a Contact to register as an IM User are out of scope for this document and shall be determined by each InteropPartner individually.

                                                                                                    2. A ServiceProvider's WaitingListService MUST record which of its IM Users have requested the JID associated with Contact's URI, and an InteropPartner's WaitingListService MUST record that Service Provider's WaitingListService (not User) has requested JID associated with Contact's URI. Therefore when Contact registers, InteropPartner's WaitingListService informs its local users as well as ServiceProvider's WaitingListService, and ServiceProvider's WaitingListService informs its local users.

                                                                                                    3. The InteropPartner's WaitingListService is not required to be hosted by InteropPartner, and could be hosted by a third party (e.g., a neutral phone number translation service). In this case, InteropPartner would simply advertise 'waitlist.third-party.com' as its WaitingListService.

                                                                                                      4. diff --git a/xep-0139.xml b/xep-0139.xml index 59bcfc00..d9a6ab2c 100644 --- a/xep-0139.xml +++ b/xep-0139.xml @@ -57,10 +57,10 @@

                                                                                                      The Security SIG shall produce at least the following deliverables:

                                                                                                      -
                                                                                                        +

                                                                                                        1. A brief document specifying the process by which the SIG shall identify, define, analyze, and prioritize a collection of documented security-related threats. This process document will not identify threats or define ways to address them, but instead specify the process to be followed in Steps 2 and 3 below. In defining the process, the SIG should also describe some of its guiding principles, such as:

                                                                                                          -
                                                                                                            +
                                                                                                            1. Rough consensus and running code are superior to "perfect" solutions
                                                                                                            2. Security measures that cannot or will not be implemented are useless
                                                                                                            3. Iteration works better than trying to define all solutions up front
                                                                                                              4. @@ -68,7 +68,7 @@

                                                                                                            4. A template to be used for documenting each identified threat. This template should include:

                                                                                                              -
                                                                                                                +
                                                                                                                1. A name for the threat
                                                                                                                2. An abstract that briefly describes the threat
                                                                                                                3. A clear and thorough definition of the threat, preferably to include an attack tree For information about attack trees, refer to <http://www.schneier.com/paper-attacktrees-ddj-ft.html>.
                                                                                                                  4. diff --git a/xep-0162.xml b/xep-0162.xml index c295655b..cd0ba0bf 100644 --- a/xep-0162.xml +++ b/xep-0162.xml @@ -131,7 +131,7 @@

                                                                                                                4. The Jabber client SHOULD NOT remove the contact from the roster. There are two exceptions:

                                                                                                                  -
                                                                                                                    +

                                                                                                                    1. The Jabber client MAY remove the contact from the roster if the user explicitely asked (so the user has to be informed he might remove both presence subscriptions).

                                                                                                                      2. diff --git a/xep-0163.xml b/xep-0163.xml index 458dd4cd..20443da1 100644 --- a/xep-0163.xml +++ b/xep-0163.xml @@ -476,7 +476,7 @@ ]]> -

                                                                                                                      As a result, the account owner's server generates notifications and sends them to all subscribers who have requested or are interested in the data as described in the Contact Notification Filtering and Generating Notifications sections of this document.

                                                                                                                      +

                                                                                                                      As a result, the account owner's server generates notifications and sends them to all subscribers who have requested or are interested in the data as described in the Contact Notification Filtering and Generating Notifications sections of this document, as well as to any of the account owner's available resources.

                                                                                                                      The server MUST set the 'from' address on the notification to the bare JID (&BAREJID;) of the account owner (in this example, "juliet@capulet.com"). When sending notifications to an entity that has a presence subscription to the account owner, the server SHOULD include an &xep0033; "replyto" extension specifying the publishing resource (in this example, "juliet@capulet.com/balcony"); this enables the subscriber's client to differentiate between information received from each of the account owner's resources (for example, different resources may be in different places and therefore may need to specify distinct geolocation data). However, a server MUST NOT include the "replyto" address when sending a notification to an entity that does not have a presence subscription to the account owner. In addition, any errors related to the notification MUST be directed to the JID of the 'from' address on the notification (i.e., the bare JID) so that bounce processing can be handled by the PEP service rather than by the publishing client.

                                                                                                                      Assuming that all three entities previously mentioned would receive the notifications, the PEP service would generate the following stanzas:

                                                                                                                      Enable an XMPP entity to request a translation from a remote XMPP entity.

                                                                                                                    2. Enable an XMPP entity to express the following mandatory elements of a translation for any receiving entities.

                                                                                                                      -
                                                                                                                        +
                                                                                                                        1. Identification of Original Text
                                                                                                                        2. Identification of Translated Text
                                                                                                                        3. Identification of any Pivot Language(s) and Text
                                                                                                                          4. @@ -110,7 +110,7 @@

                                                                                                                        4. Enable an XMPP entity to express the following optional elements of a translation for any receiving entities.

                                                                                                                          -
                                                                                                                            +
                                                                                                                            1. Identification of Language Translation Engines used.
                                                                                                                            2. Identification of Location of the translation.
                                                                                                                            3. Identification of Sender and Destination language of choice.
                                                                                                                              4. diff --git a/xep-0204.xml b/xep-0204.xml index 8b8aa787..7ce47e3b 100644 --- a/xep-0204.xml +++ b/xep-0204.xml @@ -102,7 +102,7 @@

                                                                                                                              This JEP describes a protocol that is designed to fulfill the following requirements:

                                                                                                                              -
                                                                                                                                +
                                                                                                                                1. Determine the ability for clients and servers to support and exchange collaborative data objects
                                                                                                                                2. Enable the exchange of structured data objects between clients
                                                                                                                                3. Define a protocol that supports the synchronization of structure data among participating clients. Currently @@ -133,7 +133,7 @@ Both clients want to ensure they have the most up-to-date information. The two endpoints can do so by collaborating on the data using the CDO protocol.

                                                                                                                                  For example, let's assume the clients wish to coordinate a meeting over chat. The process may look like this:

                                                                                                                                  -
                                                                                                                                    +
                                                                                                                                    1. Client A creates a new meeting that contains structured data such as the title of the meeting, participant e-mail list, start time, date, length, and location. @@ -158,7 +158,7 @@ A and B are connected to.

                                                                                                                                      -
                                                                                                                                        +
                                                                                                                                        1. Client A wishes to send information about a new meeting to client B