ITU-T T 37 AMD 1 FRENCH-1999 Procedures for the transfer of facsimile data via store-and-forward on the Internet Amendment 1 Full Mode《通过因特网存储转发的传输传真数据的规程 1号修正案 完整模式 系列T 远程信息处理业务终端.pdf

1、 UNION INTERNATIONALE DES TLCOMMUNICATIONS UIT-T T.37SECTEUR DE LA NORMALISATION DES TLCOMMUNICATIONS DE LUIT Amendement 1(09/99) SRIE T: TERMINAUX DES SERVICES TLMATIQUES Procdures pour le transfert de donnes de tlcopie en mode diffr sur le rseau Internet Amendement 1: Mode complet Recommandation U

2、IT-T T.37 Amendement 1 (Antrieurement Recommandation du CCITT) RECOMMANDATIONS UIT-T DE LA SRIE T TERMINAUX DES SERVICES TLMATIQUES Pour plus de dtails, voir la Liste des Recommandations de lUIT-T. Recommandation T.37/Amd.1 (09/99) i RECOMMANDATION UIT-T T.37 PROCDURES POUR LE TRANSFERT DE DONNES DE

3、 TLCOPIE EN MODE DIFFR SUR LE RSEAU INTERNET AMENDEMENT 1 Mode complet Rsum Le prsent amendement prend en charge le mode complet de tlcopie par Internet de la Recommandation T.37. Les fonctionnalits additionnelles comprennent la prise en charge de la transmission et de la rception de formats dimage

4、TIFF additionnels, lchange de capacits et laccus de rception. Source LAmendement 1 la Recommandation UIT-T T.37, labor par la Commission dtudes 8 (1997-2000) de lUIT-T, a t approuv le 24 septembre 1999 selon la procdure dfinie dans la Rsolution n 1 de la CMNT. ii Recommandation T.37/Amd.1 (09/99) AV

5、ANT-PROPOS LUIT (Union internationale des tlcommunications) est une institution spcialise des Nations Unies dans le domaine des tlcommunications. LUIT-T (Secteur de la normalisation des tlcommunications) est un organe permanent de lUIT. Il est charg de ltude des questions techniques, dexploitation e

6、t de tarification, et met ce sujet des Recommandations en vue de la normalisation des tlcommunications lchelle mondiale. La Confrence mondiale de normalisation des tlcommunications (CMNT), qui se runit tous les quatre ans, dtermine les thmes dtudes traiter par les Commissions dtudes de lUIT-T, lesqu

7、elles laborent en retour des Recommandations sur ces thmes. Lapprobation des Recommandations par les Membres de lUIT-T seffectue selon la procdure dfinie dans la Rsolution n 1 de la CMNT. Dans certains secteurs des technologies de linformation qui correspondent la sphre de comptence de lUIT-T, les n

8、ormes ncessaires se prparent en collaboration avec lISO et la CEI. NOTE Dans la prsente Recommandation, lexpression “Administration“ est utilise pour dsigner de faon abrge aussi bien une administration de tlcommunications quune exploitation reconnue. DROITS DE PROPRIT INTELLECTUELLE LUIT attire latt

9、ention sur la possibilit que lapplication ou la mise en uvre de la prsente Recommandation puisse donner lieu lutilisation dun droit de proprit intellectuelle. LUIT ne prend pas position en ce qui concerne lexistence, la validit ou lapplicabilit des droits de proprit intellectuelle, quils soient reve

10、ndiqus par un Membre de lUIT ou par une tierce partie trangre la procdure dlaboration des Recommandations. A la date dapprobation de la prsente Recommandation, lUIT avait t avise de lexistence dune proprit intellectuelle protge par des brevets acqurir pour mettre en uvre la prsente Recommandation. T

11、outefois, comme il ne sagit peut-tre pas de renseignements les plus rcents, il est vivement recommand aux responsables de la mise en uvre de consulter la base de donnes des brevets du TSB. Ge3 UIT 2000 Droits de reproduction rservs. Aucune partie de cette publication ne peut tre reproduite ni utilis

