diff --git a/xep-0060.xml b/xep-0060.xml index e048905d..65a3515a 100644 --- a/xep-0060.xml +++ b/xep-0060.xml @@ -442,7 +442,7 @@ And by opposing end them?

To manage permissions, the protocol defined herein uses a hierarchy of affiliations, similiar to those introduced in &xep0045;.

-

Support for the "owner" and "none" affiliations is REQUIRED. Support for all other affiliations is RECOMMENDED. Particular kinds of pubsub services MAY enforce additional requirements.

+

Support for the "owner" and "none" affiliations is REQUIRED. Support for all other affiliations is RECOMMENDED. For each non-required affiliation supported by an implementation, it SHOULD return a service discovery feature of "name-affiliation" where "name" is the name of the affiliation, such as "member", "outcast", or "publisher" (see the Feature Summary). Particular kinds of pubsub services MAY enforce additional requirements (e.g., requiring support for a given non-required affiliation or for all affiliations).

@@ -5163,6 +5163,12 @@ And by opposing end them? + + + + + + @@ -5226,8 +5232,8 @@ And by opposing end them? - - + + @@ -5942,13 +5948,18 @@ O, what a rogue and peasant slave am I! XEP-0060 - http://jabber.org/protocol/pubsub#meta-data - Node meta-data is supported. + http://jabber.org/protocol/pubsub#manage-subscription + Node owners may manage subscriptions. XEP-0060 - http://jabber.org/protocol/pubsub#manage-subscription - Node owners may manage subscriptions. + http://jabber.org/protocol/pubsub#member-affiliation + The member affiliation is supported. + XEP-0060 + + + http://jabber.org/protocol/pubsub#meta-data + Node meta-data is supported. XEP-0060 @@ -6524,6 +6535,8 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings + + @@ -6727,6 +6740,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings + @@ -6957,6 +6971,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings + diff --git a/xep-0071.xml b/xep-0071.xml index 877b1ad8..687ebbf8 100644 --- a/xep-0071.xml +++ b/xep-0071.xml @@ -758,7 +758,7 @@ That seems fine to me.

This section describes methods for discovering whether a Jabber client or other XMPP entity supports the protocol defined herein.

-

The primary means of discovering support for XHTML-IM is &xep0030;.

+

The primary means of discovering support for XHTML-IM is &xep0030; (or the dynamic profile of service discovery defined in &xep0115;).

