Yes, someone pointed out that this was not true in the thread (though that was quite long, so I don't blame you for missing it). However, I am still unaware of any feature that requires information from another feature (there are informational features but they're needed after negotiation is complete).
Right now having a second informational feature that is needed inside of another feature would make my existing stream features implementations more tightly coupled or entirely break them (eg. you could not write your own SASL implementation and use it with my CB parser or write your own CB implementation and use it with my SASL implementation). This may or may not be okay, but it seemed a perfectly fair assumption for me to make at the time that a single stream feature corresponded to a single XML element and only needed the data from that element. So if there is a separate list in the XML, I do think it has to be inside the same stream feature, but I haven't had a chance to implement both and find out if that works or breaks any existing implementations. —Sam On Tue, May 12, 2020, at 13:10, Jonas Schäfer wrote: > On Donnerstag, 7. Mai 2020 21:09:35 CEST Sam Whited wrote: > > On Thu, May 7, 2020, at 13:11, Florian Schmaus wrote: > > > I did, at first. It is totally irrelevant if it is an extra stream > > > feature or not. This just seemed a little bit more esthetic. > > > > I disagree, it's very relevant. We can discuss both, but how things > > work and are implemented may be entirely different if this is a > > stream feature that may be negotiated before auth vs. an > > informational element on an existing stream feature. > > You seem to assume that every thing in <stream:features/> may have to > be negotiated at some point. That is not true. > > XEP-0115 [1] (and the redo XEP-0390) are a prime example of a purely > informational feature which is *not* negotiated. > > Similarly, the channel binding "top level" feature proposed by Florian > would simply inform the client about the supported channel binding > types, without having to negotiate anything. > > (I split this off because I don’t think it is of much relevance > anymore since we figured out later on in the thread that extending the > <mechanisms/> element is completely fine. Just wanted to mention that > for clarity.) > > kind regards, Jonas > > [1]: https://xmpp.org/extensions/xep-0115.html#stream > _______________________________________________ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > [email protected] > _______________________________________________ > > Attachments: > * signature.asc -- Sam Whited _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
