From fc8efac7b17b5167777ec9f5d8c8879fc0c101e5 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Fri, 16 Feb 2007 05:20:39 +0000 Subject: [PATCH] xhtml fixes git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@590 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0031.xml | 6 ++-- xep-0043.xml | 86 +++++++++++++++++++++++++++------------------------- xep-0052.xml | 6 ++-- xep-0065.xml | 2 +- xep-0079.xml | 12 ++++---- xep-0087.xml | 13 ++++---- xep-0096.xml | 10 +++--- xep-0100.xml | 22 +++++++------- xep-0102.xml | 22 +++++++------- xep-0117.xml | 2 +- xep-0126.xml | 6 ++-- xep-0132.xml | 2 +- xep-0136.xml | 8 ++--- xep-0142.xml | 4 +-- xep-0153.xml | 2 +- xep-0154.xml | 2 +- xep-0159.xml | 22 +++++++------- xep-0167.xml | 67 ---------------------------------------- xep-0168.xml | 2 +- xep-0176.xml | 8 ++--- xep-0181.xml | 2 +- xep-0183.xml | 2 +- xep-0188.xml | 4 +-- xep-0190.xml | 6 ++-- xep-0198.xml | 2 +- xep-0202.xml | 2 +- xep-0205.xml | 2 +- xep.xsl | 3 ++ 28 files changed, 131 insertions(+), 196 deletions(-) diff --git a/xep-0031.xml b/xep-0031.xml index daa9ed43..5d37a905 100644 --- a/xep-0031.xml +++ b/xep-0031.xml @@ -1505,7 +1505,6 @@ The key's identifier, convId, is assembled. The payload, which consists of the confidentiality key and the integrity key, is wrapped in instances of xenc:EncryptedKey as follows:

