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

Reply via email to