Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)
My original emails were from a former editors point of view and I don't have particularly strong feelings except that we should keep the setup simple and not move the code away from where the contributors are. However, Jonas asked for contributor points of view. As a contributor I have had the opposite experience as Dave and have very strong opinions that GitLab should not be used. Every time I've used GitLab (which is not infrequently these days, sadly, it has grown in popularity a lot) it's been a mass of confusing options buried under 10 layers of menus that are hard to navigate, it had tons of functionality most of which was very buggy, and it generally felt like a sub-part product to me. As far as creating a branch and pushing it goes, it's fine, but as soon as I have to look at anything in their UI I find it absolutely terrible (then again, I don't think GitHub is great on this front either, but it's nowhere near as hard to use as GitLab). It does not feel exciting to me, it feels complicated. Give me something boring (I'll even take more boring than GitHub if it's available) that actually works and isn't confusing and slow. —Sam On Tue, Jun 16, 2020, at 17:06, Dave Cridland wrote: > I think there is considerable merit in moving to Gitlab - I've found > it impressive to use "in anger" as a product, and the technical > abilities that Jonas outlined below are mouth-wateringly exciting, but > also it feels generally more aligned to our FLOSS-friendly stance as > an organisation. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)
My two cents on this: I'm neither involved with the editors team nor am I a huge CI expert. All I can say is that if the editors team benefits from a switch then I'm all for it. I also like the move from the perspective of decentralization, even if we "just" move from the biggest provider to probably the second biggest :P Paul ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)
I suspect most people have no strong opinion on this either way (it doesn't directly affect them) - hence the quite narrow responses. So, to unironically signal my own nonchalance, I'm responding. That said, anything which improves the editor process, particularly reducing required time and effort, without otherwise placing restrictions on submissions, can only be a good thing. And if it fixes the Registry, even better. I don't consider maintaining the status quo or staying where all the cool kids are as compelling reasons for avoiding change. On the dual-HubLab approach, I expect it will cause more problems in the long run, if only from the increased complexity and confusion it will inevitably cause - good documentation should solve that, but in reality it doesn't because people are generally terrible at following instructions, or even reading them in the first place. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)
Hey, I think there is considerable merit in moving to Gitlab - I've found it impressive to use "in anger" as a product, and the technical abilities that Jonas outlined below are mouth-wateringly exciting, but also it feels generally more aligned to our FLOSS-friendly stance as an organisation. That said, I do understand the caution people are treating such a move with - it's a big move, and caution seems justified. Can we use the plan below as a basis to dip a toe in the water in a reversible fashion, and if it works, ditch Github entirely and place a holding page there? I'd personally want to see some kind of definition of success beyond "it works", but I'm very much open to suggestions there. Dave. On Tue, 16 Jun 2020 at 17:58, Jonas Schäfer wrote: > Hi again, > > Thanks Sam and Kevin for your valuable feedback. I think what you say > definitely has merit. > > In light of that, we came up with a hybrid solution which may be better or > worse. We need input on that. > > - We keep the GitHub xeps (and registar) repositories. > - We create mirror repositories on GitLab. > - We configure a two-way sync between the GitLab and GitHub repositories > for > the main branch, but not for pull/merge requests or issues or non-main > branches. > - We disable the issue tracker on GitHub (or GitLab) so that there’s only > one > place to report and track issues. > - MRs/PRs will be handled by editors on both platforms (but still with > less > work than before), with equal priority > - MRs on GitLab will gain additional features (like HTML-rendered diffs > etc.) > for users; this is because we cannot trivially add those features to > GitHub > due to lack of support, but they’re cheap to add over there. > - In the mid-term, we move xep-*.xml into a subdirectory so that the > README of > the repositories is more accessible and can be augmented with an "end > user" > guide more easily. > - xep-attic moves completely over to GitLab for simplicity. > - Thanks to the two-way sync, we can use the advanced GitLab CI features > to do > the automagic. > > Assume that we’ll update all relevant documentation to state that "XEP > contributions are accepted on GitLab, GitHub and via email to > edi...@xmpp.org". We’ll also update the repository descriptions to > indicate > that they are mirrors of each other. > > We would still have to sort out a few legal bits (e.g. around the CLA/IPR > stuff) as well as actually test if this plan is workable on a technical > level > in practice. Before we do that work, we’d like to hear from the > (rightfully!) > cautious voices about this approach. > > Again, thank you very much for your feedback. > > kind regards, > Jonas > > > P.S.: Consider the timeline from the previous email void. We don’t want to > rush ahead of the community, even though that will further delay the > recovery > of the registry. A few weeks won’t matter on this, and we don’t want a > half- > baked solution which does more harm than > good.___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)
On Sun Jun 14, 2020 at 6:31 PM CEST, Jonas Schäfer wrote: > Dear community members, > > TL;DR: Due to considerable technical advantages, the Editor team is > considering moving the repositories currently hosted at > github.com/xsf/xeps adn gitlab.com/xsf/registrar to gitlab.com/xsf. > This will reduce delays in processing XEP changes and revive the > Registry. (No hats.) I think the Editor team should use whatever tooling they think is best. A requirement to sign up for an account with a 3rd party in order to contribute was the thing that drove me to XMPP in the first place, so it is important to me that it still be possible without signing up for Github, Gitlab or any such service. I believe the Editor team accepts contributions via email, and I'm happy as long as such an option exists. -- Regards, Kim "Zash" Alvefur ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)
+1 for a full migration to Gitlab. No mirroring to Github. No nonsense. Anything that will help our editors. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)
The permissions form is confusing, but I don't think this is true, I've definitely got Travis at least setup on single organizations. If something weird has changed and this is true, we could also create an "XSF Bot" account or something and then it's not a problem because the bot only has access to XSF repos. Alternatively, just add GitHub actions to whatever repo needs them. Those definitely only have access to that repo (unless you give it access to others). On Tue, Jun 16, 2020, at 13:12, Jonas Schäfer wrote: > Due to the messed up permission model of GitHub, all of them (I can’t > test travis because I signed up with them a long time ago, Circle CI > does, GitLab CI for GitHub does, Docker Hub does for newly added > repositories; Drone seems to require infrastructure we don’t have or > want to maintain on the iteam side) seem to require full write access > to all repositories whichever account is used to set them up has > access to or will ever have access to, public and private. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)
Hi Guus, Also thanks to you for more feedback. On Dienstag, 16. Juni 2020 19:06:04 CEST Guus der Kinderen wrote: > Thanks for all of the effort that you're putting into this. A concern that > I have with the shared gitlab/github solution is that it has a lot of > moving parts, a lot of dependencies, and a lot of places where things can > go wrong. Complexity of the implementation increases (to save complexity in > the editoring process, which is a worthy cause). I'd like us to consider if > the implementation that we're going for will be maintainable in the future, > after the architects of the implementation move on to greener pastures. Valid concern indeed. I intend to mitigate this in two ways: - If we find that the complexity of this solution is too high, we will find another approach, probably at cost of more complexity elsewhere in the infrastructure. - Lots of documentation. I plan to add some "user level" stuff to the XMPP Wiki (e.g. for an upcoming Council Chair: "Where do I find editor stuff for Council if I want to?"), as well as technical level things in documentation close or inside the repositories themselves. In addition, I hope that pep. will be available for reviewing the things I do so that we have at least two people who’re aware of what’s going on at this time. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)
Hi Sam, Thanks again for your feedback. On Dienstag, 16. Juni 2020 19:03:40 CEST Sam Whited wrote: > This seems like a lot of extra maintenance burden and a very complicated > solution (and this is why editors get burnt out and we go through them, > the whole process was already somewhat complicated). Let me clarify one bit: I was asking for opinions from the community perspective intentionally. On the editor side, we are a bit sceptical (and we’ll evaluate this carefully) but in general estimate that this solution will reduce the burden of our tasks. So please don’t worry about that for now and focus on the contributor side of things. > If Docker doesn't > actually make things easier for us, maybe we shouldn't use it. It makes things a lot easier for iteam, who are also understaffed. There’s a trade-off to be had here. > Alternatively, if we do still want to use Docker, why not just use > whatever GitHub's CI is or one of the many CI solutions that can work > with GitHub without setting up lots of new infrastructure, repos, > syncing, etc? (ie. Travis, Circle CI, Drone, etc. there are tons of them > and many of them are free but also designed to work with GitHub) Due to the messed up permission model of GitHub, all of them (I can’t test travis because I signed up with them a long time ago, Circle CI does, GitLab CI for GitHub does, Docker Hub does for newly added repositories; Drone seems to require infrastructure we don’t have or want to maintain on the iteam side) seem to require full write access to all repositories whichever account is used to set them up has access to or will ever have access to, public and private. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)
Hi Jonas, Thanks for all of the effort that you're putting into this. A concern that I have with the shared gitlab/github solution is that it has a lot of moving parts, a lot of dependencies, and a lot of places where things can go wrong. Complexity of the implementation increases (to save complexity in the editoring process, which is a worthy cause). I'd like us to consider if the implementation that we're going for will be maintainable in the future, after the architects of the implementation move on to greener pastures. Regards, Guus On Tue, 16 Jun 2020 at 18:59, Jonas Schäfer wrote: > Hi again, > > Thanks Sam and Kevin for your valuable feedback. I think what you say > definitely has merit. > > In light of that, we came up with a hybrid solution which may be better or > worse. We need input on that. > > - We keep the GitHub xeps (and registar) repositories. > - We create mirror repositories on GitLab. > - We configure a two-way sync between the GitLab and GitHub repositories > for > the main branch, but not for pull/merge requests or issues or non-main > branches. > - We disable the issue tracker on GitHub (or GitLab) so that there’s only > one > place to report and track issues. > - MRs/PRs will be handled by editors on both platforms (but still with > less > work than before), with equal priority > - MRs on GitLab will gain additional features (like HTML-rendered diffs > etc.) > for users; this is because we cannot trivially add those features to > GitHub > due to lack of support, but they’re cheap to add over there. > - In the mid-term, we move xep-*.xml into a subdirectory so that the > README of > the repositories is more accessible and can be augmented with an "end > user" > guide more easily. > - xep-attic moves completely over to GitLab for simplicity. > - Thanks to the two-way sync, we can use the advanced GitLab CI features > to do > the automagic. > > Assume that we’ll update all relevant documentation to state that "XEP > contributions are accepted on GitLab, GitHub and via email to > edi...@xmpp.org". We’ll also update the repository descriptions to > indicate > that they are mirrors of each other. > > We would still have to sort out a few legal bits (e.g. around the CLA/IPR > stuff) as well as actually test if this plan is workable on a technical > level > in practice. Before we do that work, we’d like to hear from the > (rightfully!) > cautious voices about this approach. > > Again, thank you very much for your feedback. > > kind regards, > Jonas > > > P.S.: Consider the timeline from the previous email void. We don’t want to > rush ahead of the community, even though that will further delay the > recovery > of the registry. A few weeks won’t matter on this, and we don’t want a > half- > baked solution which does more harm than > good.___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)
This seems like a lot of extra maintenance burden and a very complicated solution (and this is why editors get burnt out and we go through them, the whole process was already somewhat complicated). If Docker doesn't actually make things easier for us, maybe we shouldn't use it. Alternatively, if we do still want to use Docker, why not just use whatever GitHub's CI is or one of the many CI solutions that can work with GitHub without setting up lots of new infrastructure, repos, syncing, etc? (ie. Travis, Circle CI, Drone, etc. there are tons of them and many of them are free but also designed to work with GitHub) —Sam On Tue, Jun 16, 2020, at 12:58, Jonas Schäfer wrote: > Hi again, > > Thanks Sam and Kevin for your valuable feedback. I think what you say > definitely has merit. > > In light of that, we came up with a hybrid solution which may be > better or worse. We need input on that. > > - We keep the GitHub xeps (and registar) repositories. > - We create mirror repositories on GitLab. > - We configure a two-way sync between the GitLab and GitHub > repositories for the main branch, but not for pull/merge requests or > issues or non-main branches. > - We disable the issue tracker on GitHub (or GitLab) so that there’s > only one place to report and track issues. > - MRs/PRs will be handled by editors on both platforms (but still with > less work than before), with equal priority > - MRs on GitLab will gain additional features (like HTML-rendered > diffs etc.) for users; this is because we cannot trivially add those > features to GitHub due to lack of support, but they’re cheap to add > over there. > - In the mid-term, we move xep-*.xml into a subdirectory so that the > README of the repositories is more accessible and can be augmented > with an "end user" guide more easily. > - xep-attic moves completely over to GitLab for simplicity. > - Thanks to the two-way sync, we can use the advanced GitLab CI > features to do the automagic. > > Assume that we’ll update all relevant documentation to state that "XEP > contributions are accepted on GitLab, GitHub and via email to > edi...@xmpp.org". We’ll also update the repository descriptions to > indicate that they are mirrors of each other. > > We would still have to sort out a few legal bits (e.g. around the > CLA/IPR stuff) as well as actually test if this plan is workable on a > technical level in practice. Before we do that work, we’d like to hear > from the (rightfully!) cautious voices about this approach. > > Again, thank you very much for your feedback. > > kind regards, Jonas > > > P.S.: Consider the timeline from the previous email void. We don’t > want to rush ahead of the community, even though that will > further delay the recovery of the registry. A few weeks won’t > matter on this, and we don’t want a half- baked solution which > does more harm than good. > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org > ___ > > Attachments: > * signature.asc -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)
Hi again, Thanks Sam and Kevin for your valuable feedback. I think what you say definitely has merit. In light of that, we came up with a hybrid solution which may be better or worse. We need input on that. - We keep the GitHub xeps (and registar) repositories. - We create mirror repositories on GitLab. - We configure a two-way sync between the GitLab and GitHub repositories for the main branch, but not for pull/merge requests or issues or non-main branches. - We disable the issue tracker on GitHub (or GitLab) so that there’s only one place to report and track issues. - MRs/PRs will be handled by editors on both platforms (but still with less work than before), with equal priority - MRs on GitLab will gain additional features (like HTML-rendered diffs etc.) for users; this is because we cannot trivially add those features to GitHub due to lack of support, but they’re cheap to add over there. - In the mid-term, we move xep-*.xml into a subdirectory so that the README of the repositories is more accessible and can be augmented with an "end user" guide more easily. - xep-attic moves completely over to GitLab for simplicity. - Thanks to the two-way sync, we can use the advanced GitLab CI features to do the automagic. Assume that we’ll update all relevant documentation to state that "XEP contributions are accepted on GitLab, GitHub and via email to edi...@xmpp.org". We’ll also update the repository descriptions to indicate that they are mirrors of each other. We would still have to sort out a few legal bits (e.g. around the CLA/IPR stuff) as well as actually test if this plan is workable on a technical level in practice. Before we do that work, we’d like to hear from the (rightfully!) cautious voices about this approach. Again, thank you very much for your feedback. kind regards, Jonas P.S.: Consider the timeline from the previous email void. We don’t want to rush ahead of the community, even though that will further delay the recovery of the registry. A few weeks won’t matter on this, and we don’t want a half- baked solution which does more harm than good. signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Council Agenda 2020-06-17
Hi everyone, The next XMPP Council Meeting will take place on 2020-06-17 at 15:00Z in xmpp:coun...@muc.xmpp.org?join. Everyone is welcome to join and add to the discussions. This agenda is composed from: - Editor notifications to standards@ - xsf/xeps GitHub PRs marked as Needs Council - Suggestions directly sent to me (see below) Agenda as follows: 1) Roll Call 2) Agenda Bashing * Feel free to pre-bash on-list or directly to me if you think something is missing. 3) Editor’s Update - Calls in progress - LC for XEP-0338 (ends on 2020-06-30) 4) Items for voting 4a) PR#959: XEP-0156: reorganize stating XRD/JRD requirements URL: https://github.com/xsf/xeps/pull/959 Abstract: The reference to RFC 6120 was incorrect, what this really meant is RFC 6415. But instead of simply s/RFC 6120/RFC 6415/ here, I decided to reorganize stating the requirements of XRD and JRD a little. This PR was amended to address council feedback from last session and is on the table again. 4b) PR#961: XEP-0030: Specify that the disco#info feature may not be explicitly set URL: https://github.com/xsf/xeps/pull/961 Abstract: Since #715 got rejected by council, we may as well drop the requirement to specify this explicitly. See-Also: https://github.com/xsf/xeps/pull/715 4c) PR#949: XEP-0157: Add status-addresses registrar entry URL: https://github.com/xsf/xeps/pull/949 See-Also: https://mail.jabber.org/pipermail/standards/2020-May/037443.html See-Also: https://mail.jabber.org/pipermail/standards/2020-June/037537.htmla We also had this one a few weeks back, but there was discussion about extending the registry without consent from '68. See the second linked mailing list thread. 5) Outstanding Votes 6) Date of Next 7) AOB 8) Close End of Agenda. Note that I am aiming for 30 minutes, but meetings may be extended as necessary if all council members agree. Meetings are normally held every Wednesday at 15:00 UTC in the xmpp:coun...@muc.xmpp.org?join chatroom. Meetings are open, and anyone (XSF Member or not) may attend, though only XMPP Council members may vote. Relevant comments from the floor are welcomed. Using your web browser, you can join anonymously via https://xmpp.org/chat?council Note that conversations in the room are logged publicly at https://logs.xmpp.org/council/ If you have suggestions for an agenda item, you can message me via XMPP or email at this address or at jo...@zombofant.net. I aim to publish the Agenda on the day before the Council meeting before 19:00Z. Thanks everyone, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] LAST CALL: XEP-0338 (Jingle Grouping Framework)
This message constitutes notice of a Last Call for comments on XEP-0338. Title: Jingle Grouping Framework Abstract: This specification provides an XML mapping for translating the RFC 5888 SDP Grouping Framework to Jingle URL: https://xmpp.org/extensions/xep-0338.html This Last Call begins today and shall end at the close of business on 2020-06-30. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2020-06-10
https://logs.xmpp.org/council/2020-06-10?p=h#2020-06-10-69a78d5ca075cc34 1) Roll Call Present: Zash, Jonas, Daniel, Dave, Georg Dave tries to speak ESMTP, but receives a 500 error response. 2) Agenda Bashing Jonas assumes none. 3) Editor's update * Expiring calls - CFE for XEP-0050 (ended on 2020-06-09) 4a) PR #959 (XEP-0156: reorganize stating XRD/JRD requirements) - https://github.com/xsf/xeps/pull/959 Georg isn't sure about this because it removes a "REQUIRED" and adds a "SHOULD". Jonas isn't sure on the purpose of moving from "MUST XML" to "SHOULD XML" and "SHOULD JSON" to "MAY JSON"; thinks it seems odd because now clients effectively have to support both, since a service may opt to only do JSON - asks the author, Flow, for comment. Georg might be fine with it if the new language is fixed and the old MUST/SHOULD are kept - Jonas and Daniel agree. Flow agrees to change it, but didn't think the MUST was necessary given there's no feature negotiation for this; the intention was to prohibit JRD without XRD; now agrees a MUST is probably clearer. Jonas cancels the vote and postpones it until next week. 4b) PR #598 (XEP-0050: Try to clarify usage of 'execute') - https://github.com/xsf/xeps/pull/598 Jonas, superpowered editor extraordinaire, added wording to the PR, specifically, a note discouraging use of the execute action Dave thinks this is deep into 'least harm' territory, and will be interested in what others have to say. Jonas: +1 (think this is the best we can do) Daniel: [on-list] Zash: [on-list] Georg: +1 Dave: +1 Considering possible adoption, Jonas thinks the advancement vote should be postponed until after another CFE; Dave isn't sure it could be advanced until people at least believe (delusionally or otherwise) that they have implemented the new version. 5) Outstanding votes Georg sent his votes earlier today, so everyone is up-to-date. 6) Date of Next 2020-06-17 1500 UTC 7) AOB Regarding the Message Routing stuff, Jonas apologises for mixing up dates and proposing now expired time-slots; Georg still hasn't managed to select one. Jonas thinks Friday at 1600 CEST might be the best available option - Georg would be okay with that - Jonas will send an email. Pep would like to sort out PR #949, but doesn't know what to take from the list thread - Georg took it as a general +1 with a hint to add a ".well-known" mapping. Jonas thinks Dave is correct in preferring to extend XEP-0068 (Field Standardization for Data Forms) to allow validation information, and that the Registry needs fixing. Jonas suggests the best way forward would be to update XEP-0068 and then XEP-0157 - then the PR can stay as-is, and can be applied once 0068 has been patched. Flow would like to suggest the Registry and its entries be viewed as extensible, instead of explicitly marking them, since this isn't limited to just data forms - Jonas is hesitant about that, but directs any extended discussion to the list - Dave counters that Registries are documents of record and, as such, have different rules (the same argument applies to the XEP format.) 7') Close Thanks all. Flow has updated PR #959. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
