Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Xavier Roche
Ascadix wrote:
Pour POP, ça se trouve ..mais pour IMAP, j'ai rien trouvé de clair qui semble fonctionner
<http://www.ietf.org/rfc/rfc3501.txt?number501>
Chaque commande est préfixée d'un identificateur de commande (les réponses sont potentiellement asynchrones...) ; par exemple un nombre hexadécimal incrémenté à chaque commande.
00001 LOGIN dupont toto ..
[ IMAP est au passage AMHA assez bizarre comme protocol. Très différent du reste des RFC, avec des choix plus ou moins heureux comme le fait de ne jamais permettre de manière simple de manipuler des objets RFC822, l'utilisation de UTF-7 exotique, le système de sérialisation des objets parenthésés, le coup du asynchrone assez chiant à mettre en oeuvre et pas très utile, etc.. humm enfin bon.. ]
Ascadix wrote:
Pour POP, ça se trouve ..mais pour IMAP, j'ai rien trouvé de clair qui
semble fonctionner
<http://www.ietf.org/rfc/rfc3501.txt?number501>
Chaque commande est préfixée d'un identificateur de commande (les
réponses sont potentiellement asynchrones...) ; par exemple un nombre
hexadécimal incrémenté à chaque commande.
00001 LOGIN dupont toto
..
[ IMAP est au passage AMHA assez bizarre comme protocol. Très différent
du reste des RFC, avec des choix plus ou moins heureux comme le fait de
ne jamais permettre de manière simple de manipuler des objets RFC822,
l'utilisation de UTF-7 exotique, le système de sérialisation des objets
parenthésés, le coup du asynchrone assez chiant à mettre en oeuvre et
pas très utile, etc.. humm enfin bon.. ]
Pour POP, ça se trouve ..mais pour IMAP, j'ai rien trouvé de clair qui semble fonctionner
<http://www.ietf.org/rfc/rfc3501.txt?number501>
Chaque commande est préfixée d'un identificateur de commande (les réponses sont potentiellement asynchrones...) ; par exemple un nombre hexadécimal incrémenté à chaque commande.
00001 LOGIN dupont toto ..
[ IMAP est au passage AMHA assez bizarre comme protocol. Très différent du reste des RFC, avec des choix plus ou moins heureux comme le fait de ne jamais permettre de manière simple de manipuler des objets RFC822, l'utilisation de UTF-7 exotique, le système de sérialisation des objets parenthésés, le coup du asynchrone assez chiant à mettre en oeuvre et pas très utile, etc.. humm enfin bon.. ]
DINH Viêt Hoà
<http://www.ietf.org/rfc/rfc3501.txt?number501>
Chaque commande est préfixée d'un identificateur de commande (les réponses sont potentiellement asynchrones...) ; par exemple un nombre hexadécimal incrémenté à chaque commande.
pas vraiment :)
ça peut être préfixé par zzz En fait, en gros, ça peut être une série de symboles alphanumérique.
[ IMAP est au passage AMHA assez bizarre comme protocol. Très différent du reste des RFC, avec des choix plus ou moins heureux comme le fait de ne jamais permettre de manière simple de manipuler des objets RFC822, l'utilisation de UTF-7 exotique, le système de sérialisation des objets parenthésés, le coup du asynchrone assez chiant à mettre en oeuvre et pas très utile, etc.. humm enfin bon.. ]
possibilité étendue implique évidemment une grammaire un peu complète. Ce n'est évidemment pas censé être utilisé par un humain. Cependant, il est vrai que des choses auraient pu être simplifiées.
-- DINH V. Hoa,
"tu as bientot 15 ans, faut que tu commences à être autonome" -- jul
<http://www.ietf.org/rfc/rfc3501.txt?number501>
Chaque commande est préfixée d'un identificateur de commande (les
réponses sont potentiellement asynchrones...) ; par exemple un nombre
hexadécimal incrémenté à chaque commande.
pas vraiment :)
ça peut être préfixé par zzz
En fait, en gros, ça peut être une série de symboles alphanumérique.
[ IMAP est au passage AMHA assez bizarre comme protocol. Très différent
du reste des RFC, avec des choix plus ou moins heureux comme le fait de
ne jamais permettre de manière simple de manipuler des objets RFC822,
l'utilisation de UTF-7 exotique, le système de sérialisation des objets
parenthésés, le coup du asynchrone assez chiant à mettre en oeuvre et
pas très utile, etc.. humm enfin bon.. ]
possibilité étendue implique évidemment une grammaire un peu complète.
Ce n'est évidemment pas censé être utilisé par un humain.
Cependant, il est vrai que des choses auraient pu être simplifiées.
--
DINH V. Hoa,
"tu as bientot 15 ans, faut que tu commences à être autonome" -- jul
Chaque commande est préfixée d'un identificateur de commande (les réponses sont potentiellement asynchrones...) ; par exemple un nombre hexadécimal incrémenté à chaque commande.
pas vraiment :)
ça peut être préfixé par zzz En fait, en gros, ça peut être une série de symboles alphanumérique.
[ IMAP est au passage AMHA assez bizarre comme protocol. Très différent du reste des RFC, avec des choix plus ou moins heureux comme le fait de ne jamais permettre de manière simple de manipuler des objets RFC822, l'utilisation de UTF-7 exotique, le système de sérialisation des objets parenthésés, le coup du asynchrone assez chiant à mettre en oeuvre et pas très utile, etc.. humm enfin bon.. ]
possibilité étendue implique évidemment une grammaire un peu complète. Ce n'est évidemment pas censé être utilisé par un humain. Cependant, il est vrai que des choses auraient pu être simplifiées.
-- DINH V. Hoa,
"tu as bientot 15 ans, faut que tu commences à être autonome" -- jul
Xavier Roche
DINH Viêt Hoà wrote:
ça peut être préfixé par zzz En fait, en gros, ça peut être une série de symboles alphanumérique.
C'est pourqoi j'ai bien dit "par exemple" :) Dans les faits les clients utilisent des nombres incrémentés.
Cependant, il est vrai que des choses auraient pu être simplifiées.
Certes. Les possibilités additionnelles ne justifiaient pas cette complexité. Les listes "à la LISP" pour envoyer des infos .. et la RFC822 elle pue des pieds ? UTF-7 *modifié* (UTF-7 c'est déja assez grave) parce le choix a été fait de prendre des séparateurs qui se trouvaient parmis les éléments codants de *UTF-7*.. pourquoi tant de haine ? Et quel serveur gère le côté asynchrone (à part les notifications "non sollicitées") ?
DINH Viêt Hoà wrote:
ça peut être préfixé par zzz
En fait, en gros, ça peut être une série de symboles alphanumérique.
C'est pourqoi j'ai bien dit "par exemple" :)
Dans les faits les clients utilisent des nombres incrémentés.
Cependant, il est vrai que des choses auraient pu être simplifiées.
Certes. Les possibilités additionnelles ne justifiaient pas cette
complexité. Les listes "à la LISP" pour envoyer des infos .. et la
RFC822 elle pue des pieds ? UTF-7 *modifié* (UTF-7 c'est déja assez
grave) parce le choix a été fait de prendre des séparateurs qui se
trouvaient parmis les éléments codants de *UTF-7*.. pourquoi tant de
haine ? Et quel serveur gère le côté asynchrone (à part les
notifications "non sollicitées") ?
ça peut être préfixé par zzz En fait, en gros, ça peut être une série de symboles alphanumérique.
C'est pourqoi j'ai bien dit "par exemple" :) Dans les faits les clients utilisent des nombres incrémentés.
Cependant, il est vrai que des choses auraient pu être simplifiées.
Certes. Les possibilités additionnelles ne justifiaient pas cette complexité. Les listes "à la LISP" pour envoyer des infos .. et la RFC822 elle pue des pieds ? UTF-7 *modifié* (UTF-7 c'est déja assez grave) parce le choix a été fait de prendre des séparateurs qui se trouvaient parmis les éléments codants de *UTF-7*.. pourquoi tant de haine ? Et quel serveur gère le côté asynchrone (à part les notifications "non sollicitées") ?
Xavier
Salut tout le monde
Je suis à la recherche d'info pour procéder aux manoeuvres de base sur un IMAP ..masi avec un telnet et mes p'tits doigts en guise de client.
en gros, lister le contenu du bazard, lire un mail, créer/supprimer un dossier
Pour POP, ça se trouve ..mais pour IMAP, j'ai rien trouvé de clair qui semble fonctionner
Z'auriez ça dans un coin ?
Merci
Va sur la rubrique IMAP du site http://christian.caleca.free.fr/ il y a
tout ce que tu veux sur POP, IMAP, SMTP, HTTP,...
Salut tout le monde
Je suis à la recherche d'info pour procéder aux manoeuvres de base sur
un IMAP ..masi avec un telnet et mes p'tits doigts en guise de client.
en gros, lister le contenu du bazard, lire un mail, créer/supprimer un
dossier
Pour POP, ça se trouve ..mais pour IMAP, j'ai rien trouvé de clair qui
semble fonctionner
Z'auriez ça dans un coin ?
Merci
Va sur la rubrique IMAP du site http://christian.caleca.free.fr/ il y a
Je suis à la recherche d'info pour procéder aux manoeuvres de base sur un IMAP ..masi avec un telnet et mes p'tits doigts en guise de client.
en gros, lister le contenu du bazard, lire un mail, créer/supprimer un dossier
Pour POP, ça se trouve ..mais pour IMAP, j'ai rien trouvé de clair qui semble fonctionner
Z'auriez ça dans un coin ?
Merci
Va sur la rubrique IMAP du site http://christian.caleca.free.fr/ il y a
tout ce que tu veux sur POP, IMAP, SMTP, HTTP,...
DINH Viêt Hoà
Cependant, il est vrai que des choses auraient pu être simplifiées.
Certes. Les possibilités additionnelles ne justifiaient pas cette complexité. Les listes "à la LISP" pour envoyer des infos ..
Comment aurais-tu encodé le fait de renvoyer une liste d'éléments ? Voire une liste de liste. La façon LISP me paraît assez naturelle. Ce n'est sans doute pas le point que j'aurai reproché à IMAP.
et la RFC822 elle pue des pieds ?
Oui, elle est coûteuse en temps de traitement. Le principe d'IMAP est de reporter ce travail du côté serveur.
UTF-7 *modifié* (UTF-7 c'est déja assez grave) parce le choix a été fait de prendre des séparateurs qui se trouvaient parmis les éléments codants de *UTF-7*.. pourquoi tant de haine ?
Pour ce qui est de UTF7 modifié, il faut voir qu'IMAP a été conçu tout d'abord pour les pays anglophones. Tout comme pour la RFC 2822 à laquelle on a ajouté un espèce de bricolage qu'est le support MIME (RFC 2047), à IMAP, on a ajouté le support de langues non anglophones par l'UTF7 modifié. Il s'agit d'UTF7 modifié pour la raison que tu décris. Je crois que RFC 2822 elle aussi utilise des éléments codant de UTF7.
Et quel serveur gère le côté asynchrone (à part les notifications "non sollicitées") ?
Cette histoire d'asynchronisme dont tu parles permet d'envoyer plusieurs requêtes d'un coup et n'être pas obligé d'attendre le traitement des requêtes dans l'ordre. Par exemple, si tu demande d'extraire une grosse partie MIME en premier puis une petite, il peut être intéressant pour un client de recevoir la petite tout de même en premier. Cela permet aussi de ne pas avoir à attendre la réponse d'une requête avant d'envoyer une seconde requête. Cela n'empêche pas les clients et serveurs d'implémenter le protocole de façon synchrone. L'asynchronisme n'est qu'une possibilité ouverte du protocole.
Le même genre de mécanismes se retrouve sur SMTP : RFC 2920.
Les choix fait par IMAP me semblent des choix raisonnables en général. Un des reproche que je ferai est qu'on peut encoder une chaîne de plusieurs façon. Une façon unique d'encoder les chaînes aurait simplifié le travail de plusieurs clients et serveurs.
-- DINH V. Hoa,
"un bar branché, c'est un cyber-café" -- j.j.
Cependant, il est vrai que des choses auraient pu être simplifiées.
Certes. Les possibilités additionnelles ne justifiaient pas cette
complexité. Les listes "à la LISP" pour envoyer des infos ..
Comment aurais-tu encodé le fait de renvoyer une liste d'éléments ?
Voire une liste de liste.
La façon LISP me paraît assez naturelle. Ce n'est sans doute pas le
point que j'aurai reproché à IMAP.
et la
RFC822 elle pue des pieds ?
Oui, elle est coûteuse en temps de traitement. Le principe d'IMAP est de
reporter ce travail du côté serveur.
UTF-7 *modifié* (UTF-7 c'est déja assez
grave) parce le choix a été fait de prendre des séparateurs qui se
trouvaient parmis les éléments codants de *UTF-7*.. pourquoi tant de
haine ?
Pour ce qui est de UTF7 modifié, il faut voir qu'IMAP a été conçu tout
d'abord pour les pays anglophones.
Tout comme pour la RFC 2822 à laquelle on a ajouté un espèce de
bricolage qu'est le support MIME (RFC 2047), à IMAP, on a ajouté le
support de langues non anglophones par l'UTF7 modifié.
Il s'agit d'UTF7 modifié pour la raison que tu décris.
Je crois que RFC 2822 elle aussi utilise des éléments codant de UTF7.
Et quel serveur gère le côté asynchrone (à part les
notifications "non sollicitées") ?
Cette histoire d'asynchronisme dont tu parles permet d'envoyer plusieurs
requêtes d'un coup et n'être pas obligé d'attendre le traitement des
requêtes dans l'ordre. Par exemple, si tu demande d'extraire une grosse
partie MIME en premier puis une petite, il peut être intéressant pour un
client de recevoir la petite tout de même en premier.
Cela permet aussi de ne pas avoir à attendre la réponse d'une requête
avant d'envoyer une seconde requête.
Cela n'empêche pas les clients et serveurs d'implémenter le protocole de
façon synchrone. L'asynchronisme n'est qu'une possibilité ouverte du
protocole.
Le même genre de mécanismes se retrouve sur SMTP : RFC 2920.
Les choix fait par IMAP me semblent des choix raisonnables en général.
Un des reproche que je ferai est qu'on peut encoder une chaîne de
plusieurs façon. Une façon unique d'encoder les chaînes aurait simplifié
le travail de plusieurs clients et serveurs.
Cependant, il est vrai que des choses auraient pu être simplifiées.
Certes. Les possibilités additionnelles ne justifiaient pas cette complexité. Les listes "à la LISP" pour envoyer des infos ..
Comment aurais-tu encodé le fait de renvoyer une liste d'éléments ? Voire une liste de liste. La façon LISP me paraît assez naturelle. Ce n'est sans doute pas le point que j'aurai reproché à IMAP.
et la RFC822 elle pue des pieds ?
Oui, elle est coûteuse en temps de traitement. Le principe d'IMAP est de reporter ce travail du côté serveur.
UTF-7 *modifié* (UTF-7 c'est déja assez grave) parce le choix a été fait de prendre des séparateurs qui se trouvaient parmis les éléments codants de *UTF-7*.. pourquoi tant de haine ?
Pour ce qui est de UTF7 modifié, il faut voir qu'IMAP a été conçu tout d'abord pour les pays anglophones. Tout comme pour la RFC 2822 à laquelle on a ajouté un espèce de bricolage qu'est le support MIME (RFC 2047), à IMAP, on a ajouté le support de langues non anglophones par l'UTF7 modifié. Il s'agit d'UTF7 modifié pour la raison que tu décris. Je crois que RFC 2822 elle aussi utilise des éléments codant de UTF7.
Et quel serveur gère le côté asynchrone (à part les notifications "non sollicitées") ?
Cette histoire d'asynchronisme dont tu parles permet d'envoyer plusieurs requêtes d'un coup et n'être pas obligé d'attendre le traitement des requêtes dans l'ordre. Par exemple, si tu demande d'extraire une grosse partie MIME en premier puis une petite, il peut être intéressant pour un client de recevoir la petite tout de même en premier. Cela permet aussi de ne pas avoir à attendre la réponse d'une requête avant d'envoyer une seconde requête. Cela n'empêche pas les clients et serveurs d'implémenter le protocole de façon synchrone. L'asynchronisme n'est qu'une possibilité ouverte du protocole.
Le même genre de mécanismes se retrouve sur SMTP : RFC 2920.
Les choix fait par IMAP me semblent des choix raisonnables en général. Un des reproche que je ferai est qu'on peut encoder une chaîne de plusieurs façon. Une façon unique d'encoder les chaînes aurait simplifié le travail de plusieurs clients et serveurs.
-- DINH V. Hoa,
"un bar branché, c'est un cyber-café" -- j.j.
Ascadix
De ses petits doigts agiles, Ascadix à provoqué l'apparition de l'histoire que voici <news:41c354a2$0$10207$
Salut tout le monde
Je suis à la recherche d'info pour procéder aux manoeuvres de base sur un IMAP ..masi avec un telnet et mes p'tits doigts en guise de client. en gros, lister le contenu du bazard, lire un mail, créer/supprimer un dossier
Pour POP, ça se trouve ..mais pour IMAP, j'ai rien trouvé de clair qui semble fonctionner
Z'auriez ça dans un coin ?
Merci
Merci à tous ...
Bon, ça confirme ma premiere impression ..IMAP ... pas glop à la main.
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
De ses petits doigts agiles, Ascadix à provoqué l'apparition de l'histoire
que voici
<news:41c354a2$0$10207$8fcfb975@news.wanadoo.fr>
Salut tout le monde
Je suis à la recherche d'info pour procéder aux manoeuvres de base
sur un IMAP ..masi avec un telnet et mes p'tits doigts en guise de
client.
en gros, lister le contenu du bazard, lire un mail, créer/supprimer un
dossier
Pour POP, ça se trouve ..mais pour IMAP, j'ai rien trouvé de clair qui
semble fonctionner
Z'auriez ça dans un coin ?
Merci
Merci à tous ...
Bon, ça confirme ma premiere impression ..IMAP ... pas glop à la main.
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
De ses petits doigts agiles, Ascadix à provoqué l'apparition de l'histoire que voici <news:41c354a2$0$10207$
Salut tout le monde
Je suis à la recherche d'info pour procéder aux manoeuvres de base sur un IMAP ..masi avec un telnet et mes p'tits doigts en guise de client. en gros, lister le contenu du bazard, lire un mail, créer/supprimer un dossier
Pour POP, ça se trouve ..mais pour IMAP, j'ai rien trouvé de clair qui semble fonctionner
Z'auriez ça dans un coin ?
Merci
Merci à tous ...
Bon, ça confirme ma premiere impression ..IMAP ... pas glop à la main.
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Xavier Roche
Ascadix wrote:
Bon, ça confirme ma premiere impression ..IMAP ... pas glop à la main.
Ben si t'es pas allergique aux parenthèses, ça va :)
Ascadix wrote:
Bon, ça confirme ma premiere impression ..IMAP ... pas glop à la main.
Ben si t'es pas allergique aux parenthèses, ça va :)
