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. 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.
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