12、e sous quelque forme que ce soit et par aucun procd, lectronique ou mcanique, y compris la photocopie et les microfilms, sans laccord crit de lUIT. Recommandation T.37/Amd.1 (09/99) iii TABLE DES MATIRES Page 1) Paragraphe 3. 1 2) Sous-paragraphe 6.2 . 1 3) Appendice I 2 4) Nouvel Appendice III . 5

13、5) Nouvel Appendice IV. 5 Recommandation T.37/Amd.1 (09/99) 1 Recommandation T.37 Recommandation T.37/Amd.1 (09/99) PROCDURES POUR LE TRANSFERT DE DONNES DE TLCOPIE EN MODE DIFFR SUR LE RSEAU INTERNET AMENDEMENT 1 Mode complet (Genve, 1999) 1) Paragraphe 3 Supprimer les rfrences suivantes: Recommand

14、ation CCITT T.6 (1988), Schmas de codage et fonctions de commande de codage de la tlcopie pour les tlcopieurs du groupe 4. RFC 1725, Post Office Protocol Version 3 (protocole POP Version 3). Ajouter les rfrences et la note suivantes: RFC 1869, SMTP Service Extensions (extensions du service en protoc

15、ole SMTP). RFC 1939, Post Office Protocol Version 3 (protocole POP Version 3). RFC 2060, Internet Message Access Protocol Version 4rev1 protocole Internet daccs aux messages Version 4 (Rv.1). RFC 2298, An Extensible Message Format for Message Disposition Notifications (un format extensible de messag

16、e pour les notifications de suppression de message). RFC 2532, Extended Facsimile Using Internet Mail (tlcopie tendue utilisant la messagerie par Internet). RFC 2530, Indicating Supported Media Features Using Extensions to DSN and MDN (indication des caractris-tiques de support acceptes laide dexten

17、sions des notifications DSN et MDN). RFC 2531, Content feature schema for Internet fax (schma des caractristiques des contenus pour la tlcopie par Internet). NOTE Les rfrences incorpores dans les documents RFC figurant dans la prsente Recommandation, faisant tat de “travaux en cours“, ne sont cites

18、qu titre dinformation et ne sont pas normatives. 2) Sous-paragraphe 6.2 Modifier le sous-paragraphe 6.2 comme suit: 6.2 Mode complet Le mode complet prend en charge le transfert de donnes dimage, lchange de capacits et laccus de rception, conformment aux spcifications de la Recommandation F.185. 6.2

19、.1 Procdures pour le mode complet Sauf indication contraire dans le Tableau 2, les procdures pour le mode complet sont dfinies dans RFC 2532. On trouvera dans le tableau ci-dessous un rsum fonctionnel des rfrences associes pour le mode complet. 2 Recommandation T.37/Amd.1 (09/99) Tableau 2/T.37 Rsum

20、 fonctionnel des procdures pour le mode complet 3) Appendice IAjouter le nouveau sous-paragraphe I.2 suivant: I.2 Prescriptions dimplmentation pour le mode complet Tableau I.2/T.37 Prescriptions dimplmentation pour le mode complet Adressage Procdures: RFC 2305, section 3 Messagerie lectronique: RFC

21、822 Bretelle de sortie: RFC 2303, RFC 2304 Format dimage Profils TIFF: RFC 2301 Accus de rception Confirmation de remise: RFC 1891, notification de statut de remise (DSN) Confirmation de traitement: RFC 2298, notification de suppression de message (MDN) Echange de capacits Format des capacits: RFC 2

22、531 Mcanisme des capacits: RFC 2530 Transport ESMTP: RFC 1869 Accs la bote postale POP3: RFC 1939 IMAP4: RFC 2060 NOTE La prescription de prise en charge des tlcopieurs G4 par les passerelles bretelles dentre et de sortie fera lobjet dune tude complmentaire. Emetteur Requis Envoyer les donnes dimage

23、 sous forme dun seul fichier en format RFC 2301 sur pages multiples dextension MIME RFC 2305 2.2.3 Fournir une indication en cas de problmes de retransmission RFC 2305 2.3.1 Fournir une adresse de retour dans les messages utilisant le protocole SMTP daprs len-tte figurant sur lenveloppe RFC 2305 2.3

