LAST CALL: XEP-0360 (Nonzas (are not Stanzas))
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. 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!
On 3/10/24 9:18 AM, 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.
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?
I think this spec does a good job of clarifying the use of top-level elements other than message, iq, and presence.
2. Does the specification solve the problem stated in the introduction and requirements?
Yes.
3. Do you plan to implement this specification in your code? If not, why not?
N/A
4. Do you have any security concerns related to this specification?
Maybe. See below.
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). 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? - How should the 'from' and especially 'to' attributes be handled in the light of RFC 6120 §4.7? - Could the use of these attributes introduce security issues? - Would it be better to say MUST NOT here? Peter
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 <daniel@gultsch.de <mailto:daniel@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
Hi Florian, On Fri, Mar 22, 2024 at 9:47 AM Florian Schmaus <flo@geekplace.eu> wrote:
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.
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.
You are making a lot of good arguments from the perspective of an API developer. I 100% agree that it makes sense on a library level to distinguish between Stanzas and 'top level stream elements that are not stanzas' for reasons that have been outlined here many times (One gets counted for SM, one gets routed, one is only allowed after bind etc). In fact the low level parts of the XMPP code I wrote uses similar (if not the same) hierarchy of classes. If this XEP was an informational XEP called "Common Terminology for XMPP libraries" that was optionally to implement (or even suggested by a "library" section of the Compliance Suite) I might even like it. However it is not. The XEP as proposed has major implications on the language used in existing, stable, XEPs such as SM and CSI and every future XEP we write. I don’t like that for the reasons outlined by Kev, Dave, Sam and myself. cheers Daniel
On Fri, 22 Mar 2024 at 08:47, Florian Schmaus <flo@geekplace.eu> wrote:
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.
Well, now, that's a really interesting question that delves into OOP design. So, if you're of the classical Java bent, and therefore like injecting class hierarchies into everything, you'd have (and I write this in C++, because, well, reasons): class TopLevelElement; class Stanza public TopLevelElement; class Message public Stanza; class Presence public Stanza; OK, so this seems fair - Messages and Presences are both Stanzas, which is a TLE. Great! So what about a stream:features element? class Features public TopLevelElement; Well, it's a TLE, but it's not a Stanza. The thing is, Messages, Presences, and IQs all have common behaviour which is sensibly encapsulated into a Stanza class (if we're doing classical OOP, anyway). But there's no common behaviour between Features and, say, a '198 ack - there's nothing that is needed there. Now, you might want to do polymorphism based on something that's not a Stanza - I can't actually think why - and for that you might want to inject an artificial class. But this is an implementation detail, not something to foist upon the entire community. Dave.
It's been pointed out to me that this comes across combative, which isn't the intention, and I apologise for that. The crux of my argument here is in the phrase "there's no common behaviour between Features and, say, a '198 ack". Much of the aims of XEP-0360 appear to be based on a desire to split top level elements into things that are Stanzas, and things that are not. This much is fine. The problem is that this alone does not warrant a XEP in my view. The XEP then goes further by trying to document common features of thing that are not Stanzas, but the only commonality around behaviours and syntax of things that are not Stanzas is simply that they are not Stanzas. It's a bit like trying to divide life into Plants, and things that are not Plants. The division might well be useful, but it does not follow that the things that are not Plants are all the same, somehow - the only commonality ends up being that they're not Plants. Imposing rules, however well-meaning, suggests a commonality that does not exist. The XEP is tripping over itself in trying to do demonstrate this commonality. Section 3 suggests examples from other XEPs which don't use the term. Section 4 suggests consistent behaviours that don't always apply. Section 5 describes rules for interoperability which are either broken by existing XEPs or essentially impossible to break. Paradoxically, the XEP does highlight one issue, albeit obliquely - there isn't actually a very good definition of "Stanza" anywhere. The XEP points at two different sections of RFC 6120, but as others have pointed out, XEP-0114 has something to say here too, and RFC 6120 points to RFC 6121 as well for some behaviours. This of course causes a lot of complications in Section 2. An informational XEP summarizing the definition and nature of Stanzas would be very useful, I think, to newcomers and old hands alike. I think we all kind of know what we mean when we say "Stanza", but I think there's a lot of detail that would be useful to gather into one place. Dave. On Fri, 22 Mar 2024 at 10:40, Dave Cridland <dave@cridland.net> wrote:
On Fri, 22 Mar 2024 at 08:47, Florian Schmaus <flo@geekplace.eu> wrote:
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.
Well, now, that's a really interesting question that delves into OOP design.
So, if you're of the classical Java bent, and therefore like injecting class hierarchies into everything, you'd have (and I write this in C++, because, well, reasons):
class TopLevelElement; class Stanza public TopLevelElement; class Message public Stanza; class Presence public Stanza;
OK, so this seems fair - Messages and Presences are both Stanzas, which is a TLE. Great! So what about a stream:features element?
class Features public TopLevelElement;
Well, it's a TLE, but it's not a Stanza.
The thing is, Messages, Presences, and IQs all have common behaviour which is sensibly encapsulated into a Stanza class (if we're doing classical OOP, anyway).
But there's no common behaviour between Features and, say, a '198 ack - there's nothing that is needed there.
Now, you might want to do polymorphism based on something that's not a Stanza - I can't actually think why - and for that you might want to inject an artificial class. But this is an implementation detail, not something to foist upon the entire community.
Dave.
On Fri, 22 Mar 2024 at 08:47, Florian Schmaus <flo@geekplace.eu> wrote:
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.
XEP-0220 still exists, by the way. Both db:verify, db:result, and even db:error all have to, from, and type. Dave.
On 2024/03/10, 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.
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?
Yes. The abstract and introduction seem to cover this well.
2. Does the specification solve the problem stated in the introduction and requirements?
From RFC 6120 § 8:
Three kinds of XML stanza are defined for the 'jabber:client' and 'jabber:server' namespaces: <message/>, <presence/>, and <iq/>.
Which seems somewhat restrictive. It also doesn't take into account 0114 (Component) which I guess was written later? and 0114 itself does little effort at including itself in this definition (it uses the word as if it was already defined in this context). I guess I would expect 0360 to (re?)define stanza, so it can define what nonza isn't.
§ 2 Nonza: A Nonza is every XML element found at the XMPP stream's top level which is not a Stanza. The top level of an XMPP stream is the child XML level beneath the last <stream> opening tag as defined in RFC 6120 § 4.2. "Opening a Stream", i.e. at depth=1 of the stream. Informal definition: A XMPP stream element is a Nonza, if its element name is not 'message', 'iq' or 'presence'.
This seems to be missing a namespace definition. Since Nonza here is defined by what it isn't, we might as well define Stanza properly. Maybe https://www.rfc-editor.org/rfc/rfc6120#section-4.8.2 "Content Namespace" can be worth adding somewhere in there?
3. Do you plan to implement this specification in your code? If not, why not?
N/A
4. Do you have any security concerns related to this specification?
Nothing to add to the other thread started by peter.
5. Is the specification accurate and clearly written?
I am not sure why we're talking about resource binding, but I haven't really concerned myself with stream-level features much.. Maybe some explanation here would help. RFC 6120 § 7. mentioned in 0360 § 4. confusingly talks about stanza in this case too.
On 3/10/24 11:19 AM, Maxime Buquet wrote:
On 2024/03/10, 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.
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?
Yes. The abstract and introduction seem to cover this well.
2. Does the specification solve the problem stated in the introduction and requirements?
From RFC 6120 § 8:
Three kinds of XML stanza are defined for the 'jabber:client' and 'jabber:server' namespaces: <message/>, <presence/>, and <iq/>.
Which seems somewhat restrictive.
I'd say those restrictions were intentional at the time. Indeed, IIRC the original jabberd server just checked for 'm', 'p', or 'i' as the first character of the stanza!
It also doesn't take into account 0114 (Component) which I guess was written later? and 0114 itself does little effort at including itself in this definition (it uses the word as if it was already defined in this context).
XEP-0114 defines two namespaces, jabber:component:accept and jabber:component:connect, and treats top-level elements in those namespaces as stanzas (although the handshake element is really a nonza in those namespaces). So it's kind of a special exception. We weren't necessarily as careful about things in the early days (the Jabber component protocol predates our work at the IETF but we didn't document it right away, perhaps because so many components used the internal component protocol in jabberd).
I guess I would expect 0360 to (re?)define stanza, so it can define what nonza isn't.
Maybe. I'm not sure it's worth the effort to nail this down precisely, but I suppose it can't hurt to try. ;-) Peter
On Sun, Mar 10, 2024 at 4:18 PM Daniel Gultsch <daniel@gultsch.de> 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.
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?
I’m honestly not convinced that the problem the XEP introduces "This leads to the unfortunate situation where some submitted XEPs erroneous refer to non-Stanza top level stream elements as 'Stanzas'." exists. Or if introducing a new term fixes the issue. We have terminology ("element", "stream element") for that. I briefly checked with some XEPs (Bind 2, SM, CSI) and they all seem to be fine without this new term. Also - and this is probably something that might have changed since this XEP was first introduced - we don’t have that many XEPs that use custom stream elements after bind (after routing is enabled). CSI and SM seem to be the only major one. We didn’t see an influx in them. And XEPs like Bind2 an SASL2 are fairly normal in their usage of stream elements I would say.
2. Does the specification solve the problem stated in the introduction and requirements?
I guess. But my argument is mostly that the problem isn’t an actual problem.
3. Do you plan to implement this specification in your code? If not, why not?
No. If I were to write a new XEP I would rather not use the word nonza.
4. Do you have any security concerns related to this specification?
No
5. Is the specification accurate and clearly written?
Yes. cheers Daniel
------ Original Message ------ From "Daniel Gultsch" <daniel@gultsch.de> To standards@xmpp.org Date 11/03/2024 09:14:36 Subject [Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))
On Sun, Mar 10, 2024 at 4:18 PM Daniel Gultsch <daniel@gultsch.de> 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.
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?
I’m honestly not convinced that the problem the XEP introduces "This leads to the unfortunate situation where some submitted XEPs erroneous refer to non-Stanza top level stream elements as 'Stanzas'." exists. Or if introducing a new term fixes the issue. We have terminology ("element", "stream element") for that. I briefly checked with some XEPs (Bind 2, SM, CSI) and they all seem to be fine without this new term.
Also - and this is probably something that might have changed since this XEP was first introduced - we don’t have that many XEPs that use custom stream elements after bind (after routing is enabled). CSI and SM seem to be the only major one. We didn’t see an influx in them.
And XEPs like Bind2 an SASL2 are fairly normal in their usage of stream elements I would say.
2. Does the specification solve the problem stated in the introduction and requirements?
I guess. But my argument is mostly that the problem isn’t an actual problem.
3. Do you plan to implement this specification in your code? If not, why not?
No. If I were to write a new XEP I would rather not use the word nonza.
4. Do you have any security concerns related to this specification?
No
5. Is the specification accurate and clearly written?
Yes. I'm largely with Daniel on this.
/K
On Montag, 11. März 2024 10:14:36 CET Daniel Gultsch wrote:
On Sun, Mar 10, 2024 at 4:18 PM Daniel Gultsch <daniel@gultsch.de> wrote:
This message constitutes notice of a Last Call for comments on XEP-0360. […] 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?
I’m honestly not convinced that the problem the XEP introduces "This leads to the unfortunate situation where some submitted XEPs erroneous refer to non-Stanza top level stream elements as 'Stanzas'." exists. Or if introducing a new term fixes the issue. We have terminology ("element", "stream element") for that.
The issue I have with the "stream element" terminology is that it may also include Stanzas. Sometimes, we need to talk about things which are stream elements, but not Stanzas. Having an agreed-upon word for that is useful, IMO.
I briefly checked with some XEPs (Bind 2, SM, CSI) and they all seem to be fine without this new term.
Actually, looking at Stream Management (XEP-0198), I think it benefits from a clear definition of what a Stanza even is. RFC 6120 doesn't clearly state whether *only* the elements defined by RFC 6120 are stanzas. The text is at least ambiguous. To quote the introduction of RFC 6120 section 8:
Three kinds of XML stanza are defined for the 'jabber:client' and 'jabber:server' namespaces: <message/>, <presence/>, and <iq/>. In addition, there are five common attributes for these stanza types. These common attributes, as well as the basic semantics of the three stanza types, are defined in this specification; more detailed information regarding the syntax of XML stanzas for instant messaging and presence applications is provided in [XMPP-IM], and for other applications in the relevant XMPP extension specifications.
(In addition to that, note the comments by pep in regards to XEP-0114.) To me, it's not fully clear that this is the complete definition of the word Stanza. And Stream Management only uses that term, which means that depending on your interpretation of RFC 6120, you may be counting Nonzas, such as CSI changes. Even if we consider Nonzas worth counting (I'm not sure they are, and there's certainly a loop to avoid with <r/> / <a/> in '198), that should be spelled out clearly.
Also - and this is probably something that might have changed since this XEP was first introduced - we don’t have that many XEPs that use custom stream elements after bind (after routing is enabled). CSI and SM seem to be the only major one. We didn’t see an influx in them.
True. Nontheless worth documenting, don't you think? kind regards, Jonas
On Sun, 10 Mar 2024 at 15:19, Daniel Gultsch <daniel@gultsch.de> 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.
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?
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.
2. Does the specification solve the problem stated in the introduction and requirements?
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.
3. Do you plan to implement this specification in your code? If not, why not?
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.
4. Do you have any security concerns related to this specification?
My concerns are not security related.
5. Is the specification accurate and clearly written?
Anything that introduces a new made-up word cannot, almost by definition, count as clearly written.
Your feedback is appreciated! _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
I have similar views to Dave and Daniel on this. This specification is not needed to fill any gaps in the protocol, it is quite easy to refer to "non-stanza top-level elements" or "non-stanza stream-level elements" without inventing a new word for them. We have enough jargon floating around without making things impenetrable to new users and if I were to write more XEPs in the future I would not use this word, standardized or no. Writing technical specs is all about clear communication. Inventing new words for the sake of saving a few characters of typing (but let's ignore the inevitable citation to this document that would be necessary on every single first use of the word in another XEP) is not doing anything to make our communication clearer, instead it's just one more thing you have to read before you can understand any other spec that references it. —Sam On 3/10/24 11: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.
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 -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
-- Sam Whited sam@samwhited.com
participants (8)
-
Daniel Gultsch -
Dave Cridland -
Florian Schmaus -
Jonas Schäfer -
Kevin Smith -
Maxime Buquet -
Peter Saint-Andre -
Sam Whited