Discutant de protocoles, de format, d'API etc. dans les commentaires de la dernière dépêche Et voici Movim 0.5 « Snowball » !, je me suis réinterrogé sur la nécessité d'un (format/protocole/api) très très KISS qui permettrait à un serveur d'identité de décrire les services disponible aux dites identités, et les protocoles, serveurs utilisés et autres détails techniques qui sont toujours à retrouver sur des obscures pages web et au fin fond des FAQ.
Je trouve que c'est un truc tout bête qui manque beaucoup…
Par exemple, comment faire un client mail qui serve uniquement à se connecter à une boîte mail distante, mais sans conservation de la session, tout comme on lance une session Firefox dans un cyber café sans enregistrer aucun mot de passe, ou quand on lance la "navigation privée" chez un ami ou l'école/le boulot pour ne rien laisser sur le poste de travail ? Je pense que ce genre de logiciel manque vraiment.
Je trouve que le client-mail "sans conservation des données" est un bon exemple, car il est parlant pour l'utilisateur et pour l'administrateur, et il répond à un vrai besoin.
Quand l'administrateur assure déjà des tas de services en lignes pour que ce soit accessible depuis le boulot, ou en itinérance sur les smartphones des utilisateur, et correctement sauvegardé, devoir prendre en charge les mailbox locales dans les procédures de sauvegarde c'est un peu gaspiller du temps et de l'argent. La solution choisie aujourd'hui est d'utiliser un webmail, mais c'est pas vraiment la panacée.
Pour l'utilisateur, il veut juste pouvoir se connecter et se déconnecter au service, comme sur un vulgaire site internet.
Tous les logiciels comme Evolution, Thunderbird etc. ne répondent pas au besoin. Il faudrait pouvoir se connecter à sa boîte mail comme les ados se connectaient à MSN et se déconnectaient aussi simplement : en donnant son adresse et son mot de passe !
Mais vu ce qu'on attend d'un logiciel de mail aujourd'hui, c'est infaisable : il faut connaître le serveur IMAP, la méthode de connexion, le port, le serveur SMTP, la méthode de connexion, le protocole qui gère les contact, le serveur de contact, le protocole qui gère le calendrier, le serveur du calendrier, il faut connaître la forme de l'identifiant (si l'adresse est blabla@example.com, c'est blabla l'identifiant, ou bien blabla@example.com ?). Un enfer…
Il suffirait d'une simple méthode de description, par exemple un simple fichier standardisé accessible sur http://example.com/services qui décrive les services associés aux identités servies, et les différents serveurs/protocoles et autres détail pour tout les comptes de ce serveur.
Alors il suffirait seulement de désactiver la mise en cache locale d'un logiciel comme Geary pour pouvoir se passer de la lourdeur d'un webmail, et si un tel logiciel était rendu possible par une aussi simple méthode, et devenait répandu, on pourrait se passer des webmail, et on pourrait proposer plus facilement des services alternatifs à gmail/ymail/hotmail/etc. !
Et puis… lorsque les paradigmes de gestion de boîte au lettre évoluent (les dossiers de l'imap versus les tags de gmail), il serait envisageable d'élaborer un protocole pour les décrire. Aujourd'hui, puisque tout se fait en webclient (webmail, webchat), on n'élabore plus de protocoles, comme on n'élabore plus de protocole, on ne fait plus de client, on fait des webclient, le serpent se mort la queue.
Alors qu'il pourrait être si simple qu'un simple GET /services sur un serveur quelconque puisse répondre :
mailbox:
server:imap.example.com
proto:imap4+ssl
port:993
login:complete
smtp:
server:smtp.example.com
proto:smtp+starttls
port:465
login:complete
xmpp:
server:talk.example.com
…
calendar:
…
addressbook:
…
x-board:
x-url:http://example.com/board
…
On peut aussi imaginer un protocole simple de clé/valeur, mais ce n'est peut-être même pas nécessaire, on peut aussi imaginer la description de plusieurs protocoles supportés pour une même tâche, et de préciser lequel est déclaré préférable, décrire des protocoles non standardisés. C'est simplissime, mais qu'est ce que ça manque !
Si on ne fait pas des trucs aussi simple, on est condamné à n'avoir que des logiciels qui ne savent se connecter qu'aux "assez grand pour avoir été référencé", et là encore le serpent se mort la queue : on n'ose pas développer de client (ou ce n'est accessible qu'aux geeks), on n'ose pas proposer des serveurs alternatifs (ou ce n'est accessible qu'aux geeks).
L'émergence des smartphones nous a donné une chance énorme : tous les services en lignes se sont mit à vanter à leur services via imap etc. Il parait que même hotmail soit accessible en imap, ils ont bien été obligé de le faire pour ne pas perdre la clientèle des smartphones !
On est donc à une époque charnière : les faibles capacités de nos ordinateurs de poches ont remit au goût du jour l'usage de logiciel client et de protocoles standardisés, mais la puissance de ces mêmes ordinateurs de poches venant à s'améliorer, les webclient vont refleurir sur ces machines et cette petite bulle de standardisation pourra bientôt éclater. Ce serait dommage de ne pas profiter de cette chance inattendue pour travailler au désengorgement des "grands" et à la diversification des fournisseurs de services, pour notre bien à tous.
Mais pour que tout soit simple, parfois on a juste besoin d'un peu, un tout petit peu de description !
Alors peut-être que ça existe déjà et que ce n'est pas utilisé, mais dans ce cas, pourquoi ?
Qu'en pensent tes collègues et amis, Nal ?
# Champs SRV du DNS
Posté par Gilles Mocellin . Évalué à 8.
Le DNS est encore plus commun que le Web.
En dehors de deux cas particulier ayant leur propre enregistrement (NS et MX),
les enregistrements SRV ont été créés pour trouver le nom de la machine pour un service donné.
C'est massivement utilisé par… Windows Active Directory, pour trouver les composants LDAP, Kerberos…
Je crois que c'est utilisé pour le XMPP.
[^] # Re: Champs SRV du DNS
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Dans XMPP il y a http://xmpp.org/extensions/xep-0030.html aussi.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Champs SRV du DNS
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Je m'attendais à ce quelqu'un me fasse remarquer que je demandais quelque chose de KISS tout en donnant un exemple de requête HTTP GET (pas qu'HTTP ne soit pas KISS, mais que c'est fait pour tout faire !), c'était un très discret œuf de troll pour le vendredi ! :)
Je ne connais pas bien SRV, mais il me semble, comme tu le dis, que le SRV renseigne un service donné : tu sais déjà quel protocole tu recherche !
Moi je veux savoir quels sont les protocoles disponibles pour un usage. Comme le relève kaouette plus bas, le problème est sémantique.
Et puis l'expérience montre qu'il ne suffit pas de connaître les noms de serveurs mais qu'il faut en savoir souvent un peu plus (port, méthode de chiffrement, les trucs dégueu à la pop-before-smtp (ça existe encore ??) ça ne se devine pas).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Champs SRV du DNS
Posté par Larry Cow . Évalué à 2.
Un usage ne correspond pas forcément à un seul protocole, ni réciproquement.
Exemple A) Le mail, qui a besoin d'au moins deux protocoles pour fonctionner efficacement.
Exemple B) MMmmh, on est vendredi. Alors disons HTTP. :)
[^] # Re: Champs SRV du DNS
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Et je dirais aussi que sans carnet d'adresse tu ne fais pas grand chose (d'ailleurs beaucoup de monde préféreraient perdre leur mbox que leur carnet)
Ce qui montre bien que les solutions à la DNS SRV ne répondent pas au problème : le protocole ne décrit pas l'usage.
Rien n'empêche de répondre ainsi :
Pouvoir référencer les outils répondant à un besoin/usage donné. En effet il ne suffit pas de cercher un protocole donné ou un serveur donné pour tout savoir. Autant un serveur imap annonce qu'il supporte le chiffrement ou non, et les formes de connexion possible, mais un serveur http ne décrit pas les services disponibles, qui sont établis sur une couche encore supérieure.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Champs SRV du DNS
Posté par Larry Cow . Évalué à 3.
Précisément. Disons IMAP+SMTP+LDAP+SIEVE, par exemple ;)
Oui. D'où les solutions à base de XRDS.
[^] # Re: Champs SRV du DNS
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
oui, j'avais omi la définition de règle par souci de concision, ça devient vite compliqué une messagerie !
Je ne connaissais pas XRDS, je me penche dessus merci ! C'est utilisé, sinon pourquoi ?
ce commentaire est sous licence cc by 4 et précédentes
# Webservice?
Posté par Pouetpouet . Évalué à 3.
Moi ça me fait penser aux webservices (SOAP+wsdl toussa)
# Active Directory + Exchange + Outlook
Posté par dinomasque . Évalué à 2.
Je suis sur que c'est faisable en piochant dans le catalogue Microsoft.
Exchange permet de configurer un compte en rentrant seulement son adresse email et son mot de passe : le client Exchange va trouver tout seul tous les paramètres pour les mails, les contacts et les agendas.
Et avec les trucs et les machins d'Active Directory, il doit être possible de demander à Outlook de tout oublier à la fermeture.
BeOS le faisait il y a 20 ans !
[^] # Re: Active Directory + Exchange + Outlook
Posté par Frank-N-Furter . Évalué à 4.
Exchange Autodiscovery service
Tu as un enregistrement SRV dans le DNS pointant sur l'emplacement du service d'auto conf,et outlook à partir de là se configure tout seul.
Depending on the time of day, the French go either way.
# Le doigt dans la toile
Posté par Larry Cow . Évalué à 5.
Tout cela me semble largement intégrable (si pas déjà intégré) dans le package Webfinger+XRDS+… . Non?
D'ailleurs, pour ce qui est de Thunderbird, il se connecte déjà très bien tout seul avec adresse et mot de passe, grâce à leur protocole d'autoconfiguration. Ce n'est pas basé sur Webfinger, mais le principe est sensiblement le même (sauf qu'il faut pouvoir utiliser le nom DNS "autoconfig.mondomaine.truc")
# Thunderbird et autoconfig
Posté par ashgan . Évalué à 4.
depuis quelques versions, Thunderbird inclus un mécanisme d'auto-configuration basé sur un fichier XML, qu'on peut coller soit dans le répertoire d'install soit sur le web
il permet de récupérer directement les paramètres mails en demandant juste a l'utilisateur de rentrer son mail et son password.
alors oui, c'est pas forcement aisé a déployer, mais n'est-ce pas pile le besoin?
un poil de lecture (en anglais): https://developer.mozilla.org/en/Thunderbird/Autoconfiguration
# Sémantique
Posté par Victor . Évalué à 5.
Salut,
Il me semble que toute la discussion ici se concentre sur l'aspect syntaxique du problème.
C'est une chose qui est déjà réglé théoriquement (en gros), mais qui manque d'adoption comme le journal le souligne.
L'ennui avec tout ça, c'est que le VRAI problème, c'est la sémantique qu'on associe à ces descriptions syntaxique. Et c'est là que le bat blesse : il devient très difficile de "découvrir" des protocoles ou des services juste en demandant à un serveur ce qu'il propose si on ne sait pas ce que veulent dire les choses.
Des chercheurs (que ce soit des académiques ou non, je prend le terme au sens large) se penchent dessus, j'ai en tête la communauté des (web)services, mais il y en a pleins d'autres qui se posent ces questions.
[^] # Re: Sémantique
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
Tu as cerné exactement le problème que je voulais décrire ! Le problème est sémantique !
J'ai reregardé les SRV suite au message de Gilles Mocellin, plus haut, wikipedia me dit par exemple :
La personne qui fait la requête SRV sait déjà ce qu'il cherche : il cherche du sip sur tcp !
hors moi je voudrais pouvoir demander à un serveur ce qu'il propose pour un usage, mais point de vue humain.
Q : je veux voir mes mails
R : je propose de l'imap ou de l'exchange pour ça
Q : je veux discuter (voix, texte)
R : je propose du XMPP, du SIP et un serveur murmur !
Q : je veux mes contacts
R : ils sont dans le compte exchange ou le compte XMPP !
Après ça, SRV peut servir à trouver les serveurs, en effet…
En plus, une telle méthode permettrait d'annoncer des protocoles expérimentaux pour un usage habituel
Q : je veux voir mes mails
R : je propose imap, mais aussi x-google-maboiteaulettre
avec le SRV, on sait déjà ce qu'on cherche, donc on ne saura jamais qu'il y a de nouvelles méthodes.
Et oui il y a certainement, en associant tout ce qu'on connait, la possibilité d'annoncer et rechercher… mais ce n'est pas adopté. Peut-être que ce n'est pas adopté parce que l'actuel n'est pas évident et ne répond que partiellement au besoin, et qu'il faut cumuler plusieurs services pour avoir ce qu'on veux !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Sémantique
Posté par Didier (site web personnel) . Évalué à 8.
En théorie c'est sympa ton exemple, mais dans la pratique ça ne se passe(ra) pas comme ça !
Quand tu dis "je veux voir mes mails", tu utilises un logiciel ad-hoc (thunderbird par exemple) qui supporte un nombre limité de protocoles (IMAP, POP, SMTP…). À quoi sert-il que thunderbird puisse savoir que le serveur propose en plus le protocole MON_PROTOCOLE qu'il ne gère pas ?
Le client email n'a qu'à fait une requêtes DNS SRV sur les protocoles qu'il supporte lors de l'auto-configuration et, hop, le tour est joué !
[^] # Re: Sémantique
Posté par philou . Évalué à 2.
Très juste. C'est l'intérêt de l'autoconfiguration. A noter que le respect des standards pour la rédaction de sa zone DNS prend alors tout son sens (je ne sais pas si on doit parler de standards ou de bonnes habitudes).
Si on a configuré un alias "imap" et un alias "smtp" dans sa zone, Thunderbird sera tout à fait capable de s'autoconfigurer. En lui disant que son adresse est jean-jacques@example.org, il va faire une requête DNS sur imap.example.org et une autre sur smtp.example.org… Si ça répond, c'est gagné.
L'utilisation généralisée des enregistrements SRV serait bien-sûr une meilleure solution. Elle permettrait par exemple de se passer de l'alias "www". Un bug existe depuis 13 ans chez Mozilla à ce sujet. Mieux, cela permettrait aux pauvres geeks de faire de la répartition de charge pas chère ou de mettre en place des relais en cas de panne d'une machine. Bah oui, l'intérêt des enregistrements SRV, c'est qu'on peut en mettre plusieurs pour un même couple [protocole applicatif / protocole de transport] avec des paramètres différents au niveau de la priorité, etc.
A ma connaissance, ça ne règle pas la question des méthodes d'authentification mais ça reste la partie secondaire du problème soulevé par Thomas, à mon avis du moins ;) Comme l'a dit Didier, le client pourrait alors tenter sa chance pour les protocoles qu'il connaît et s'en sortir comme ça.
Standard, propre, facile, bref on fait pas comme ça…
[^] # Re: Sémantique
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
J'ai envie de répondre "et pourquoi pas".
La raison de mon journal est bien que dans la pratique ça ne se passe pas comme ça, je m'interroge donc si ça pourrait le devenir, et de manière simple !
Oui, mais là c'est facile : tu pars du principe que tu sais déjà ce que tu veux (utiliser un client imap pour te connecter à un serveur imap).
"Voir de mails" n'implique pas du tout d'utiliser Thunderbird ni de dialoguer en Imap.
J'ai donné l'exemple d'un client mail, c'est une illustration, mais on peut imaginer des cas où c'est utile. Déjà, en tant que simple utilisateur, j'aimerai pouvoir demander ce que le serveur propose, et peut-être alors que je choisirai un autre logiciel !
Ensuite, le logiciel dans lequel tu entre ton adresse d'identité et ton mot de passe n'est pas nécessairement un logiciel de courrier, cela peut-être un outil tel que celui-là :
(c'est le nouveau gestionnaire de compte en ligne de Gnome)
Ce logiciel, il ne cherche pas spécifiquement à te connecter à ta boîte mail, il cherche les services associés à ton compte identité.
S'il y a une boîte mail associée, il configurera ton client mail, s'il y a une service de messagerie associée, il configurera ton client IM, et ainsi de suite.
On peut imaginer qu'un tel outil puisse te connecter à un service de musique en ligne ou un bugtracker…
Je peux encore donner l'exemple du compte Ubuntu One : il propose un volume de stockage distant, on peut télécharger de la musique… Actuellement il faut un outil spécial pour se connecter à Ubuntu One, dans le bureau Ubuntu on a donc deux outils de connexion : celui de la copie d'écran, et celui d'Ubuntu. Pour le deuxième, ça ne marche que parce qu'on a déjà la réponse préinstallé dans un paquet .deb !
On a vu apparaitre sur nos bureaux linux des supers plugins qui savaient automatiquement récupérer des plugins manquant, on peut imaginer que le gestionnaire de connexion sus-cité propose le logiciel le plus adapté, ou un plugin dans le dépôt de la distribution !
J'imagine bien un message "Votre logiciel ne supporte que l'IMAP, mais vous ne pourrez pas classer vos conversations par tag, un plugin gère le protocole IMAP++ recommandé par votre fournisseur, voulez-vous l'installer ?".
Si le serveur ne déclare pas les ressources mais se laisse seulement interrogé, cela signifie que le "gestionnaire de connexion" doit être mit à jour à chaque nouveau protocole ou version, pour pouvoir interroger ce protocole nouveau (et cela signifie qu'il doit savoir parler ce protocole !). Si le seruveur déclare ses ressources, et que les logiciels clients déclarent les ressources gérées, alors le gestionnaire de connexion peut les relier entre eux sans rien connaitre du fonctionnement de ces protocoles : le client qui s'est vanté de savoir le faire s'en occupe !
C'est pour cela aussi que je vois plus la description selon l'usage que selon le protocole, ce que ne font pas les DNS SRV. Quand on demande un serveur imap j'ai envie de dire qu'on l'a déjà trouvé !
Comme dit plus ailleurs dans la discussion, il y a plein de protocoles qui fonctionnent sur http, je crois que les plugin du logiciel evolution pour les calendrier et contacts google passent par http, le DNS SRV ne déclarent rien dessus, je pense. Le DNS peut déclarer les miroirs de ces serveurs http, mais pas dire lesquels font du calendrier sur http !
Il faut bien pouvoir demander à un moment "tel usage" et se voir répondre "tel protocole et telle ressource". Ça n'enlève pas l'utilité du DNS SRV, c'est complémentaire : dans certains cas il suffirait seulement de répondre le protocole et le DNS SRV complèterait alors avec l'adresse du serveur.
Le DNS SRV ne répond pas à la question des usages mais à la question des moyens.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Sémantique
Posté par flan (site web personnel) . Évalué à 2.
Ça me fait pas mal penser d'une part au protocole Bonjour / Zeroconf (très utilisé par les produits Apple, notamment), et d'autre part à l'autoconfiguration dispo sur les Mac.
Exemple : j'ai un compte local toto sur un OS X client, que j'ai installé en dehors de mon réseau local. Sur mon réseau local, j'ai un serveur OS X, avec pas mal de services (mails, calendriers, carnet d'adresse, jabber, par exemple).
Automatiquement, l'OS X client détecte que :
- il y a un OS X server sur le réseau local
- le compte toto y est également défini
- il y a les services mails, calendriers, carnet d'adresse, jabber (…)
- il propose de configurer les logiciels correspondant
Pour info, Zeroconf permet d'annoncer sur un réseau local à peu près n'importe quel service, (ldap, http, imap, streaming audio ou vidéo, ssh, ftp, imprimantes, …).
Le plus simple serait de s'inspirer de Zeroconf (qui remplit plutôt bien son rôle, mais qui est limité au réseau local) pour le rendre utilisable sur un réseau global.
Je trouve également que ça ne vaut pas forcément le coup de préciser les méthodes d'authentification lors de l'annonce du service :
- elles peuvent être annoncées lors de la connexion (HTTP)
- les différentes méthodes connues peuvent être essayées (c'est le cas avec certains clients mail récents)
[^] # Re: Sémantique
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Je ne connais pas bien bonjour/zeroconf/avahi, il semble qu'il y a une partie qui utilise les enregistrement DNS que certains ont cités dans les commentaires, c'est pas mal.
Par contre je ne pense pas qu'on ai besoin de toute la partie broadcast qui n'est certainement pas pertinente sur Internet, et qui ne nous sert à rien dans le cas présent : dans une adresse d'identité on a un domaine, et donc on a déjà une adresse à interroger. Tout ce qu'il faut c'est qu'un service disponible sur le serveur qui porte ce nom de domaine sache dénoncer ses petits camarades !
Si zeroconf permet de configurer simplement tout le bouzin dns, c'est intéressant ! À creuser ! C'est peut-être pas très KISS, mais si c'est éprouvé et pas trop compliqué…
Et il ne reste plus qu'à faire adopter ce genre de pratique. Et là ce n'est pas un problème technique donc c'est certainement ce qu'il y a de plus dur à obtenir ! :/
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Sémantique
Posté par Batchyx . Évalué à 5.
J'ai une super idée pour ça. Tu n'a qu'à avoir des enregistrements du type :
Comme ça, avec une requête sur
_services._dns-sd._udp.exemple.com, tu peux connaître la liste des services sur le réseau, y compris les nouvelles méthodes révolutionnaires que tu viens d'inventer et qu'aucun logiciel ne gère.Et si il y a plusieurs serveurs HTTP disponibles sur le réseau et que l'utilisateur doit en choisir un, tu pourrai, plutôt que de mettre un SRV sur
_http._tcp.example.com, tu mettrai un PTR sur_http._tcp.example.comqui pointerai verswebmail-interne._http._tcp.example.comet un autre versintranet._http._tcp.example.com, avec chacun un SRV. Et tu présenterai juste à l'utilisateur "intranet" et "webmail-interne".Et si jamais tu veux pouvoir répondre à la question "ou est le webmail", tu rajouterai aussi un PTR de
_mail._sub._http._tcp.example.comverswebmail-interne._http._tcp.example.com, et tu pourra interroger_mail._sub._http._tcp.example.compour trouver le serveur webmail.C'est une idée super originale, je suis sur que personne ne l'a fait avant.
[^] # Re: Sémantique
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Ah pas mal ! bon maintenant on peut se poser une des dernières questions de mon journal :
Pour reprendre l'exemple du mail, il me semble que les smartphones ont une liste prédéfinies de fournisseurs, et sinon il faut parcourir les FAQ, pourtant là ça aurait été dans l'intérêt d'une part des développeurs de systèmes mobiles et d'autre part des fournisseurs de service de s'entendre sur l'utilisation d'une méthode commune de découverte…
ce commentaire est sous licence cc by 4 et précédentes
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.