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 :
Un enregistrement SRV contient les informations suivantes :
Service: le nom symbolique du service concerné.
Protocole: généralement, c'est soit TCP, soit UDP.
Nom de domaine: le domaine de validité de l'enregistrement.
[…]
Par exemple, un enregistrement SRV peut ressembler à ceci : _sip._tcp.example.com. 86400 IN SRV 0 5 5060 serveursip.example.com.
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 Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Décrire les services servis et comment s'y connecter. É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