- +

  • The HMAC is computed using SKi of the security session over the following values: @@ -1726,7 +1726,6 @@ this specification is '1.0'. The value of convId MUST correspond to an existing,

    The actual message body is encoded into a character string corresponding to a Jabber message body element. This character string is then wrapped in an instance of xenc:EncryptedData as follows:

    -
    • +

  • Using the HMAC key indicated by the convId attribute, the HMAC is computed @@ -2101,12 +2101,12 @@ Support for Elliptic Curve Cryptography

    Additional symmetric algorithms

    +

  • Additional hash algorithms

    • -

    diff --git a/xep-0043.xml b/xep-0043.xml index e4581be8..9085bfd0 100644 --- a/xep-0043.xml +++ b/xep-0043.xml @@ -64,36 +64,39 @@

    @@ -332,7 +335,7 @@

    Attributes only used in the <col> element within a <where> element are the op (for operator) and conj for (conjunction). The op is used for comparison operators such - as <, >, =, <>, <=, >= + as <, >, =, <>, <=, >=

    -

    -

    The conjuction attribute is used to combined constraints in the where clause +

    The conjuction attribute is used to combined constraints in the where clause

    -

    Result

    @@ -696,8 +697,9 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)

    Three responses are possible from the server.

      -
    1. It supports that version number and responds with: -

      +

    2. +

      It supports that version number and responds with:

      + <iq id="000" type="result" from="db.host"> <database xmlns="http://openaether.org/projects/jabber_database.html"> @@ -705,20 +707,20 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123) </database> </iq> - The type of 'result' indicates that the version request was +

      The type of 'result' indicates that the version request was successful and if the client is satisfied with the version number, may continue with schema requests or whatever.

      3. -
    3. It does not support that version number and responds with: -

      +

    4. It does not support that version number and responds with:

      + <iq id="000" type="error" from="db.host"> <database xmlns="http://openaether.org/projects/jabber_database.html"/> </iq> - The type of 'error' indicates a failure in conforming to the +

      The type of 'error' indicates a failure in conforming to the desired version number. The server may optionally send an - alternative option. + alternative option.

      <iq id="000" type="error" from="db.host"> <database @@ -726,7 +728,7 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123) <version>0.2</version> </database> </iq> -

      5. +
    5. If the server has no idea what the client is talking about it should send the appropriate Jabber error code.
    diff --git a/xep-0052.xml b/xep-0052.xml index ee048c2a..1ba4ad39 100644 --- a/xep-0052.xml +++ b/xep-0052.xml @@ -329,9 +329,8 @@

    The "offset" attribute defines the range offset, in bytes. This attribute MAY be present if the containing <file/> has an action value of "get", otherwise it SHOULD NOT be present. If this attribute is not present, a value of 0 is implied. The value of this attribute MUST be an integer, MUST NOT be less than 0, and MUST be less than (size - length).

     -

    - There are three main error conditions in file transfer. Following are the - conditions, error codes and descriptions: +

    There are three main error conditions in file transfer. Following are the + conditions, error codes and descriptions:

    • Declining Transfer (403): During the meta-data negotiation @@ -357,7 +356,6 @@ sender. The <error/> CDATA is not important.
    -

    diff --git a/xep-0065.xml b/xep-0065.xml index 4f0a8268..082fcf50 100644 --- a/xep-0065.xml +++ b/xep-0065.xml @@ -170,7 +170,7 @@

  • Initiator and Target may begin using the bytestream.

    • - +

    Mediated connection is slightly more complicated. In this situation, the StreamHost is not the Initiator but a Proxy, which means that the Initiator must discover the network address of the StreamHost before sending the initial IQ-set, must negotiate a connection with the StreamHost in the same way that the Target does, and must request that the StreamHost activate the bytestream before it can be used. The process for establishing bytestreams in this case is as follows:

    1. Optionally, Initiator discovers the network address of StreamHost in-band.

      2. diff --git a/xep-0079.xml b/xep-0079.xml index a913ac90..5a02fda0 100644 --- a/xep-0079.xml +++ b/xep-0079.xml @@ -409,7 +409,7 @@

      The following actions are defined by this document.

      The "alert" action triggers a reply &MESSAGE; stanza to the sending entity. This &MESSAGE; stanza MUST contain the element <amp status='alert'/>, which itself contains the <rule/> that triggered this action. In all other respects, this action behaves as "drop".

      - @@ -420,14 +420,14 @@ - ]]> + ]]>

      The "drop" action silently discards the message from any further delivery attempts and ensures that it is not placed into offline storage. The drop MUST NOT result in other responses.

      The "error" action triggers a reply &MESSAGE; stanza of type "error" to the sending entity. The &MESSAGE; stanza's <error/> child MUST contain a <failed-rules xmlns='http://jabber.org/protocol/amp#errors'/> error condition, which itself contains the rules that triggered this action.

      - - ]]> + ]]>

      Note that the error SHOULD be of type "modify", and the general error condition SHOULD be <undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>.

      The "notify" action triggers a reply &MESSAGE; stanza to the sending entity. This &MESSAGE; stanza MUST contain the element <amp status='notify'/>, which itself contains the <rule/> that triggered this action. Unlike the other actions, this action does not override the default behavior for a server. Instead, the server then executes its default behavior after sending the notify.

      - @@ -461,7 +461,7 @@ - ]]> + ]]>       diff --git a/xep-0087.xml b/xep-0087.xml index ac03dd6f..4ff077fb 100644 --- a/xep-0087.xml +++ b/xep-0087.xml @@ -293,10 +293,11 @@

      Creating a profile is fairly simple. First, a name is chosen, the - complete name is formatted like: + complete name is formatted like:

      http://jabber.org/protocol/si/profile/profile-name +

      The complete name is what is presented in information discovery requests in order to show that the profile is supported. It is also used for the <si> profile attribute. Next, the information for the headers is @@ -321,7 +322,7 @@ streams must link the Stream Initiation to the stream. The id attribute of the <si> node is intended to provide this link. It is out of scope of this document to define how streams will make use of this - facility, but it does suggest some methods: + facility, but it does suggest some methods:

       -

      - The attributes and data of <si> are fairly simple: + The attributes and data of <si> are fairly simple:

      • id - An opaque identifier generated by the Sender. @@ -363,7 +363,7 @@ profile - The profile's fulle name, selected by Sender.
      - The data of the node is a mixture of a feature negotiation for the stream +

      The data of the node is a mixture of a feature negotiation for the stream and the profiles headers.

      @@ -382,7 +382,7 @@

      There are two error codes that are used. Following are the conditions, - meanings and data: + meanings and data:

      • Declining Transfer (403): During the Stream Initiation @@ -396,7 +396,6 @@ they send a 406 error. The <error/> CDATA is not important.
      -

      diff --git a/xep-0096.xml b/xep-0096.xml index d2b666d5..0ce29b78 100644 --- a/xep-0096.xml +++ b/xep-0096.xml @@ -105,7 +105,7 @@
      • Enable seamless file transfer, including fall-back mechanisms as appropriate.
      • Ensure that the profile will work even when one or both parties are behind a firewall.
        • -
      • Define a full-featured set of metadata for file transfers, including the following: +

      • Define a full-featured set of metadata for file transfers, including the following:

        • description
        • size
          • @@ -126,7 +126,7 @@

          The root element is <file> and has four attributes. The attributes - are used only during the offer stage of stream initiation: + are used only during the offer stage of stream initiation:

          • size - The size, in bytes, of the data to be sent.
          • name - The name of the file that the Sender wishes to send.
            • @@ -134,7 +134,7 @@ specified using the DateTime profile as described in &xep0082;.
          • hash - The MD5 sum of the file contents.
          - The size and name attributes MUST be present in the +

          The size and name attributes MUST be present in the profile. The other attributes MAY be present.

          @@ -150,7 +150,7 @@ When <range> is sent in the offer, it should have no attributes. This signifies that the sender can do ranged transfers. When a Stream Initiation result is sent - with the <range> element, it uses these attributes: + with the <range> element, it uses these attributes:

          • offset - Specifies the position, in bytes, to start @@ -163,7 +163,7 @@ end.
          - Both attributes are OPTIONAL on the <range> element. Sending no +

          Both attributes are OPTIONAL on the <range> element. Sending no attributes is synonymous with not sending the <range> element. When no <range> element is sent in the Stream Initiation result, the Sender MUST send the complete file starting at diff --git a/xep-0100.xml b/xep-0100.xml index f4179f0e..6579aaef 100644 --- a/xep-0100.xml +++ b/xep-0100.xml @@ -317,7 +317,7 @@

            -

          1. User information not verified: +

          2. User information not verified:

            1. Gateway returns ¬acceptable; error to Jabber User. (For detailed information regarding error conditions, refer to &xep0086;.)

              @@ -339,7 +339,7 @@

            2. Use Case Ends unsuccessfully.

            -

            3. +
          @@ -400,7 +400,7 @@
            -

          1. Edit unsuccessful: +

          2. Edit unsuccessful:

            1. Gateway returns ¬acceptable; error to Jabber User.

              @@ -422,7 +422,7 @@

            2. Use Case Ends unsuccessfully.

            -

            3. +
          @@ -533,7 +533,7 @@
            -

          1. Login fails: +

          2. Login fails:

            1. Gateway sends appropriate presence error to Jabber User (¬authorized; if password is bad, &timeout; if Legacy Service is down, etc.).

              @@ -549,7 +549,7 @@

            2. Use Case Ends unsuccessfully.

            -

            3. +
          @@ -583,7 +583,7 @@
            -

          1. Legacy Service supports directed presence and Gateway receives presence stanza of type "unavailable" directed to a Legacy User: +

          2. Legacy Service supports directed presence and Gateway receives presence stanza of type "unavailable" directed to a Legacy User:

            1. Gateway passes through directed unavailable presence to Legacy User.

              @@ -595,7 +595,7 @@

            2. Use Case Ends.

            -

            3. +
          @@ -793,7 +793,7 @@
            -

          1. Jabber User denies subscription request: +

          2. Jabber User denies subscription request:

            1. Jabber User sends presence stanza of type "unsubscribed" to Legacy User.

              @@ -806,7 +806,7 @@

            2. Gateway cleans up subscription state and MUST NOT send Jabber User's presence to Legacy User.

            3. Use Case Ends unsuccessfully.

            -

            3. +
          @@ -877,7 +877,7 @@

    Gateways and clients SHOULD implement at least one of these protocols; at a minimum, it is RECOMMENDED for gateways and clients to implement the 'jabber:iq:gateway' protocol.

    - +

    The 'jabber:iq:gateway' protocol performs two functions:

    1. It enables a client to determine the text for the "prompt" to show to a Jabber User when the user wants to add a legacy contact to the user's roster (e.g., "Please enter the AOL Screen Name of the person you would like to contact"), as well as the preferred name for the prompted item (e.g., "Screen Name"). To do so, the client sends an empty <query/> element and the gateway returns a <prompt/> element (the name for the prompted item) and optionally a <desc/> element (the text of the prompt itself).

      2. diff --git a/xep-0102.xml b/xep-0102.xml index 77300951..7e85c0f5 100644 --- a/xep-0102.xml +++ b/xep-0102.xml @@ -285,7 +285,7 @@

      xmody means: x is divided by y and the remainder is returned

      Suppose two nodes want to agree on a shared secret key to exchange information securely, they will exchange their public keys in order to encrypt that information. To this goal, the transport XMPP packet SHOULD include an extension of the form:

      - @@ -293,7 +293,7 @@ -]]> +]]>

      In this extension, the only negotiable parameter is the key length that is passed in the length attribute of the <KeyAgreement/> tag. The length attribute is used to retrieve the DH parameter group and the associated prime and generator values. We are using DH groups derived from the Internet Key Exchange protocol (IKE) which is used by IPSec. A summary of these groups and the associated parameters are described later in this document.

      @@ -301,7 +301,7 @@

      The client uses an empty <x/> element in the request to signal that it supports the XMPP security extension.

      The flow between client and server will look like:

      - @@ -309,11 +309,11 @@ -]]> +]]>

      The server will reply to the request by sending out its own ephemeral public key inside the <x/> extension.

      - @@ -327,12 +327,12 @@ -]]> +]]>

      The client then generate its own public key, calcultate the shared secret according to the DH method and uses it to encrypt the password accordingly. It includes its own ephemeral public key into the reply to the server inside the <x/> extension.

      - username @@ -346,15 +346,15 @@ -]]> +]]>

      The server now calculates the shared secret according to the DH method and uses its private key to decrypt the password.

      - -]]> +]]>       @@ -1354,7 +1354,7 @@ The real body is protected.

      An RSA Laboratories Technical Note Version 1.4 -Revised November 1, 1993

      Supersedes June 3, 1991 version, which was also published as NIST/OSI Implementors' Workshop document SEC-SIG-91-19. PKCS documents are available by electronic mail to <pkcs@rsa.com>.

      +Revised November 1, 1993upersedes June 3, 1991 version, which was also published as NIST/OSI Implementors' Workshop document SEC-SIG-91-19. PKCS documents are available by electronic mail to <pkcs@rsa.com>.

      This standard describes a method for implementing Diffie-Hellman key agreement, whereby two parties, without any prior arrangements, can agree upon a secret key that is known only to them (and, in particular, is not known to an eavesdropper listening to the dialogue by which the parties agree on the key). This secret key can then be used, for example, to encrypt further communications between the parties.

      The intended application of this standard is in protocols for establishing secure connections, such as those proposed for OSI's transport and network layers [ISO90a][ISO90b].

      diff --git a/xep-0117.xml b/xep-0117.xml index 36aaf0f0..23ef42e1 100644 --- a/xep-0117.xml +++ b/xep-0117.xml @@ -78,7 +78,7 @@

      The &xep0073; introduced the concept of a "protocol suite". This document extends the basic support specified in XEP-0073 by specifying an Intermediate IM Protocol Suite.

       - +

      This document follows the same approach as XEP-0073. By design, the Basic IM Protocol Suite does not include more advanced instant messaging functionality; the present document fills the need for a protocol suite that addresses such functionality.

      A protocol is deemed worthy of inclusion in this protocol suite if:

        diff --git a/xep-0126.xml b/xep-0126.xml index 9195770b..e913e306 100644 --- a/xep-0126.xml +++ b/xep-0126.xml @@ -408,14 +408,14 @@

        In general it is probably easiest for users to become visible/invisible either globally or based on roster group, since these models are conceptually simple. Although, naturally, a client developer cannot tell users what to do, it probably best to encourage the use of conceptually simple models for privacy lists.

        Privacy lists can become complex and must be carefully managed by clients. For example, let us imagine that the user is currently applying another active list unrelated to visibility (e.g., a list that blocks communications with a stalker); if the user then clicks "Go Invisible" and the client is not smart, it could overwrite the stalker blocking. Therefore, if the user has an active list that incorporates rules other than those related to visibility/invisibility, the client SHOULD either assume that visibility/invisibility is an overlay on the list currently in use (generating an appropriate privacy list that takes both into account) or prompt the user regarding their intentions. In the absence of privacy lists unrelated to visibility/invisibility, the client may proceed in a less cautious fashion.

        - +

        For security concerns related to privacy lists, refer to RFC 3921. Care must be taken regarding privacy lists, especially so that visibility/invisibility rules do not overwrite existing rules the user has set for the sake of security and privacy; for details, see the Implementation Notes section of this document.

        It is important to recognize that invisibility can be defeated without more advanced privacy lists than those defined above and an awareness of context on the part of a client. For example, if a user usually logs in as the same resource (e.g., "Home"), a contact can send an IQ request to that resource's full JID using &xep0012;, &xep0030;, &xep0090;, or &xep0092; and receive a reply, thus providing information that reveals the user's availability. In addition, Last Activity requests sent by a subscribed contact to the user's bare JID will normally reveal the user's availability as well. To help ensure that the user's invisibility cannot be defeated in this way, the user's client SHOULD add IQ blocking to the relevant privacy list. Finally, the user's client SHOULD NOT return "is-composing" events as defined in &xep0022; or &xep0085;.

         - +

        This document requires no interaction with &IANA;.

         - +

        No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this specification.

         diff --git a/xep-0132.xml b/xep-0132.xml index 43eee6cc..d5aaaa87 100644 --- a/xep-0132.xml +++ b/xep-0132.xml @@ -29,7 +29,7 @@ Per a vote of the Jabber Council, advanced status to Active. - +

        &xmppcore; and &xmppim; define methods for exchanging information about a person's network availability via the XML <presence/> stanza. In general, such presence information is generated only when a person initiates interaction with a client, although it can be generated programmatically through features such as auto-away. However, sometimes a user is present in the vicinity of a client but is not actively engaged with the client interface. In such circumstances, it would be helpful to have a mechanism that is sometimes referred to as <presence type='probe-irl'/>: the ability to invoke a real-life means of determining the physical presence of the user. This document defines just such a mechanism.

         diff --git a/xep-0136.xml b/xep-0136.xml index 873b0fda..598a25fd 100644 --- a/xep-0136.xml +++ b/xep-0136.xml @@ -238,7 +238,7 @@

      • If administrator policies require that at least the <body/> elements (or the full content) of every message are logged automatically, and the client sets the value of the 'save' attribute to 'false' (or 'body').

       - +

      A client may use a similar protocol to set the Modes for a particular contact or domain of contacts (bare JID, full JID or domain). Note: It is STRONGLY RECOMMENDED for the value of the 'jid' attribute to be a bare JID (&BAREJID;).

      @@ -265,7 +265,7 @@ ]]>

      The same error cases apply as when Setting Default Modes.

       - + @@ -475,7 +475,7 @@ ]]> - +

      The client MAY specify an absolute time for any message by providing a longer 'utc' attribute (which MUST be UTC and adhere to the DateTime format specified in Jabber Date and Time Profiles) instead of a 'secs' attribute. The absolute time MAY be before the start time of the collection:

      @@ -708,7 +708,7 @@ ]]>

      As soon as the server has finished archiving a collection, it MUST securely destroy all copies of the symmetric key it used to encrypt the messages. Note: If the security of the server is compromised, then only the collections being recorded during the attack will be revealed (i.e. only those messages that would have been compromised even if they had not been archived).

       - +

      The server MUST return a <feature-not-implemented/> error in the following cases:

      • If the client is trying to enable automatic archiving, but the server does not allow the saving of full message stanza content, and the user has specified the 'message' Save Mode in one of its Archiving Preferences.

        • diff --git a/xep-0142.xml b/xep-0142.xml index 03d191f4..5f501185 100644 --- a/xep-0142.xml +++ b/xep-0142.xml @@ -897,10 +897,10 @@ Agent Service ]]> - +

        There are no defined error conditions for agent invitations.

         - +

        An invitation from the server on behalf of the support@example.net workgroup:

        ]]>

        If the client subsequently obtains an avatar image (e.g., by updating or retrieving the vCard), it SHOULD then publish a new &PRESENCE; stanza with character data in the <photo/> element.

        +

        Note: This enables recipients to distinguish between the absence of an image (empty photo element) and mere support for the protocol (empty update child).

        -

        Note: This enables recipients to distinguish between the absence of an image (empty photo element) and mere support for the protocol (empty update child).

     diff --git a/xep-0154.xml b/xep-0154.xml index c6002b1e..1d320348 100644 --- a/xep-0154.xml +++ b/xep-0154.xml @@ -788,7 +788,7 @@ ]]> - +

    Longitude is a person's longitude in relation to the equator, where positive longitude is east of the meridian and negative longitude is west of the equator.

    The Data Forms field that represents longitude is "lon".

    This field maps to:

    diff --git a/xep-0159.xml b/xep-0159.xml index 8cb5e4ab..ef9b47a3 100644 --- a/xep-0159.xml +++ b/xep-0159.xml @@ -107,14 +107,14 @@ ]]> - +

    This section specifies server functionality not defined in RFC 3921. This document will not reach Draft status until Server-Based Privacy Rules has been modified to permit this functionality.

    - +

    A server that supports this protocol MAY maintain a separate If the server were to maintain a single unified list of the correspondents of all its users, then SPIMers would only need to pass a single SPIM recognition test before being allowed to send SPIM to all the server's users. list of each user's correspondents. Each list contains all the bare JIDs the user has either sent a stanza to or received a stanza from (over the past few weeks or months).

    Note: When it blocks a stanza, the server MUST NOT add the 'from' attribute of the stanza to the correspondents list.

    Note: The lists of correspondents have a very different function from rosters. Edits are initiated by the server not the client, allowing the lists to be completely transparent to clients.

     - +

    The server SHOULD perform the following procedures whenever it receives a stanza that falls through the active privacy list of the user it is addressed to without being either allowed or denied:

    1. If the server maintains correspondents lists, and if the bare JID in the 'from' attribute of the received stanza is on the addressed user's correspondents list, then the server SHOULD allow the stanza to be delivered to the user.
      2. @@ -122,7 +122,7 @@
    2. Depending on the result of those procedures, it SHOULD then either allow, deny or delay the delivery of the stanza without informing the sender.
     - +

    When a SPIM recognition procedure delays delivery of a stanza the server SHOULD store it temporarily.

    While delivery is being delayed:

      @@ -134,16 +134,16 @@ - +

      This informative section requires no client or server functionality beyond that defined in RFC 3921.

      - - + +

      The client SHOULD use the 'subscription' type to exclude all JIDs on the user's roster from SPIM blocking (see the items with order 20, 30 and 40 in the example below).

       - +

      At least in the medium term, clients that use non-XMPP protocols cannot be expected to support interactive SPIM recognition techniques (like Robot Challenges). So, if its server uses interactive techniques, the client MAY use the 'jid' type to ensure its server does not block stanzas arriving from the transports the user has registered with (see the item with order 50 in the example below).

       - +

      If a user believes SPIM will not be sent by users of a particular server (e.g. the user's own corporate server), then the client MAY use the 'jid' type to exclude all these users from SPIM blocking (see the item with order 60 in the example below).

             - +

      If stanzas from a SPIM robot running on a zombie domain somehow manage to get past the server's SPIM recognition then the client MAY use the 'jid' type to block one or all JIDs from the domain. (RFC 3921 already enables this functionality.)

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

      A client MAY disable server-side SPIM blocking by ensuring the default fall-through action is never applied. It does this simply by including an explicit fall-through item in its active privacy list.

      diff --git a/xep-0167.xml b/xep-0167.xml index e0cd5dad..eacb6346 100644 --- a/xep-0167.xml +++ b/xep-0167.xml @@ -158,73 +158,6 @@ ]]>

      Note: The parameter names are effectively guaranteed to be unique, since &IANA; maintains a registry of SDP parameters (see <http://www.iana.org/assignments/sdp-parameters>).

       - -

      Upon receiving a Jingle initiate stanza containing a Jingle Audio content description as defined in this document, a receiver iterates through the list of offered payload types, composing an appropriate Jingle Audio response description according to the following rules:

      -
        -
      • If the receiver does not support the offered encoding, it MUST NOT include the encoding in its response.
        • -
      • If the receiver does support the offered encoding, it SHOULD include the encoding in the response, preserving the offered payload type.
        • -
      • If the receiver is unable to support the offered encoding with the offered payload type, it MAY provide an alternate payload type in its response. This typically will happen only when translating from other signalling protocols.
        • -
      • The receiver SHOULD preserve the order of the offered encodings, which represents the priority assigned to them by the initator.
        • -
      -

      If, after applying these rules, the receiver determines it does not support any of the offering encodings, the receiver MUST reject the session by sending a <unsupported-codecs/> error in response to the initiator's "initiate" action. Otherwise, it MUST provisionally accept the session by sending an empty IQ result. If the response content type differs from the one offered, the receiver MUST then propose the change in a "description-modify" action as defined in XEP-0166. If the description is identical, the receiver MUST send a "description-accept" action (either explicitly, or implicitly as part of a "session-accept" or "content-accept" action).

      -

      Following is an example of this negotiation:

      - - - - - - - - - ... - - - - - ]]> -

      The receiver now follows the rules provided in this section and determines it can only support PCMU. It provisionally accepts the session:

      - - ]]> -

      It then offers the new content description in a 'description-modify' action:

      - - - - - - - - - - ]]> -

      The initiator acknowledges the 'description-modify' with an empty IQ result, and sends a 'description-accept' to accept the new Jingle Audio content description.

      - - - - - - - - - - - - ]]> -

      Finally, the target acknowledges the 'description-accept'.

      - - ]]> -

      Upon receiving a Jingle initiate stanza containing a Jingle Audio content description as defined in this document, a target entity iterates through the list of offered payload types, composing an appropriate Jingle Audio response description according to the following rules:

        diff --git a/xep-0168.xml b/xep-0168.xml index 41e7e8a4..f871d8d2 100644 --- a/xep-0168.xml +++ b/xep-0168.xml @@ -133,7 +133,7 @@

      • A client MUST NOT generate a <rap/> element that has an 'app' attribute whose value is "messaging" or that has no 'app' attribute (since the default 'app' is "messaging").

        • - +

        The user's server may have special information that enables it to flag a resource as primary for a given application type. For instance, the server may include a communication policy service that enables the user to define (outside the context of any presence priorities) that she would prefer to be called at her "desktop" resource only between the hours of 9:00 AM and 5:00 PM local time, prefer to be called on her mobile at all other times, and so on.

        To flag the primary resource related to a specific application type, the server shall add a <primary/> child to the relevant RAP element. Here is an example:

        0.5 2006-10-31 psa -

        Updated to track ICE-12; corrected service discovery process; completed editorial review; removed mention of DTMF, which is for audio only.

         +

        Updated to track ICE-12; corrected service discovery process; completed editorial review; removed mention of DTMF, which is for audio only.

         0.4 2006-09-13 psa -

        Updated to track ICE-10; added section on service discovery.

         +

        Updated to track ICE-10; added section on service discovery.

                 0.3 2006-07-12 se/psa -

        Specified that DTMF must use in-band signalling (XEP-0181).

         +

        Specified that DTMF must use in-band signalling (XEP-0181).

                 0.2 2006-03-24 psa -

        Recommended use of RTP-native methods for DTMF.

         +

        Recommended use of RTP-native methods for DTMF.

                 0.1 diff --git a/xep-0181.xml b/xep-0181.xml index f2d5e9d5..8fd6ef0e 100644 --- a/xep-0181.xml +++ b/xep-0181.xml @@ -97,7 +97,7 @@ ]]>

        If the receiving entity does not understand or cannot process the payload, it MUST return an appropriate XMPP error (such as &unavailable; or &unexpected;).

         - +

        Some applications may want to stream Jingle voice RTP directly to a non-XMPP entity, such as a SIP phone. In this scenario, DTMF needs to be sent in the content channel. Jingle DTMF enables Jingle entities to negotiate whether to send RTP over the XMPP signalling channel as described above, or over the content channel using &rfc4733;.

        To request that the voice session switches to RFC 4733, a client sends a <dtmf-method/> element, qualified by the 'http://jabber.org/protocol/info/dmtf' namespace as the payload of a Jingle content-info message:

        - + diff --git a/xep-0188.xml b/xep-0188.xml index d1fafe38..7def564b 100644 --- a/xep-0188.xml +++ b/xep-0188.xml @@ -203,13 +203,13 @@

        The solution should be compatible with existing (and future) cryptographic algorithms and identity certification schemes (including X.509 and PGP). The protocol should also be able to evolve to correct the weaknesses that are inevitably discovered once any cryptographic protocol is in widespread use.

         - +

        Ideally, it would be possible for an XMPP user to exchange encrypted messages (and, potentially, presence information) with users of non-XMPP messaging systems.

        Ideally, it should be possible to encrypt one-to-one communications that are stored for later delivery instead of being delivered immediately, such as so-called "offline messages". However, any vulnerabilities introduced to enable offline communications must not make online communications more vulnerable.

         - +

        For cases where a session is not desired, it should be possible to encrypt, sign and send a single stanza in isolation, so-called "object encryption".

                 diff --git a/xep-0190.xml b/xep-0190.xml index 898f3540..b956f3e0 100644 --- a/xep-0190.xml +++ b/xep-0190.xml @@ -59,11 +59,11 @@ -

        As shown in the basic "session" example in the Simplified Stream Examples (4.8 of RFC 3920), it is a valid transaction to close the outgoing stream by sending +

        As shown in the basic "session" example in the Simplified Stream Examples (4.8 of RFC 3920), it is a valid transaction to close the outgoing stream by sending

        ]]> - then wait for the other entity to close its stream, like this: +

        then wait for the other entity to close its stream, like this:

        ]]> - and shut down the underlying TCP connection.

        +

        and shut down the underlying TCP connection.

        This will ensure that, should the other entity have transmitted any data, it will arrive and be processed before the TCP connection is terminated.

        Special care MUST be taken that under no circumstance further packets may be written to the socket after the stream was closed, until the other side shuts down the socket.

        On the outgoing TCP connection, an implementation MAY do a read-only shutdown of the socket, as long as the other side will safely be able to send its stream termination token.

        diff --git a/xep-0198.xml b/xep-0198.xml index dcf72cb1..d8510f05 100644 --- a/xep-0198.xml +++ b/xep-0198.xml @@ -179,7 +179,7 @@

        Upon approval of this XEP, the Jabber Registrar shall add 'http://jabber.org/features/ack' to its registry of stream features.

         - +

        Upon approval of this XEP, the ®ISTRAR; shall add 'http://jabber.org/protocol/ack' to its registry of protocol namespaces.

                 diff --git a/xep-0202.xml b/xep-0202.xml index b0d61421..2d840039 100644 --- a/xep-0202.xml +++ b/xep-0202.xml @@ -105,7 +105,7 @@

        This protocol was designed in a way that makes migration from XEP-0090 straightforward. This document specifies a different format for the XML character data of the <utc> element (compliant with XEP-0082) and specifies a new <tzo> element for the numeric offset from UTC, while removing the formerly optional and effectively useless <display/> and <tz/> elements.

        Implementations that support XEP-0090 should support the protocol defined herein as soon as possible, but should continue to support the protocol defined in XEP-0090 for backwards compatibility until the status of that specification is changed to Obsolete.

         - +

        Revealing an entity's numeric time zone offset may leak limited information about the entity's current location. If the entity's understanding of UTC is far off from actual UTC, revealing that discrepancy may make it possible for an attacker to send XML stanzas that appear to be in the past or future even though they are not; therefore an entity should use the Network Time Protocol (&rfc0958;) or a similar technology to stay synchronized with actual UTC.

         diff --git a/xep-0205.xml b/xep-0205.xml index 82b22920..8545ebb8 100644 --- a/xep-0205.xml +++ b/xep-0205.xml @@ -78,7 +78,7 @@

        A server implementation SHOULD enable a server administrator to limit the number of connections that it will from a given IP address at any one time. Alternatively, it is possible to limit the number of connections at the TCP layer rather than at the XMPP application layer. Care must be taken in doing so, since limits at the TCP layer might result in an inability to access non-XMPP services. The maximum number of connections per IP address is a matter of deployment policy, and no recommendations are provided herein.

        If an entity attempts to connect but the maximum number of connections has been reached, the receiving server MUST NOT allow the new connection to proceed. There are no XMPP errors associated with this behavior, since it occurs at the binding (TCP or HTTP) level before an XML stream is initiated.

        - +

        A server implementation SHOULD enable a server administrator to limit the number of connection attempts that it will from a given IP address in a given time period (e.g., one hour). Alternatively, it is possible to limit the number of connections at the TCP layer rather than at the XMPP application layer. Care must be taken in doing so, since limits at the TCP layer might result in an inability to access non-XMPP services. It is RECOMMENDED for a deployment to set the maximum number of connection attempts per IP address to 120 per hour.

        If an entity attempts to connect but the maximum number of connections has been reached, the receiving server MUST NOT allow the new connection to proceed. There are no XMPP errors associated with this behavior, since it occurs at the binding (TCP or HTTP) level before an XML stream is initiated.

         diff --git a/xep.xsl b/xep.xsl index 6c39207b..0a568208 100644 --- a/xep.xsl +++ b/xep.xsl @@ -712,7 +712,10 @@ + + +