[standards-jig] NEW: Packet Filtering (JEPs 0062, 0063, 0064)

Ralph Meijer jabber.org at ralphm.ik.nu
Tue Dec 24 20:31:21 UTC 2002

On Tue, Dec 24, 2002 at 11:03:07AM -0800, Iain Shigeoka wrote:
> On 12/19/02 12:38, "Ralph Meijer" <jabber.org at ralphm.ik.nu> wrote:
> > What about having the current stanza as context node for the xpath queries,
> > but that the entire document (only preceding stuff probably) can be reached
> > by using '/' as first character? Most XPath implementations I know support
> > the notion of setting a node other than '/' as context node for relative
> > queries.
> It certainly could be done. The issue I think is not how the XPath is
> formatted but how much of the document we want to require servers to keep
> around for the filters to act on. There is the potential for a lot of
> information to be stored in the opening stream tag (a prefix 'dictionary' if
> you will). As packets are switched from one stream (c2s) to another stream
> (s2s) and yet another (c2s) this information will need to be
> converted/mapped and tracked. If we allow the XPath to know about the stream
> tag, we would need to work out how the XPath expressions map to these
> different packets in different streams even though it is the same 'packet'
> (something XML in general is not designed to do). If we strip out the stream
> tag as something XPath can know about, then the query works only on some
> relatively independent sub-document which (if standard XMPP) should be
> message, presence, or iq in the jabber:client namespace. That way at least
> the root of every filterable packet will match at least one standard XPath
> query. /message for example.
> On the other hand, it could be useful to dig into the root stream especially
> for end point addresses and prefixes if they aren't required to be
> 'resolved' by the filter engine.

Hmm, just thinking aloud here. What if the information to be acted upon by
XPath would be a virtual document containing the root element (with all of its
namespace and attribute subnodes and of course a simulated end tag) and the
current stanza as its child? That would enable you to use the namespaces
defined in the root tag. You loose any preceding context, but the namespaces
defined in those stanzas are irrelevant.

While thinking about this, you could also create a new xpath function that
'stores' the current stanza in the virtual document, to be acted upon later
on by other xpath queries, and maybe also a matching one to clear the context.

I will not get into the debate about elements magically switching namespaces as
is current practice, other than saying 'we' cheated. I'll leave that for the
xmppwg mailinglist.


More information about the Standards mailing list