On Sep 15, 2009, at 8:36 AM, XMPP Extensions Editor wrote:
Version 0.1 of XEP-0273 (Stanza Interception and Filtering
Technology) has been released.
After reading over this XEP, I think this concept got a bit more
complex/generalized than the problem(s) it was originally trying to
solve.
From what I understand, the original impetus for this was for giving
mobile clients a way to silence incoming presence ("presence hush"),
and give them a way to rebuild the presence state of their roster
quickly and efficiently when presence it is actually needed. The first
part is easy if your server supports privacy lists, but there is no
easy way to rebuild the presence state when you are actually
interested in it. (about the only way is to send out a presence probe
to everyone on your roster. Horrible.)
Then there were two additional considerations: 1) the idea that you
should be able to join a groupchat during presence silence (ie: you
should allow directed presence), and 2) the idea that you might want
to also not deal with incoming IQs (but you would still want your
server to be polite and bounce the incoming stanza). The second point
was quickly amended to allow for namespace-based exceptions so that
you could accept things like incoming Jingle calls while rejecting
things like version queries.
From what I can tell, this XEP goes a bit further:
You can disable receipt of inbound message stanzas.
You can add exceptions to the blocking of any stanza type (not just IQ
stanzas), based on...
...a localname/namespace element match.
...the nature of the sender: all senders, local vs. remote senders, or
other senders vs. oneself.
...the specificity of the recipient: the user's bare JID or the
particular client's full JID.
"Enable future extensibility based on regular expressions, XPath
expressions, etc."
I'm not really a big fan of all of this added complexity. While it
makes the protocol more general, it also dilutes the importance of the
problem it was originally trying to solve. For example, In section
4.1, the act of resyncing the client's presence state after a presence
hush is given as a "SHOULD", but it really needs to be a "MUST"---
because otherwise presence hush just isn't very useful.
I need to do some more thinking before I can fully embrace the
generalist approach in this case, but in the mean time I'll give some
additional feedback on what I've grok'd so far.
There is (IMHO) a glaring omission from section 2 (requirements):
"Make it possible to easily and quickly rebuild the presence state
when you once again allow presence traffic." I really think this is
the most important part of this XEP.
Regarding section 3.2: I'm not sure how I feel about the complexity of
discovering how much of the XEP the server supports. I would be much
more comfortable with simply having it all just described using disco
features:
<feature var="urn:xmpp:sift:0">
<feature var="urn:xmpp:sift:0:message">
<feature var="urn:xmpp:sift:0:message-sift:recipient:all">
<feature var="urn:xmpp:sift:0:message-sift:senders:all">
<feature var="urn:xmpp:sift:0:message-sift:senders:others">
This allows the client to simply use any pre-existing service
discovery feature caching rather than having to add an additional
mechanism to probe how much of spec their server has implemented.
I think that it is important to note in the XEP that implementations
only need to worry about implementing parts of the protocol that are
interesting to the problems they are trying to solve. I think a lot of
people are going to be put off by the scope of the XEP and might not
realize that they don't have to implement the whole thing to support
something like presence hush easily.
The first and last paragraphs of section 4.1 are inconsistent with
respect to how the server would bring the client's presence state up
to date at the end of a presence hush period. The first paragraph
implies sending probes is the best (only?) way, and the last paragraph
states that how this is done is implementation specific:
When the client indicates that it wishes to receive inbound presence
notifications, the server SHOULD send outbound presence probes on
the client's behalf. Responses to these presence probes are
addressed to the bare JID of the account and then broadcasted to all
of the resources that have expressed interest in receiving inbound
presence notifications.
---snip---
If the client then indicates again that it wishes to receive inbound
presence notifications, the server shall resynchronize the client
regarding the presence states of its contacts (how it does so is
implementation-specific, e.g. whether it queues received presence
notifications or re-probes the user's contacts).
In the second paragraph of section 4.3, a confusing distinction is
made regarding the IQ stanzas being addressed to the full JID of the
client. This requirement should be self-evident. Also, it is my vote
that the server shouldn't be in the business of knowing how to respond
to various namespaces. I think we should in all filtered cases return
<service-unavailable/>, perhaps with a type of "wait" instead of
"cancel".
Is section 4.4 really necessary? It seems quite obvious that if the
server supports SIFT and the client never asks for it that the server
shouldn't be doing any SIFT stuff. Maybe it is necessary and I just
have too much faith...?
Section 5.1 seems kinda silly to me. Servers shouldn't be defaulting
to filter inbound presence in a way that would make something like
this completely necessary. (And directly-addressed messages should be
delivered by default, even if the initial presence hasn't yet been
sent) As far as I can tell, after you have started the session all you
would want the server to do is send out a presence probe, and the most
natural way I can think of for the client to communicate that would be
for it to send a <presence type="probe"/> and for the server to take
that to mean that it should send a presence probe to the appropriate
entities in the roster. There are much more clean (and flexible) ways
to go about invisibility anyway. But that's just me.
The name of section 5.2 ("Negative Presence Priority") doesn't seem to
accurately describe the contents of that section. That being said, I
can't immediately think of a concise alternative.
Section 5.3 should really recommend that when requesting presence hush
that the client explicitly allow directed presence. The given example
will block all inbound presence, and break MUC. Speaking of which,
there should probably be a section in the XEP elaborating on presence
hush and how it impacts directed presence and MUC.
In conclusion, I'm really looking forward to having a clean and solid
way to implement presence hush. While I need to give this approach
some more thought, this XEP seems like a reasonable start.
__________________
Robert Quattlebaum
Jabber: [email protected]
eMail: [email protected]
www: http://www.deepdarc.com/
