SUDDIVISIONE DELLA PRESENTAZIONE

Transcript

1 X.400 Nel 1984 il CCITT ha pubblicato 8 raccomandazioni riguardanti il message handling system (MHS) X.400 System Model - service elements X.401 Basic Service elements and optional user facilities X.408 Encoded information type conversion rules X.409 Presentation Transfer Syntax and Notation X.410 Remote operations and reliable transfer service X.411 Message Transfer Layer X.420 Interpersonal messaging user agent layer X.430 Access protocol for teletext terminals CCITT non ha "inventato" il Message Handling System. I concetti di base esistevano già nei documenti dell'ifip, datati fine anni 70, che sono stati poi ripresi dall'ecma per produrre MIDA (Message Interchange Distributed Application) e dall'iso per produrre MOTIS (Message Oriented Text Interchange System). La pubblicazione degli standard CCITT dell'84 ha creato un grosso interesse da parte di vari gruppi sparsi per il mondo. Essi hanno dovuto subito risolvere il primo problema che si poneva loro per poter realmente interoperare: risolvere le ambiguità dello standard. Si è pertanto giunti alla necessità di definire dei profili funzionali. Le raccomandazioni CCITT vengono aggiornate a scadenza quadriennale: nel 1988 è stata infatti pubblicata una nuova versione delle raccomandazioni riguardanti i Message Handling System. SUDDIVISIONE DELLA PRESENTAZIONE 1 of 10 12/04/

2 1. ARCHITETTURA GENERALE DI UN MHS 2. ORGANIZZAZIONE A LIVELLI 3. X PRESENTATION TRANSFER SYNTAX 4. INDIRIZZAMENTO 5. MTS - MESSAGE TRANSFER SERVICE 6. PROTOCOLLO P1 7. RTS - RELIABLE TRANSFER SERVICE 8. PROTOCOLLO P3 9. PROTOCOLLO P2 10. EVOLUZIONE X.400 VERSO CONVERSIONI PARTE 1: ARCHITETTURA GENERALE DI UN MESSAGE HANDLING SYSTEM 1984 STRUTTURA DEL MESSAGGIO Envelope + Content * La busta (envelope) porta le informazioni che devono essere usate per trasferire i messaggi * Il contenuto (content) è l'informazione che il mittente (Originator) 2 of 10 12/04/

3 vuole sia consegnata ad uno o più destinatari (Recipient) Esiste una notevole analogia tra lo schema dell'x.400 e un normale servizio postale. X.400 non serve però solo per fare Interpersonal Messaging. Possono fungere da Originator e Recipient sia persone che programmi applicativi. La Posta Elettronica per lo scambio dei messaggi interpersonali è solo uno dei possibili utilizzi di X.400. STRUTTURA DEL MESSAGGIO Envelope Content * X.400 Envelope * X.400 Content - submission envelope (P3) - Interpersonal Message - relaying envelope (P1) content type (P2) - delivery envelope (P3) - Messaggio EDI content type (PEDI) => INTERPERSONAL MESSAGE INTERPERSONAL MESSAGE INTERPERSONAL MESSAGE HEADING - contiene informazioni di controllo quali per esempio 3 of 10 12/04/

4 il (i) destinatario(i) del messaggio (to), il soggetto, la priorità... BODY - contiene le informazioni vere e proprie che un utente desidera comunicare. In generale il Body di un IP-message può contenere diversi tipi di informazioni codificate, quali per esempio testo, voce, facsimile e grafica X definisce la struttura dell'envelope content type = P2 X definisce la struttura del content di un Interpersonal Message X definisce le procedure per la conversione di diversi tipi di informazioni codificate TRASFERIMENTO MESSAGGI * la submission e delivery di un messaggio possono aver luogo su di una rete (stabilendo in questo caso una connessione) o direttamente utilizzando una interfaccia locale * un messaggio submitted singolarmente può essere recapitato ad un numero qualsiasi di destinatari, indicati nell'envelope dello stesso. Il Message Transfer Service sarà in grado di spedire il messaggio leggendo le istruzioni fornite dal mittente e contenute nell'envelope * il Message Transfer Service non garantisce in ogni caso la consegna simultanea di messaggi indirizzati a più di un destinatari I PROTOCOLLI X of 10 12/04/

5 P1 - MESSAGE TRANSFER PROTOCOL P2 - INTERPERSONAL MESSAGING PROTOCOL P3 - SUBMISSION & DELIVERY PROTOCOL (solo per UA non co-residenti) MESSAGE TRANSFER SERVICE - il servizio offerto è di tipo Store & Forward - X.400 non fornisce limiti temporali per la delivery, anche se un MTS può offrire un servizio di tipo urgente, non-urgente e normale - Il profilo funzionale CEN-CENELEC è un esempio di proposta di limiti sulla delivery: - messaggi urgenti : 45 minuti - messaggi normali : 4 ore - messaggi non-urgenti : 24 ore USER AGENT (UA) SUBMISSION & DELIVERY - ogni utente ha uno User Agent che si occupa della submission e delivery dei messaggi 5 of 10 12/04/

