From b2d5676a299eb3ca3307cdb457d6ee282d566b10 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Thu, 1 Oct 2009 20:01:48 +0000 Subject: [PATCH] 1.13rc6 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3483 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0060.xml | 147 +++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 125 insertions(+), 22 deletions(-) diff --git a/xep-0060.xml b/xep-0060.xml index 4f6db9e4..b4aa426c 100644 --- a/xep-0060.xml +++ b/xep-0060.xml @@ -50,8 +50,8 @@ &ralphm; - 1.13rc5 - in progress, 2009-09-29 + 1.13rc6 + in progress, 2009-10-01 psa
    @@ -62,10 +62,11 @@
  • Removed multiple node discovery since it depended on the deprecated Service Discovery Publishing feature.
  • Defined "room" value for itemreply config option.
  • Added optional 'publisher' attribute to <item/> element.
    • +
  • Added optional 'timestamp' attribute to <item/> element.
  • Added optional <redirect/> child to <delete/> element.
  • Clarified meaning of filtered notifications (they are based on NodeIDs, not payload namespaces).
  • Added pubsub-on-a-jid service discovery feature for explicit discovery that an IM and presence account also functions as a virtual pubsub service.
    • -
  • Added purge_offline node configuration option for purging the node when the owner goes offline, for use in certain extended presence applications.
    • +
  • Added purge_offline node configuration option for purging the node when the relevant publisher goes offline, for use in certain extended presence applications.
  • Added item_expire node configuration option for automatically removing items after a certain number of seconds.
  • Added notification_type node configuration option for defining which value of the <message/> type attribute shall be used for notifications.
  • Added retrieve-default-sub feature for retrieving default subscription configuration from a node (as you can retrieve default node configuration from the service).
    • @@ -473,7 +474,7 @@ And by opposing end them?
    • An entity MUST be able to publish events to a service such that all subscribers to a node receive notification of the event. See Publish an Item to a Node.
    • An entity MUST be able to subscribe to a node (or be informed that subscription is not allowed). See Subscribe to a Node.
      • -
    • An entity MUST be allowed to be affiliated with a node. Allowable affiliations are owner, publisher, none, and outcast. Implementations MUST support affiliations of owner and none, and MAY support affiliations of outcast and publisher. See Affiliations.
      • +
    • An entity MUST be allowed to be affiliated with a node. Allowable affiliations are owner, publisher, none, and outcast. Implementations MUST support affiliations of owner and none, and MAY support affiliations of outcast, publisher, and publish-only. See Affiliations.
    • An entity MUST be allowed to query the pubsub service (or a specific node) to determine what optional features of this specification the service (or node) implements. This query MUST use the Service Discovery (disco#info) protocol. See Discover Node Information.
    @@ -504,7 +505,7 @@ And by opposing end them? Subscribe Retrieve Items Publish Item - Delete Item + Delete Single Item Configure Node Delete Node Purge Node @@ -524,10 +525,20 @@ And by opposing end them? Yes Yes Yes + Yes * + No + No + Yes * + + + Publish-Only + No + No + Yes + No * Yes No - No - Yes/No * + No * Member @@ -560,7 +571,7 @@ And by opposing end them? No -

    * Note: A service MAY allow any publisher to delete any item once it has been published to that node instead of allowing only the original publisher to remove it.

    +

    * Note: A service MAY allow any publisher to delete / purge any item once it has been published to that node instead of allowing only the original publisher to remove it. This behavior is NOT RECOMMENDED for the publish-only affiliation, which SHOULD be allowed to delete only items that the publish-only entity has published.

    The ways in which an entity changes its affiliation with a node are well-defined. Typically, action by an owner is required to make an affiliation state transition. Affiliation changes and their triggering actions are specified in the following table.

    @@ -942,7 +953,7 @@ And by opposing end them? - +
    pubsub#languageLanguage
    pubsub#publisherPublisher
    pubsub#titleTitle
    pubsub#typeType The pubsub type SHOULD be the namespace that defines the payload (such as 'http://www.w3.org/2005/Atom'), if payloads are supported.
    pubsub#typeType The pubsub type is the namespace that defines the payload (such as 'http://www.w3.org/2005/Atom'), if payloads are supported.
    @@ -1124,7 +1135,7 @@ And by opposing end them? to='francisco@denmark.lit' id='affil2'> - + @@ -2667,6 +2678,43 @@ And by opposing end them? ]]> + +

    If configured to do so, the service can include the pubisher of the item when it generates notifications.

    + + + + + [ ... ENTRY ... ] + + + + + ]]> +

    The value of the 'publisher' attribute MUST be generated by the service, not accepted by the service in the published item, since allowing the publisher to assert its JID would open the possibility of spoofing.

    +

    The JID stamped by the service can be either (1) the full JID &LOCALFULL; of the publisher as taken the 'from' attribute of the IQ-set used to publish the item or (2) the bare JID &LOCALBARE; of the publisher as derived from a formal affiliation in the explicit list of whitelisted publishers.

    +     + +

    If configured to do so, the service can include the timestamp of the item when it generates notifications.

    + + + + + [ ... ENTRY ... ] + + + + + ]]> +

    The value of the 'timestamp' attribute MUST conform to the dateTime format specified in XEP-0082, in UTC.

    +

    The value of the 'timestamp' attribute MUST be generated by the service, not accepted by the service in the published item.

    +

    The combination of the ItemID and item timestamp MUST be unique, such that a subsequent publish with the same ItemID MUST have a different (later) value of the 'timestamp' attribute than the earlier published item, even at the expense of literal accuracy (thus it is similar to the modtime attribute in ACAP &rfc2244;).

    +

    However, the 'timestamp' attribute does not provide accurate tracking of the exact chronology of the items published at a node, and a recipient cannot rely on this attribute for versioning, synchronization, or other similar purposes.

    +

    If a single entity is subscribed to a node multiple times, the service SHOULD notate the event notification so that the entity can determine which subscription identifier(s) generated this event. If these notations are included, they MUST use the &xep0131; format and SHOULD be included after the event notification information (i.e., as the last child of the &MESSAGE; stanza).

    - + @@ -3334,7 +3382,7 @@ And by opposing end them? publishers + label='Purge all items when the relevant publisher goes offline?'> 0 - + @@ -3675,7 +3723,7 @@ And by opposing end them? publishers + label='Purge all items when the relevant publisher goes offline?'> 0     -

    If no error occurs, the service MUST return the list of entities whose affiliation is "owner", "publisher", or "outcast" (it MUST NOT return entities whose affiliation is "none").

    +

    If no error occurs, the service MUST return the list of entities whose affiliation is "owner", "publisher", "publish-only", or "outcast" (it MUST NOT return entities whose affiliation is "none").

    -

    If the node or service does not support the requested affiliation, it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "member-affiliation", "outcast-affiliation", or "publisher-affiliation" as appropriate.

    +

    If the node or service does not support the requested affiliation, it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "member-affiliation", "outcast-affiliation", "publisher-affiliation", or "publish-only-affiliation" as appropriate.

    OPTIONAL Publishing Options + + publish-only-affiliation + The publish-only affiliation is supported. + OPTIONAL + Affiliations + publisher-affiliation The publisher affiliation is supported. @@ -5037,7 +5091,45 @@ And by opposing end them? -

    Implementations of pubsub MAY enable an entity to subscribe to a node temporarily, i.e., only for as long as the subscriber is online in its current presence session. To subscribe temporarily, the subscriber sets the "pubsub#expire" subscription configuration option to a value of "presence". The service will then automatically cancel the subscription when it receives presence of type "unavailable" from the subscriber.

    +

    An implementation MAY enable an entity to subscribe to a node temporarily, i.e., only for as long as the subscriber is online in its current presence session. To subscribe temporarily, the subscriber MUST set the "pubsub#expire" subscription configuration option to a literal value of "presence".

    + + + + + + http://jabber.org/protocol/pubsub#subscribe_options + + ... + presence + ... + + + + + ]]> +

    The service will then automatically cancel the subscription when it receives presence of type "unavailable" from the subscriber.

    +

    An implementation MAY enable the node owner to force all subscriptions to be temporary, which is useful for nodes that are also configured to use presence-based delivery. This setting uses the "pubsub#tempsub" node configuration option set to a value of true.

    + + + + + + http://jabber.org/protocol/pubsub#node_config + + true + + + + + ]]>     @@ -5045,7 +5137,7 @@ And by opposing end them? -

    If the pubsub service supports presence-based delivery and a node is configured to enable such delivery, the service MAY offer a value of "iq" for the "pubsub#notification_type" node configuration option. If this value is chosen, the service shall deliver notifications in XMPP IQ stanzas instead of in XMPP message stanzas. Because IQ stanzas are addressed to full JIDs &LOCALFULL;, if the service does not know the full JID of a given subscriber then it MAY send notifications to the bare JID &LOCALBARE; of the subscriber via the usual message stanza, or MAY not send a notification at all. The IQ stanza containing a notification shall be of type "set", and in accordance with the semantics of the IQ stanza defined in RFC 3920 the recipient MUST return either an IQ stanza of type "result" or an IQ stanza of type "error". An example follows

    +

    If the pubsub service supports presence-based delivery and a node is configured to enable such delivery, the service MAY offer a value of "iq" for the "pubsub#notification_type" node configuration option. If this value is chosen, the service shall deliver notifications in XMPP IQ stanzas instead of in XMPP message stanzas. Because IQ stanzas are addressed to full JIDs &LOCALFULL;, if the service does not know the full JID of a given subscriber then it SHOULD NOT send a notification at all (just as it would not for presence-based delivery via &MESSAGE; stanzas). The IQ stanza containing a notification shall be of type "set", and in accordance with the semantics of the IQ stanza defined in RFC 3920 the recipient MUST return either an IQ stanza of type "result" or an IQ stanza of type "error". An example follows

    Publication with publish options is supported. XEP-0060 + + http://jabber.org/protocol/pubsub#publish-only-affiliation + The publish-only affiliation is supported. + XEP-0060 + http://jabber.org/protocol/pubsub#publisher-affiliation The publisher affiliation is supported. @@ -6024,6 +6121,9 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae + @@ -6098,7 +6198,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae + label='Whether to purge all items when the relevant publisher goes offline'/> @@ -6115,9 +6215,9 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae on_sub_and_presence - + 1 @@ -6312,6 +6412,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings + @@ -6537,6 +6638,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings + @@ -6779,6 +6881,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings +