Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Mon, 2011-08-22 at 20:30 +0200, Alexander Holler wrote: Hello, [..] And in my list before, I've forgotten to mention the problem that for requests a form is send by the user to room, which the room then forwards to moderators, and the moderators will see the form with the room as sender. I see it as a problem if the MUC-service really forwards such a request without checking every content. And if the service has to check everything of the form, there is no reason why a form must be send by the user, the service could build the form too and something more simple could be used for requests (e.g. something like x xmlns='...muc#request) I assume this is about 'Registering with a Room'. There are two parts to this: 1) The interaction between the occupant and the room to submit the request 2) The interaction between the admin/owner and the room to approve the request. The reason step 1 is done using Data Forms, is that allows a lot of flexibility in what information is requested from the occupant to complete the registration. Having a namespace with some predefined fields limits this tremendously. We had this for in-band account registration in the very early Jabber days, and is one of the reasons why Data Forms were invented. On top of that Field Data Standardization for Data Forms (XEP-0068) allows for providing a namespace for the the field names. In this case, the form sent to the admin doesn't have an encapsulating element in a MUC namespace, and any Jabber client that can handle data forms is able to provide a UI for this, without any knowledge of the underlying semantics. XEP-0068 also provides a way to have fields with names that are entirely application specific. They MUST start with 'x-'. This is great for asking for information from the occupant that is not covered by the predefined fields in XEP-0045 or registered with the XMPP Registrar. Step 2 is entirely optional and up to the implementation and/or configuration of the MUC service: 9.9 Approving Registration Requests If a service does not automatically accept requests to register with a room, it MAY provide a way for room admins to approve or deny registration requests over XMPP (alternatively, it could provide a web interface or some other admin tool). [..] You appear to want to check the values sent to the room admin/owner, but why? What attack vector do you believe needs to be addressed? -- ralphm
Re: [Standards] Microblogging: XEP-0277 and beyond
On 08/23/2011 09:14 AM, Justin Karneges wrote: On Monday, August 22, 2011 05:12:54 AM Sergey Dobrov wrote: On 08/19/2011 04:55 AM, Justin Karneges wrote: On Thursday, August 18, 2011 05:10:58 AM Goffi wrote: - the ability to get missed items between the last time a contact was disconnected and the time it reconnect I have a protocol flow for reliable pubsub that I've not yet publicized, but essentially the idea is to include Result Set Management (XEP-0059) UID values in pubsub event notifications. The client can then notice if it missed an item and use iq-get to catch up. Maybe this could go in some RSM with PubSub XEP that sorely needs to be written. Justin You forgot that we need to know about item retraction as well as about item publishing. The same thing about item update. The possibility to get items by date and time is good but it's not cover these problems and it's not necessary at this time from my point of view. The basic solve for item retraction is for the server to keep deletion markers around. For example the server could clear all content of an item and flag it as deleted, but keep it in the same position in the item list. This way retracted items can be reported in iq responses. That would not work because it is equal to the item update with the blank payload but how could you know that the item was updated? Unfortunately XEP-0060 never discusses sending retract in an iq response where item normally is, so I am not sure if this would be allowed today without a protocol update. Alternatively, retractions could be represented within the items themselves. For example if you were using Atom, an empty entry element may suffice to indicate deletion. Protocol needs many edits anyway. For example, it very useful to see a publisher of an item but XEP-60 doesn't give us good explanation how to determine if pubsub service can send such notifications. Item publish and update are fine though, right? Or what are you thinking about them? Publish is ok since we have RSM. Update has the same problem as retract. From my point of view, the best solution is node journal but I can't be sure since that idea was not discussed. Justin -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Am 23.08.2011 11:23, schrieb Ralph Meijer: On Mon, 2011-08-22 at 20:30 +0200, Alexander Holler wrote: Hello, [..] And in my list before, I've forgotten to mention the problem that for requests a form is send by the user to room, which the room then forwards to moderators, and the moderators will see the form with the room as sender. I see it as a problem if the MUC-service really forwards such a request without checking every content. And if the service has to check everything of the form, there is no reason why a form must be send by the user, the service could build the form too and something more simple could be used for requests (e.g. something likex xmlns='...muc#request) I assume this is about 'Registering with a Room'. There are two parts to this: I meant the wording e.g. in 8.6: As noted in the Requesting Voice section of this document, when a service receives a request for voice from an occupant it SHOULD forward that request to the room moderator(s). That 'forward' is what makes me nervous. You appear to want to check the values sent to the room admin/owner, but why? What attack vector do you believe needs to be addressed? One of the first things I first thought about is what happens with fields of type 'hidden' in the request. I haven't checked any implementation, but I could imagine implementations which really would just forward such fields which then might end in the approval form send to and back from the moderator. Playing with UTF-stuff in (forwarded) labels could allow some funny things too. Maybe I just take that 'forward' to literal, but I don't like it. Regards, Alexander
Re: [Standards] Microblogging: XEP-0277 and beyond
On 8/21/11 4:45 PM, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: Good catch, I didn't consider clock skew. I wonder if the client should just specify a timestamp 5-10m in the past instead of having magic at the node servers. Then accurate time queries (made relative to timestamps of other items provided by the server) stay optimized. Seems to me that client writers are more likely to incorrectly think the server clock is going to be right than the other way around, but I don't care where the skew is added as long as it's specified which side does it, so we don't double-skew. -- Joe Hildebrand
Re: [Standards] Microblogging: XEP-0277 and beyond
On 8/22/11 8:14 PM, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: The basic solve for item retraction is for the server to keep deletion markers around. For example the server could clear all content of an item and flag it as deleted, but keep it in the same position in the item list. This way retracted items can be reported in iq responses. Unfortunately XEP-0060 never discusses sending retract in an iq response where item normally is, so I am not sure if this would be allowed today without a protocol update. Alternatively, retractions could be represented within the items themselves. For example if you were using Atom, an empty entry element may suffice to indicate deletion. Item publish and update are fine though, right? Or what are you thinking about them? I was hoping for something more like atomic-subscribe-and-send-updates as a subscription option, so that the client's notification handling didn't have to change. The server could then just send normal retracts in that flow. If there was another subscription option that says it's ok to send me multiple notifications in the same message, the server could intelligently batch the notifications together for clients that have added the extra foreach loop. -- Joe Hildebrand
Re: [Standards] Microblogging: XEP-0277 and beyond
On Tuesday, August 23, 2011 04:34:12 AM Sergey Dobrov wrote: On 08/23/2011 09:14 AM, Justin Karneges wrote: The basic solve for item retraction is for the server to keep deletion markers around. For example the server could clear all content of an item and flag it as deleted, but keep it in the same position in the item list. This way retracted items can be reported in iq responses. That would not work because it is equal to the item update with the blank payload but how could you know that the item was updated? I'm still unsure what you're saying but I'll try to guess: do you mean to say that you cannot determine the difference between a publish vs update, unless you have a local copy of the item to compare with? If so, I have found that in many situations this does not actually matter. Can you share a use case? From my point of view, the best solution is node journal but I can't be sure since that idea was not discussed. True. I am trying to avoid this if possible. My stance is there is nothing wrong with using a journal to implement pubsub, but ideally pubsub-using protocols should not be so complex that they require a journal-based implementation to participate. Justin
