The ytstenut spec has an example of a status XML node:
uri='some random youtube url'
Playing a video about colour-based optical illusions.
and mentions that the value of the capability attribute should be like those mentioned in section 3.7.1, all of which are of the form "yts-caps-..." with no prefix. That's sensible: ytstenut statuses always pertain to a capability, not a transfer protocol, status or alike.
The C2S Ytstenut stack which gabble is a part of encapsulates these nodes inside PEP events. PEP event autosubscription works by advertising a XEP-0115 feature token of the form "<node-name>+notify", where <node-name> is like a "topic", a node on which events are published. Ytstenut status push subscriptions are to capabilities; hence the node name must include the capability. But the node name must be globally unique. By prefixing the capability with "urn:ytstenut:capabilities:", a globally unique node name is attained. This is what the Gabble-based stack uses as the PEP event node name.
However, this is where the gabble plugin gets it wrong: it overrides whatever "capability" attribute was in the status XML passed to it with the prefixed version. Thus, it'd send the example status node from the spec with "capability='urn:ytstenut:capabilities:yts-caps-video'".
Should we change the spec, or should we change gabble? I don't think we need the redundant prefixes in the XML, so I vote for fixing gabble.
> capability. But the node name must be globally unique. By prefixing the
> capability with "urn:ytstenut:capabilities:", a globally unique node name is
> attained. This is what the Gabble-based stack uses as the PEP event node name.
This brings an another possible issue: the PEP node is transient, so it will only ever contain one event at a time. But as the PEP node is capability-wide, multiple services on a given full JID will override each other's statuses if they announce statuses on the same capabilities.
So if we want to support many services with overlapping capabilities separately announcing a status, this must be addressed as a separate spec bug.
Off the cuff I'd agree to better cut down on redundancy. Need to look at it in more detail though (test case).