Re: [Standards] Adding namespaced content to Registry entries
On 6/3/20 5:25 PM, Jonas Schäfer wrote:> Hi everyone, > > Flow and I got in a discussion about whether it is OK to add foreign, > namespaced elements to Registry entries. I think registry entries should be just as extensible as the elements that are registered. This would also align nicely with the spirit of extensibility of XMPP. In this [1] particular example, it mimics how data form validation extend form fields on the wire protocol, at the registry layer. A situation where additional requirements and further information is only part of the textual specification and not of the registry entry, when it *could* be part of the entry, appears undesirable. - Florian 1: https://github.com/xsf/xeps/pull/949/files#diff-ebab582ef0efc48448fc287612a72d1dR208 signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Minutes 2020-05-27
I have submitted another revision removing this workaround since no control character or special whitespace character can be found with appropriate semantics. Let's take this opportunity for a clean break and take any further discussion of this particular topic to a new thread, if necessary since this is getting rather long. Sorry I didn't change the subject line soon. —Sam On Thu, Jun 4, 2020, at 10:03, Jonas Schäfer wrote: > On Dienstag, 2. Juni 2020 17:36:32 CEST Sam Whited wrote: > > > Then it has a non-obvious disadvantage (apparently) even to > > > technical users, in that it inserts invisible unicode codepoints. > > > This will cause hard-to- troubleshoot issues when (parts of) the > > > message are copied into a thing which cares about it, such as a C > > > compiler. > > > > I don't think this is a problem we should worry about. If this is a > > problem for you, you already have this problem all over the web and > > everywhere else and the answer is not "pretend Unicode doesn't exist > > and don't use it". > > I have yet to see a widely used thing in the web which injects hidden > Unicode codepoints in user-submitted content. > > Note that I’m not complaining about the use of Unicode. I’m > complaining about the non-obvious injection of invisible codepoints in > user content messages. > > kind regards, Jonas > ___ > 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] Council Minutes 2020-05-27
On Dienstag, 2. Juni 2020 17:36:32 CEST Sam Whited wrote: > > Then it has a non-obvious disadvantage (apparently) even to technical > > users, in that it inserts invisible unicode codepoints. This will > > cause hard-to- troubleshoot issues when (parts of) the message are > > copied into a thing which cares about it, such as a C compiler. > > I don't think this is a problem we should worry about. If this is a > problem for you, you already have this problem all over the web and > everywhere else and the answer is not "pretend Unicode doesn't exist and > don't use it". I have yet to see a widely used thing in the web which injects hidden Unicode codepoints in user-submitted content. Note that I’m not complaining about the use of Unicode. I’m complaining about the non-obvious injection of invisible codepoints in user content messages. 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] Adding namespaced content to Registry entries
On Mittwoch, 3. Juni 2020 22:50:26 CEST Dave Cridland wrote: > On Wed, 3 Jun 2020 at 16:30, Jonas Schäfer wrote: > > Hi everyone, > > > > Flow and I got in a discussion about whether it is OK to add foreign, > > namespaced elements to Registry entries. > > > > I’m not sold to either side, I was just curiously wondering if there’s > > precedent and if it’s considered a good, terrible or neutral idea by the > > community. > > > > The context (for better understanding) is PR#949: > > https://github.com/xsf/xeps/pull/949 > > > > Please weigh in if you have a strong opinion one way or the other. > > I think this is not allowed. > > But I suspect it should be. > > If you are not of a pedantic persuasion, look away now. > > As I understand XEP-0053, there's actually no need to run registrations by > the Council (excepting if the Registrar declines a registration; then the > Council acts as an appeals body) - the only reason this has touched the > Council is that it's an update to an existing Active XEP. It would be > perfectly possible (and might even be preferable) to add items to > XEP-0157's FORM_TYPE within a new XEP, or just by asking the Registrar > nicely (by email). The simple fact that one can add to the registry (or > alter existing entries) without touching the XEP that defined the registry > both imposes restrictions and is the very point of a registry (rather than, > say, a definitive list in a XEP). > > The Registry is defined quite clearly in XEP-0068, including the XML format > it takes, and there is no mention of form validation there (or default > options, by the way). Perhaps more to the point, the rendered version of it > at https://xmpp.org/registrar/formtypes.html doesn't include any validation > information - merely blindly adding extension elements to the registry > would mean that the rendered versions need updating. Therefore I think the > definition of a registry has to be considered exhaustive. > > So, in conclusion of the status quo, I don't think adding validation (or > other elements within an arbitrary namespace) is allowed. Excellent summary of what my unverbalised thoughts were regarding the linked PR. > That said, I think there's two useful things we can do here: > > 1) Validation information is clearly useful in this case; we should add > that to the XEP-0068 registry by an update to XEP-0068 *and* an update to > whatever stylesheet generates the registry page. +1. > 2) In the longer term, we should step back and decide what we actually want > our registry process to be. It feels as though we're too often updating > existing XEPs to add small features which could easily enough be either a > new XEP (maybe) or a registry submission. We should ensure that even > private additions are easy (though ideally, we can avoid that by use of > URI-based namespacing). I would argue we should make registries operate by > PR or email as needed, and have the registry stipulate requirements (like > "Open Specification required", or "FCFS", or whatever). Well. Yeah. Our registries are broken, which is a known fact. Fixing them is currently blocked by "out of ideas with the current constraints". We can chat about this in iteam@ in more detail if you’re interested (but I think iteam details are off-topic for this list). If they weren’t broken, registry submissions would be nice and yes, this PR would not have passed by council (though I would’ve probably sent it to Council anyways due to the validation thing). We also have a bunch of other stuff which needs to be fixed/updated in registries, and that list only gets longer unfortunately. 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 ___
