[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

On Sun, 10 Mar 2024 at 15:19, Daniel Gultsch &lt;daniel(a)gultsch.de&gt; wrote: No. Many of you have heard my views on this before. I argued against this XEP from the outset and I have seen nothing to change my view. Sorry for rehashing this argument, for those of you who have heard me on this before, but I still feel strongly that this is a very poor idea. Introducing new words - not just new terms, but new collections of letters that have previously never had a meaning at all - seems like a very poor way to make specifications (and simply our technology) more approachable. I have always avoided this new word, and will continue to do so, as the rare specification that introduces a new top-level element will never be made more simple by saying "This specification adds a new furbley bloople ding dong - now go and read XEP-0987 for an entire document on what this might mean.". As an industry, we are rightly chastised for introducing pointless jargon. It is a clear barrier to entry for newcomers, and should always be avoided. The situation becomes even worse in the circumstances of a chatroom or conversation, by making it more impenetrable that it likely already is. Casual conversations do not have convenient footnotes and reference sections. Of course jargon inevitably accumulates - stanza is an obvious example, but if I mention CSI, or PEP most people on this list will know what those mean - but these are essentially shorthands for a large volume of information. This specification simply introduces a word for top-level elements that are not stanzas. That's six words to cover the entire XEP. The rest of the XEP just adds additional words. These are sometimes questionable, and other times useless. Section 4 says that usually, top-level elements that are not stanzas that are exchanged prior to resource binding are request-response. And after resource binding, they're usually not request/response. Though in fact, some of the most common examples are the reverse - XEP-0198 uses <r/> and <a/> exchanges, whereas <stream:features/> has no response as such. Section 5 tells me that top-level elements that aren't stanzas MUST NOT be routed. So, wait - a server that's compliant to this won't route these elements? OK. And if a server isn't compliant to this, what does this mean? These are not interoperability requirements, these are just statements of fact. Stanzas being routable top-level elements, it is axiomatic that a top-level element that is not a stanza is not routed. We do not need to wave an RFC 2119 statement around to ensure this is the case. Is a server that offers XEP-0114 not compliant with XEP-0360, since XEP-360 references only RFC 6120? Or do we use the informal definition that talks about "element name" - does this mean the local name? Does this mean that a top-level element of <message xmlns="urn:xmpp:not-the-default-namespace"/> is in fact a Stanza by the definition of XEP-0360? None of this serves - or can serve - to clarify an existing protocol to a new reader. I dispute there was ever a problem, whereas it has added a new problem by its existence. As I recall, one of the suggested problems was that people might be confused about what top-level elements to count in XEP-0198, maybe around whether to count CSI elements - yet neither specification has ever introduced the term. I have never used the new word in a specification I have written or contributed to, and will continue to avoid doing so. "This specification introduces a new top-level element <foo/>, qualified by the urn:xmpp:bar:0 namespace - it is not routable and MUST NOT be considered a stanza." Infinitely simpler, and usually overkill. My concerns are not security related. Anything that introduces a new made-up word cannot, almost by definition, count as clearly written.