XEP-0054 - profile + TO BE ASSIGNED &stpeter; 0.5 @@ -124,7 +124,7 @@

  1. IQ (request-and-response) semantics.

    -

    In the simplest case, an entity may store its own profile data and provide only the complete profile and only on request, using the request-response semantics of the XMPP &IQ; stanza type. This model is most appropriate for stable entities that are always online and whose profile data does not change frequently, such as servers and server-side components (entities that are not always online or that frequently modify their profile data, such as IM users, may prefer to publish their information to entities that are always online, such as an IM user's server). While it may seem desirable to embed profile data in the responses an entity provides to service discovery information requests using &xep0128;, it is likely that profile data will be quite extensive; therefore, we define a standalone "wrapper" element for profile data, qualified by the 'http://jabber.org/protocol/profile' namespace.

    +

    In the simplest case, an entity may store its own profile data and provide only the complete profile and only on request, using the request-response semantics of the XMPP &IQ; stanza type. This model is most appropriate for stable entities that are always online and whose profile data does not change frequently, such as servers and server-side components (entities that are not always online or that frequently modify their profile data, such as IM users, may prefer to publish their information to entities that are always online, such as an IM user's server). While it may seem desirable to embed profile data in the responses an entity provides to service discovery information requests using &xep0128;, it is likely that profile data will be quite extensive; therefore, we define a standalone "wrapper" element for profile data, qualified by the 'http://www.xmpp.org/extensions/xep-0154.html#ns' namespace &NSNOTE;.

  2. Pubsub (publish-and-subscribe) semantics.

    @@ -148,7 +148,7 @@

    A format represented by means of &w3rdf;.

    An argument could be made that RDF is a reasonable approach for representing profile data for communication over the XMPP network; however, such an argument will not be made in the current proposal. The author has considered RDF and has concluded that there are several reasons why RDF is undesirable as an XMPP wire protocol:

      -
    1. RDF exists in an XML representation but the semantics of RDF impose a more complex conceptual structure (data triples) than does XML, which is sub-optimal since unnecessary complexity is to be avoided (see &xep0134;).
      2. +
    2. RDF exists in an XML representation but the semantics of RDF impose a more complex conceptual structure (data triples) than does XML; this is sub-optimal since unnecessary complexity is to be avoided (see &xep0134;).
    3. RDF requires a specialized parser rather than the normal XML parser that comes standard with all XMPP implementations.
    4. As long as it is possible to define a consistent mapping of profile data to RDF representations, it should be straightforward to convert the XMPP data formats into those RDF representations if desired (e.g., to output a FOAF file).
    @@ -167,13 +167,13 @@
-

Therefore, this proposal specifies that profile data shall be scoped by a FORM_TYPE of 'http://jabber.org/protocol/profile', in accordance with the field standardization methods defined in XEP-0068. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the ®ISTRAR; (although they may or may not be defined in a XMPP Extension Protocol specification). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of XEP-0068. Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.

+

Therefore, this proposal specifies that profile data shall be represented in data forms scoped by a FORM_TYPE of 'http://www.xmpp.org/extensions/xep-0154.html#ns' &NSNOTE;, in accordance with the field standardization methods defined in XEP-0068. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the ®ISTRAR; (although they may or may not be defined in a XMPP Extension Protocol specification). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of XEP-0068. Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.

The following is a simple and incomplete example of profile data represented via the Data Forms protocol, containing two registered data fields and one unregistered field:

+ - http://jabber.org/protocol/profile + http://www.xmpp.org/extensions/xep-0154.html#ns Peter Saint-Andre @@ -188,7 +188,7 @@ ]]> -

By specifying that all fields are scoped by a FORM_TYPE of 'http://jabber.org/protocol/profile', this proposal does not mean to imply that all profile data will or should be gathered in one data form. In reality, most such data will probably be gathered at the time of registration either at a website or via a "wizard" interface that breaks the process into smaller bundles (such as "Basic Personal Data", "Physical Location", "Internet Addresses", "Hobbies and Interests", and "Favorite Things"). The use of one FORM_TYPE is simply meant to scope the data fields so that each field is unique within the context of profile data. Any form that uses these fields along with a FORM_TYPE of 'http://jabber.org/protocol/profile' is of the "profile type" (i.e., is a specific instance of that type), which does not limit the number of forms that can be of that type.

+

By specifying that all fields are scoped by a FORM_TYPE of 'http://www.xmpp.org/extensions/xep-0154.html#ns', this proposal does not mean to imply that all profile data will or should be gathered in one data form. In reality, most such data will probably be gathered at the time of registration either at a website or via a "wizard" interface that breaks the process into smaller bundles (such as "Basic Personal Data", "Physical Location", "Internet Addresses", "Hobbies and Interests", and "Favorite Things"). The use of one FORM_TYPE is simply meant to scope the data fields so that each field is unique within the context of profile data. Any form that uses these fields along with a FORM_TYPE of 'http://www.xmpp.org/extensions/xep-0154.html#ns' is of the "profile type" (i.e., is a specific instance of that type), which does not limit the number of forms that can be of that type.

However, scoping all data fields with a single FORM_TYPE implies it is necessary to define separate data fields for similar kinds of information. For example, the vCard specification (RFC 2426) defines "types" for certains kinds of data, such as email addresses, telephone numbers, and physical addresses, making it possible to specify that a telephone number corresponds to a fax machine or mobile phone or that a physical address corresponds to one's home or work location. In the Data Forms representation, any desired piece of information (e.g., work phone) must be represented with a separate data field.

In order to address most (if not all) of the pieces of information described in existing profile specifications, this document defines a great number of data fields. Even so, the data fields specified herein are not exhaustive, and it is expected that additional fields will be registered in the future through the mechanisms specified in the XMPP Registrar Considerations section of this document.

 @@ -198,10 +198,10 @@

In order to publish a full profile, an entity sends an IQ-set to its server with a child element of <profile/> containing the full profile information.

- + - http://jabber.org/protocol/profile + http://www.xmpp.org/extensions/xep-0154.html#ns Hamlet @@ -226,12 +226,12 @@

Otherwise it MUST return an error. If the server does not support the profile data functionality, the error MUST be &unavailable;.

-

In order to update selected fields in a public profile, an entity simply publishes the modified fields (not the entire profile) to a pubsub node of "http://jabber.org/protocol/profile" at its server using the PEP subset of the publish-subscribe extension, as specified in XEP-0163.

+

In order to update selected fields in a public profile, an entity simply publishes the modified fields (not the entire profile) to a pubsub node of "http://www.xmpp.org/extensions/xep-0154.html#ns" at its server using the PEP subset of the publish-subscribe extension, as specified in XEP-0163.

- - + + http://www.denmark.lit/blogs/princely_musings @@ -246,9 +246,9 @@ - + - + http://www.denmark.lit/blogs/princely_musings @@ -270,7 +270,7 @@ -

If an entity can provide profile data directly using the standalone 'http://jabber.org/protocol/profile' namespace, it SHOULD advertise that feature in response to &xep0030; information requests:

+

If an entity can provide profile data directly using the standalone 'http://www.xmpp.org/extensions/xep-0154.html#ns' namespace, it SHOULD advertise that feature in response to &xep0030; information requests:

... - + ... @@ -295,13 +295,13 @@

Note: Because the foregoing request was sent to the bare JID <hamlet@denmark.lit>, the response is provided by the <denmark.lit> server on behalf of the registered account. The answer indicates that the server can also provide profile data on behalf of the registered account.

 -

In order to request the full profile, the requesting entity sends an IQ-get to the providing entity's JID, where the request contains an empty <profile/> element qualified by the 'http://jabber.org/protocol/profile' namespace. In this example, the request is sent to a server:

+

In order to request the full profile, the requesting entity sends an IQ-get to the providing entity's JID, where the request contains an empty <profile/> element qualified by the 'http://www.xmpp.org/extensions/xep-0154.html#ns' namespace. In this example, the request is sent to a server:

- + ]]>

