diff --git a/ref.xsl b/ref.xsl index 7848a555..6c77535c 100644 --- a/ref.xsl +++ b/ref.xsl @@ -25,7 +25,7 @@ THE SOFTWARE. --> diff --git a/xep-0052.xml b/xep-0052.xml index 5183968b..36637c3f 100644 --- a/xep-0052.xml +++ b/xep-0052.xml @@ -80,7 +80,7 @@

Primary Flow:

  1. Determine if the receiver supports FT through disco/browse. [E1]
    2. -
  2. Sender sends meta-data and available methods to receiver
    3. +
  3. Sender sends metadata and available methods to receiver
  4. Receiver sends the accepted method to Sender and any range/offset information. [E2],[E3]
  5. Sender and Receiver establish the negotiated method[E4]
    6. @@ -214,7 +214,7 @@

    At this point the sender will setup the stream method and begin to transfer data. The stream itself can use the file transfer namespace to tie the - meta-data to the actual data sent, this is illustrated below using iq:oob. + metadata to the actual data sent, this is illustrated below using iq:oob.

    @@ -252,7 +252,7 @@

    - If the transfer does not complete, for any reason after the meta-data + If the transfer does not complete, for any reason after the metadata negotiation, the party that has the error SHOULD send an error 500 and the file id to the other party.

    @@ -266,9 +266,9 @@ -

    By staying in just the realm of negotiating the meta-data to a file, we allow for multiple transport layers, or streams, to be used. Some streams will need to tie the meta-data to the actual data transfer, to help accomodate this the stream may use the <file/> with an action of start and the correct id. The <file/> could be transported in the stream negotiations, or along side it. Although this spec does not mandate any specific methods to new stream authors, it does provide the syntax for the currently existing "iq:oob" system.

    +

    By staying in just the realm of negotiating the metadata to a file, we allow for multiple transport layers, or streams, to be used. Some streams will need to tie the metadata to the actual data transfer, to help accomodate this the stream may use the <file/> with an action of start and the correct id. The <file/> could be transported in the stream negotiations, or along side it. Although this spec does not mandate any specific methods to new stream authors, it does provide the syntax for the currently existing "iq:oob" system.

    -

    For an "iq:oob" transfer to be related to its meta-data, a <file/> is transported along side the <query/>. The id used on the <file/> is the id for the meta-data of the actual data that is being sent. The action on the <file/> is "start". An example of this can be found in the Basic Usage section.

    +

    For an "iq:oob" transfer to be related to its metadata, a <file/> is transported along side the <query/>. The id used on the <file/> is the id for the metadata of the actual data that is being sent. The action on the <file/> is "start". An example of this can be found in the Basic Usage section.

         @@ -292,7 +292,7 @@ ]]> -

    The <file/> element is the "workhorse" element. This element is used to convey meta-data and report file transfer actions. This elemnt contains attributes for file meta-data and actions, and MAY contain a <desc/>, a <range/>, and zero or more <feature xmlns='jabber:iq:negotiate'/> (&xep0020;) elements.

    +

    The <file/> element is the "workhorse" element. This element is used to convey metadata and report file transfer actions. This elemnt contains attributes for file metadata and actions, and MAY contain a <desc/>, a <range/>, and zero or more <feature xmlns='jabber:iq:negotiate'/> (&xep0020;) elements.

    The "id" attribute specifies the identifier for this particular file transfer. This attribute MUST be present at all times. There are no value requirements other than it MUST be unique between the sender and receiver.

    The "action" attribute specifies the action to undertake with the given file. This attribute SHOULD be present in most cases. If not present, the value "offer" is implied. The value of "action" MUST be one of the following:

    @@ -310,7 +310,7 @@ - + @@ -342,7 +342,7 @@ conditions, error codes and descriptions:

    • - Declining Transfer (403): During the meta-data negotiation + Declining Transfer (403): During the metadata negotiation the receiver may decline the transfer by sending the 403 error. The <error/> CDATA MAY contain a descriptive reason why, but is not necessary. diff --git a/xep-0060.xml b/xep-0060.xml index 0c1e66a7..e724c154 100644 --- a/xep-0060.xml +++ b/xep-0060.xml @@ -171,7 +171,7 @@
    • Removed the notion of batch publishing because it makes information coherence and atom handling excessively difficult.
    • Added error handling for too-many-subscriptions to help prevent a certain denial of service attack.
    • Added process for retrieving default subscription configuration options for leaf nodes, by omitting the 'node' attribute on the <default/> element (also added the <default/> element to the schema for the http://jabber.org/protocol/pubsub namespace, since it was missing).
      • -
    • Removed informational mapping of node meta-data to Dublin Core.
      • +
    • Removed informational mapping of node metadata to Dublin Core.
    @@ -256,7 +256,7 @@
  6. Changed retrieval of default node configuration options to use <default/> element, not <configure/> element
  7. Allowed caching of last published item
  8. Added pubsub#deliver subscription option
    9. -
  9. Added meta-data fields for pubsub#owners and pubsub#contact
    10. +
  10. Added metadata fields for pubsub#owners and pubsub#contact
  11. Changed element for retrieval of default node configuration options from <configure/> to <default/> to prevent ambiguity related to configuration of root collection node
  12. Specified pubsub#node_type configuration field
  13. Specified pubsub#collection SHIM header
    14. @@ -285,7 +285,7 @@
  14. Added type attribute for the <create/> and <configure/> elements to differentiate between leaf nodes and collection nodes
  15. In Section 8.1.7, changed affiliations retrieval support to SHOULD and added pubsub#retrieve-affiliations feature
  16. In Section 8.1.10, removed two duplicate examples
    17. -
  17. In Section 8.1.12, clarified relationship between normal disco#info data and node meta-data (which uses a service discovery extension)
    18. +
  18. In Section 8.1.12, clarified relationship between normal disco#info data and node metadata (which uses a service discovery extension)
  19. In Section 8.2.4, specified that node purgation MUST result in one event notification, not a notification per item
  20. In Section 8.1.8, further specified handling of SubIDs
  21. Clarified nature of the pubsub#type field
    22. @@ -301,7 +301,7 @@ 1.62004-07-13pgm/psa -

    Added service discovery features for pubsub#meta-data, and pubsub#retrieve-items. Added pubsub#subscription_depth configuration option. Specified pubsub-specific error condition elements qualified by pubsub#errors namespace.

     +

    Added service discovery features for pubsub#metadata, and pubsub#retrieve-items. Added pubsub#subscription_depth configuration option. Specified pubsub-specific error condition elements qualified by pubsub#errors namespace.

     1.5 @@ -367,7 +367,7 @@ 0.12 2003-08-13 pgm/psa -

    Defined public vs. private nodes; described how changes to existing nodes might trigger meta-node events (e.g., configuration changes); changed <x/> to <event/> for #events namespace; added meta-data about meta-nodes; fully defined XMPP Registrar considerations.

     +

    Defined public vs. private nodes; described how changes to existing nodes might trigger meta-node events (e.g., configuration changes); changed <x/> to <event/> for #events namespace; added metadata about meta-nodes; fully defined XMPP Registrar considerations.

         0.11 @@ -584,7 +584,7 @@ And by opposing end them?
  22. A node MAY be configured to persist published items to some persistent storage mechanism.
  23. A node MAY be configured to persist only a limited number of items.
  24. A service MAY support collections as described in XEP-0248.
    25. -
  25. A service or node MAY support extended service discovery information (meta-data).
    26. +
  26. A service or node MAY support extended service discovery information (metadata).
    27. @@ -981,7 +981,7 @@ And by opposing end them? ]]> -

    The "disco#info" result MAY include detailed meta-data about the node, encapsulated in the &xep0004; format as described in &xep0128;, where the data form context is specified by including a FORM_TYPE of "http://jabber.org/protocol/pubsub#meta-data" in accordance with &xep0068;. If meta-data is provided, it SHOULD include values for all configured options as well as "automatic" information such as the node creation date, a list of publishers, and the like.

    +

    The "disco#info" result MAY include detailed metadata about the node, encapsulated in the &xep0004; format as described in &xep0128;, where the data form context is specified by including a FORM_TYPE of "http://jabber.org/protocol/pubsub#metadata" in accordance with &xep0068;. If metadata is provided, it SHOULD include values for all configured options as well as "automatic" information such as the node creation date, a list of publishers, and the like.

    ]]> - - http://jabber.org/protocol/pubsub#meta-data + http://jabber.org/protocol/pubsub#metadata http://www.w3.org/2005/Atom @@ -1041,7 +1041,7 @@ And by opposing end them? ]]> -

    Note: Node meta-data can be set in many ways. Some of it is based on node configuration (e.g., the owner's JID) whereas some of it may be dynamic (e.g., the number of subscribers). Any static information to be provided in the node meta-data SHOULD be provided as fields in the node configuration form.

    +

    Note: Node metadata can be set in many ways. Some of it is based on node configuration (e.g., the owner's JID) whereas some of it may be dynamic (e.g., the number of subscribers). Any static information to be provided in the node metadata SHOULD be provided as fields in the node configuration form.

    Note: The pubsub#language field SHOULD be list-single so that the pubsub service can present an appropriate list of languages and language codes.

     @@ -5118,8 +5118,8 @@ And by opposing end them?     - - + + @@ -6013,8 +6013,8 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae XEP-0060 - http://jabber.org/protocol/pubsub#meta-data - Node meta-data is supported. + http://jabber.org/protocol/pubsub#metadata + Node metadata is supported. XEP-0060 @@ -6136,7 +6136,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
  27. Authorization of subscriptions using the 'http://jabber.org/protocol/pubsub#subscribe_authorization' namespace.
  28. Configuration of subscription options using the 'http://jabber.org/protocol/pubsub#subscribe_options' namespace.
  29. Configuration of a node using the 'http://jabber.org/protocol/pubsub#node_config' namespace.
    30. -
  30. Setting of metadata information using the 'http://jabber.org/protocol/pubsub#meta-data' namespace.
    31. +
  31. Setting of metadata information using the 'http://jabber.org/protocol/pubsub#metadata' namespace.

    32. The registry submissions associated with these namespaces are defined below.

    Note: There is no requirement that configuration fields need to be registered with the XMPP Registrar. However, as specified in Section 3.4 of XEP-0068, names of custom (unregistered) fields MUST begin with the characters "x-" if the form itself is scoped by a registered FORM_TYPE.

    @@ -6240,10 +6240,10 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae ]]> - + - http://jabber.org/protocol/pubsub#meta-data + http://jabber.org/protocol/pubsub#metadata XEP-0060 Forms enabling setting of metadata information about pubsub nodes - + diff --git a/xep-0103.xml b/xep-0103.xml index 999ebeca..aebae721 100644 --- a/xep-0103.xml +++ b/xep-0103.xml @@ -60,7 +60,7 @@

    The requirements this protocol fulfills are:

    • Simple usage that can be easily extended
      • -
    • Provide any meta-data necessary for using the URL
      • +
    • Provide any metadata necessary for using the URL
    • Compatibility with &xep0095;
    diff --git a/xep-0105.xml b/xep-0105.xml index 2b29e29c..9e3acf17 100644 --- a/xep-0105.xml +++ b/xep-0105.xml @@ -7,7 +7,7 @@
    Tree Transfer Stream Initiation Profile - A profile describing meta-data for transferring trees of files using stream inititation. + A profile describing metadata for transferring trees of files using stream inititation. &LEGALNOTICE; 0105 Deferred @@ -41,7 +41,7 @@
    -

    File transfers of entire trees require a lot more meta-data and prior setup to link paths to files with unique ids so that clients can track them. This profile provides a more robust method of defining that meta-data so that directory trees can be transfered.

    +

    File transfers of entire trees require a lot more metadata and prior setup to link paths to files with unique ids so that clients can track them. This profile provides a more robust method of defining that metadata so that directory trees can be transfered.
      diff --git a/xep-0142.xml b/xep-0142.xml index 43fabb36..89fd79b7 100644 --- a/xep-0142.xml +++ b/xep-0142.xml @@ -163,7 +163,7 @@ U: U: U: ]]> -

      The request may contain application-specific meta-data to help the service determine queuing of the user or Data Forms data when submitting form information (definition of such data is out of scope for this document). In addition, the <join-queue> element MAY contain a standard <queue-notifications/> element, which indicates that the user would like to receive user status updates about their state in the queue.

      +

      The request may contain application-specific metadata to help the service determine queuing of the user or Data Forms data when submitting form information (definition of such data is out of scope for this document). In addition, the <join-queue> element MAY contain a standard <queue-notifications/> element, which indicates that the user would like to receive user status updates about their state in the queue.

      A successful join results in a success response:

      @@ -213,7 +213,7 @@ S: from='support@workgroup.example.com' S: to='user@example.net/home' S: id='id1'/> ]]> -

      The following XML is another example where meta-data is sent by the user to assist the workgroup server in queuing and routing (naturally, the custom namespace that qualifies the <crm/> element in this example would be defined outside the context of this specification).

      +

      The following XML is another example where metadata is sent by the user to assist the workgroup server in queuing and routing (naturally, the custom namespace that qualifies the <crm/> element in this example would be defined outside the context of this specification).

      Agents join a workgroup to indicate they are capable of handling conversations with users. Agent membership in the workgroup is expected to be a long term, persistent relationship similar to roster membership. For example, a customer support agent may join the support@workgroup.example.com workgroup when they begin working at example.com and will only depart when they leave that position. The wide variety of relationships, processes and permissions associated with joining and leaving workgroups lies outside the scope of this document.

      -

      Once an agent has joined a workgroup they will receive workgroup status updates to inform them of the status of other members of the workgroup. Agents are responsible for updating the workgroup service with their presence so the service can intelligently route chat requests to the 'best' agent. Workgroup agent presence uses standard XMPP presence packets with optional meta-data to help routing of chat requests to agents. Some meta-data will be standard and defined later in this document. It is expected that other deployment specific meta-data will also be needed to make routing decisions.

      +

      Once an agent has joined a workgroup they will receive workgroup status updates to inform them of the status of other members of the workgroup. Agents are responsible for updating the workgroup service with their presence so the service can intelligently route chat requests to the 'best' agent. Workgroup agent presence uses standard XMPP presence packets with optional metadata to help routing of chat requests to agents. Some metadata will be standard and defined later in this document. It is expected that other deployment specific metadata will also be needed to make routing decisions.

      The general agent workgroup state diagram is shown below:

      | | | ]]>       -

      The agent must inform the workgroup of its presence by sending it a directed (not broadcast) presence update packet. Agent presence updates use standard XMPP presence with optional meta-data. However, there must always be an agent-status workgroup sub-element in the presence packet to indicate that the presence update relates to agent workgroup presence. Agent workgroup presence is designed to allow a separation between the agent's normal XMPP presence (server-managed via rosters) and their presence with the workgroup.

      +

      The agent must inform the workgroup of its presence by sending it a directed (not broadcast) presence update packet. Agent presence updates use standard XMPP presence with optional metadata. However, there must always be an agent-status workgroup sub-element in the presence packet to indicate that the presence update relates to agent workgroup presence. Agent workgroup presence is designed to allow a separation between the agent's normal XMPP presence (server-managed via rosters) and their presence with the workgroup.

      U: @@ -561,7 +561,7 @@ U:
    • xa - The agent is physically away from their terminal and should not have a chat routed to them.
    • dnd - The agent is busy and should not be disturbed. However, special case, or extreme urgency chats may still be offered to the agent although offer rejection or offer timeouts are highly likely.
    -

    Agents MAY also embed meta-data to help the workgroup service route chat requests, using the <max-chats> element, which specifies the maximum number of chats the agent can handle. If a presence is sent to the workgroup that does not contain the max-chats value, the "default setting" will be assumed. The value of the default setting for an agent is up to an implementation. The max-chats value sent from agent to workgroup service is a 'hint' or recommended value. The workgroup service is not obliged to accept this value. The actual max-chats value for the agent will be sent to the agent via the next Agent Status Update. This allows administrators to constrain agent behavior in order to enforce company policy, quality assurance, etc.

    +

    Agents MAY also embed metadata to help the workgroup service route chat requests, using the <max-chats> element, which specifies the maximum number of chats the agent can handle. If a presence is sent to the workgroup that does not contain the max-chats value, the "default setting" will be assumed. The value of the default setting for an agent is up to an implementation. The max-chats value sent from agent to workgroup service is a 'hint' or recommended value. The workgroup service is not obliged to accept this value. The actual max-chats value for the agent will be sent to the agent via the next Agent Status Update. This allows administrators to constrain agent behavior in order to enforce company policy, quality assurance, etc.

    There are no defined error conditions for presence updates.

     @@ -750,7 +750,7 @@ S: seconds S: S: ]]> -

    Application specific meta-data will normally be added as a sub-element of <offer> to help agents decide whether to accept or not (formats for which are out of scope for this document). An optional <timeout> sub-element may be included indicating the amount of time the offer stands before the service will revoke it.

    +

    Application specific metadata will normally be added as a sub-element of <offer> to help agents decide whether to accept or not (formats for which are out of scope for this document). An optional <timeout> sub-element may be included indicating the amount of time the offer stands before the service will revoke it.

    ]]> @@ -773,7 +773,7 @@ A: from='alice@example.com/work' A: id='id1' A: type='result'/> ]]> -

    The following is a more typical offer containing meta-data about the user. The offer will be revoked in 30 seconds.

    +

    The following is a more typical offer containing metadata about the user. The offer will be revoked in 30 seconds.

    The server sends an invitation to the agent to begin their conversation with the user, structured according to the format defined in XEP-0045. The 'from' attribute of the <invite/> element MUST be set to the JID of the workgroup.

    -

    In order to match invitations to offers, all invitations SHOULD include meta-data in the <offer/> element, with the JID of the user specified via the 'jid' attribute. The typical meta-data fragment would appear as:

    +

    In order to match invitations to offers, all invitations SHOULD include metadata in the <offer/> element, with the JID of the user specified via the 'jid' attribute. The typical metadata fragment would appear as:

    ]]> @@ -927,7 +927,7 @@ S:
  32. Use the <identity> type='workgroup'.
  33. Use the <feature> var='http://jabber.org/protocol/workgroup'.
    34. -

    An example of discovery browsing is included. Notice how probing starts at the server (example.com) revealing the workgroup service by its JID (workgroup.example.com) and a simple, human friendly name ("Example.com Live Assistant"). It is only during the discovery probing of the service that it is identified as a workgroup using the <identity> and <feature> tags. Finally individual workgroups (support and sales) can be discovered on the Workgroup service. When individual workgroups are probed, the <identity> and <feature> tags are again presented to identify them as workgroups along with (optional) associated meta-data.

    +

    An example of discovery browsing is included. Notice how probing starts at the server (example.com) revealing the workgroup service by its JID (workgroup.example.com) and a simple, human friendly name ("Example.com Live Assistant"). It is only during the discovery probing of the service that it is identified as a workgroup using the <identity> and <feature> tags. Finally individual workgroups (support and sales) can be discovered on the Workgroup service. When individual workgroups are probed, the <identity> and <feature> tags are again presented to identify them as workgroups along with (optional) associated metadata.

    U: diff --git a/xep-0214.xml b/xep-0214.xml index 4c33bb6d..280aab60 100644 --- a/xep-0214.xml +++ b/xep-0214.xml @@ -127,7 +127,7 @@ - http://jabber.org/protocol/pubsub#meta-data + http://jabber.org/protocol/pubsub#metadata Juliet's Sonnets Optional Description @@ -163,7 +163,7 @@ - http://jabber.org/protocol/pubsub#meta-data + http://jabber.org/protocol/pubsub#metadata Sonnets About Romeo Optional Description @@ -218,7 +218,7 @@ - http://jabber.org/protocol/pubsub#meta-data + http://jabber.org/protocol/pubsub#metadata sonnet.txt Sonnet 42 @@ -234,7 +234,7 @@ - + 5623 2006-12-13T18:30:02Z 59282c5db190bdc3b152c5b38363442bfda8ebdd @@ -332,7 +332,7 @@ - http://jabber.org/protocol/pubsub#meta-data + http://jabber.org/protocol/pubsub#metadata Sonnet 42 sonnet.txt diff --git a/xep-0248.xml b/xep-0248.xml index c6a12088..f31a91e9 100644 --- a/xep-0248.xml +++ b/xep-0248.xml @@ -248,7 +248,7 @@ ]]> -

    The notification event MAY also include the node meta-data, formatted using the &xep0004; protocol.

    +

    The notification event MAY also include the node metadata, formatted using the &xep0004; protocol.

    - http://jabber.org/protocol/pubsub#meta-data + http://jabber.org/protocol/pubsub#metadata 2003-07-29T22:56Z diff --git a/xep-0258.xml b/xep-0258.xml index ba65972f..fae35433 100644 --- a/xep-0258.xml +++ b/xep-0258.xml @@ -16,8 +16,8 @@
    Security Labels in XMPP This document describes the use of security labels in XMPP. The document specifies - how security label meta-data is carried in XMPP, when this meta-data should or should - not be provided, and how the meta-data is to be processed. &LEGALNOTICE; + how security label metadata is carried in XMPP, when this metadata should or should + not be provided, and how the metadata is to be processed. &LEGALNOTICE; 0258 Draft Standards Track @@ -167,7 +167,7 @@ standardized formats for security labels, clearances, and security policy are generalized and do have application in non-government networks.

    This document describes the use of security labels in &xmpp;. The document specifies how - security label meta-data is carried in XMPP. It standardizes a mechanism for carrying + security label metadata is carried in XMPP. It standardizes a mechanism for carrying ESS Security Labels in XMPP, as well as provides for use of other label formats. ESS Security Labels are specified in &rfc2634;. ESS Security Labels are commonly used in conjunction with &X.500; clearances and either X.841 or &SDN.801c; security @@ -195,8 +195,8 @@ ]]>

    Note: The &IC-ISM; label example is for illustrative purposes only.

    -

    The document details when security label meta-data should or should not be provided, and - how this meta-data is to be processed.

    +

    The document details when security label metadata should or should not be provided, and + how this metadata is to be processed.

    This document does not provide:

      @@ -248,7 +248,7 @@ -

      An element, &SECURITYLABEL;, is defined to carry security label meta-data. This meta-data +

      An element, &SECURITYLABEL;, is defined to carry security label metadata. This metadata includes a security label, zero or more equivalent security labels, and optionally display marking data.

      ]]> -

      The security label meta-data is carried in an &SECURITYLABEL; element. The +

      The security label metadata is carried in an &SECURITYLABEL; element. The &SECURITYLABEL; element which contains one and only one &LABEL; element, zero or more &EQUIVALENTLABEL; elements, and an optional &DISPLAYMARKING; element.

      The &LABEL; provides the primary security label. It is commonly issued by the sender diff --git a/xep-0327.xml b/xep-0327.xml index 4404be69..5d1b7603 100644 --- a/xep-0327.xml +++ b/xep-0327.xml @@ -430,7 +430,7 @@

      Sessions may be established either at the request of the Rayo client (an outbound call) or as a result of a 3rd party request (an inbound call). Each scenario differs in the Rayo protocol only up to the point at which the session is established and media begins to flow. First we shall examine the sequence of stanzas passed between server and client in each of these scenarios.

      -

      In order for a client to establish a new outbound call, it MUST first send a dial command to the server, indicating the proposed target for the call, its apparent source, and any meta-data to send to the target as headers.

      +

      In order for a client to establish a new outbound call, it MUST first send a dial command to the server, indicating the proposed target for the call, its apparent source, and any metadata to send to the target as headers.

    -

    The server MUST present the recording for consumption by the client by way of recording meta-data on the complete reason, including a URI at which the recording may be fetched. It MUST provide uri, duration & size data as specified on the recording element.

    +

    The server MUST present the recording for consumption by the client by way of recording metadata on the complete reason, including a URI at which the recording may be fetched. It MUST provide uri, duration & size data as specified on the recording element.

    - May be any component specific meta-data elements, such as . + May be any component specific metadata elements, such as . diff --git a/xep-0342.xml b/xep-0342.xml index 421dd362..51e805ec 100644 --- a/xep-0342.xml +++ b/xep-0342.xml @@ -87,7 +87,7 @@

    The receivefax completion reason MUST be one of the core Rayo reasons or finish (indicating that the document was fully received). Receivefax component completion provides a fax element only when a document was successfully received.

    -

    The server MUST present the fax for consumption by the client by way of fax meta-data on the complete reason, including a URI at which the document may be fetched. It MUST provide url, resolution, file size & page count data as specified on the fax element. In cases of partial receipt of a fax, a fax element MAY be returned in addition to the error completion reason.

    +

    The server MUST present the fax for consumption by the client by way of fax metadata on the complete reason, including a URI at which the document may be fetched. It MUST provide url, resolution, file size & page count data as specified on the fax element. In cases of partial receipt of a fax, a fax element MAY be returned in addition to the error completion reason.

    pw

    - Added the possibility for owners to update meta-data about its things. + Added the possibility for owners to update metadata about its things. This is done through the optional attribute jid on the update element.

    Added ROOM to the list of predefined tag names.

    @@ -1134,7 +1134,7 @@

    - An owner of a thing can also update the meta-data of a thing it has claimed. To do this, you simply add a jid attribute containing the JID of the thing to the + An owner of a thing can also update the metadata of a thing it has claimed. To do this, you simply add a jid attribute containing the JID of the thing to the update element. (If this attribute is not present, the JID is assumed to be that of the sender of the message.)

    @@ -1157,7 +1157,7 @@ ]]>

    - The owner can update meta-data of things behind concentrators also. To do this, the corresponding attributes nodeId, sourceId + The owner can update metadata of things behind concentrators also. To do this, the corresponding attributes nodeId, sourceId and cacheType must be used to identify the thing, as follows:

    @@ -1895,7 +1895,7 @@

    If using external services when creating QR-codes, like the Google Charts API used in this document, make sure HTTPS is used and certificates validated. If HTTP is used, - meta-data tags used in Thing Registry registrations can be found out by sniffing the network, making it possible to hijack the corresponding devices. + metadata tags used in Thing Registry registrations can be found out by sniffing the network, making it possible to hijack the corresponding devices.

    diff --git a/xep-0379.xml b/xep-0379.xml index d9e44dd5..17aa5a47 100644 --- a/xep-0379.xml +++ b/xep-0379.xml @@ -165,7 +165,7 @@ xmpp:romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;name=Romeo+Montague
    1. XSF: a central place would provide a common ground for a curated client list and ensure long-term availability. However, - the operator would be able to collect meta-data and abuse authentication tokens.
      2. + the operator would be able to collect metadata and abuse authentication tokens.
    2. Client developer: the developer of Romeo's client can provide a landing page for invitation requests created with this client. This is a feasible short-term solution and allows to recommend @@ -175,7 +175,7 @@ xmpp:romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;name=Romeo+Montague down, invitation links created with the client will cease working.
    3. User's server: this is the optimal long-term solution, as the user's server is already entrusted with the relevant - meta-data and will exist at least as long as the user's account on that + metadata and will exist at least as long as the user's account on that server. However, this requires an additional server component to query for invitation URIs and a web server hosting the landing page. Furthermore, the server operator needs to maintain the list of
    offerThe file transfer is offered (meta-data MUST be present)The file transfer is offered (metadata MUST be present)
    start Affiliations
    meta-dataNode meta-data is supported.metadataNode metadata is supported. RECOMMENDED