ok, les schémas ont l'air assez complet, même si je n'ai pas vu 3 points :
- le cas où il y a des proxies voire firewall : le passage en 443/https est souvent utilisé mais c'est dévoyer un port qui n'est pas fait pour cela, autant identifier des canaux privilégiés et identifiés que de contourner les politiques de sécurité
- la gestion inter-serveurs : il faut pouvoir répartir la charge (le serveur de session utilisé initialement n'est pas forcément celui qui va gérer la connexion), le client peut faire par exemple faire des propositions de serveurs intermédiés "préférés" par passage de paramètres (que ce soit pour optimiser la topologie, respecter des règles de sécurité pour éviter le transit par des serveurs "non-trusted" ou tout simplement utiliser un serveur dédié qui permet à l'utilisateur de gérer ses points de passage)
- il y a des propositions spécifiques de comportement, il faudrait sans doute que je relise pour voir si "le cas idéal concret" est proposé (au sens celui qui minimise la charge de bout en bout, tout en respectant les fonctionnalités de sécurité) : pour moi l'idéal au minimum, ce sont des ports correctement définis (au pire une plage) pour en faire un protocole normalisé et la possibilité de choix des serveurs de relais de flux (éviter d'envoyer tout le flux au canada comme avec le Blackberry ou chez un seul opérateur comme avec Skype...).
C'est tout de même ballot d'en arriver là alors que les NAT ne sont généralement pas mis en place pour les bonnes raisons :/ (IPv6 ne résoudra peut-être même pas cela si les topologies réseau n'évoluent pas, même s'il peut contribuer à tout remettre à plat et addressable).
Autre point : tout comme pour jabber où les serveurs d'authentification sont répartis (et où l'on peut définir des proxies pour les transferts de fichier), dans le cas général il devrait être possible de relayer les flux par défaut (avec les serveurs du fournisseur de service utilisé) ou permettre à l'utilisateur de choisir ses relais (ou tout simplement se donner rendez-vous sur un service de chatroom comme on peut le faire avec les MUC ou la conférence dans le monde téléphonique, VoIP ou pas...).
[^] # Re: Quid des possiblités de JABBER ?
Posté par BAud (site web personnel) . En réponse à la dépêche Neuvième causerie APRIL sur Jabber/XMPP. Évalué à 1.
- le cas où il y a des proxies voire firewall : le passage en 443/https est souvent utilisé mais c'est dévoyer un port qui n'est pas fait pour cela, autant identifier des canaux privilégiés et identifiés que de contourner les politiques de sécurité
- la gestion inter-serveurs : il faut pouvoir répartir la charge (le serveur de session utilisé initialement n'est pas forcément celui qui va gérer la connexion), le client peut faire par exemple faire des propositions de serveurs intermédiés "préférés" par passage de paramètres (que ce soit pour optimiser la topologie, respecter des règles de sécurité pour éviter le transit par des serveurs "non-trusted" ou tout simplement utiliser un serveur dédié qui permet à l'utilisateur de gérer ses points de passage)
- il y a des propositions spécifiques de comportement, il faudrait sans doute que je relise pour voir si "le cas idéal concret" est proposé (au sens celui qui minimise la charge de bout en bout, tout en respectant les fonctionnalités de sécurité) : pour moi l'idéal au minimum, ce sont des ports correctement définis (au pire une plage) pour en faire un protocole normalisé et la possibilité de choix des serveurs de relais de flux (éviter d'envoyer tout le flux au canada comme avec le Blackberry ou chez un seul opérateur comme avec Skype...).
C'est tout de même ballot d'en arriver là alors que les NAT ne sont généralement pas mis en place pour les bonnes raisons :/ (IPv6 ne résoudra peut-être même pas cela si les topologies réseau n'évoluent pas, même s'il peut contribuer à tout remettre à plat et addressable).
Autre point : tout comme pour jabber où les serveurs d'authentification sont répartis (et où l'on peut définir des proxies pour les transferts de fichier), dans le cas général il devrait être possible de relayer les flux par défaut (avec les serveurs du fournisseur de service utilisé) ou permettre à l'utilisateur de choisir ses relais (ou tout simplement se donner rendez-vous sur un service de chatroom comme on peut le faire avec les MUC ou la conférence dans le monde téléphonique, VoIP ou pas...).