10 Mar
2024
10 Mar
'24
9:18 a.m.
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(a)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!
10 Mar
10 Mar
9:49 a.m.
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(a)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
22 Mar
22 Mar
2:46 a.m.
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(a)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:
Thanks, I like the proposed wording very much and will change the text
accordingly.
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?
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
3:59 a.m.
Hi Florian,
On Fri, Mar 22, 2024 at 9:47 AM Florian Schmaus <flo(a)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
4:40 a.m.
On Fri, 22 Mar 2024 at 08:47, Florian Schmaus <flo(a)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.
6:10 a.m.
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(a)cridland.net> wrote:
On Fri, 22 Mar 2024 at 08:47, Florian Schmaus <flo(a)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.
4:45 a.m.
On Fri, 22 Mar 2024 at 08:47, Florian Schmaus <flo(a)geekplace.eu> wrote:
XEP-0220 still exists, by the way. Both db:verify, db:result, and even
db:error all have to, from, and type.
Dave.
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.
10 Mar
10 Mar
11:19 a.m.
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(a)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.
11:51 a.m.
On 3/10/24 11:19 AM, Maxime Buquet wrote:
On 2024/03/10, Daniel Gultsch wrote:
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!
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(a)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).
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
11 Mar
11 Mar
3:14 a.m.
On Sun, Mar 10, 2024 at 4:18 PM Daniel Gultsch <daniel(a)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(a)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
3:17 a.m.
------ Original Message ------
From "Daniel Gultsch" <daniel(a)gultsch.de>
To standards(a)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(a)gultsch.de> wrote:
I'm largely with Daniel on this.
/K
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(a)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. 
11:47 a.m.
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(a)gultsch.de> wrote:
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.
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(a)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.
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
7 p.m.
On Sun, 10 Mar 2024 at 15:19, Daniel Gultsch <daniel(a)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(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
15 Mar
15 Mar
7:14 a.m.
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(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
--
Sam Whited
sam(a)samwhited.com
240
days inactive
252
days old
13 comments
8 participants
participants (8)
-
Daniel Gultsch -
Dave Cridland -
Florian Schmaus -
Jonas Schäfer -
Kevin Smith -
Maxime Buquet -
Peter Saint-Andre -
Sam Whited