[Standards] Re: XEP-0440 and tls-server-end-point
Another use case of tls-server-end-point is for cases where you are unable to support tls-exporter, ie. in some languages TLS/SSL stack doesn’t expose data required for tls-exporter. In those cases it is better to have tls-server-end-point for channel binding instead of not having anything available. > Wiadomość napisana przez Holger Weiß w dniu > 11.01.2024, o godz. 13:39: > > * Simon Josefsson [2024-01-11 13:10]: >> I believe tls-server-end-point is generally best left unimplemented to >> guide efforts towards supporting the stronger tls-exporter. > > One use case I see for tls-server-end-point is that it allows for supporting > channel binding by setups where TLS is terminated by some reverse proxy, > thereby protecting against _some_ but not all attack vectors that > tls-exporter protects against. > > Holger > ___ > Standards mailing list -- standards@xmpp.org > To unsubscribe send an email to standards-le...@xmpp.org Regards, Andrzej Wójcik XMPP: andrzej.woj...@tigase.org Email: andrzej.woj...@tigase.net ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
Re: [Standards] XEP-0388 SASL2: #2 Inline features
As someone who also implemented SASL2, Bind2, FAST & SM as a SASL2 features, I do think that wrapping subsequent stream features in makes a lot of sense. It is not only convenient for developers (as they need to pass just element as Daniel mentioned), but it also makes it easier to understand which features are available after SASL2 and Bind2. It is the same as in the classic XMPP stream establishment process when subsequent stream openings a different set of features is advertised (separate in a separate stream features element). With element we have the same separation which will not be achieved if we would just inline those features directly in the stream features (even if we would make a way to distinguish features available after SASL2 from other stream features). Moreover, from my understanding of RFC 6120 (I know it may not be written anywhere), I would always assume that each feature advertised in the stream features sent by the server may always be used just after receiving this stream features set and I do not need to do any other establishment before being able to use any of those new features. That is something which would change if we would inline features from directly into stream features. Regards, Andrzej Wójcik ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Possible MAM & PEP issue
Hi, Looking at XEP-0313: Message Archive Management and XEP-0163: Personal Eventing Protocol I think that there may be an interoperability issue between those XEPs. XEP-0163 states that Jabber/XMPP server that supports PEP associates a virtual PubSub service with the account. In fact, this makes PubSub service available under user account bare JID. In XEP-0313 in section 7. Determining support we have the following statement: "If a server or other entity hosts archives and supports MAM queries, it MUST advertise the 'urn:xmpp:mam:2' feature in response to Service Discovery (XEP-0030) [15] requests made to archiving JIDs (i.e. JIDs hosting an archive, such as users' bare JIDs)" and XEP-0313 also suggests the possibility to use MAM to query PubSub items. Now if we consider that XEP-0163 uses bare JID as a PubSub service JID and XEP-0313 MAM uses the same bare JID address to host an archive of user messages then it is not possible to advertise and use MAM support for PEP (PubSub) nodes hosted under the same address. In this case MAM will advertise feature "urn:xmpp:mam:2" for jid u...@example.com and the same feature should be returned for PEP if it supports MAM. There is no way to distinguish which one is supported. The same issue is with querying archives. No way to tell if we should query PEP archive or user messages archive as both are under the same bare JID! Even if we would consider that user message archive should be queried with an without 'to' attribute set and we would query PEP nodes with 'to' attribute set, then there is still no possibility to determine if MAM is supported for PEP or for user archive only are to determine support we are sending disco#info query always to the same bare JID. Am I correct? or maybe I'm missing something? Thanks, Andrzej ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
