[standards-jig] NEW: Packet Filtering (JEPs 0062, 0063, 0064)
iain.shigeoka at messaginglogic.com
Tue Dec 24 19:03:07 UTC 2002
On 12/19/02 12:38, "Ralph Meijer" <jabber.org at ralphm.ik.nu> wrote:
> On Thu, Dec 19, 2002 at 11:12:34AM -0800, Iain Shigeoka wrote:
>>> This leads again to some namespace issues, since namespaces declared on
>>> the <stream:stream/> element will no more be available. I'd rather
>>> evaluate the expression against a document formed by the real root and
>>> the current packet.
>>> From a lazy programmer standpoint, I can see why treating the sub-docs as
>> the entire doc for xpath searches is nice. But for proper namespace support
>> you're probably right. This will become especially important as people start
>> exploiting prefixes in the root tag to 'compress' their jabber packets.
> 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
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.
More information about the Standards