On Tue Sep 21 16:36:45 2010, Evgeniy Khramtsov wrote:
21.09.2010 01:47, Dave Cridland wrote:
1) The <mark/> element's text would be more usefully enclosed
within a <comment/> element or some such, since that makes it
substantially easier to extend later.
I agree. But I think the element should be <reason/> :)
You can paint it any colour you like.
3) It's not entirely clear to me how multiple filters would work
For example, external component (such as SMTP transport) may mark
stanzas. If a user is connected to another XMPP server through XMPP
gateway, "legacy" XMPP server may add its markers, an external
filtering component may add markers as well - it should interact
with the server somehow, but I think this is out of the scope of
this proposal.
but I assume that they are all trusted by the home server
Not sure about this assumption. I'd say the server should not care.
I think you have tw different kinds of servers. Servers which don't
do this spec at all will just ignore them, and it's basically left to
the client to figure out the mess. Servers which do understand the
protocol should probably aggregate the marking from remote filtering
entities, and discard the rest.
In this instance, a server supporting spin-marker should be able
to strip all spim-marker elements on input over S2S.
Why should it do so? Do you think spimmers will mark themselves?
Just like in XEP-0076? :) I think it should strip markers matching
itself.
I think if a server is aware of marking, it should be able to strip
all the foreign markers and add one of its own if appropriate.
Regarding other your comments and comments from the Council
discussion: it seems like the most problematic part is reporting
mechanism. I agree with you: it is a bit tricky and has lots of
security problems. So, we can drop it from this ProtoXEP and,
probably, move that part in XEP-0268 if someone feels enough
strength to maintain it.
I'd be keen on seeing this included, actually, I don't think it's a
lost cause, and I think it'll be useful. Given that it's easy not to
implement - you just don't include the report stuff in the stanzas -
I don't see the harm in working on it for now.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade