Re: [Standards] Proposed XMPP Extension: Message Fastening
Thanks for the feedback. I don’t want to ignore this, but was trying to digest bits. > On 12 Dec 2019, at 12:10, Marvin W wrote: > > On 12/11/19 6:50 PM, Kevin Smith wrote: >>> The business rules in §4 say that a Fastening can not have a Fastening >>> themselves. If both message attaching, reactions and others are realized >>> using Fastening, this implies that you can not react to an attached >>> message, for example you would not be able to thumbs-up the fact that a >>> bot provided a helpful attaching. While it is arguable that this is not >>> strictly a required feature, the restriction seems to be unreasonable in >>> that case. >> This one was deliberate - reacting to reactions to reactions (and similar) >> is the sort of scenario that it’s easy to spec, but then generally horrific >> to implement (I refer to pubsub collections as a simpler example of where a >> similar concept seems pleasantly general but ends up being overcomplicated >> to work with - to the point of neglect). > > I think the question this comes down to is, what we want to build using > fastenings. I don't want reactions to reactions, but if we allow some sort of > "comment" as a Fastening, then we should also allow reactions to such > comments. > If we keep this restriction, I believe we'd need a generic standard for > associating a message to another message, independent of it being a fastening > or another kind of message (that can have fastenings). I think we’re moving on this later in the thread. > Also one of the reasons why everyone agreed it would help to have the > fastened elements as a sub-element of the instead of directly in > the as in XEP-0367, is that if we don't do that, it isn't clear how > to handle the correction of a message attaching case (a fastening of a > fastening). Thus if we decide against allowing fastening of fastenings, the > decision to use sub-element and etc should be revisited... > >> I think can contain multiple elements, and they’re treated >> independently >> So if you apply-to two elements, and then replace apply-to one element, it >> would replace the relevant one, leaving the other intact. If you then >> replace apply-to both elements, it would replace both of them. This is >> under-(not at all) specified. >> For elements, it should be the target name/namespace, as if it >> was a child. > > How are edits supposed to work then? Because for various (good) reasons they > exist of multiple elements in the example. > https://xmpp.org/extensions/xep-0422.html#example-4 I need to go back and work through examples. I’m not immediately sure that what I was saying didn’t make sense. If you have multiple elements in an apply-to, you would replace them by specifying the replacement of the particular element (or elements) you wanted to replace. Am I missing the point? > >>> What happens if a client accidentally does not add the `replace="true"` >>> (for example because the same element was send from two different >>> devices at about the same time)? Will a) there be two elements with the >>> same namespace and name then, b) the second silently ignored or c) the >>> first silently replaced? In case of a), how to decide which to replace >>> in the future? In case of b), how does the sending entity know if there >>> message was first or second? In case of c), why put `replace="true"` at >>> all if it is implicitly done anyways? >> Is it sufficient to assert that protocols that want to attach multiple of >> the same namespace then can’t replace them, or do we need ids on the >> fastenings? >> I guess if we have 😂 and >> 🤦🏻♂️ as individual fastenings, we need to be able to remove one and leave >> the other intact. OTOH, if a fastening contained one reaction for both 😂 and >> 🤦🏻♂️, it could be replaced with a reaction with just 🤦🏻♂️. > > I don't quite understand what you want to say here. If each reaction is a > separate fastening, how do you remove a single one if you only identify > reactions by their qname. That’s what I was saying, I think. If we were to treat multiple reactions as multiple fastenings, we would need to introduce new mechanisms. If we were to treat all reactions as one fastening, we wouldn’t. > Also it apparently is currently specified how to replace but not how to > remove a fastening. Replacing with an empty variant may be technically > possible, but that empty variant would then still be required to send out to > clients (because we don't want servers to have to know what an empty variant > looks like for each fastening). I’d made a note that removal isn’t specified, yes. I’ll address this. >> I have assumed that if you’re doing full stanza encryption, and want >> archiving, your only choice as things stand is to have a complete download >> of your archive, and to do all collation locally. Having both smart >> archivability (without decryption) and encryption is a more or less >> unsolvable problem. >> Does anyone have a wor
Re: [Standards] Proposed XMPP Extension: Message Fastening
Am Mittwoch, den 11.12.2019, 17:10 + schrieb Kevin Smith: > > On 9 Sep 2019, at 20:37, Florian Schmaus wrote: > > Furthermore, xep359 makes it very clear > > that xep359-IDs are just unique and stable within the scope of the > > id-assigning-entity (this allows implementations to use simple > > mechanisms to generate the ID without considering collisions with > > other > > id-assigning-entities). > > Good point, thanks Flo. Although I’m not sure that 359 does make it > clear that it’s not globally unique, actually the opposite - I > believe it’s a SHOULD on using UUID, and my understanding has always > been that these are intended to be globally unique (I realise you > have authority on claims of the original intention) from reading it. > This isn’t the only XEP that’s written on the basis of the unique IDs > being unique :) > > We probably need to clear this up - was I the only one with this > misconception? (i.e. do we update 422 (and others) or 359?) > Yes this was also my understanding all the way through. It is the reason all my MAM indices are composite including id and assigning entity. If we go for UUID we'd probably need to mention which version it should be and what to consider a namespace and name (if v5) or MAC (if v1) to make sure there won't be other assumptions (like reproducible UUIDs - for duplication/collision detection) --RR ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Fastening
On 12 Dec 2019, at 15:08, Dave Cridland wrote: > > On Thu, 12 Dec 2019 at 12:11, Marvin W mailto:x...@larma.de>> > wrote: > I think the question this comes down to is, what we want to build using > fastenings. I don't want reactions to reactions, but if we allow some > sort of "comment" as a Fastening, then we should also allow reactions to > such comments. > > > Interesting - from a syntactic viewpoint, you're absolutely right. But I > think you're entirely wrong from a protocol behaviour standpoint. So I wonder > if there's a distinction to be made between various kinds of relationship: > > * Messages that are pure ancillary messages, like a reaction. If I don't see > the reactions at all, it's not great, but probably a reasonable degradation. > Normally, I'll just want a summary on view. Sometimes I'll dig for more > detail. > > * Messages where the content of the message substantially alters another. > Edits, attachments, etc. If I don't see these at all, I've got significant > information loss with regards to the conversation - I'm not just missing out > on some additional content, I'm actually seeing different content. > > * Messages where the content relates to another. Comments, threading, > replies, etc are all closely related to another message, but they're clearly > a message in their own right. A degradation here might involve losing the > relationship rather than the message. > > I think Fastenings really only cover the first - MAM would here provide a > summary view of any fastenings. MAM doesn't urgently need to support the last > case at all. The middle case is somewhat harder - we might want to have MAM > aware of these but it would need to collate these in full - and perhaps it > even provides a unified view of a message and its edits etc? > > As a thought experiment, it'd be interesting to ask: > > 1) Are there any other "buckets" of message relationship types? > > 2) What existing relationships fit into what types? > > 3) What typical behaviours do we want to see (and thus support) on the > clients? I agree more or less with these distinctions, and think each needs distinct handling. I do see them all as being feasibly within fastening. After a a discussion with Dave, I think the current best suggestion is that we annotate a fastening based on what type of summary is possible. This also largely aligns with Dave’s asterisks above. 1) summary=‘urn:xmpp:fastening:count:0': Messages that can be counted by having the same bodies (by the archive). e.g. Reactions where you want to know at a glance that 50 people reacted with 🤦🏻♂️, 20 with 🤮. These messages are ‘pure ancillary messages’ in Dave’s above list, and so don’t themselves get fastened to. You can quick-query an archive to get the summary - you can also full-query to get the full details if you want, such as who made each fastening(reaction). 2) summary=‘urn:xmpp:fastening:full:0': Messages that can’t be collated with others, but where you need them for the first message to be complete. e.g. edits. These also don’t get fastened to. These are ‘where the content of the message substantially alters another’ in Dave terms. 3) summary=‘urn:xmpp:fastening:none:0': Where the new message is a new message in its own right, but that has some sort of link to a previous one. e.g. Comments (I’m not convinced that this is the right way to be doing comments, but if we did, like this). These can have their own fastenings. ‘Messages where the content relates to another’ from Dave’s list. An indivdiual fastening type would have (in the defining XEP) a particular summary approach (e.g. Reactions are always count, edits are always full, comments are always none). This lets us put a cap on the madness that ensues if e.g. you can react to reactions to reactions, while also allowing reactions to those messages that logically contain content of their own, e.g. comments. It is compatible with the previously discussed splitting of content and pointer in some manner that lets archives still return relevant fastenings in some manner while encrypted, although if the content is encrypted it will obviously be unable to count things. This is a bit more optimistic than a strawman, but may well have holes. Please drive your busses through them. Thoughts? /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] A Meta-Discussion about the Standards Process
Am Do., 12. Dez. 2019 um 09:24 Uhr schrieb Dave Cridland : > 1) The "Florian Plan" - introduce a phase prior to Experimental, wherein a > XEP is semi-adopted but remains without a number. This somewhat happens > anyway, but it does so outside our IPR rules, so arguably this is a case of > formalizing the status quo to some degree. On the other hand, it abandons > anything Experimental about Experimental. I'm calling this the Florian Plan > just because Florian Schmaus has been a vocal proponent - but he's far from > the only one. What bothers me about the Florian Plan is that it introduces an *additional* step to what in my view is already way too many steps. Ideally what I want is a 'florian stage' (I was tempted to call it draft stage but unfortunately we already have a stage called 'draft') and a stable 'stage'. I don’t see why we need a lot in between. (Maybe; we might want to hold on to the 'in review' stage; but in the past we haven’t been very thoroughly with actually moving XEPs in and out of that 'in review' stage. I mean correct me if I'm wrong but the IETF seems to be doing fine with just two stages. > > 2) The "Daniel Plan", which is to encourage Council to adopt pretty well > anything. If this sounds radical to you, it might help if I described it as > simply reimposing the de-jure standards process as described in XEP-0001. I > can certainly see the attraction, but I also think it ignores the status quo > and the problems alluded to above. Most recently suggested by Daniel Gultsch. In a way it doesn’t really matter if we introduce a new Florian Stage or if we reuse the existing Experimental stage for that purpose. In both cases we somehow have to deal with the status quo. There are a number of XEPs currently in Experimental that certainly belong into 'Florian'. (I'm going to follow Dave’s example of not providing examples.) But that's to me is one of the underlying issues here; While I can certainly see why Council would require a certain readiness of a XEP before giving it a number, that quality measurement has been applied very unevenly in the past. There are *a bunch* of XEPs that literally have the text 'TODO' in them. Which brings us to: > b) We have to, in particular, codify what each transition means, and > therefore tighten up Council's veto-for-any-reason here. I don't mean that we > remove any judgement calls on the part of Council, but I do mean that we > should create a yardstick on what constitutes a "usual" versus "unusual" veto. Yes I agree with that. More transparent and fairer processing would certainly eliminate the feeling of XEP authors to retry after the next council has been elected. I feel like only having two stages (Draft and stable) would help with that; because it is pretty obvious that for it being stable it has to be stable. cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Fastening
Hi, I am just realizing that all these magic server features are incompatible to encryptions which use ratchet mechanisms. Because those depend on messages received in order. So for example OMEMO could never use these archive features, I don't think we can do anything about that. We still have OpenPGP. Which should have no problem with that. Yeah your approach with the "external name" stuff looks fine to me. I'm not sure about this merge approach, looks like it could run into server stanza size limits in bigger group chats, definitely doesn't seem like it can scale up well. For single chat this should be fine and probably convenient, for group chats i think it makes more sense to request fastend content separately. Not sure what you mean by archive id and message id mismatch, yes those are never the same but why is this a problem? When we use the merge functionality of the server we would never need the archive ids of fastening messages, only for non-fastening messages. because of that i would say the archive-id can be omitted and the applied content can also be within the forwarded element. Or maybe I don't understand what other problem there is. Would be interesting to get the opinion of server developers if such merge features are even realistic to implement. Regards Philipp ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Fastening
On Thu, 12 Dec 2019 at 12:11, Marvin W wrote: > I think the question this comes down to is, what we want to build using > fastenings. I don't want reactions to reactions, but if we allow some > sort of "comment" as a Fastening, then we should also allow reactions to > such comments. > > Interesting - from a syntactic viewpoint, you're absolutely right. But I think you're entirely wrong from a protocol behaviour standpoint. So I wonder if there's a distinction to be made between various kinds of relationship: * Messages that are pure ancillary messages, like a reaction. If I don't see the reactions at all, it's not great, but probably a reasonable degradation. Normally, I'll just want a summary on view. Sometimes I'll dig for more detail. * Messages where the content of the message substantially alters another. Edits, attachments, etc. If I don't see these at all, I've got significant information loss with regards to the conversation - I'm not just missing out on some additional content, I'm actually seeing different content. * Messages where the content relates to another. Comments, threading, replies, etc are all closely related to another message, but they're clearly a message in their own right. A degradation here might involve losing the relationship rather than the message. I think Fastenings really only cover the first - MAM would here provide a summary view of any fastenings. MAM doesn't urgently need to support the last case at all. The middle case is somewhat harder - we might want to have MAM aware of these but it would need to collate these in full - and perhaps it even provides a unified view of a message and its edits etc? As a thought experiment, it'd be interesting to ask: 1) Are there any other "buckets" of message relationship types? 2) What existing relationships fit into what types? 3) What typical behaviours do we want to see (and thus support) on the clients? Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Fastening
On 12/12/19 2:53 PM, Philipp Hörist wrote: This is a pretty substantial feature so to fallback to a "Download the whole archive" approach to make it work is not a good solution for me and will probably lead to fastening not working with full stanza encryption The solution for me is to separate metadata and content I totally agree we should make sure encryption is fully considered in the design of Fastening (although some features will never work on encrypted messages). However I don't think your suggested solution will serve this purpose. One reason I understood why we put elements inside the is that this way, servers know which part of the messages is to be fastened and can strip out all the parts of the message not required for the client. So with your example but encrypted and useless metadata added: Servers would be able to fasten the message to the correct referenced message, however they can not strip the useless metadata as it's not clear what is important and what is not. Example for useless metadata would be a store hint. I think I like this model more: [...] Which the server can "merge" to: [...] It would even allow subsequent edits to replace without leaking anything other that one message replaces another: Resulting in [...] (Stuff is going to be a bit more complicated as message IDs and archive IDs mismatch...) (I am putting the directly in message here, but it would in practice be outside the element in a MAM message) Marvin ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Fastening
Thanks Philipp. On 12 Dec 2019, at 13:53, Philipp Hörist wrote: > The solution for me is to separate metadata and content > > lets do something like > > to="chatroom@chatservice.example"> > > > Very much > > This seems like a good compromise, I’ll incorporate similar, thanks. (I think Marvin suggested a similar approach, I’m going to work through his mail next). /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Fastening
Hi, The current approach is not good for full stanza encryption. And we have to assume full stanza encryption will become the norm at some point so any proposal should have that in mind. Full stanza encryption does not mean Full stanza encryption. There are elements that are never encrypted, for example store hints for the server, delay elements added by the server, and im sure i will find one or two more. Full stanza encryption means, we encrypt everything that makes sense and don't negatively impact usability. This is a pretty substantial feature so to fallback to a "Download the whole archive" approach to make it work is not a good solution for me and will probably lead to fastening not working with full stanza encryption The solution for me is to separate metadata and content So instead of Very much lets do something like Very much This allows us to encrypt content but not the metadata, and in turn allows the server archive to do some magic, for example if we want to request all messages which were fastened to another message. Keep in mind if this metadata leak is a problem for a client, nobody forces a client to support fastening while encryption is activated. But it should be possible if the user wishes. Regards Philipp ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Fastening
On 12/11/19 6:50 PM, Kevin Smith wrote: The business rules in §4 say that a Fastening can not have a Fastening themselves. If both message attaching, reactions and others are realized using Fastening, this implies that you can not react to an attached message, for example you would not be able to thumbs-up the fact that a bot provided a helpful attaching. While it is arguable that this is not strictly a required feature, the restriction seems to be unreasonable in that case. This one was deliberate - reacting to reactions to reactions (and similar) is the sort of scenario that it’s easy to spec, but then generally horrific to implement (I refer to pubsub collections as a simpler example of where a similar concept seems pleasantly general but ends up being overcomplicated to work with - to the point of neglect). I think the question this comes down to is, what we want to build using fastenings. I don't want reactions to reactions, but if we allow some sort of "comment" as a Fastening, then we should also allow reactions to such comments. If we keep this restriction, I believe we'd need a generic standard for associating a message to another message, independent of it being a fastening or another kind of message (that can have fastenings). Also one of the reasons why everyone agreed it would help to have the fastened elements as a sub-element of the instead of directly in the as in XEP-0367, is that if we don't do that, it isn't clear how to handle the correction of a message attaching case (a fastening of a fastening). Thus if we decide against allowing fastening of fastenings, the decision to use sub-element and etc should be revisited... I think can contain multiple elements, and they’re treated independently So if you apply-to two elements, and then replace apply-to one element, it would replace the relevant one, leaving the other intact. If you then replace apply-to both elements, it would replace both of them. This is under-(not at all) specified. For elements, it should be the target name/namespace, as if it was a child. How are edits supposed to work then? Because for various (good) reasons they exist of multiple elements in the example. https://xmpp.org/extensions/xep-0422.html#example-4 What happens if a client accidentally does not add the `replace="true"` (for example because the same element was send from two different devices at about the same time)? Will a) there be two elements with the same namespace and name then, b) the second silently ignored or c) the first silently replaced? In case of a), how to decide which to replace in the future? In case of b), how does the sending entity know if there message was first or second? In case of c), why put `replace="true"` at all if it is implicitly done anyways? Is it sufficient to assert that protocols that want to attach multiple of the same namespace then can’t replace them, or do we need ids on the fastenings? I guess if we have 😂 and 🤦🏻♂️ as individual fastenings, we need to be able to remove one and leave the other intact. OTOH, if a fastening contained one reaction for both 😂 and 🤦🏻♂️, it could be replaced with a reaction with just 🤦🏻♂️. I don't quite understand what you want to say here. If each reaction is a separate fastening, how do you remove a single one if you only identify reactions by their qname. Also it apparently is currently specified how to replace but not how to remove a fastening. Replacing with an empty variant may be technically possible, but that empty variant would then still be required to send out to clients (because we don't want servers to have to know what an empty variant looks like for each fastening). I have assumed that if you’re doing full stanza encryption, and want archiving, your only choice as things stand is to have a complete download of your archive, and to do all collation locally. Having both smart archivability (without decryption) and encryption is a more or less unsolvable problem. Does anyone have a workable way to go beyond ‘archive can’t be smart’ with E2E? It depends on how "smart" your archive should be. Just attaching a message to another message does work perfectly fine with encrypted messages, but you can obviously not summarize them. What does not work with encryption is to know the qname of the element. And I think it would be desirable to not leak that for the sake of smarter archiving (so that it cannot be seen if I react to a message or just mark it as read), so if we can come up with something that makes this not required, that would be great. It could even be that this can not work well with race conditions (= you have to have received the last encrypted reaction before you can send a new encrypted reaction and if you didn't, others will always have to fetch both just to find out that they only needed one after decrypting). By the way, I can hardly imagine summarizing to work in a generic way. The only
Re: [Standards] A Meta-Discussion about the Standards Process
On 12 Dec 2019, at 09:22, Dave Cridland wrote: > > Many moons past, we had a clever idea. > > What we thought was that we should change the XML namespace system we used - > previously, XEPs had been allocated a namespace when adopted, and they stuck > with this namespace throughout. Sometimes this broke things during > Experimental (indeed, if a XEP had to change in Draft, it'd break things > then, too). As a result, people were very shy of implementing anything in > Experimental, and this was a problem. Also a problem was that people who did > take the plunge on Experimental could end up affecting people who had waited > for Draft. > > We initially changed it to a URN, "urn:xmpp:tmp:XYZ". This meant that we > could go wild during Experimental, but then change to "urn:xmpp:XYZ" on > Draft, stabilising the XEP. While this meant that people who waited for Draft > were fine, it still meant that using a "tmp" namespace was a wild west. > > Our final change was that we introduced "versioned" namespaces. Essentially, > we stopped being so proud about the final namespace, and just used a prefix > to generate new namespaces for a XEP, changing the namespace any time an > incompatible change was introduced. We've got so used to this we often change > namespace when we shouldn't, frankly, but it's still better than the wild > west. > > The effect this has had, though, goes beyond merely allowing safe > Experimentation during Experimental - instead, we've a number of XEPs that > Council has "allowed in", but have resulted in such widespread implementation > and deployment during Experimental that we cannot meaningfully change them > without heavy disruption. Meanwhile, the "rules", such as they are, for > adopting Experimental do not really reflect that people can safely implement > and deploy, from an interoperability point of view. This has lead to another > problem, wherein XEPs are adopted in a rough state, but stay rough and the > proponents of the XEP never bother changing the XEP. I could give concrete > examples of both cases, but I suspect that would only serve to debate whether > these are indeed correct - instead I'll leave people to make up their own > minds. In any case, the effect of this has been that Council are quite > reticent about adopting Experimental XEPs. > > To address these problems, I see several possibilities. I'm putting these in > no particular order, because I'm personally conflicted on which, if any, are > the right solution, but I hope these can be an interesting start point. > > 1) The "Florian Plan" - introduce a phase prior to Experimental, wherein a > XEP is semi-adopted but remains without a number. This somewhat happens > anyway, but it does so outside our IPR rules, so arguably this is a case of > formalizing the status quo to some degree. On the other hand, it abandons > anything Experimental about Experimental. I'm calling this the Florian Plan > just because Florian Schmaus has been a vocal proponent - but he's far from > the only one. > > 2) The "Daniel Plan", which is to encourage Council to adopt pretty well > anything. If this sounds radical to you, it might help if I described it as > simply reimposing the de-jure standards process as described in XEP-0001. I > can certainly see the attraction, but I also think it ignores the status quo > and the problems alluded to above. Most recently suggested by Daniel Gultsch. > > 3) Something Else. We could introduce an additional phase *with* a number, > for example, or we could decide the problems are outliers and do nothing. > > While I don't have any particular opinion about what solution, if any, to > choose, I do think we have to address a couple of issues: > > a) We have to define what our standards process actually is. I don't mind if > that means we change our standards process to match our documentation, or we > change the documentation to match the process, or a mixture. > > b) We have to, in particular, codify what each transition means, and > therefore tighten up Council's veto-for-any-reason here. I don't mean that we > remove any judgement calls on the part of Council, but I do mean that we > should create a yardstick on what constitutes a "usual" versus "unusual" veto. > > Finally, whatever we choose, we should make that choice by considering > carefully the outcome we desire. The namespace changes we made - which > contributed to the current state - were made in good faith, and we never > foresaw what effect they'd have over the years. > > Thanks for reading this wall of text, To my mind, given where we are, I don’t see a way out of this unless we have a stage of the process where we can accept under XSF IPR something that we know needs significant changes before it’s advancable. I believe that having such things published is good, but we don’t currently have such a space (we do on paper - Experimental - but as you say, reality is far removed from
[Standards] A Meta-Discussion about the Standards Process
Many moons past, we had a clever idea. What we thought was that we should change the XML namespace system we used - previously, XEPs had been allocated a namespace when adopted, and they stuck with this namespace throughout. Sometimes this broke things during Experimental (indeed, if a XEP had to change in Draft, it'd break things then, too). As a result, people were very shy of implementing anything in Experimental, and this was a problem. Also a problem was that people who did take the plunge on Experimental could end up affecting people who had waited for Draft. We initially changed it to a URN, "urn:xmpp:tmp:XYZ". This meant that we could go wild during Experimental, but then change to "urn:xmpp:XYZ" on Draft, stabilising the XEP. While this meant that people who waited for Draft were fine, it still meant that using a "tmp" namespace was a wild west. Our final change was that we introduced "versioned" namespaces. Essentially, we stopped being so proud about the final namespace, and just used a prefix to generate new namespaces for a XEP, changing the namespace any time an incompatible change was introduced. We've got so used to this we often change namespace when we shouldn't, frankly, but it's still better than the wild west. The effect this has had, though, goes beyond merely allowing safe Experimentation during Experimental - instead, we've a number of XEPs that Council has "allowed in", but have resulted in such widespread implementation and deployment during Experimental that we cannot meaningfully change them without heavy disruption. Meanwhile, the "rules", such as they are, for adopting Experimental do not really reflect that people can safely implement and deploy, from an interoperability point of view. This has lead to another problem, wherein XEPs are adopted in a rough state, but stay rough and the proponents of the XEP never bother changing the XEP. I could give concrete examples of both cases, but I suspect that would only serve to debate whether these are indeed correct - instead I'll leave people to make up their own minds. In any case, the effect of this has been that Council are quite reticent about adopting Experimental XEPs. To address these problems, I see several possibilities. I'm putting these in no particular order, because I'm personally conflicted on which, if any, are the right solution, but I hope these can be an interesting start point. 1) The "Florian Plan" - introduce a phase prior to Experimental, wherein a XEP is semi-adopted but remains without a number. This somewhat happens anyway, but it does so outside our IPR rules, so arguably this is a case of formalizing the status quo to some degree. On the other hand, it abandons anything Experimental about Experimental. I'm calling this the Florian Plan just because Florian Schmaus has been a vocal proponent - but he's far from the only one. 2) The "Daniel Plan", which is to encourage Council to adopt pretty well anything. If this sounds radical to you, it might help if I described it as simply reimposing the de-jure standards process as described in XEP-0001. I can certainly see the attraction, but I also think it ignores the status quo and the problems alluded to above. Most recently suggested by Daniel Gultsch. 3) Something Else. We could introduce an additional phase *with* a number, for example, or we could decide the problems are outliers and do nothing. While I don't have any particular opinion about what solution, if any, to choose, I do think we have to address a couple of issues: a) We have to define what our standards process actually is. I don't mind if that means we change our standards process to match our documentation, or we change the documentation to match the process, or a mixture. b) We have to, in particular, codify what each transition means, and therefore tighten up Council's veto-for-any-reason here. I don't mean that we remove any judgement calls on the part of Council, but I do mean that we should create a yardstick on what constitutes a "usual" versus "unusual" veto. Finally, whatever we choose, we should make that choice by considering carefully the outcome we desire. The namespace changes we made - which contributed to the current state - were made in good faith, and we never foresaw what effect they'd have over the years. Thanks for reading this wall of text, Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
