[standards-jig] JEP0024, namespaces and permissions...

Piers Harding piers at ompa.net
Fri Jul 12 13:15:55 UTC 2002

OK - Hi,

On Fri, Jul 12, 2002 at 12:11:38PM +0100, Timothy Carpenter wrote:
> As I am in the process of building a real-time information transport on
> Jabber, I am interested in pub:sub.
> 1) Is it possible to clarify that pub:sub namespaces have to be expressed in
> terms relative to the publisher, not the sender? Such items as
> news:political:home asked of a France-based international news publisher by
> someone from the UK would provide French domestic news!

The namespace ( in JEP 24 ) is the entirely publisher centric - ie. it
is an indentifier of a realm of data that a publisher is going to push
to subscribers.  It can be anything - it is completely free form within
the namespace definition formats as described by the W3C.

The French news based issue is an application issue.  If you need to
distinguish between countries of origin, and or Language, then ( I would
) introduce that into your hierarchical namespace format.

> Alternatively, advise against relative namespaces or permit namespace
> translation? (I prefer the former)
> 2) Data may have more than one 'namespace'...in fact NEWS especially has the
> possibility of tens of classifications per story - e.g. politics, drugs, US,
> police, Washington, Civil Rights, election etc. The alternative is to have
> embedded codings as payload data and filter after the delivery, which many
> systems do already with the obvious bandwidth and processing implications on
> the last mile. 
> I would suggest to avoid confusion, that the news namespace be altered in
> JEP0024 to suggest something that would work as a more unique namespace, if
> only one namespace can be given to data by the publisher. E.g.
> automobiles:mercedes:W108.
> Alternative is duplicating messages with different namespaces or multiple
> namespaces sent by the publisher...
> "news:[politics|US|Police|Washington|drugs|heroin|crime]:wires"? The pub:sub
> entity would then have to filter on this, or the client filters at the other
> end.

I think you are hitting on a idea that has been thrown arround - the
idea of possibly "wildcarding" namespaces that are subscribed too.  So
far the reason that this has been avoided is the difficulty that this
would bring to the implementation of the component.
"Implementation" - I hear you say!  Yes - we had to start somewhere.  If
a reasonable set of rules by which a sophisticated namespace or hierachy
matching could be applied ( for instance an XPath style expression ),
that didn't have the prospect of making the scalability of the pubsub
component a problem, then I'd be interested.

> The centralised filtering allows for lower bandwidth last mile dumb
> streaming to the client device but puts a greater load on the server to sift
> multiple namespace combinations. Server should have right to refuse.
> With the current framework, we are only able to send multiple messages from
> the publisher to achieve namespace granularity, so placing an assumption on
> the architecture. If we allow "polynamespacing" then we have further choices
> of filtering at server or client. This allows us to decide trade-offs of cpu
> and bandwidth. 

Ok - but these are tied to a decision above.  Do we allow multiple
tagging of namespaces to the published data, or do we allow
subscriptions to be more inteligent ( wildcards etc.) ?   Need to think
about that one.

> A mobile phone streamer, for example, would prefer polynamespace filtering
> at the server. The publisher may like to have polynamespace publishing (once
> only per item), but intermediate caches with terrestrial, high powered
> data-hungry clients would perfer to have client-side filtering by streaming
> over a few multicast channels.
> (It may be worth warning namespacer's to be aware of the implications of
> multicast delivery on namespace allocation)

This is very applicaiton specific - a publisher/subscriber subscription
relationship would tune their relationship ( ie. the agreement of what
namespaces meant ) to meet their needs.  The key is to ensure that the
specification is open enough to make this possible.

> 3) Permissions are not included in the spec, but from a publisher's (and
> even redistributor's) point of view, it needs to send out information to
> control that and in a way that sits comfortably alongside the pub:sub
> framework. This is not easy, from long experience in data distribution
> systems (16 yrs Reuters/Tibco).
> BTW: I am looking into permissions for my real time data architecture I am
> building. Central and distributed, grant and deny.

Authorisation is a tricky subject.  The idea at the time JEP 24 was
created was that this would be controlled by some other standard eg.
Proxy components etc.  I guess a lot more discussion could be had about

> 4) Finally and trivially..I would like to confirm if namespaces can be
> 'sticky' within a node, such that a headline, body and other information
> (subject codes) have the same namespace without repeating it for each field.
> If not, it would be preferable to have some form of "~:" or other operator
> to say "whatever, plus...". Forgive me if this is already sorted, but it was
> not clear to me (my fault) from the short data payloads of the examples in
> JEP0024.

If I understand the question correctly then published data does inherit
the namespace with packets like this:

SEND: <iq type='set' to='pubsub.localhost'
             from='publisher.localhost' id='s1'>
         <query xmlns='jabber:iq:pubsub'>
             <publish ns='foo'/>

namespace published to is foo and the namespace specified on the payload
is foo.

                <foo xmlns='foo'>bar</foo>

Maybe DJ has something to add to all of this :-)


> Thanks 
> Tim Carpenter
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

More information about the Standards mailing list