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 [email protected] 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
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
