[Standards] Stream startup / feature "negotiation" (was: Proposed XMPP Extension: Channel Binding Pseudomechanisms)
sam at samwhited.com
Tue May 12 17:36:42 UTC 2020
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.
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  (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
> : https://xmpp.org/extensions/xep-0115.html#stream
> Standards mailing list Info:
> https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards-
> unsubscribe at xmpp.org
> * signature.asc
More information about the Standards