Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?
On 8/25/11 7:46 AM, Ralph Meijer wrote: On Thu, 2011-08-25 at 15:00 +0200, Andreas Monitzer wrote: On Thursday, August 25 2011 at 00:19, Peter Saint-Andre wrote: Right, there are use cases (e.g., vCards in chatrooms) that make PEP unworkable. I'm willing to have the discussion again. :) Then why not fix it at the source (PEP), maybe by creating a separate XEP for MUC-PEP? Is it better to have a workaround in every XEP that would otherwise use PEP instead? Agreed. We've talked about his on several instances of the XMPP Summit, lastly in the Cisco offices near Brussels, sparked by the very same specification for vCard. As far as I can remember we covered a lot of ground, but didn't reach a conclusion. I'm not sure if anyone made notes there, but it would be valuable to have a summary of aspects and issues around PubSub inside MUC. Kevin, Matt, Joe, do you have such notes? I don't know of any such notes. My major issue is that requiring specific server support results in a huge delay in deployment, and some servers will never support it at all (which means that client developers will still have to implement vcard-temp in 2020), since many server developers and admins are of the kind if it ain't broke, don't touch it. I'm not sure if this is also about using PEP for transporting vCard4, but I seem to remember some of the possible solutions did impose cooperation of the MUC room for doing PEP 'properly'. That is my recollection, too. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?
On Aug 25, 2011, at 07:46, Ralph Meijer wrote: On Thu, 2011-08-25 at 15:00 +0200, Andreas Monitzer wrote: On Thursday, August 25 2011 at 00:19, Peter Saint-Andre wrote: Right, there are use cases (e.g., vCards in chatrooms) that make PEP unworkable. I'm willing to have the discussion again. :) Then why not fix it at the source (PEP), maybe by creating a separate XEP for MUC-PEP? Is it better to have a workaround in every XEP that would otherwise use PEP instead? Agreed. We've talked about his on several instances of the XMPP Summit, lastly in the Cisco offices near Brussels, sparked by the very same specification for vCard. As far as I can remember we covered a lot of ground, but didn't reach a conclusion. I'm not sure if anyone made notes there, but it would be valuable to have a summary of aspects and issues around PubSub inside MUC. Kevin, Matt, Joe, do you have such notes? I have some notes from a e2e discussion, but they only say MUC should support PEP (-: My major issue is that requiring specific server support results in a huge delay in deployment, and some servers will never support it at all (which means that client developers will still have to implement vcard-temp in 2020), since many server developers and admins are of the kind if it ain't broke, don't touch it. I'm not sure if this is also about using PEP for transporting vCard4, but I seem to remember some of the possible solutions did impose cooperation of the MUC room for doing PEP 'properly'. Agreed. - mm http://goo.gl/voEzk
Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?
On 8/20/11 12:49 PM, Kim Alvefur wrote: On Fri, 2011-08-19 at 22:04 +0200, Andreas Monitzer wrote: Why doesn't it use plain PEP, instead defining its own protocol? It did, see this thread: http://mail.jabber.org/pipermail/standards/2011-April/024355.html Right, there are use cases (e.g., vCards in chatrooms) that make PEP unworkable. I'm willing to have the discussion again. :) Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?
On Wed, 2011-08-24 at 16:19 -0600, Peter Saint-Andre wrote: Right, there are use cases (e.g., vCards in chatrooms) that make PEP unworkable. I'm willing to have the discussion again. :) Did someone have a good reason to not allow both methods? -- Kim Alvefur z...@zash.se
Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?
On 8/24/11 4:21 PM, Kim Alvefur wrote: On Wed, 2011-08-24 at 16:19 -0600, Peter Saint-Andre wrote: Right, there are use cases (e.g., vCards in chatrooms) that make PEP unworkable. I'm willing to have the discussion again. :) Did someone have a good reason to not allow both methods? I'm open to that. Although it's not always a good idea to have two ways of doing the same thing. :) /psa
Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?
On Aug 24, 2011, at 16:36, Peter Saint-Andre wrote: On 8/24/11 4:21 PM, Kim Alvefur wrote: On Wed, 2011-08-24 at 16:19 -0600, Peter Saint-Andre wrote: Right, there are use cases (e.g., vCards in chatrooms) that make PEP unworkable. I'm willing to have the discussion again. :) Did someone have a good reason to not allow both methods? I'm open to that. Although it's not always a good idea to have two ways of doing the same thing. :) I think in this case, we'll survive (-: Having the ability to know when a vCard changes without having to poll is very very very nice. - mm http://goo.gl/voEzk
Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?
On 8/24/11 4:52 PM, Matthew A. Miller wrote: On Aug 24, 2011, at 16:36, Peter Saint-Andre wrote: On 8/24/11 4:21 PM, Kim Alvefur wrote: On Wed, 2011-08-24 at 16:19 -0600, Peter Saint-Andre wrote: Right, there are use cases (e.g., vCards in chatrooms) that make PEP unworkable. I'm willing to have the discussion again. :) Did someone have a good reason to not allow both methods? I'm open to that. Although it's not always a good idea to have two ways of doing the same thing. :) I think in this case, we'll survive (-: Having the ability to know when a vCard changes without having to poll is very very very nice. Agreed. One stumbling block, to me, is the publishing side. How does a client know which publishing method is preferred? Do we allow only PEP publish or IQ publish, and expect the server to make the information available to both kinds of subscribers/retrievers? Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?
On Wed, 2011-08-24 at 17:04 -0600, Peter Saint-Andre wrote: On 8/24/11 4:52 PM, Matthew A. Miller wrote: Having the ability to know when a vCard changes without having to poll is very very very nice. Agreed. One stumbling block, to me, is the publishing side. How does a client know which publishing method is preferred? Do we allow only PEP publish or IQ publish, and expect the server to make the information available to both kinds of subscribers/retrievers? Transparently mapping IQ set/gets to equivalent PEP publish/retrieve on the server-side doesn't sound so hard. If both ways are available and does the same, then what difference would it make? So, how about leaving preferences up to implementors? If we do go with allowing both, then all servers with PEP support already support half of it. That instantly gives clients with PEP support something to test against, which may speed implementation and adoption. And that should encourage server devs to implement the other part. I'd expect the IQ way to be used when PEP is missing (like a client that didn't already support it but really wants to have vCard4) or unusable (like in MUC rooms). And maybe if you are cheap and want to save a few bytes. ;) Also, maybe we should also look at making XEP-84 MUC-friendlier? -- Kim Alvefur z...@zash.se
Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?
25.08.2011 08:52, Matthew A. Miller wrote: I think in this case, we'll survive (-: I don't like PEP, so I won't :P Having the ability to know when a vCard changes without having to poll is very very very nice. We already have vcard-temp:x:update for that. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?
On Aug 24, 2011, at 20:43, Evgeniy Khramtsov wrote: 25.08.2011 08:52, Matthew A. Miller wrote: I think in this case, we'll survive (-: I don't like PEP, so I won't :P What specifically about PEP do you not like? Or you can discover how to stop worrying and love the PEP (-: Having the ability to know when a vCard changes without having to poll is very very very nice. We already have vcard-temp:x:update for that. In my opinion, vcard-temp:x:update is a hack: * It is documented in XEP-0153 solely for vCard(-temp)-based avatars * It violates at least one SHOULD in RFC 6121 § 4.2.2 (presence update not related to a user's availability for communication or the communication capabilities of the resource) * It requires at least one resource for a user to be or become online (inappropriate to impossible for corporate/enterprise deployments) Also, what happens when XEP-0292 supersedes XEP-0054? - mm http://goo.gl/voEzk
Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?
On 8/24/11 9:59 PM, Matthew A. Miller wrote: On Aug 24, 2011, at 20:43, Evgeniy Khramtsov wrote: 25.08.2011 08:52, Matthew A. Miller wrote: I think in this case, we'll survive (-: I don't like PEP, so I won't :P What specifically about PEP do you not like? Or you can discover how to stop worrying and love the PEP (-: Having the ability to know when a vCard changes without having to poll is very very very nice. We already have vcard-temp:x:update for that. In my opinion, vcard-temp:x:update is a hack: * It is documented in XEP-0153 solely for vCard(-temp)-based avatars * It violates at least one SHOULD in RFC 6121 § 4.2.2 (presence update not related to a user's availability for communication or the communication capabilities of the resource) * It requires at least one resource for a user to be or become online (inappropriate to impossible for corporate/enterprise deployments) Also, what happens when XEP-0292 supersedes XEP-0054? urn:ietf:params:xml:ns:vcard-4.0:x:update, anyone?
Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?
25.08.2011 13:59, Matthew A. Miller wrote: On Aug 24, 2011, at 20:43, Evgeniy Khramtsov wrote: I don't like PEP, so I won't :P What specifically about PEP do you not like? Or you can discover how to stop worrying and love the PEP (-: As for me, PEP scales poorly. I have already wrote on the topic in this list and I'd like not to restart that flame :) We already have vcard-temp:x:update for that. In my opinion, vcard-temp:x:update is a hack: * It is documented in XEP-0153 solely for vCard(-temp)-based avatars So? :) * It violates at least one SHOULD in RFC 6121 § 4.2.2 (presence update not related to a user's availability for communication or the communication capabilities of the resource) SHOULD is not a MUST. Violate if you want. * It requires at least one resource for a user to be or become online (inappropriate to impossible for corporate/enterprise deployments) Is it really a big issue? Also, what happens when XEP-0292 supersedes XEP-0054? Indeed, what? I really have no idea :) -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?
On Aug 24, 2011, at 22:19, Evgeniy Khramtsov wrote: We already have vcard-temp:x:update for that. In my opinion, vcard-temp:x:update is a hack: * It is documented in XEP-0153 solely for vCard(-temp)-based avatars So? :) It only covers pushing an update when the avatar changes, not changes to given name, surname, phone numbers, etc. * It violates at least one SHOULD in RFC 6121 § 4.2.2 (presence update not related to a user's availability for communication or the communication capabilities of the resource) SHOULD is not a MUST. Violate if you want. From RFC 2119: SHOULD This word, or the adjective RECOMMENDED, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I don't see Violate if you want anywhere in that description. * It requires at least one resource for a user to be or become online (inappropriate to impossible for corporate/enterprise deployments) Is it really a big issue? Yes it is. For corporate and enterprise environments, the vCard information is most often managed in a central location (such as LDAP/AD). These same environments often have a strong requirement for updates to be broadcasted in a timely manner. - mm http://goo.gl/voEzk
Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?
On Fri, 2011-08-19 at 22:04 +0200, Andreas Monitzer wrote: Why doesn't it use plain PEP, instead defining its own protocol? It did, see this thread: http://mail.jabber.org/pipermail/standards/2011-April/024355.html -- Kim Alvefur z...@zash.se
