Juliet wishes to make her sonnets available for retrieval by the public. She creates a Root Pubsub Collection Node which will contain her file listing:

Juliet also wishes to add a subsection for her sonnets about Romeo. She creates another PubSub Collection Node under the Root Node:

Romeo wishes to view all of Juliet's shared sonnets. To do this, Romeo subscribes to the Root Collection Node:

Juliet has just finished a new sonnet and wishes to announce its availability on her File Listing. She adds the sonnet as a new PubSub Node stored in her Collection Node, then inserts a first revision of her sonnet as an Item within that Node:

The Item ID is set to 1, signifying the first revision for this file. Subsequent revisions/items will have incremented ID values, like one would see in a versioning system such as CVS or SVN. Implementations MAY follow this convention, but are not required to do so. For example, a given implementation may instead mark revisions using version numbers ("Beta 1", "6.2", etc) or use other arbitrary strings. However, no two revisions of a given file may share the same ID.

Node IDs MAY take the form of "path/to/file.ext", rather than the randomized string "a6190c5d38e22452041d1c5798eff3f5" provided in the above use case. For example, Juliet's sonnet MAY instead use a Node ID of "juliets_sonnets/sonnet.txt", as long as this ID is unique within the PubSub server. Randomized strings are used in this document to illustrate that Node IDs SHOULD NOT be used for providing information about files.

Here is a listing of the possible metadata in a file revision (Item), each field is OPTIONAL:

Because Romeo is now subscribed, he receives notice of Juliet's addition:

The above examples give a listing of several possible file transfer protocols in example configurations. Only the sipub mirror type is REQUIRED; the other types are OPTIONAL. Here is a full listing of those protocols and their available settings:

The Description field is where an arbitrary description of the mirror MAY be placed. For example, if a File Listing is advertising mirrors which are located in different geographic locations, then this field may be used to specify those locations.

The Ref field is a unique address or identifier for retrieving the file from the mirror server. In the above examples, it is used as a path to the file.

The address and port fields describe the server where the file may be retrieved using the specified protocol. If a port is not provided, the default value (specified in parentheses) MAY be assumed.

The User and Pass fields are for providing credentials which, if given by the File Listing, SHOULD be used when requesting the file. For example, an sftp mirror MAY require that the user log in using specified credentials before the file may be retrieved.

Juliet has revised her sonnet and wishes to publish the new version, while still leaving the original copy available for retrieval. To do this, she inserts a new Item, representing her new revision, into the file's Node:

Juliet has uploaded a copy of her revised sonnet to a new mirror, and wishes to let her subscribers know about this secondary source. She is able to do this by modifying the revision in question to include a reference to her website, overwriting the existing mirrors in the Item with an updated list:

Juliet now wishes to allow others to contribute to her sonnet collection. She gives owner access for the entire Listing to Romeo, and publisher access to her nurse:

Romeo uses his owner access to remove the older revision of Juliet's sonnet:

Other deletion, modification, and user management operations are available as described in &xep0060; and &xep0248;.