Re: [Standards] XEP-0124 and XEP-0206
Hi, XEP-0124 defines a way for maintaining bi-directional streams over HTTP. It can be any stream, not just XMPP. XEP-0206 advises how to use XEP-0124 for streaming XML streams that are in use in XMPP. Thanks. On 19/05/2015 07:43, Vaibhav Ranglani wrote: Went through the specifications of both XEP-124 and XEP-206. Can somebody please throw a pointer as to how they are related. Thanks Vaibhav -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Proposed XMPP Extension: Unique and stable message IDs
I'm in broad agreement with what Kurt writes below. I think the only point where we differ is that the does MUC issue new ids question is really one we could answer now (and if not directly answer, certainly fix). I would also add that using the stanza's id and from attributes, plus a (possibly server-provided) public tracking identifier for the stream, should be unique - and in at least most cases where we care we can mandate it. On 4 June 2015 at 11:56, Kurt Zeilenga kurt.zeile...@isode.com wrote: It’s not clear to me that the problems that this extensions proposes to address can be addressed through use an extension to XMPP. Extensions ought to be truly optional. This ProtoXEP appears to be making mandates which are more appropriate made, if the community were to support them being made, in a revision of the XMPP base specification. For instance, the ProtoXEP not only says XMPP entities, which are routing stanzas, MUST NOT strip the message-id element from message stanzas” but seems to be rely on all servers adhering to this MUST NOT. That’s never going to be case… certainly not for implementations not purporting to implement this extension… and likely not for some implementations which might purport to implement this extension. This spec needs to consider and discuss what happens in face of elements it suggests be added are stripped by another entity. I have a big problem with one ID to rule them all… and a bigger problem with the last ID being that ID (the overrride requirement). To the extent IDs are needed, they need to “stable”. This means they cannot be overridden. For operational and security reasons, it unwise for one entity to rely on IDs for services it provides (such as MAM) provide by some other entity. To the extent IDs are needed, we need per-entity IDs… possibly even per-enitty handling IDs (that is, when an IM handles a stanza for the second time (such as after being handled by an MUC service, it might need to separately ID the stanza). This because stanza content can and will change as its handled by other entities. It’s not clear to me how this id provided by this extension would or could be used in message type=error stanzas. It’s not clear to me why this extension proposes a message/ only solution, when it seems likely that stanza id= problems are not necessarily specific to message stanzas. It seems that there’s many security risks here associated with ID forgery, replay, etc., but I’m not sure what, if any, mitigation is needed. I suggest instead an element allowing entities to provide IDs in stanzas they originate or handle. stanza-id xmlns=‘…’ id=‘ID’ provider=“JID”/ where ID is some opaque ID and JID is the providers JID. Servers which need to provide different IDs in different contexts can use different JIDs. (or possibly better to allow a context attribute or something). I’m not convinced having an extension providing an ID (whether by the ProtoXEP suggestion or mine or other) reliably solves any problem I’m faced with. For the MUC use case, I rather we solve this as part of the MUC2 effort… For the MAM case, to the extent what it offers in the current Experimental XEP is not sufficient, I suggest MAM XEP be modified to provide for reliable identification of archived content. — Kurt
[Standards] Fwd: [Council] Minutes 2015-06-03
FYI Begin forwarded message: From: Kevin Smith Subject: [Council] Minutes 2015-06-03 Date: 4 June 2015 08:19:49 BST To: XMPP Council Reply-To: XMPP Council Room logs: http://logs.xmpp.org/council/2015-06-03/ 1) Roll call Lance, Matt, Kev, Dave, Fippo present 2) Date of next meeting 2015-06-10 15:00Z 3) Any other business No Council action (for general discussion, see logs) Fini
Re: [Standards] Proposed XMPP Extension: Nonzas (are not Stanzas)
On 3 Jun 2015, at 16:02, XMPP Extensions Editor edi...@xmpp.org wrote: http://xmpp.org/extensions/inbox/nonza.html I like short XEPs - much easier to scan through :) The definition here seems potentially useful. I would add a ‘generally’ to 4 so that it becomes “...they are generally used in a more…”, so as not to be seen as prescriptive. I’m not sure that the business rules in 5 are useful - particularly given that (2) then has to be clarified to already not apply in some cases. None of the current nonzas are routed, but it doesn’t seem impossible that one might be in the future, and I don’t see a reason to forbid it here. Noting that they’re not expected to be routed seems useful and sufficient, to me. /K
Re: [Standards] Proposed XMPP Extension: Unique and stable message IDs
On 3 June 2015 at 16:02, XMPP Extensions Editor edi...@xmpp.org wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Unique and stable message IDs Abstract: This specification describes unique and stable IDs for message stanzas. URL: http://xmpp.org/extensions/inbox/mid.html Yay, thanks Florian! My feedback so far: ## client-id This is much better than the first draft I saw containing 'client-id'. However I'm still unconvinced that it belongs here. It has different uses, and different semantics. If it stays in this XEP (which I'm ok with), I think it should be in another element, which the server doesn't have to even care about. However for the use-cases that I understand it to be solving, I don't believe it should even be necessary. The id attribute is the client's id and it should be preserved. Duplicating it in a content element is a silly hack in my opinion. ## replacing message-id's This revision says that there must only be a single id at any point in time. This would prevent you from learning the id that a remote MUC service (or any other entity) assigned it (in case you want to query a MUC's archive). I would probably go for the same approach as the original archived/ element in MAM, and have a 'by' attribute (similar also to delay/): message-id id=1234-- by=example.com / This would also allow clients to use it if they really wanted to, by putting their JID in the 'by'. Regards, Matthew
Re: [Standards] Proposed XMPP Extension: Unique and stable message IDs
It’s not clear to me that the problems that this extensions proposes to address can be addressed through use an extension to XMPP. Extensions ought to be truly optional. This ProtoXEP appears to be making mandates which are more appropriate made, if the community were to support them being made, in a revision of the XMPP base specification. For instance, the ProtoXEP not only says XMPP entities, which are routing stanzas, MUST NOT strip the message-id element from message stanzas” but seems to be rely on all servers adhering to this MUST NOT. That’s never going to be case… certainly not for implementations not purporting to implement this extension… and likely not for some implementations which might purport to implement this extension. This spec needs to consider and discuss what happens in face of elements it suggests be added are stripped by another entity. I have a big problem with one ID to rule them all… and a bigger problem with the last ID being that ID (the overrride requirement). To the extent IDs are needed, they need to “stable”. This means they cannot be overridden. For operational and security reasons, it unwise for one entity to rely on IDs for services it provides (such as MAM) provide by some other entity. To the extent IDs are needed, we need per-entity IDs… possibly even per-enitty handling IDs (that is, when an IM handles a stanza for the second time (such as after being handled by an MUC service, it might need to separately ID the stanza). This because stanza content can and will change as its handled by other entities. It’s not clear to me how this id provided by this extension would or could be used in message type=error stanzas. It’s not clear to me why this extension proposes a message/ only solution, when it seems likely that stanza id= problems are not necessarily specific to message stanzas. It seems that there’s many security risks here associated with ID forgery, replay, etc., but I’m not sure what, if any, mitigation is needed. I suggest instead an element allowing entities to provide IDs in stanzas they originate or handle. stanza-id xmlns=‘…’ id=‘ID’ provider=“JID”/ where ID is some opaque ID and JID is the providers JID. Servers which need to provide different IDs in different contexts can use different JIDs. (or possibly better to allow a context attribute or something). I’m not convinced having an extension providing an ID (whether by the ProtoXEP suggestion or mine or other) reliably solves any problem I’m faced with. For the MUC use case, I rather we solve this as part of the MUC2 effort… For the MAM case, to the extent what it offers in the current Experimental XEP is not sufficient, I suggest MAM XEP be modified to provide for reliable identification of archived content. — Kurt
Re: [Standards] Proposed XMPP Extension: Unique and stable message IDs
On 3 Jun 2015, at 16:02, XMPP Extensions Editor edi...@xmpp.org wrote: Title: Unique and stable message IDs URL: http://xmpp.org/extensions/inbox/mid.html Hoorah again for short XEPs. 3.1 - I think SHOULD is too strong for UUIDs here, isn’t it? There’s no interoperability concern - so I’d just go with ‘suggested’. 3.2 - I think MUST here is weird when combined with ‘some use cases’ being unnamed. In general, is stamping multiple message-ids, together with who did the stamping, most elegant here? /K
[Standards] Added elements (was: Proposed XMPP Extension: Unique and stable message IDs)
On 4 jun. 2015, at 11:26, Matthew Wild mwi...@gmail.com wrote: I would probably go for the same approach as the original archived/ element in MAM, and have a 'by' attribute (similar also to delay/): message-id id=1234-- by=example.com http://example.com/ / This would also allow clients to use it if they really wanted to, by putting their JID in the 'by'. I fully admit that this is going to sound like an over-engineered solution to a rare and unimportant problem, but anyway. Servers adding elements to stanzas is tricky because the client needs to determine whether it was actually that server that added them, not the sender or some other server along the line, and I fear clients might mess up that check. delay has the exact same problem. Your server can't strip out elements that it knows nothing about. But instead of adding stripping support for every new XEP to all servers, how about making a new, general, XEP to indicate who added elements? For example, adding a single attribute 'by' in a new namespace: delay xmlns='urn:xmpp:delay' stamp='2002-09-10T23:41:07Z' added:by='conference.example.lit' xmlns:added='urn:xmpp:added' / message-id xmlns='urn:xmpp:mid:0' id='de305d54-75b4-431b-adb2-eb6b9e546013' added:by='muc.capulet.lit' xmlns:added='urn:xmpp:added' / This means the server does not need to know the XEP used to strip those elements out, it can just remove all elements that have a 'added:by' value that is obviously incorrect. As they are in a new namespace, the original XEPs don't need to be updated and clients that don't understand this specification can easily ignore them. Alternatively, we could give 'from', as it is already used by Delayed Delivery, extra meaning, (like required/ in stream features), but I fear that may have unintended consequences. Of course this doesn't protect clients from servers maliciously adding, removing or changing elements, it only protects users from others impersonating their own server. Regards, Thijs signature.asc Description: Message signed with OpenPGP using GPGMail
