Re: [Standards] LAST CALL: XEP-0232 (Software Information)
> (Client asks local [trusted] server, which fetches image, checks it, etc). Interesting idea. It would sure make life easier on clients. cheers, Remko
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
Jiří Zárevúcký a écrit : Another thing to clarify - how to handle groups? That is.. Union? Intersection? Should client synchronize them when "merging" contacts? Etc.. I think that best approach would be union and synchronizing between all sub-contacts. In gajim we show contact in the groups of the highest priority contact, and we merge contact group when creating the meta contact. groups of sub-contacts takes the group of the highest priority contact. -- Yann
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
Jiří Zárevúcký a écrit : 2009/1/22 Yann Leboulanger : each contact has its own name, there is not a name for the "group" of contacts. I don't see how it could be usefull to have a name from the metacontact "group". I think it could be useful in some scenarios. Example: cont...@whatever.org - "Contact - Company" cont...@google.com - "Contact - GTalk" 123456...@icq.whatever.org - "Contact - ICQ" Metacontact - "Contact" Rationale: every sub-contact can have some explanation/specification/location specified in name Perhaps it would not be very useful for most people, I don't know. I personally would use it in this way. And in your roster you see "Contact"? So dou don't know to which jid you'll talk when you'll open a chat window. but if you show the name of the highest priority resource, you'll see "Contact - Company" in yout roster and you'll know to which jid you'll talk.
Re: [Standards] LAST CALL: XEP-0232 (Software Information)
On Thu, Jan 22, 2009 at 03:44:44PM -0700, Joe Hildebrand wrote: > On Jan 22, 2009, at 10:10 AM, Jiří Zárevúcký wrote: > >> 2009/1/22 Olivier Goffart : >>> Why do we need to send icons URL for status? I think it will just confuse >>> the >>> user if each cotact has different icons for different statuses. >> I agree. IMO there is no reason, why should one client tell another >> how to display it's states. I would certainly not implement (or enable >> in client supporting this) such behavior. Noted security issue is also >> a problem. On the other hand, if some client really used it, it would >> have no way of knowing, whether cached images are up-to-date. > > This is to combat every client coming up with their own icons for other > peoples' clients. You do not need to use the info, or provide it, but it > is useful for the folks that believe that what client you are using matters > to the end user. The question here is not about the single 'this is the icon for my client' icon. It is about the 'this is my client away', 'this is my client busy', etc. icons. Icons which seem to only be useful in place of the user's client's status icons. As even if you are displaying icons for the remote contacts client you are (presumably) still showing local status icons. At worst if you are using some sort of emblem system you can continue using your standard emblems with whatever the custom client icon is. Personally, I'd fight displaying client icons in pidgin entirely but not block a patch. I'd definitely block a patch showing per-status client icons in place of our own. -Etan
Re: [Standards] LAST CALL: XEP-0232 (Software Information)
On Jan 22, 2009, at 4:30 PM, Dave Cridland wrote: On Thu Jan 22 22:45:48 2009, Joe Hildebrand wrote: On Jan 21, 2009, at 2:31 PM, Remko Tronçon wrote: Shouldn't it be specified how the 'value' field should be interpreted for things like 'icon' etc.? Should this be limited to http URIs? I guess it is with data forms, because you can only have one string as a value child? Yes, this should be specified. XEP-0221? XEP-0231? The problem with 221 is that it won't affect the caps hash, right? If we modified 221 so that the value was a hash of the media element, it would work fine.
Re: [Standards] LAST CALL: XEP-0232 (Software Information)
On Thu Jan 22 22:45:48 2009, Joe Hildebrand wrote: On Jan 21, 2009, at 2:31 PM, Remko Tronçon wrote: Shouldn't it be specified how the 'value' field should be interpreted for things like 'icon' etc.? Should this be limited to http URIs? I guess it is with data forms, because you can only have one string as a value child? Yes, this should be specified. XEP-0221? XEP-0231? Shouldn't the security considerations mention something about fetching the icons OOB? (i.e. exposing unwanted information about location etc., potential malicious files, ...) Yes. Particularly since there have been attacks against various image libraries. New XEP suggestion: server mediated BoB resolution. (Client asks local [trusted] server, which fetches image, checks it, etc). Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] LAST CALL: XEP-0232 (Software Information)
On Jan 21, 2009, at 2:31 PM, Remko Tronçon wrote: Shouldn't it be specified how the 'value' field should be interpreted for things like 'icon' etc.? Should this be limited to http URIs? I guess it is with data forms, because you can only have one string as a value child? Yes, this should be specified. Shouldn't the security considerations mention something about fetching the icons OOB? (i.e. exposing unwanted information about location etc., potential malicious files, ...) Yes. Particularly since there have been attacks against various image libraries.
Re: [Standards] LAST CALL: XEP-0232 (Software Information)
On Jan 22, 2009, at 10:10 AM, Jiří Zárevúcký wrote: 2009/1/22 Olivier Goffart : Why do we need to send icons URL for status? I think it will just confuse the user if each cotact has different icons for different statuses. I see also that as a potential security issue that can reveal user's presence + IP (while following the links) I agree. IMO there is no reason, why should one client tell another how to display it's states. I would certainly not implement (or enable in client supporting this) such behavior. Noted security issue is also a problem. On the other hand, if some client really used it, it would have no way of knowing, whether cached images are up-to-date. This is to combat every client coming up with their own icons for other peoples' clients. You do not need to use the info, or provide it, but it is useful for the folks that believe that what client you are using matters to the end user. Other thing: every client can have different sizes of icons. I imagine one could solve this by offering big images for client to scale down. Now we can download 50+ (probably more) 128x128px images every startup. So.. I think it is nice reinterpretation of XEP-92, but these icons are way too useless. We should specify a suggested size, and that you MUST cache and use HEAD requests to check cache if you're going to use the icons.
Re: [Standards] LAST CALL: XEP-0232 (Software Information)
On Jan 21, 2009, at 2:44 PM, Peter Saint-Andre wrote: Remko Tronçon wrote: Can someone remind me why we use data forms for this, and not real elements? I guess it has something to do with how disco information is to be extended (looking at XEP-115). Anyway, I guess we don't have a choice here, but that doesn't mean I like it :-) Right, it's all about XEP-0128 (extended info in service discovery). Now, maybe that one was wrong in the first place, but that's another story... The idea was that you could write a client UI that displayed name/ value pairs, and have the list be easily extensible.
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
2009/1/22 Matthew Wild : > > I must say I'm inclined to agree with Olivier. Perhaps we are solving > the problem from the wrong angle? Specifically, perhaps we can solve > the need for users to append "(Home)", "(Work)", "(ICQ)" and "(MSN)"? > > I'm not going to object to this XEP, I just can't help wondering if > the same could be achieved in a simpler way. > > Matthew. > Custom contact tagging? I smell a new XEP... :D
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
On Thu, Jan 22, 2009 at 9:05 PM, Remko Tronçon wrote: >> Thus, I consider the Kopete behaviour rather bad. > > I wouldn't call it bad. It's a good enough poor-man's metacontact, > especially in the case where private storage is not available on the > server. However, I do think behavior like this should be optional. I > for example have a few contacts with the same name in my roster (but > in different groups). > > Leapfrog provides both approaches IIRC. > I must say I'm inclined to agree with Olivier. Perhaps we are solving the problem from the wrong angle? Specifically, perhaps we can solve the need for users to append "(Home)", "(Work)", "(ICQ)" and "(MSN)"? I'm not going to object to this XEP, I just can't help wondering if the same could be achieved in a simpler way. Matthew.
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
Another thing to clarify - how to handle groups? That is.. Union? Intersection? Should client synchronize them when "merging" contacts? Etc.. I think that best approach would be union and synchronizing between all sub-contacts.
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
> Thus, I consider the Kopete behaviour rather bad. I wouldn't call it bad. It's a good enough poor-man's metacontact, especially in the case where private storage is not available on the server. However, I do think behavior like this should be optional. I for example have a few contacts with the same name in my roster (but in different groups). Leapfrog provides both approaches IIRC. cheers, Remko
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
2009/1/22 Jonathan Schleifer : > Olivier Goffart wrote: > >> What would be the need of having different name for sub-contacts >> inside the same metacontact? > > If someone got two XMPP accounts, you might append the server name in > brackets. Or when using transports, you might want to append something > like (ICQ). Or one got a work accound and a private account, you might > want to add (Work) and (Home). Or someone still uses his old account, > but only for a short amount of time, so you might append (old). Or you > added the other account as a fallback, so you might want to append > (fallback). There are 1000 of reasons. Thus, I consider the Kopete > behaviour rather bad. > > -- > Jonathan > Exactly my point.
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
Olivier Goffart wrote: > What would be the need of having different name for sub-contacts > inside the same metacontact? If someone got two XMPP accounts, you might append the server name in brackets. Or when using transports, you might want to append something like (ICQ). Or one got a work accound and a private account, you might want to add (Work) and (Home). Or someone still uses his old account, but only for a short amount of time, so you might append (old). Or you added the other account as a fallback, so you might want to append (fallback). There are 1000 of reasons. Thus, I consider the Kopete behaviour rather bad. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
Le mardi 20 janvier 2009, XMPP Extensions Editor a écrit : > XEP-0209 (Metacontacts) has been Deferred because of inactivity. > > Abstract: This document specifies an XMPP protocol extension for defining > metacontacts and grouping member JIDs. > > URL: http://www.xmpp.org/extensions/xep-0209.html > > If and when a new revision of this XEP is published, its status will be > changed back to Experimental. What we do in Kopete is to merge into one metacontact contacts that have the same name. I have read the idea on this very mailing list. So there is no need of a metacontact specification, and the problem of metacontact across account are solved. What would be the need of having different name for sub-contacts inside the same metacontact? What would be the point of having the same name for two different metacontact? -- Olivier signature.asc Description: This is a digitally signed message part.
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
2009/1/22 Yann Leboulanger : > each contact has its own name, there is not a name for the "group" of > contacts. > I don't see how it could be usefull to have a name from the metacontact > "group". > I think it could be useful in some scenarios. Example: cont...@whatever.org - "Contact - Company" cont...@google.com - "Contact - GTalk" 123456...@icq.whatever.org - "Contact - ICQ" Metacontact - "Contact" Rationale: every sub-contact can have some explanation/specification/location specified in name Perhaps it would not be very useful for most people, I don't know. I personally would use it in this way.
Re: [Standards] LAST CALL: XEP-0205 (Best Practices to Discourage Denial of Service Attacks)
Kevin Smith wrote: > On Thu, Jan 22, 2009 at 7:15 PM, Peter Saint-Andre wrote: >> Proposed text at the bottom. > > WFM. http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0205.xml?%40diffMode=u&%40diffWrap=s&r1=2634&r2=2681&u=3&ignore=&k= I think this is small enough that we can edit in place and not generate version 1.1, but we'll let the Council decide on that. :) /psa
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
Jiří Zárevúcký wrote: >>> 1) Why not use user-specified handle (meta-contact name) instead of >>> some opaque "tag"? >> Sure, you could do that too (unlness I overlook something, It's been >> some time). I'll clarify this. > > "The value of the 'tag' is used as a non-human readable unique > identifier for a metacontact." > I think it would be nice to drop the "non-human readable" part. > Actually, making it a human readable name would allow users to name > metacontacts. each contact has its own name, there is not a name for the "group" of contacts. I don't see how it could be usefull to have a name from the metacontact "group". -- Yann
Re: [Standards] LAST CALL: XEP-0205 (Best Practices to Discourage Denial of Service Attacks)
On Thu, Jan 22, 2009 at 7:15 PM, Peter Saint-Andre wrote: > Proposed text at the bottom. WFM. Thanks Peter, /K
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
>> 1) Why not use user-specified handle (meta-contact name) instead of >> some opaque "tag"? > > Sure, you could do that too (unlness I overlook something, It's been > some time). I'll clarify this. "The value of the 'tag' is used as a non-human readable unique identifier for a metacontact." I think it would be nice to drop the "non-human readable" part. Actually, making it a human readable name would allow users to name metacontacts. >> 2) How are these meta-contact data supposed to be scattered across >> multiple accounts? I really didn't get this part. (clarification >> needed?) > > Every account needs to store the tags of its contacts separately. Same > tag on different account == same metacontact. > > I'll add some clarification about this. > So this apply only for clients that allow multiple accounts connected simultaneously, without rosters being separated (Gajim's merged mode), right? Ok, that was obvious... sorry for asking.. :)
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
> 1) Why not use user-specified handle (meta-contact name) instead of > some opaque "tag"? Sure, you could do that too (unlness I overlook something, It's been some time). I'll clarify this. > 2) How are these meta-contact data supposed to be scattered across > multiple accounts? I really didn't get this part. (clarification > needed?) Every account needs to store the tags of its contacts separately. Same tag on different account == same metacontact. I'll add some clarification about this. cheers, Remko
Re: [Standards] LAST CALL: XEP-0205 (Best Practices to Discourage Denial of Service Attacks)
Proposed text at the bottom. Peter Saint-Andre wrote: > Alexey Melnikov wrote: > >> In Section 3, bullet 3 says: >> >>> Limiting the number of authentication attempts for a given Jabber ID in a >>> given time period. >>> While such a limit may seem beneficial, in fact it might result in locking >>> out the legitimate >>> owner of a Jabber ID if a malicious entity attempts a large number of >>> illegitimate >>> authentication attempts for the Jabber ID; therefore such a limit is not >>> recommended >>> and it is instead recommended to limit the number of connections and >>> connection >>> attempts on a per-IP basis. >> I think this text is also arguing against counting the number of >> failed authentication attempts on a single connection, which is wrong. >> Limiting the number of authentications on a single connection doesn't >> result in lockout (the client can disconnect and reconnect) and it >> only punishes malicious (or broken) clients. This is also much easier >> to implement than a counter across multiple connections. > > If you have forgotten your password you might try to authenticate 3 or 4 > times before giving up. > > If I'm trying to hack your password (dictionary attack) I might try to > authenticate 1000 times or whatever over some period of time. > > Therefore, allowing a reasonably number of authentication retries is a > good idea but allowing an unreasonable number is a bad idea. For SASL, > rfc3920bis says at least 2 and no more than 5 authentication retries per > connection / stream: > > http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-08.html#sasl-process-neg-failure > > If one hits the SASL limit, the server would terminate the stream (SASL > failure) and one would need to reconnect. Therefore, for a given > connection or stream one would be allowed 3 to 6 auth attempts. If I > want to hack your password, I'd need to "lather, rinse, repeat" (new > stream, ~5 auth attempts, failure; new stream, ~5 auth attempts, > failure; etc.). Therefore I would quickly accumulate connection attempts > to hack your account, whereas if you forget your password then you might > connect once or twice (~5 to ~10 auth attempts) then give up. > > I think we have consensu that such an approach is appropriate. > > Now, if I'm trying to DoS you then I could repeatedly do the > connect+auth+retry dance until your account gets locked down. > > The question is, how does a server determine when to lock down an > account? You seem to envision that lockout might happen based on > exceeding some limit per time period for any of the following options: > > 1. authentication attempts per account > 2. authentication attempts per IP address > 3. connection attempts per account > 4. connection attempts per IP address > 5. simultaneous connections per account > 6. simultaneous connections per account > > Currently XEP-0205 says a server could do #1 but the consequences might > be a DoS against the legitimate user, so instead it recommends #4 or #6 > because the spec assumes that the attacker will come from a different IP > address than the one used by the legitimate user. But #4 and #6 don't > solve the problem that Waqas mentions (a DoS attack launched by someone > from your same IP address, e.g. from behind the same NAT). > > I hope that clarifies the options, even if it doesn't describe a full > consensus. So I chatted about this with Alexey using a real-time communications technology. ;-) We concluded that we need to refer to Section 7.3.5 of rfc3920bis: http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-08.html#sasl-process-neg-failure Therefore I would propose the following adjustment: *** Limiting the number of authentication attempts for a given Jabber ID in a given time period. While such a limit may seem beneficial, in fact it might result in locking out the legitimate owner of a Jabber ID if a malicious entity attempts a large number of illegitimate authentication attempts for the Jabber ID; therefore such a limit is not recommended *except as described in Section 7.3.5 of rfc3920bis*, and it is instead recommended to limit the number of connections and connection attempts on a per-IP basis. *** This does not address the issue of whole countries behind NATs, for which we might want to add a note in Section 4.2 of XEP-0205. /psa
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
I have 2 question about this spec: 1) Why not use user-specified handle (meta-contact name) instead of some opaque "tag"? 2) How are these meta-contact data supposed to be scattered across multiple accounts? I really didn't get this part. (clarification needed?)
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
Remko Tronçon wrote: >> XEP-0209 (Metacontacts) has been Deferred because of inactivity. > > I'll take some action on this after FOSDEM. And you have some more important writing projects to finish, too. ;-) /psa
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
> XEP-0209 (Metacontacts) has been Deferred because of inactivity. I'll take some action on this after FOSDEM. cheers, Remko
Re: [Standards] LAST CALL: XEP-0232 (Software Information)
2009/1/22 Olivier Goffart : > Why do we need to send icons URL for status? I think it will just confuse the > user if each cotact has different icons for different statuses. > > I see also that as a potential security issue that can reveal user's presence > + IP (while following the links) > I agree. IMO there is no reason, why should one client tell another how to display it's states. I would certainly not implement (or enable in client supporting this) such behavior. Noted security issue is also a problem. On the other hand, if some client really used it, it would have no way of knowing, whether cached images are up-to-date. Other thing: every client can have different sizes of icons. I imagine one could solve this by offering big images for client to scale down. Now we can download 50+ (probably more) 128x128px images every startup. So.. I think it is nice reinterpretation of XEP-92, but these icons are way too useless.
Re: [Standards] Intra-Jid Private State
> I'm not sure I follow - surely we can use XEP-0050 here, and just define an > ad-hoc command that has the precise properties we need? My opinion: making assumptions about what certain ad-hoc commands do is contradictory. To me, ad-hoc means 'made up on the spot', something that doesn't have a protocol, something that requires human interpretation to understand what a command does. If you want to make assumptions about commands, create a real protocol for it, don't abuse ad-hoc. That's also why I consider FORM_TYPE not to be something to be used for automation of ad-hoc commands, but rather an extra hint on how to display a form. > I'm intending to formally define the Missing Messages bit within this XEP, I > just wanted to get this much out, to try to avoid the accusations that I've > not made any such proposal. Even better. > Good question. I think the answer is probably yes - we have a command which > says "Gimme messages [from X] [and mark 'em read]". +1 > BTW, I keep on reading "intra-jid" as "infra dig" for some bizarre reason. > Don't ask me why. I won't. cheers, Remko
[Standards] Intra-Jid Private State
On Thu Jan 22 07:39:44 2009, Remko Tronçon wrote: > Attached is part of a solution to the (largely unstated) problem. Apart from the spelling mistakes, I like it so far. Spellling mistakes? As iff. > 1) A refinement on the remote control ad-hoc commands to send only some > pending messages. (Not really essential, but might be nice). Actually, a real protocol (based on ad-hoc RC) will probably be better here. I'm not sure I follow - surely we can use XEP-0050 here, and just define an ad-hoc command that has the precise properties we need? > 2) A mechanism Kev proposed for raising priority dynamically relative to > other resources based on user activity (as opposed to current practise, > which is lowering it due to use inactivity without looking at other > clients). Ok. I like that the private state thingy is independent of the dynamic priority approach. Both are interesting solutions in their own right, and complement each other very well. Right - if Kev's dynamic priority thing works out (and I think it should), then misdirected messages should be quite rare - they'd only happen post "lock on". I guess the third missing part is a XEP that specifies the 'awaiting messages' profile of intra-jid status formally, and describes hints on how clients might behave. For example, whenever a client detects user action (e.g. mouse movement), it automatically fetches the awaiting messages from other clients and displays them. I'm intending to formally define the Missing Messages bit within this XEP, I just wanted to get this much out, to try to avoid the accusations that I've not made any such proposal. There's also the question on whether it makes sense to provide more intra-jid state for 'awaiting messages'. For example, a remote client could change the icon of a contact in a roster if it knew there were messages awaiting for it in another client, and would fetch them when clicked; this would mean that the intra-jid state could specify awaiting messages per contact. The (probably better) alternative is that the client pulls this information if it wants it (which would move it to the RC protocol). This in turn raises the question: should there be a 'peek message' command (on top of the 'fetch message' command), which would allow all clients to display pending messages in open chat dialogs without owning the message? Good question. I think the answer is probably yes - we have a command which says "Gimme messages [from X] [and mark 'em read]". BTW, I keep on reading "intra-jid" as "infra dig" for some bizarre reason. Don't ask me why. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
