diff --git a/inbox/pubsub-labels.xml b/inbox/pubsub-labels.xml new file mode 100644 index 00000000..924b82d9 --- /dev/null +++ b/inbox/pubsub-labels.xml @@ -0,0 +1,209 @@ + + +%ents; + <label/>"> + <catalog/>"> + <item/>"> + <securitylabel/>"> + <displaymarking/>"> + <equivalentlabel/>"> + <headline/>"> + <identity/>"> + <publish/>"> +]> + + +
+ Security Labels in PubSub + This document describes an extension to XEP-0258 (Security Labels in XMPP) to allow for the use of security labels in PubSub. This document describes + how security label metadata can be applied to the various elements within PubSub, including nodes and items. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XEP-0060 + XEP-0258 + + + + NOT_YET_ASSIGNED + + Ashley + Ward + ashley.ward@surevine.com + ashley.ward@surevine.com + + + Lloyd + Watkin + lloyd.watkin@surevine.com + lloyd.watkin@surevine.com + + + 0.0.1 + 2012-05-16 + asw +

First draft.

 + +
+ +

This XEP defines a method to include Security Labels (as defined in &xep0258;) into PubSub (as + defined in &xep0060;). Security labels (sometimes referred to as confidentiality labels) blah + blah blah

+ + +

STRONGLY RECOMMENDED.

+ + +

OPTIONAL.

+
+
Security Label
+
The schema defined in &xep0258; with the XML namespace "urn:xmpp:sec-label:0"
+
+ + +

This section defines the use cases for and protocols to be used by any entity wishing to + publish or subscribe to content with a Security Label

+ +

A server SHOULD provide a label feature and information discovery for each node

+

Clients SHOULD discover label feature and information on a per-node basis

+ + +

The protocol for node discovery is as defined in &xep0060;, but with the caveat that the + server SHOULD NOT return any nodes that have a security marking that the entity is not + authorised to view.

+

If a service implements a hierarchy of nodes (via + Collection Nodes) + then the server MUST also prevent access to any child nodes of any nodes which the entity + is not authorised to view, even if the node's individual security label would otherwise + allow this

+ + + + + + + + + +

Each Item within a &PUBLISH; element may be individually labelled with a &SECURITYLABEL;

+

The server SHOULD apply the default label for the node to any items which do not contain a + &SECURITYLABEL;

+ + + + + + Soliloquy + +To be, or not to be: that is the question: +Whether 'tis nobler in the mind to suffer +The slings and arrows of outrageous fortune, +Or to take arms against a sea of troubles, +And by opposing end them? + + + tag:denmark.lit,2003:entry-32397 + 2003-12-13T18:30:02Z + 2003-12-13T18:30:02Z + + + UNCLASSIFIED + + + + + + + ]]> + +

The service then notifies appropriately cleared subscribers

+ + + + + + Soliloquy + +To be, or not to be: that is the question: +Whether 'tis nobler in the mind to suffer +The slings and arrows of outrageous fortune, +Or to take arms against a sea of troubles, +And by opposing end them? + + + tag:denmark.lit,2003:entry-32397 + 2003-12-13T18:30:02Z + 2003-12-13T18:30:02Z + + + UNCLASSIFIED + + + + + + + ]]> + + +

If the node is configured not to include payloads

+ + + + +

OPTIONAL.

+
    +
  1. Server responses from a request for a node which the entity is not authorised to view MUST + be identical to a response as if that node did not exist. + + + + + + ]]> +
    2. +
+ + +

OPTIONAL.

+ + +

OPTIONAL.

+ + +

OPTIONAL.

+ + +

REQUIRED.

+ + +

REQUIRED.

+ + +

REQUIRED.

+ + +

REQUIRED for protocol specifications.

+ + diff --git a/inbox/xml-media-element.xml b/inbox/xml-media-element.xml new file mode 100644 index 00000000..11ce76d6 --- /dev/null +++ b/inbox/xml-media-element.xml @@ -0,0 +1,126 @@ + + +%ents; +]> + + +
+ Data Forms XML Element + This specification defines an XMPP protocol extension for including XML-data in XEP-0004 data forms. + &LEGALNOTICE; + xxxx + Experimental + Standards Track + Standards + + XMPP Core + XEP-0004 + + None + None + media-element + + http://www.xmpp.org/schemas/xml-element.xsd + + + Sergey + Dobrov + binary@jrudevels.org + binary@jrudevels.org + http://jrudevels.org/ + + + 0.0.1 + 2012-06-13 + snd +

Initial version.

 + +
+ + +

In certain protocols that make use of &xep0004;, it can be helpful to include XML-data (for example, when we want to insert a big amount of structured data which is hard to insert as a separate fields). This document defines a method for including XML-data in a data form.

+ + + +

The root element for XML-data is <xml/>. This element MUST be qualified by the "urn:xmpp:xml-element" namespace. The <xml/> element MUST be contained within a <field/> element qualified by the 'jabber:x:data' namespace.

+

The <xml/> element SHOULD contain an XML-data which needs to be represented in a form.

+ + + Romeo&apos;s Microblog + tag:montague.lit,2008:home + 2008-05-08T18:30:02Z + + Romeo Montague + xmpp:romeo@montague.lit + + + + ]]> + + [ ... ] + + + + Romeo&apos;s Microblog + tag:montague.lit,2008:home + 2008-05-08T18:30:02Z + + Romeo Montague + xmpp:romeo@montague.lit + + + + + [ ... ] + + ]]> + + + +

XML-data is usually hard for manual editing and SHOULD be used only for machine level iteractions. So it's RECOMMENDED to include it in the form as a "hidden" field.

+

However, there are situations when human editing of XML-data may be useful (for example, to see XML-logs of some XMPP-service). In that case it's RECOMMENDED for a client to represent this XML in a pretty formatted form and give an instruments to make it easier to edit XML-data.

+ + + +

This document requires no interaction with &IANA;.

+ + + + +

The ®ISTRAR; includes "urn:xmpp:xml-element" in its registry of protocol namespaces (see &NAMESPACES;).

+ + + + + + + + + + + The protocol documented by this schema is defined in + XEP-XXXX: http://www.xmpp.org/extensions/xep-xxxx.html + + + + + + + + + + + + + ]]> + + +