24、.1 Demander la notification de statut de remise, si lmetteur souhaite avoir confirmation de la remise RFC 2532 2.1.1 (Note 3) Demande de notification de suppression de message, si lmetteur souhaite avoir confirmation que le traitement a bien t effectu RFC 2532 2.1.2 (Note 3) Fortement Inclure lident

25、ificateur de message RFC 2305 2.2.1 recommand Utiliser le codage Base 64 pour les donnes dimage Pouvoir reconnatre et traiter les tiquettes de caractristiques dfinies dans le format RFC 2531 lors de linventaire des capacits offertes par un destinataire ventuel RFC 2532 3 (Note 2) Facultatif Utiliser

26、 dautres Profils TIFF si lon est averti au pralable de la prise en charge de tels profils par le rcepteur RFC 2305 4 Signaler la rception dune notification de type DSN ou autre RFC 1894 (Note 3) Demander une notification DSN/MDN positive, si une rponse de la capacit de notification DSN/MDN est souha

27、ite RFC 2532 3.3 (Notes 1, 2, 4) Envoyer un message contenant la fois le sous-ensemble minimal du format TIFF et un format TIFF de qualit suprieure utilisant une option de choix multiples ou dalternative RFC 2532 3 Annuler manuellement le positionnement par dfaut RFC 2532 3.1 Accder la structure dan

28、nuaire des capacits du destinataire RFC 2532 3.2 Utiliser lun quelconque des Profils TIFF dfinis dans le format RFC 2301 pour mettre vers un destinataire dont les capacits correspondantes sont fonction de la rponse fournie par la capacit de notification MDN/DSN RFC 2532 3 (Notes 1, 2, 4) Recommandat

29、ion T.37/Amd.1 (09/99) 3 Tableau I.2/T.37 (suite) Rcepteur Requis Etre conforme lextension MIME sauf quil nest pas requis de proposer linsertion dune pice jointe code en extension MIME dans un fichier et quil est possible dimprimer un fichier reu au lieu de lafficher RFC 2305 2.2.2 Avoir la capacit

30、de traiter, dans un seul message, plusieurs fichiers dimage en profil S du format RFC 2301 sur pages multiples dextension MIME RFC 2305 2.2.4 Signaler dventuels problmes de rception ou de traitement RFC 2305 2.3.2 (Note 3) Implmenter la notification de suppression de message RFC 2532 2.2 (Notes 1, 2

31、, 4) Indiquer les caractristiques du support admises dans le message de notification DSN ou MDN en format RFC 2530 RFC 2532 2.2 Choix dune configuration permettant de ne pas tenir compte dune demande de notification MDN sans signaler cette non-prise en compte RFC 2532 2.2.1 Ne pas mettre de notifica

32、tion MDN non sollicite pour indiquer que le traitement a t effectu RFC 2532 2.2.1 Possibilit, pour un oprateur, de dsactiver les rponses de notification MDN automatiques RFC 2532 2.2.1 Ne pas mettre de notification DSN en cas dutilisation des protocoles POP3 et IMAP4 RFC 2532 2.2.2 Fortement recomma

33、nd Si lagent MTA conclut limpossibilit de traiter le message, rejeter celui-ci avec le code de statut 5.6.1 RFC 2530 (Note 3) Facultatif Avoir la capacit de traiter tout Profil TIFF RFC 2305 4 Pouvoir configurer le systme automatis de telle sorte quil puisse toujours rpondre une demande de notificat

34、ion MDN RFC 2532 2.2.1 Infrastructure de lmetteur Requis Prise en charge de la notification DSN RFC 2532 2.3.1 (Note 5) Infrastructure du rcepteur Requis Prise en charge de la notification DSN RFC 2532 2.3.2 (Note 5) Passerelle bretelle de sortie (si elle est implmente) Requis Etre conforme au proto

35、cole SMTP RFC 0821 Signaler un dfaut de remise RFC 1894, RFC 2305 2.3.1 (Note 3) Avoir la capacit de traiter les adresses de messagerie lectronique par RTPC/FAX RFC 2303, RFC 2304 Etre conforme aux Recommandations de lUIT applicables la transmission de tlcopie T.30 Tenter de faire suivre les message