6 - ogni User Agent ha un MTA che si occupa della gestione di tutti i suoi messaggi MESSAGE HANDLING SYSTEM MESSAGE HANDLING SYSTEM La figura precedente mostra le relazioni esistenti fra entità quali USER, UA e MTA e definisce concetti quali: - MESSAGE TRANSFER SYSTEM (MTS) l'insieme degli MTA che forniscono gli elementi del Message Transfer Service. Il MTS si occuperà del trasferimento dei messaggi qualunque sia il loro contenuto ma solamente fra UA della stessa classe - MESSAGE HANDLING SYSTEM (MHS) l'insieme degli UA della stessa classe e il MTS - MESSAGE HANDLING ENVIRONMENT (MHE) un particolare MHS con l'insieme di tutti gli utenti del servizio SUBMISSION, DELIVERY & NOTIFICATION 6 of 10 12/04/

7 - l'utente può specificare separatamente per ogni destinatario del messaggio la richiesta di: - notifica di mancata ricezione (non delivery report) - notifica di avvenuta ricezione (delivery report) - nessuna notifica (no report) - notifica di avvenuta o non avvenuta ricezione Esistono un certo numero di motivi per i quali un messaggio può non essere stato consegnato: - l'indirizzo del destinatario del messaggio é sbagliato - il tipo di informazioni codificate nel messaggio non sono compatibili con il destinatario finale - il destinatario finale non può essere raggiunto IPM UA / MTA - realizzazioni possibili... MORE ABOUT UA... - nell'esempio tutti gli UA (non-co-residenti) gestiscono tipi diversi di utenti ovvero classi di UA cooperanti - solo UA della stessa classe possono cooperare e quindi comunicare 7 of 10 12/04/

8 - in generale un MTA conosce la classe dei propri UA e pertanto non si dovrebbe verificare che per esempio un IPM message venga spedito ad un UA di tipo EDI MANAGEMENT DOMAINS - un Management Domain (MD) è formato da uno o più MTA con i loro UA gestiti da una sola organizzazione - esistono due tipi di MD: MD Pubblici e MD privati (ADMD - Administration MD e PRMD - Private MD) - il tipo più semplice di MD è formato da un solo MTA con il suo UA associato - la interfaccia di un MD verso altri MD è P1 - MD contenenti più di un MTA mantengono verso l'esterno la stessa interfaccia - P1 - Il trasferimento di messaggi fra MTA all'interno di uno stesso MD non è vincolato ad uno standard particolare, anche se è consigliato l'utilizzo di P1 ADMD & PRMD MANAGEMENT DOMAINS Il concetto di Management Domain riveste una particolare importanza in ambiente MHS. Ogni MD consta di uno o più MTA 8 of 10 12/04/

9 con i loro UA. A livello di standard maggiore importanza rivestono i MD Pubblici (ADMD), in quanto questi domini sono solitamente enti quali le PTT od organizzazioni equivalenti, le quali indubbiamente hanno ruolo e responsabilità diversi (rispetto per esempio ad un qualsiasi ente privato). Una funzionalità che caratterizza un MD pubblico è quella di relaying ossia la capacità da parte degli MTA appartenenti al MD di distribuire i messaggi ricevuti ma non indirizzati a nessuno degli UA associati a quel particolare dominio. Malgrado lo X.400 riservi la funzionalità di relaying ai domini pubblici, ciò nonostante anche un MTA appartenente ad un PRMD può essere in grado di eseguire relay di messaggi. SCAMBIO DI MESSAGGI FRA MD Il concetto di MD può essere esteso in modo da includere qualsiasi ambiente in grado di comunicare con l'esterno utilizzando il protocollo P1. I protocolli per la submission e delivery dei messaggi sono completamente trasparenti agli ambienti esterni. CARENZE DEL MTS - se un messaggio non può essere consegnato entro una certa data (o ora), lo stesso sarà scartato e il mittente informato 9 of 10 12/04/

10 - in questo modo anche un semplice UA deve essere on-line 24 ore su 24 con memoria sufficiente per accettare le notifiche - è necessario l'introduzione di una nuova entità: il Message Store CARENZE DEL MTS - introdotto nella versione 1988 dell'x fornisce un'alternativa alla delivery normale ad uno UA - tutti i messaggi sono raccolti dall'utente finale nel momento per lui più opportuno - soluzione ideale nel caso di utilizzo di workstation non dedicate allo scambio di mail MHS - MODELLO FUNZIONALE VERSIONE of 10 12/04/