10 Mar
2024
10 Mar
'24
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.