36、s lectroniques jusquaux terminaux de tlcopie G3 correspondants RFC 2305 3.2 Faire en sorte que les prescriptions juridiques locales, concernant les transmissions de tlcopie, soient respectes Fortement recommand Utilisation de notifications DSN pour signaler les dfauts de remise RFC 2305 2.3.1, RFC 1

37、894 (Note 3) Utilisation dun protocole agr pour laccs la bote postale lors de la fourniture de services plusieurs utilisateurs RFC 2305 2.1.3 Facultatif Convertir les donnes dimage en format acceptable par le tlcopieur G3 destinataire RFC 2305 2.1.2 Utilisation dun protocole daccs une bote postale l

38、ors de la fourniture de services un unique destinataire de messagerie RFC 2305 2.1.3 4 Recommandation T.37/Amd.1 (09/99) Tableau I.2/T.37 (fin) NOTE 1 Limplmentation type du mode complet comprend lchange de capacits. La mthode prconise pour obtenir une rponse au sujet des capacits consiste demander

39、une notification MDN ou DSN. Dans la rponse, le destinataire devrait donner une indication des capacits utilisant des extensions DSN/MDN conformes lextension RFC 2530. Les modalits dtailles de demande de notification MDN/DSN ainsi que lutilisation dautres mthodes de demande et dindication de capacit

40、s appellent un complment dtude. NOTE 2 Dans le cas de limplmentation type du mode complet, la notification DSN ou MDN qui est renvoye devrait contenir des informations dcrivant les capacits du destinataire. Lexpditeur devrait utiliser ces informations pour des communications ultrieures avec le desti

41、nataire. Par exemple, un expditeur peut utiliser lun quelconque des Profils TIFF dfinis dans RFC 2301 lorsquil met vers un destinataire dont les capacits correspondantes sont fonction de la rponse fournie par la capacit de notification MDN/DSN. NOTE 3 Dans le cas de limplmentation type du mode compl

42、et, la confirmation de remise et la confirmation de traitement peuvent tre obtenues en utilisant la notification DSN et la notification MDN. Linclusion de donnes supplmentaires, telles que le nombre total de pages et le nombre de pages errones, dans les messages de notification MDN et DSN, appelle u

43、n complment dtude. NOTE 4 Certains responsables de limplmentation souhaiteront peut-tre ajouter des extensions prives limplmentation normale du mode complet. Par exemple, les constructeurs/fournisseurs pourraient trouver des types dextensions MIME et un en-tte de courrier lectronique X propres leur

44、socit pour faciliter limplmentation dapplications spcifiques. NOTE 5 Conformment au RFC 2532, la notification DSN doit tre assure dans le cadre de linfrastructure de lmetteur et du rcepteur. Les terminaux fonctionnant en mode complet peuvent continuer fonctionner dans des situations dans lesquelles

45、certains agents MTA du trajet de retransmission du courrier nassurent pas la notification DSN. En pareil cas, il ne sera pas donn de confirmation de remise via notification DSN pour la destination finale. La confirmation du traitement via notification MDN pourra toutefois encore tre donne. Recommand

46、ation T.37/Amd.1 (09/99) 5 4) Nouvel Appendice III Ajouter le nouvel Appendice III suivant: Appendice III Tableau des rfrences RFC pour le mode complet On trouvera dans le prsent appendice un tableau montrant des relations entre les diffrentes normes Internet utilises pour la fonctionnalit “mode com

47、plet“ expose dans la Recommandation T.37. T0828420-98/d01EIFAXRFC 2532schmaRFC 2531syntaxeRFC 2533acheminementdu courrierRFC 974modesimpleRFC 2305ditionRFC 2530TIFF pourtlcopieRFC 2301mappageavec la Rec. T.30et avec les RFCinformationnelextension duserveur SMTPRFC 2034mcanismeDSNRFC 1891caractristiquesdu supportRFC 2534enregistrementRFC 2506BCPcodedtatRFC 1893formatDSNRFC 1894compte rendudu choixmultipleRFC 1892MDNRFC 2298FIGURE D01 5) Nouvel Appendice IV Ajouter le nouvel Appendice IV suivant: Appendice IV Exemples de codage des