[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

[Dave Cridland]

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  wrote:

>
>
> On Fri, 22 Mar 2024 at 08:47, Florian Schmaus  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.
>
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

[Dave Cridland]

On Fri, 22 Mar 2024 at 08:47, Florian Schmaus  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.
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

[Dave Cridland]

On Fri, 22 Mar 2024 at 08:47, Florian Schmaus  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.
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

[Daniel Gultsch]

Hi Florian,

On Fri, Mar 22, 2024 at 9:47 AM Florian Schmaus  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
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

[Florian Schmaus]

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  > 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
>  and  exchanges, whereas  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).

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

[Sam Whited]

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-le...@xmpp.org


--
Sam Whited
s...@samwhited.com
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

[Dave Cridland]

On Sun, 10 Mar 2024 at 15:19, 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?
>
>
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  and
 exchanges, whereas  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 
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 , 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-le...@xmpp.org
>
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to 

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

[Jonas Schäfer]

On Montag, 11. März 2024 10:14:36 CET Daniel Gultsch wrote:
> On Sun, Mar 10, 2024 at 4:18 PM Daniel Gultsch  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: , , and . 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  /  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

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

[Kevin Smith]

-- Original Message --
From "Daniel Gultsch" 
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  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
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

[Daniel Gultsch]

On Sun, Mar 10, 2024 at 4:18 PM 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’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
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

[Peter Saint-Andre]

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: , , and .


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 -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

[Maxime Buquet]

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: , , and .

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  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 -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

[Peter Saint-Andre]

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

___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org