The server then replies:

@@ -310,10 +310,10 @@ from='shakespeare.lit' to='hamlet@denmark.lit/elsinore' id='iq1'> - + - http://jabber.org/protocol/profile + http://www.xmpp.org/extensions/xep-0154.html#ns shakespeare.lit IM server @@ -364,7 +364,7 @@ from='bard@shakespeare.lit/globe' to='hamlet@denmark.lit' id='iq2'> - + ]]>

If the requesting entity is not allowed to retrieve hosted profiles (e.g., because it is not on a whitelist of entities permitted to "spider" the server's users), the server SHOULD return a &unavailable; error:

@@ -373,7 +373,7 @@ from='hamlet@denmark.lit' to='bard@shakespeare.lit/globe' id='iq2'> - + @@ -386,10 +386,10 @@ from='hamlet@denmark.lit' to='bard@shakespeare.lit/globe' id='iq2'> - + - http://jabber.org/protocol/profile + http://www.xmpp.org/extensions/xep-0154.html#ns Hamlet @@ -412,14 +412,14 @@ ]]> -

In order to receive updated fields for a contact's profile, an entity shall send a pubsub subscription request to the contact's bare JID (&BAREJID;) and specify a node of "http://jabber.org/protocol/profile":

+

In order to receive updated fields for a contact's profile, an entity shall send a pubsub subscription request to the contact's bare JID (&BAREJID;) and specify a node of "http://www.xmpp.org/extensions/xep-0154.html#ns":

- + ]]> @@ -434,9 +434,9 @@ - + - + http://www.denmark.lit/blogs/princely_musings @@ -1928,7 +1928,7 @@ XhK8hFkPvXjudl7xAJ95+2fAHfmHheZJVaO8VaJiL54Tvw==
AffiliationOPTIONAL Manage Subscribers
member-affiliationThe member affiliation is supported.RECOMMENDEDAffiliations
meta-data Node meta-data is supported.
publisher-affiliation The publisher affiliation is supported.OPTIONAL RECOMMENDEDAffiliations
purge-nodes