On 10/03/2024 16.18, Daniel Gultsch wrote: > This message constitutes notice of a Last Call for comments on > XEP-0360. > > Title: Nonzas (are not Stanzas) > Abstract: > This specification defines the term "Nonza", describing every top > level stream element that is not a Stanza. > > URL: https://xmpp.org/extensions/xep-0360.html > > This Last Call begins today and shall end at the close of business on > 2024-03-25. > > 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?
When I initially submitted the XEP, I was surprised that a few seemed to deem it unnecessary. Everyone is entitled to their own opinion, and I think there is not much I can argue to convince those people otherwise. Sometimes it appears that there are only two kinds of views: those who consider this XEP unnecessary and those who believe that it fills a gap in the RFC specification, clarifies the rules of non-stanza top-level stream elements, and therefore constitutes a valuable addition.
I belong to the latter group of people. > 3. Do you plan to implement this specification in your code? If not, > why not?Yes, Smack models Nonzas as language-level type and uses this type in its API. Among other things, this makes the API and implementation less error prone.
On 12/03/2024 02.00, Dave Cridland wrote: > On Sun, 10 Mar 2024 at 15:19, Daniel Gultsch <dan...@gultsch.de > <mailto:dan...@gultsch.de>> wrote: > 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.I could not agree more on not introducing pointless jargon. However, we seem to disagree on whether this is pointless or not.
> 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.That downplays the XEP. But even it it where true, having a single-word term for top-level elements that are not stanzas is sensible.
For example, assume a XMPP library written in an object-oriented language. There is a superclass TopLevelStreamElement which has one obvious subclass named Stanza. Now, how should we name the other subclass? TopLevelElementThatIsNotAStanza? Feels ridiculous.
Furthermore, the term is also useful outside of programming in human-to-human communication. Yes, it is one additional jargon term. But as you said yourself, it is easy to grasp what a Nonza is, so the mental effort required to learn it is minimal.
> 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.
Fair point, even though you left out that the XEP talks about no immediate result Nonza post-bind. In any case, the wording can be easily improved.
> 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.Wait. So, from stanzas being routable it follows that top-level stream elements that are not stanzas are not routable? That is a bit far-fetched. I certainly would not have deduced that. Clarifying that Nonzas are not routable is one of the reasons I wrote the XEP.
On 10/03/2024 16.49, Peter Saint-Andre wrote: > On 3/10/24 9:18 AM, Daniel Gultsch wrote: >> 5. Is the specification accurate and clearly written? > > In Section 4, I suggest a tweak to the following sentence: > > OLD > Nonzas are commonly used when it is not necessary to route the exchanged > information behind the endpoints of an XMPP stream. > > NEW > Nonzas are commonly used to exchange information between, but not > beyond, the endpoints of an XMPP stream (e.g., between a client and its > server).Thanks, I like the proposed wording very much and will change the text accordingly.
> In Section 5, business rule #2 states: > > "Nonzas SHOULD NOT have a 'from' or 'to' attribute." > > I have a few questions: > > - When is it sensible to make an exception to this SHOULD NOT?I can not think of one. However, this does not mean that there may be one, hence the defensive wording.
> - How should the 'from' and especially 'to' attributes be handled in the > light of RFC 6120 §4.7?Hard to answer without any experience with Nonzas carrying a 'from' or 'to' attribute.
> - Could the use of these attributes introduce security issues?Using 'to' and 'from' attributes on Nonzas makes it is not unlikely to introduce security issues. For example, I could imagine that implementations only apply their "firewall" rules for Stanzas and not for to/from-Nonzas.
> - Would it be better to say MUST NOT here?My crystall-ball model shows a 42% chance that once we change it to MUST NOT, a more-or-less valid use-case of a to/from-Nonzas appears within 21 hours. :)
But this aside, if there is consensus to stricten this restriction, then I am all for it.
Finally, I would like to thank everyone for their feedback. As always, this is much appreciated.
- Florian
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
