désolé, j'avais commencé à répondre, puis j'ai fait autre chose à côté et quand je suis revenu sur ma réponse et l'ai publiée, je vois que tu t'es auto-répondu!
Donc voilà, c'est une question de définition. Avoir des automatismes permet de rendre l'implémentation plus facile. Si on se met à dire « ah oui mais "ceci" sert à X, mais parfois à Y en même temps, et des fois — mais c'est rare! — ça sert juste à Y mais pas à X », ça rend les choses compliqué. Donc nous, on a un automatisme: on identifie les diverses entités du réseau avec SASL. À partir de là, il nous faut choisir un mécanisme SASL pour identifier deux serveurs. Bah ça tombe bien, y a external fait justement pour ce genre de cas!
C'est un peu comme les fonctionnalités à négocier lors de la création d'une connexion. Avant dans la RFC3920, c'était un gros bordel. C'était en gros "ben on peut un peu envoyer des nouvelles fonctionnalités à tout moment, et des fois, on peut ne pas les envoyer, c'est un peu comme on veut hein, ici c'est à la bonne franquette!". Quand j'ai commencé à implémenter ça, je me suis dit que c'était nul. Y avait aucune fiabilité dans cette logique, que des cas particuliers. J'ai donc relevé le problème, on en a discuté et on a maintenant un beau diagramme d'état avec des explications précises de ce qu'il faut envoyer, et quand. Et maintenant c'est facile à implémenter.
Ce genre de design ne peut impliquer sur le long terme que bug et incompatibilité entre systèmes poppant de temps en temps.
Ben là pour SASL EXTERNAL, je n'étais pas là quand ça a été décidé donc je ne peux assurer que c'est la raison exacte pour laquelle c'est là, mais dans mon esprit, c'est la même chose. Ça permet un système logique et fiable.
Et donc si au final, SASL external et Dialback ont tout à voir. Ils ont tous les deux pour but d'identifier des serveurs quand ils communiquent ensemble. Sauf que la vieille méthode le faisait avec un système à part basé sur le DNS et donc était totalement bancal. Le nouveau est un mécanisme SASL (qui encapsule certes le protocol TLS) permettant d'homogénéiser l'identification en S2S et C2S: tout SASL, quel que soit le type d'identité.
En fait faut voir SASL EXTERNAL comme une encapsulation de code qui rend le code plus haut niveau bien plus lisible et donc exempt de bug. Si tu es développeur, tu comprendras de quoi je parle.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: TLS external
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 1.
Salut,
désolé, j'avais commencé à répondre, puis j'ai fait autre chose à côté et quand je suis revenu sur ma réponse et l'ai publiée, je vois que tu t'es auto-répondu!
Donc voilà, c'est une question de définition. Avoir des automatismes permet de rendre l'implémentation plus facile. Si on se met à dire « ah oui mais "ceci" sert à X, mais parfois à Y en même temps, et des fois — mais c'est rare! — ça sert juste à Y mais pas à X », ça rend les choses compliqué. Donc nous, on a un automatisme: on identifie les diverses entités du réseau avec SASL. À partir de là, il nous faut choisir un mécanisme SASL pour identifier deux serveurs. Bah ça tombe bien, y a external fait justement pour ce genre de cas!
C'est un peu comme les fonctionnalités à négocier lors de la création d'une connexion. Avant dans la RFC3920, c'était un gros bordel. C'était en gros "ben on peut un peu envoyer des nouvelles fonctionnalités à tout moment, et des fois, on peut ne pas les envoyer, c'est un peu comme on veut hein, ici c'est à la bonne franquette!". Quand j'ai commencé à implémenter ça, je me suis dit que c'était nul. Y avait aucune fiabilité dans cette logique, que des cas particuliers. J'ai donc relevé le problème, on en a discuté et on a maintenant un beau diagramme d'état avec des explications précises de ce qu'il faut envoyer, et quand. Et maintenant c'est facile à implémenter.
Ce genre de design ne peut impliquer sur le long terme que bug et incompatibilité entre systèmes poppant de temps en temps.
Ben là pour SASL EXTERNAL, je n'étais pas là quand ça a été décidé donc je ne peux assurer que c'est la raison exacte pour laquelle c'est là, mais dans mon esprit, c'est la même chose. Ça permet un système logique et fiable.
Et donc si au final, SASL external et Dialback ont tout à voir. Ils ont tous les deux pour but d'identifier des serveurs quand ils communiquent ensemble. Sauf que la vieille méthode le faisait avec un système à part basé sur le DNS et donc était totalement bancal. Le nouveau est un mécanisme SASL (qui encapsule certes le protocol TLS) permettant d'homogénéiser l'identification en S2S et C2S: tout SASL, quel que soit le type d'identité.
En fait faut voir SASL EXTERNAL comme une encapsulation de code qui rend le code plus haut niveau bien plus lisible et donc exempt de bug. Si tu es développeur, tu comprendras de quoi je parle.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]