e.Toscana Compliance 
Request for Comments: 6 
Del: 04/8/2006 
Categoria: Applicativa
Destinatari: Regione Toscana, Amministrazioni locali 
(Secondo il DPR 445 e il DPCM 31-10-2000, i destinatari sono tutte le
amministrazioni definite dal DL 165/2001)

Protocollo Informatico
 
Indice
------
1. Contesto di riferimento ed obiettivi
2. Integrazione dei sistemi informativi	
3. Interazioni previste tra Enti Locali e Regione
3.1 Tipologie di messaggi
3.2 Scenari di cooperazione
3.2.1 Invio di un messaggio di protocollo
3.2.2 Ricezione di un messaggio di protocollo
3.2.3 Notifiche a seguito della ricezione
4. Formato dei messaggi
4.1. Messaggi di trasporto delle registrazioni di protocollo
4.2. Messaggi di notifica delle registrazioni di protocollo
4.3. Messaggi per la comunicazione con soggetti esterni al CART
4.4. Messaggi per la gestione dell'indice regionale delle AOO
4.5. Messaggio di Acknowledge 
5. Prodotti attesi
6. Bibliografia

1. Contesto di riferimento ed obiettivi
---------------------------------------
La legislazione [N1] definisce il protocollo informatico come "l'insieme delle 
risorse di calcolo, degli apparati, delle reti di comunicazione e delle 
procedure informatiche utilizzati dalle amministrazioni per la gestione dei 
documenti", ovvero, tutte le risorse tecnologiche necessarie alla realizzazione 
di un sistema automatico per la gestione elettronica dei flussi documentali.

In [N2] l'obiettivo dell'attuazione del protocollo informatico  cos 
dichiarato: "promuovere in tutte le amministrazioni centrali e gli enti pubblici 
sottoposti alla vigilanza ministeriale la realizzazione di sistemi informativi 
per la gestione elettronica dei flussi documentali.
Ci allo scopo di assicurare il pi rapido e proficuo utilizzo del documento 
informatico e della firma elettronica negli scambi di documenti ed atti tra 
amministrazioni [...]. Il protocollo informatico e, pi in generale, la gestione 
elettronica dei flussi documentali hanno la finalit di migliorare lefficienza 
interna degli uffici attraverso leliminazione dei registri cartacei, la
riduzione degli uffici di protocollo e la razionalizzazione dei flussi 
documentali. Inoltre con tali sistemi ci si prefigge di migliorare la 
trasparenza dell'azione amministrativa attraverso strumenti che consentano 
laccesso allo stato dei procedimenti ed ai relativi documenti da parte di 
cittadini, imprese ed altre amministrazioni."


2. Integrazione dei sistemi informativi
---------------------------------------
L'interoperabilit dei sistemi informativi  fondamentale affinch sia possibile 
la gestione elettronica e automatica dei flussi documentali, come chiaramente 
affermato da CNIPA:
"Parlando di protocollo informatico non si pu non parlare di interoperabilit 
dei suoi sistemi, termine con cui si intende la possibilit di trattamento 
automatico, da parte di un sistema ricevente, delle informazioni trasmesse da un 
sistema di protocollo mittente, allo scopo di automatizzare anche le attivit e 
i processi amministrativi conseguenti."

La realizzazione della interoperabilit richiede la definizione di modalit di 
trasmissione di dati e documenti, come affermato in [N2]: 
"Il concetto di interoperabilit presuppone quindi che vengano innanzitutto 
stabilite delle modalit di comunicazione di base, ovvero le modalit di 
trasmissione telematica dei documenti sulla rete. Questa scelta, espressa nelle 
regole tecniche, individua nella posta elettronica il mezzo di comunicazione 
comune."

Nel caso di Regione Toscana, la capacit di trasmissione e trattamento 
automatico auspicata dalla normativa  attuata e rafforzata attraverso l'uso 
dell'infrastruttura CART (Cooperazione Applicativa della Regione Toscana).
CART da un lato sostituisce la posta elettronica abilitando lo scambio di 
documenti attraverso servizi di cooperazione applicativa; dall'altro permette 
anche l'integrazione con sistemi di posta certificata che garantiscono la 
trasmissione telematica di documenti con valore legale.

Da un punto di vista architetturale, l'infrastruttura CART abilita la 
cooperazione tra i SIL attraverso la realizzazione di interfacce applicative (
Proxy Applicativi). 
Ogni proxy applicativo presenta una doppia interfaccia: da un lato utilizza i 
servizi infrastrutturali del CART per inviare e ricevere informazione e 
per invocare servizi; dall'altro rende disponibili i servizi ai SIL 
attraverso una molteplicit di interfacce.

Al fine di supportare l'integrazione di sistemi SIL diversi, realizzati in tempi 
diversi e con tecnologie eterogenee, ogni proxy applicativo fornisce una 
descrizione standard di ogni interfaccia esposta ai SIL. Questo riguarda 
aspetti diversi:
- documentazione delle interfacce di servizio in modo standard (es. WSDL)
- rappresentazione dell'informazione scambiata in modo standard (XML come 
indicato nelle linee guida [AP1])
- documentazione del formato dell'informazione scambiata in modo standard 
(XMLSchema)


3. Interazioni previste tra Enti e Regione
------------------------------------------
L'eterogeneit dei sistemi cooperanti, le differenti caratteristiche
organizzative interne del singolo Ente e la dinamicit intrinseca del sistema 
complessivo, richiedono l'adozione di un modello di cooperazione che permetta un 
accoppiamento lasco tra i partecipanti. 
Il modello di cooperazione per eventi del CART soddisfa questa esigenza 
abilitando la cooperazione attraverso scambio asincrono di messaggi. 
Esso individua due ruoli tra i SIL partecipanti:
- Pubblicatore: un SIL assume il ruolo di pubblicatore quando invia eventi (
messaggi) nel sistema; 
- Sottoscrittore: ruolo ricoperto da SIL che comunicano all'infrastruttura 
interesse per un certo tipo di eventi e vengono da questa notificati al loro 
arrivo. 

3.1 Tipologie di messaggi
-------------------------
Nel dominio del Protocollo, si individuano le seguenti tipologie di messaggi:

 -> Messaggi di trasporto delle registrazioni di protocollo
    Trasferiscono documenti e informazione di archiviazione ad essi relativa 
    (si veda [N4]). A questa tipologia appartengono i messaggi seguenti:
    
      - Protocollo-E1 - "Messaggio protocollato":  il messaggio che trasporta 
      il documento informatico primario protocollato in uscita. Include la 
      segnatura informatica che contiene informazioni archivistiche, 
      informazioni sulla struttura del messaggio protocollato  tra le quali la 
      distinzione tra documento primario ed allegati  ed informazioni 
      utilizzabili dalle AOO riceventi per il trattamento dei documenti.
      Nell'implementazione, il messaggio  codificato come una busta SOAP e la 
      segnatura informatica  codificata come attachment part di nome 
      Segnatura.xml che contiene almeno:
         - indicazione o codice dell'amministrazione
         - indicazione o codice della AOO
         - numero di protocollo
         - data di protocollo  
      
      - Protocollo-E2 - "Conferma ricezione" : comunica al mittente l'avvenuta 
      protocollazione in ingresso del messaggio ricevuto. E'inviato dal SIL
      destinatario del "Messaggio protocollato" su esplicita 
      richiesta del mittente. Il messaggio riporta anche alcune informazioni 
      archivistiche aggiuntive, quali lidentificatore della registrazione di 
      protocollo dei documenti ricevuti, come effettuata dal SIL ricevente. 
      Nell'implementazione, una conferma di ricezione  codificata come una 
      busta SOAP che contiene almeno una attachment part avente nome 
      Conferma.xml.

      - Protocollo-E3 - "Notifica eccezione" : ha lo scopo di comunicare al SIL 
      mittente le eventuali anomalie che presenta il messaggio protocollato 
      ricevuto. 
      Nell'implementazione, un messaggio di notifica di eccezione  codificato 
      come una busta SOAP che contiene una attachment part avente nome 
      Eccezione.xml.

      - Protocollo-E4 - "Aggiornamento di Conferma" : comunica il verificarsi, 
      presso il SIL ricevente, di un evento rilevante, successivo alla 
      protocollazione in ingresso. E'inviato su esplicita richiesta del 
      mittente.
      Nell'implementazione, un aggiornamento di conferma  codificato come una 
      busta SOAP che contiene almeno una attachment part avente nome 
      Aggiornamento.xml.

      - Protocollo-E5 - "Annullamento protocollazione" : ha lo scopo di 
      comunicare al SIL mittente lannullamento di una registrazione di 
      protocollo in ingresso effettuata dal SIL ricevente. In questo caso, 
      linvio di un messaggio di annullamento da parte della AOO ricevente  
      obbligatorio, anche qualora il SIL mittente non abbia richiesto la 
      conferma di ricezione. 
      Nell'implementazione, un annullamento di protocollazione  codificato 
      come una busta SOAP che contiene almeno una attachment part avente nome 
      Annullamento.xml.
    
 -> Messaggi di notifica delle registrazioni di protocollo
    Messaggi con cui il sistema (CART) notifica al SIL mittente l'esito del  
    trasporto dei messaggi di protocollo fino al destinatario attraverso l' 
    infrastruttura CART. A questa tipologia appartengono i seguenti messaggi:
    
      - Notifica-E1 - "Messaggio di accettazione" : notifica al SIL lavvenuta 
      presa in carico del messaggio di protocollo da parte del sistema di 
      cooperazione applicativa.
      Im particolare, alla ricezione di un messaggio di protocollo dal SIL, il 
      Proxy Applicativo:
        - compie i controlli formali sul documento;
        - verifica la correttezza degli indirizzi dei destinatari interrogando 
        il server LDAP (invocando un servizio sincrono di consultazione 
        nelle modalit ammesse dal Framework CA);
        - per ogni destinatario, invia una busta e.Toscana al sistema di 
        cooperazione applicativa, utilizzando i metodi messi a disposizione dal 
        Framework CA;

      Se linvio della busta e.Toscana ha esito positivo per tutti i 
      destinatari, il Proxy Applicativo crea un "messaggio di accettazione" 
      (unico a prescindere dal numero di destinatari al quale il messaggio di 
      protocollo  stato inviato) e lo mette a disposizione del SIL mittente (ad 
      es. lo inserisce nel repository degli eventi del SIL mittente)
      Con questo messaggio quindi il proxy notifica al SIL che la pubblicazione 
      del messaggio sul CART  avvenuta con successo per tutti i destinatari.

      - Notifica-E2 - "Messaggio di non accettazione" : con questo messaggio il 
      proxy notifica al SIL che il messaggio di protocollo non pu essere 
      trasmesso a causa di un errore di formato o un errore nell'indirizzo di 
      almeno un destinatario, oppure perch il messaggio non  accettato dalla 
      infrastruttura. 
      In ogni caso il messaggio riporta le motivazioni della non 
      accettazione (ad es. nel caso di un errore nell'indirizzo del destinatario 
      o non accettazione da parte della infrastruttura, il messaggio riporta l'
      elenco dei destinatari per i quali la pubblicazione non  riuscita).
      Il messaggio  unico a prescindere dal numero di destinatari ai quali  
      stato inviato.

      - Notifica-E3 - "Messaggio di avvenuta consegna" : con questo messaggio il 
      proxy destinatario comunica che il messaggio di protocollo  stato 
      trasferito ed  stato consegnato al SIL. 
      Il messaggio viene generato sia quando il destinatario  un Ente che 
      utilizza l'infrastruttura per lo scambio dei messaggi di protocollo, sia 
      quando il destinatario utilizza un altro indirizzo elettronico, ad esempio 
      una casella di posta elettronica certificata. 
      Nel secondo caso il "messaggio di avvenuta consegna" corrisponde alla 
      rielaborazione della "ricevuta di avvenuta consegna" prodotta dal punto di 
      consegna dei sistemi di gestione di posta elettronica certificata.
      Al SIL mittente sar notificato un "messaggio di avvenuta consegna" per 
      ognuno dei destinatari del messaggio di protocollo.

      - Notifica-E4 - "Messaggio di errore di consegna" : messaggio che indica 
      l'impossibilit di consegnare il messaggio al SIL destinatario.
      E'corrispondente alla "ricevuta di errore di consegna" 
      prodotta dai sistemi di gestione di posta elettronica certificata. 
      Nel caso del CART, il messaggio pu essere generato solo se il 
      destinatario non  un Ente che utilizza l'infrastruttura del CART, quindi 
      solo se il destinatario utilizza un altro indirizzo elettronico ad esempio 
      un indirizzo di posta certificata. 
   
 -> Messaggi per la comunicazione con "soggetti esterni al CART".
    Come "soggetti esterni al CART" si intendono:
    
    - Soggetti non pubblici accreditati: cittadini o imprese non dotati di un 
    servizio di posta certificata ma in possesso di un certificato di accesso 
    rilasciato da una autorit di certificazione riconosciuta ed interoperante 
    con l'autorit di certificazione di RTRT;
    
    - Soggetti esterni: 
      - soggetto non pubblico provvisto di firma digitale 
      - soggetto non pubblico che invia comunicazioni attraverso un generico 
      provider di posta certificata 
      - soggetto non pubblico non provvisto di firma digitale 
    
    - Altri:
      - Pubblica Amministrazione che invia messaggi non conformi alla circolare 
      AIPA/CR/28
      - Pubblica Amministrazione che non utilizza sistemi sicuri di trasporto 
      quali la posta elettronica certificata
      
    A questa tipologia appartengono i seguenti messaggi:
  
      - Comunicazione-E1 : "Messaggio anomalia di trasporto"
      Viene inviato da un'apposita applicazione dislocata su CART quando il 
      server di posta certificata di RT riceve una mail da un sistema di posta 
      non certificata oppure quando riceve una mail da un sistema di posta 
      certificata ma falliscono controlli formali (firma non presente o non 
      valida).

      - Comunicazione-E2 : "Comunicazione da soggetto non pubblico accreditato 
      via web"
      Viene generato da un'apposita applicazione dislocata su CART che crea 
      il messaggio a partire dai dati inseriti da un soggetto non pubblico 
      accreditato (in possesso di un certificato rilasciato da una CA 
      riconosciuta da RT) attraverso un'interfaccia web.
      
      - Comunicazione-E3 : "Comunicazione da soggetto non pubblico accreditato 
      via intermediario certificato"
      Viene inviato quando il server di posta certificata di RT riceve una mail  
      inviata da soggetto non pubblico accreditato attraverso un sistema 
      intermediario di posta certificata.

 -> Messaggi per la gestione dell'indice regionale delle AOO
    Messaggi con cui il sistema regionale che gestisce l'indice regionale delle  
    AOO comunica ai SIL variazioni che intervengono sull'indice. Questo permette 
    ai SIL di mantenere allineati gli indici locali (eventualmente presenti) con 
    l'indice regionale.
    
      - AOO-E1 : "IscrizioneAOO" : Notifica ai SIL sottoscrittori linserimento 
      di una nuova AOO nell'indice regionale
    
      - AOO-E2 : "AggiornamentoIAOO" : notifica ai SIL sottoscrittori che  
      avvenuta una modifica sullIndice delle AOO
    
      - AOO-E3 : "AggiornamentoIUO" : notifica ai SIL sottoscrittori la modifica 
      dellIndice delle UO
      
      - AOO-E4 : "Cancellazione AOO": notifica l'eliminazione di una Area 
      Organizzativa Omogenea dall'indice regionale delle AOO.

3.2 Scenari di cooperazione
---------------------------
Si riportano di seguito alcuni tipici scenari di cooperazione che comportano 
lo scambio dei messaggi di protocollo (scenari adattati da [N4]):

3.2.1 Invio di un messaggio di protocollo
-----------------------------------------
1. presso il SIL mittente viene composto un messaggio di Registrazione di 
Protocollo (Protocollo-E1 - "Messaggio protocollato"). Esso includer almeno un 
documento firmato digitalmente, corrispondente al documento primario e la 
segnatura informatica;

2. il messaggio protocollato viene trasmesso dal SIL mittente al proxy 
applicativo di protocollo informatico a cui il SIL afferisce;

3. il proxy pubblica il messaggio sul CART che lo inoltra al proxy destinatario 
(o alla casella di posta elettronica certificata nel caso di comunicazione 
esterna al CART). 

4. Il proxy mittente genera il messaggio di accettazione / non accettazione 
(Notifica-E1, Notifica-E2) a seconda che la pubblicazione sia avvenuta con 
successo o meno per tutti i destinatari e lo mette a disposizione del SIL (ad 
es. archiviandolo nel repository degli eventi del SIL) 

5. Il proxy restituisce al SIL un messaggio di acknowledge.


3.2.2 Ricezione di un messaggio di protocollo
---------------------------------------------
6. Il SIL destinatario chiede la ricezione dei messaggi, il proxy gli consegna 
il messaggio di protocollo. 

7. Il SIL conferma al proxy la corretta ricezione con l'invio di un acknowledge.

8. All'arrivo dell'acknowledge, il proxy pubblica un "Messaggio di avvenuta 
consegna" (Notifica-E3) all'indirizzo del SIL mittente.

NOTA: la ricezione di un messaggio di comunicazione non conforme avviene in modo 
analogo e prevede anch'essa la produzione di un messaggio di avvenuta consegna. 

9a. Se non vengono riscontrate anomalie nel messaggio ricevuto, questo viene 
protocollato in ingresso dal SIL ricevente. 
Qualora richiesto dal SIL mittente, il ricevente crea e invia al proxy un 
messaggio di "Conferma ricezione" (Protocollo-E2).

9b. Nel caso in cui il sistema rilevi delle anomalie nel messaggio ricevuto, 
esso genera ed invia un messaggio di "Notifica eccezione" (Protocollo-E3), 
contenente la descrizione delle anomalie riscontrate.

3.2.3 Notifiche a seguito della ricezione
-----------------------------------------
11. Determinati eventi riguardanti il trattamento presso il SIL ricevente (per 
esempio l'attivazione di un procedimento) possono essere accompagnati da un 
messaggio di "Aggiornamento di conferma" (Protocollo-E4), generato 
automaticamente dal SIL ricevente, qualora ci sia stato richiesto dal mittente.

12. L'eventuale annullamento, a posteriori, della protocollazione comporta l'
invio di un messaggio di "Annullamento protocollazione" (Protocollo-E5) all'
indirizzo del SIL mittente.


4. Formato dei messaggi
-----------------------

4.1. Messaggi di trasporto delle registrazioni di protocollo
------------------------------------------------------------
Un messaggio di trasporto delle registrazioni di protocollo  una busta SOAP che 
contiene:
- un documento informatico primario (codifica MIME/DIME)
- un numero qualsiasi di documenti informatici allegati (codifica MIME/DIME)
- una segnatura informatica (XML definito da Schema o DTD)

Ciascuna parte di un messaggio  codificata come una attachment part, 
univocamente identificata nella struttura MIME che codifica il messaggio. 
La segnatura in particolare  un documento XML che distingue il tipo del 
messaggio (Protocollo-E1/E2/E3/E4/E5) ed  anch'essa inserita in allegato alla 
busta. Il nome dell'allegato  stabilito e riservato: Segnatura.xml, Conferma.
xml, Eccezione.xml, Aggiornamento.xml, Annullamento.xml rispettivamente per i 
messaggi Protocollo-E1,E2,E3,E4,E5.

Il formato della segnatura  definito dalla normativa e pertanto non  riportato 
in questo documento. Per la definizione del formato si faccia riferimento al 
documento [N4]. 

4.2. Messaggi di notifica delle registrazioni di protocollo
-----------------------------------------------------------
Un messaggio di trasporto delle registrazioni di protocollo  una busta SOAP.
Le informazioni del messaggio sono strutturate in XML all'interno del body della 
busta. 
Il formato  unico per tutti i tipi di messaggio: 
il tipo specifico  determinato dal valore dell'attributo "tipo" dell'elemento 
radice ("cartcert") del messaggio XML che pu assumere uno dei seguenti valori:
 - accettazione
 - non_accettazione
 - avvenuta_consegna 
 - errore_di_consegna

Di seguito si riporta la definizione del formato del messaggio attraverso DTD:

<?xml version="1.0" encoding="UTF-8"?>
<!-- L'elemento "cartcert" identifica la radice -->
<!-- Il DTD viene utilizzato per notificare l'esito dell'invio di un messaggio 
nel colloquio tra Proxy Applicativo applicativi nella interoperabilit fra 
Sistemi Informativi Locali nell'ambito della rete regionale toscana -->
<!-- L'attributo "tipo" identifica la tipologia del messaggio di notifica, ed in 
particolare permette di comunicare la accettazione di un messaggio e la avvenuta 
consegna, Il tipo "errore_di_consegna"  gestito solo per la ricezione di un 
messaggio da una AOO esterna  ed  comumque prodotto dal dominio -->
<!-- L'attributo "errore" codifica tutti i possibile errori che si possono 
verificare nell'invio di un messaggio: -->
<!-- "nessuno" = nessun errore -->
<!-- "no-dest" (con tipo="errore_di_consegna") = destinatario errato -->
<!-- "no-conforme" (con tipo="errore_di_consegna" o "non_accettazione") = dtd 
messaggio originale non conforme -->
<!-- "AOO-errata" (con tipo="non_accettazione) = AOO destinataria errata o non 
pi abilitata -->
<!ELEMENT cartcert (intestazione, dati)>
<!ATTLIST cartcert
	tipo (accettazione | non_accettazione | avvenuta_consegna | 
  errore_di_consegna) #REQUIRED
	errore (nessuno | no_dest | no_conforme | AOO_errata | errore_generico) "
  nessuno"
>
<!-- Intestazione del messaggio originale -->
<!ELEMENT intestazione (mittente)>
<!-- Identificativo del mittente del messaggio originale -->
<!ELEMENT mittente (#PCDATA)>
<!-- Dati del messaggio di posta certificata -->
<!ELEMENT dati (idmessaggio, data, consegna*, errore-esteso?)>
<!-- Identificativo interno del messaggio -->
<!ELEMENT idmessaggio (identificativoPA, identificativoAOO, numeroProtocollo, 
Anno)>
<!-- Identificativo della PA -->
<!ELEMENT identificativoPA (#PCDATA)>
<!-- Identificativo della AOO -->
<!ELEMENT identificativoAOO (#PCDATA)>
<!-- Numero di registrazione protocollo -->
<!ELEMENT numeroProtocollo (#PCDATA)>
<!-- Anno espresso nel formato AAAA -->
<!ELEMENT Anno (#PCDATA)>
<!-- Data/ora di elaborazione del messaggio -->
<!ELEMENT data (giorno, ora)>
<!-- Giorno nel formato "aaaa-mm-gg " -->
<!ELEMENT giorno (#PCDATA)>
<!-- Ora locale in formato "hh:mm:ss" -->
<!ELEMENT ora (#PCDATA)>
<!-- Per le ricevute di consegna e di errore di consegna -->
<!-- Destinatario a cui  stata effettuata/tentata la consegna -->
<!ELEMENT consegna (#PCDATA)>
<!-- In caso di errore -->
<!-- Descrizione errore -->
<!ELEMENT errore-esteso (destinatario*)>
<!-- Dati relativi ai destinatari per i quali non  stato possibile consegnare 
il messaggio -->
<!ELEMENT destinatario (indirizzo, motivazione?)>
<!-- Denominazione del destinatario per il quale non  stato possibile 
pubblicare il messaggio sul Framework CA (non accettazione) o del destinatario 
al quale non  stato possibile consegnare il messaggio (errore di consegna) -->
<!ELEMENT indirizzo (#PCDATA)>
<!-- Descrizione estesa relativa all'errore che ha causata la mancata 
accettazione/consegna -->
<!ELEMENT motivazione (#PCDATA)> 

Un esempio di evento XML di notifica di accettazione (Notifica-E1) conforme al 
DTD  il seguente:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cartcert SYSTEM "Notifica_protocollo.dtd" >
<cartcert errore="nessuno" tipo="accettazione">
  <intestazione>
    <mittente>mittente</mittente>
  </intestazione>
  <dati>
    <idmessaggio>
      <identificativoPA>identificativoPA</identificativoPA>
      <identificativoAOO>identificativoAOO</identificativoAOO>
      <numeroProtocollo>numeroProtocollo</numeroProtocollo>
      <Anno>Anno</Anno>
    </idmessaggio>
    <data>
      <giorno>giorno</giorno>
      <ora>ora</ora>
    </data>
    <consegna>consegna</consegna>
    <errore-esteso>
      <destinatario>
        <indirizzo>indirizzo</indirizzo>
        <motivazione>motivazione</motivazione>
      </destinatario>
    </errore-esteso>
  </dati>
</cartcert>


4.3. Messaggi per la comunicazione con soggetti esterni al CART
---------------------------------------------------------------
Un messaggio per la comunicazione con soggetti esterni  una busta SOAP 
che include in allegato il messaggio originario che pu essere: 
- un messaggio errato o di posta ordinaria inviato attraverso un sistema di 
posta certificata
- un messaggio di posta elettronica certificata inviata da un soggetto non 
pubblico accreditato tramite un intermediario certificato
- un messaggio di comunicazione inserito da un soggetto non pubblico accreditato

Il body della busta contiene invece informazioni riepilogative del messaggio 
originale. Questo include anche la distinzione del tipo di messaggio attraverso 
l'attributo "tipologia" dell'elemento radice "nonconforme".
Le informazioni sono strutturate secondo il DTD seguente:

<?xml version="1.0" encoding="UTF-8"?>
<!-- L'elemento "nonconforme" identifica la radice -->
<!-- Il DTD viene utilizzato per notificare i dati riepilogativi del messaggio 
di comunicazione non conforme, ovvero di:
- un messaggio errato o di posta ordinaria inviato a Sistemi Informativi Locali 
nell'ambito della rete regionale toscana attraverso un sistema di posta 
certificata
- un messaggio di posta elettronica certificata inviata da un soggetto non 
pubblico accreditato tramite un intermediario certificato
- un messaggio di comunicazione inserito da un soggetto non pubblico accreditato 
in possesso di un certificato di accesso rilasciato da una autorit di 
certificazione riconosciuta ed interoperante con la CA di Rete Telematica 
Regionale Toscana-->
<!ELEMENT nonconforme (intestazione, dati)>
<!-- Identitica la natura della comunicazione:
- "ANOMTRASP": messaggio errato o di posta ordinaria inviato ad Sistemi 
Informativi Locali nell'ambito della rete regionale toscana attraverso un 
sistema di posta certificata
- "NONPAINT": da soggetto non pubblico accreditato attraverso un sistema 
intermediario di posta certificata
- "NONPAWEB": da soggetto non pubblico accreditato in possesso di un certificato 
di accesso rilasciato da una autorit di certificazione riconosciuta ed 
interoperante con la CA di Rete Telematica Regionale Toscana
 -->
<!ATTLIST nonconforme
	tipologia (ANOMTRASP | NONPAINT | NONPAWEB) #REQUIRED>
<!-- Intestazione del messaggio di comunicazione non conforme -->
<!ELEMENT intestazione (mittente)>
<!-- Identificativo del mittente del messaggio originale -->
<!ELEMENT mittente (#PCDATA)>
<!-- Dati del messaggio di posta certificata -->
<!ELEMENT dati (idmessaggio, data, consegna*, errore-esteso?)>
<!-- Identificativo del messaggio originale  -->
<!ELEMENT idmessaggio (#PCDATA)>
<!-- Identitica se inviare o meno il messaggio di avvenuta protocollazione -->
<!ATTLIST idmessaggio
	avvenutaProtocollazione (noninvio | invio) #REQUIRED>
<!-- Data/ora di elaborazione del messaggio -->
<!ELEMENT data (giorno, ora)>
<!-- Giorno nel formato "aaaa-mm-gg" -->
<!ELEMENT giorno (#PCDATA)>
<!-- Ora locale in formato "hh:mm:ss" -->
<!ELEMENT ora (#PCDATA)>
<!-- Destinatario al quale era indirizzato il messaggio originale  -->
<!ELEMENT consegna (#PCDATA)>
<!-- Descrizione errore -->
<!ELEMENT errore-esteso (#PCDATA)>

Un esempio di evento XML di comunicazione conforme al DTD  il seguente:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE nonconforme SYSTEM "Comunicazione_Non_Conforme.dtd" >
<nonconforme tipologia="ANOMTRASP">
  <intestazione>
    <mittente>mittente</mittente>
  </intestazione>
  <dati>
    <idmessaggio avvenutaProtocollazione="noninvio">idmessaggio</idmessaggio>
    <data>
      <giorno>giorno</giorno>
      <ora>ora</ora>
    </data>
    <consegna>consegna</consegna>
    <errore-esteso>errore-esteso</errore-esteso>
  </dati>
</nonconforme>


4.4. Messaggi per la gestione dell'indice regionale delle AOO
-------------------------------------------------------------
I messaggi per la gestione dell'indice regionale delle AOO sono codificati come 
buste SOAP che presentano nell'header un tag che identifica l'evento e nella 
body part il contenuto xml dipendente dal tipo di evento.

Il formato  diverso per le quattro tipologie di messaggio riportate in sezione 
3.1:

- AOO-E1 : "IscrizioneAOO" 
==========================
Notifica ai SIL sottoscrittori linserimento di una nuova AOO nell'indice 
regionale. Il formato del messaggio  definito dal DTD seguente:

<?xml version="1.0" encoding="UTF-8"?>
<!-- L'elemento "IscrizioneAOO" identifica la radice -->
<!-- Il DTD viene utilizzato per richiedere l'iscrizione di una AOO -->
<!ELEMENT IscrizioneAOO (AOO, description, mail, nomeSIL?, webserviceVisura?, 
nomeResp?, cognomeResp?, mailResp?, telephonenumberResp?, dataistituzione, 
datasoppressione?, CAurl?, telephoneNumber?, facsimiletelephonenumber?, l?, 
street?, postalcode?, regione?, provincia?, codiceuff*, servizio*)> 
<!-- Codice Area Organizzativa Omogenea -->
<!ELEMENT AOO (#PCDATA)>
<!-- Nome esteso amministrazione -->
<!ELEMENT description (#PCDATA)>
<!-- Indirizzo e-mail istituzionale AOO: indirizzo della casella "istituzionale" 
di posta elettronica associato alla AOO. -->
<!ELEMENT mail (#PCDATA)>
<!--Nome del SIL cui afferisce la AOO-->
<!ELEMENT nomeSIL (#PCDATA)>
<!--URL del webservice per le visure-->
<!ELEMENT webserviceVisura (#PCDATA)>
<!-- Nome referente -->
<!ELEMENT nomeResp (#PCDATA)>
<!-- Cognome referente -->
<!ELEMENT cognomeResp (#PCDATA)>
<!-- Indirizzo e-mail referente -->
<!ELEMENT mailResp (#PCDATA)>
<!-- Numero telefono referente -->
<!ELEMENT telephonenumberResp (#PCDATA)>
<!-- Data istituzione nel formato AAAA-MM-GG -->
<!ELEMENT dataistituzione (#PCDATA)>
<!-- Data soppressione nel formato AAAA-MM-GG -->
<!ELEMENT datasoppressione (#PCDATA)>
<!-- URL CA emittente certificato: collegamento alla Certification Authority per 
la verifica della validit dei certificati
da utilizzare per l'accesso ai servizi protetti -->
<!ELEMENT CAurl (#PCDATA)>
<!-- Numero di telefono -->
<!ELEMENT telephoneNumber (#PCDATA)>
<!-- Numero fax -->
<!ELEMENT facsimiletelephonenumber (#PCDATA)>
<!-- Denominazione Citt sede legale amministrazione -->
<!ELEMENT l (#PCDATA)>
<!-- Indirizzo sede legale amministrazione -->
<!ELEMENT street (#PCDATA)>
<!-- CAP sede legale amministrazione -->
<!ELEMENT postalcode (#PCDATA)>
<!-- Denominazione Regione di appartenenza sede legale -->
<!ELEMENT regione (#PCDATA)>
<!-- Denominazione Provincia di appartenenza sede legale -->
<!ELEMENT provincia (#PCDATA)>
<!-- Codice Ufficio -->
<!ELEMENT codiceuff (#PCDATA)>
<!-- Dati servizio -->
<!ELEMENT servizio (nomes, descriziones, fruibs, servizioTelematico, mailS, 
telephonenumbers)>
<!-- Nome servizio -->
<!ELEMENT nomes (#PCDATA)>
<!-- Descrizione servizio -->
<!ELEMENT descriziones (#PCDATA)>
<!-- Fruibilit da internet del servizio -->
<!ELEMENT fruibs (#PCDATA)>
<!-- URL Servizio -->
<!ELEMENT servizioTelematico (#PCDATA)>
<!-- Indirizzo e-mail servizio -->
<!ELEMENT mailS (#PCDATA)>
<!-- Numero di telefono servizio -->
<!ELEMENT telephonenumbers (#PCDATA)>

Un esempio di evento XML IscrizioneAOO conforme al DTD  il seguente:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE IscrizioneAOO SYSTEM "Iscrizione_AOO.dtd" >
<IscrizioneAOO>
  <AOO>AOO</AOO>
  <description>description</description>
  <mail>mail</mail>
  <nomeSIL>nomeSIL</nomeSIL>
  <webserviceVisura>webserviceVisura</webserviceVisura>
  <nomeResp>nomeResp</nomeResp>
  <cognomeResp>cognomeResp</cognomeResp>
  <mailResp>mailResp</mailResp>
  <telephonenumberResp>telephonenumberResp</telephonenumberResp>
  <dataistituzione>dataistituzione</dataistituzione>
  <datasoppressione>datasoppressione</datasoppressione>
  <CAurl>CAurl</CAurl>
  <telephoneNumber>telephoneNumber</telephoneNumber>
  <facsimiletelephonenumber>facsimiletelephonenumber</facsimiletelephonenumber>
  <l>l</l>
  <street>street</street>
  <postalcode>postalcode</postalcode>
  <regione>regione</regione>
  <provincia>provincia</provincia>
  <codiceuff>codiceuff</codiceuff>
  <servizio>
    <nomes>nomes</nomes>
    <descriziones>descriziones</descriziones>
    <fruibs>fruibs</fruibs>
    <servizioTelematico>servizioTelematico</servizioTelematico>
    <mailS>mailS</mailS>
    <telephonenumbers>telephonenumbers</telephonenumbers>
  </servizio>
</IscrizioneAOO>

    
- AOO-E2 : "AggiornamentoIAOO"
==============================
Notifica ai SIL sottoscrittori che  avvenuta una modifica sull'Indice delle AOO
Il formato del messaggio  definito dal DTD seguente:
    
<?xml version="1.0" encoding="UTF-8"?>
<!-- L'elemento "AggiornamentoIAOO" identifica la radice -->
<!-- Il DTD viene utilizzato per richiedere l'iscrizione di una AOO -->
<!ELEMENT AggiornamentoIAOO (AOO, description, mail, nomeSIL?, webserviceVisura?
, nomeResp?, cognomeResp?, mailResp?, telephonenumberResp?, dataistituzione, 
datasoppressione?, CAurl?, telephoneNumber?, facsimiletelephonenumber?, l?, 
street?, postalcode?, regione?, provincia?, codiceuff*, servizio*)> 
<!-- Codice Area Organizzativa Omogenea -->
<!ELEMENT AOO (#PCDATA)>
<!-- Nome esteso amministrazione -->
<!ELEMENT description (#PCDATA)>
<!-- Indirizzo e-mail istituzionale AOO: indirizzo della casella "istituzionale" 
di posta elettronica associato alla AOO. -->
<!ELEMENT mail (#PCDATA)>
<!--Nome del SIL cui afferisce la AOO-->
<!ELEMENT nomeSIL (#PCDATA)>
<!--URL del webservice per le visure-->
<!ELEMENT webserviceVisura (#PCDATA)>
<!-- Nome referente -->
<!ELEMENT nomeResp (#PCDATA)>
<!-- Cognome referente -->
<!ELEMENT cognomeResp (#PCDATA)>
<!-- Indirizzo e-mail referente -->
<!ELEMENT mailResp (#PCDATA)>
<!-- Numero telefono referente -->
<!ELEMENT telephonenumberResp (#PCDATA)>
<!-- Data istituzione nel formato AAAA-MM-GG -->
<!ELEMENT dataistituzione (#PCDATA)>
<!-- Data soppressione nel formato AAAA-MM-GG -->
<!ELEMENT datasoppressione (#PCDATA)>
<!-- URL CA emittente certificato: collegamento alla Certification Authority per 
la verifica della validit dei certificati
da utilizzare per l'accesso ai servizi protetti -->
<!ELEMENT CAurl (#PCDATA)>
<!-- Numero di telefono -->
<!ELEMENT telephoneNumber (#PCDATA)>
<!-- Numero fax -->
<!ELEMENT facsimiletelephonenumber (#PCDATA)>
<!-- Denominazione Citt sede legale amministrazione -->
<!ELEMENT l (#PCDATA)>
<!-- Indirizzo sede legale amministrazione -->
<!ELEMENT street (#PCDATA)>
<!-- CAP sede legale amministrazione -->
<!ELEMENT postalcode (#PCDATA)>
<!-- Denominazione Regione di appartenenza sede legale -->
<!ELEMENT regione (#PCDATA)>
<!-- Denominazione Provincia di appartenenza sede legale -->
<!ELEMENT provincia (#PCDATA)>
<!-- Codice Ufficio -->
<!ELEMENT codiceuff (#PCDATA)>
<!-- Dati servizio -->
<!ELEMENT servizio (nomes, descriziones, fruibs, servizioTelematico, mailS, 
telephonenumbers)>
<!-- Nome servizio -->
<!ELEMENT nomes (#PCDATA)>
<!-- Descrizione servizio -->
<!ELEMENT descriziones (#PCDATA)>
<!-- Fruibilit da internet del servizio -->
<!ELEMENT fruibs (#PCDATA)>
<!-- URL Servizio -->
<!ELEMENT servizioTelematico (#PCDATA)>
<!-- Indirizzo e-mail servizio -->
<!ELEMENT mailS (#PCDATA)>
<!-- Numero di telefono servizio -->
<!ELEMENT telephonenumbers (#PCDATA)>

Un esempio di evento XML AggiornamentoIAOO conforme al DTD  il seguente:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE AggiornamentoIAOO SYSTEM "Aggiornamento_IAOO.dtd" >
<AggiornamentoIAOO>
  <AOO>AOO</AOO>
  <description>description</description>
  <mail>mail</mail>
  <nomeSIL>nomeSIL</nomeSIL>
  <webserviceVisura>webserviceVisura</webserviceVisura>
  <nomeResp>nomeResp</nomeResp>
  <cognomeResp>cognomeResp</cognomeResp>
  <mailResp>mailResp</mailResp>
  <telephonenumberResp>telephonenumberResp</telephonenumberResp>
  <dataistituzione>dataistituzione</dataistituzione>
  <datasoppressione>datasoppressione</datasoppressione>
  <CAurl>CAurl</CAurl>
  <telephoneNumber>telephoneNumber</telephoneNumber>
  <facsimiletelephonenumber>facsimiletelephonenumber</facsimiletelephonenumber>
  <l>l</l>
  <street>street</street>
  <postalcode>postalcode</postalcode>
  <regione>regione</regione>
  <provincia>provincia</provincia>
  <codiceuff>codiceuff</codiceuff>
  <servizio>
    <nomes>nomes</nomes>
    <descriziones>descriziones</descriziones>
    <fruibs>fruibs</fruibs>
    <servizioTelematico>servizioTelematico</servizioTelematico>
    <mailS>mailS</mailS>
    <telephonenumbers>telephonenumbers</telephonenumbers>
  </servizio>
</AggiornamentoIAOO>

    
- AOO-E3 : "AggiornamentoIUO"
=============================
Notifica ai SIL sottoscrittori la modifica dell'Indice delle UO
Il formato del messaggio  definito dal DTD seguente:
      
<?xml version="1.0" encoding="UTF-8"?>
<!-- L'elemento "AggiornamentoIUO" identifica la radice -->
<!-- Il DTD viene utilizzato per richiedere l'aggiornamento dell'Indice delle 
Unit Organizzative  -->
<!ELEMENT AggiornamentoIUO (ou, description, dn?, aooref?, mail?, st?, CAurl?, 
telephoneNumber?, facsimiletelephonenumber?, l?, street?, postalcode?, regione?, 
provincia?, nomeResp?, cognomeResp?, mailResp?, telephonenumberResp?, servizio*)
>
 <!-- Codice ufficio -->
<!ELEMENT ou (#PCDATA)>
<!-- Nome ufficio -->
<!ELEMENT description (#PCDATA)>
<!-- Codice dell'Unit Organizzativa (ufficio, divisione, direzione, 
dipartimento) di appartenenza -->
<!ELEMENT dn (#PCDATA)>
<!-- Codice dell'Area Organizzativa Omogena a cui l'unit fa riferimento per il 
protocollo informatico -->
<!ELEMENT aooref (#PCDATA)>
<!-- Indirizzo e-mail ufficio: se di posta elettronica certificata deve fare 
riferimento al dominio di posta elettronica certificata dell'amministrazione -->
<!ELEMENT mail (#PCDATA)>
<!-- Casella di posta elettronica certificata: indicare "SI" se l'indirizzo 
specificato nel campo "mail" fa riferimento ad una casella di posta elettronica 
certificata, "NO" altrimenti;  obbligatorio se il campo "mail"  valorizzato --
>
<!ELEMENT st (#PCDATA)>
<!-- URL Certification Autority emittente certificato -->
<!ELEMENT CAurl (#PCDATA)>
<!-- Numero di telefono -->
<!ELEMENT telephoneNumber (#PCDATA)>
<!-- Numero di fax -->
<!ELEMENT facsimiletelephonenumber (#PCDATA)>
<!-- Denominazione Citt -->
<!ELEMENT l (#PCDATA)>
<!-- Indirizzo -->
<!ELEMENT street (#PCDATA)>
<!-- CAP sede  -->
<!ELEMENT postalcode (#PCDATA)>
<!-- Denominazione regione -->
<!ELEMENT regione (#PCDATA)>
<!-- Denominazione provincia -->
<!ELEMENT provincia (#PCDATA)>
<!-- Nome responsabile -->
<!ELEMENT nomeResp (#PCDATA)>
<!-- Cognome responsabile -->
<!ELEMENT cognomeResp (#PCDATA)>
<!-- Indirizzo e-mail del responsabile -->
<!ELEMENT mailResp (#PCDATA)>
<!-- Numero di telefono responsabile -->
<!ELEMENT telephonenumberResp (#PCDATA)>
<!-- Dati sul servizio -->
<!ELEMENT servizio (nomeS, descrizioneS, fruibS, servizioTelematico, mailS, 
telephonenumberS)>
<!-- Nome servizio -->
<!ELEMENT nomeS (#PCDATA)>
<!-- Descrizione servizio -->
<!ELEMENT descrizioneS (#PCDATA)>
<!-- Fruibilit da internet del servizio -->
<!ELEMENT fruibS (#PCDATA)>
<!-- URL Servizio -->
<!ELEMENT servizioTelematico (#PCDATA)>
<!-- Indirizzo e-mail referente servizio -->
<!ELEMENT mailS (#PCDATA)>
<!-- Numero di telefono referente servizio -->
<!ELEMENT telephonenumberS (#PCDATA)>

Un esempio di evento XML AggiornamentoIUO conforme al DTD  il seguente:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE AggiornamentoIUO SYSTEM "Aggiornamento_IUO.dtd" >
<AggiornamentoIUO>
  <ou>ou</ou>
  <description>description</description>
  <dn>dn</dn>
  <aooref>aooref</aooref>
  <mail>mail</mail>
  <st>st</st>
  <CAurl>CAurl</CAurl>
  <telephoneNumber>telephoneNumber</telephoneNumber>
  <facsimiletelephonenumber>facsimiletelephonenumber</facsimiletelephonenumber>
  <l>l</l>
  <street>street</street>
  <postalcode>postalcode</postalcode>
  <regione>regione</regione>
  <provincia>provincia</provincia>
  <nomeResp>nomeResp</nomeResp>
  <cognomeResp>cognomeResp</cognomeResp>
  <mailResp>mailResp</mailResp>
  <telephonenumberResp>telephonenumberResp</telephonenumberResp>
  <servizio>
    <nomeS>nomeS</nomeS>
    <descrizioneS>descrizioneS</descrizioneS>
    <fruibS>fruibS</fruibS>
    <servizioTelematico>servizioTelematico</servizioTelematico>
    <mailS>mailS</mailS>
    <telephonenumberS>telephonenumberS</telephonenumberS>
  </servizio>
</AggiornamentoIUO>
     
      
- AOO-E4 : "Cancellazione AOO" 
==============================
notifica l'eliminazione di una Area Organizzativa Omogenea dall'indice regionale 
delle AOO.

..............


4.5. Messaggio di Acknowledge 
-----------------------------
In riferimento agli scenari di cooperazione illustrati in sezione 3.2, il 
messaggio di acknowledge  il messaggio XML scambiato tra Proxy Applicativo e 
SIL per comunicare l'esito dell'invio o ricezione di un messaggio.

Il formato del messaggio  documentato dal DTD seguente:

<?xml version="1.0" encoding="UTF-8"?>
<!--
L'elemento acknowledgement identifica la radice.
Il DTD viene utilizzato per comunicare l'esito dell'invio o ricezione di un 
busta soap  tra Proxy Applicativo e SIL evoluto.
-->
<!ELEMENT acknowledgement (codice, descrizione?)>
<!--
L'elemento codice  identifica il numero di codice di errore dell'invio di un 
busta soap. 
-->
<!ELEMENT codice (#PCDATA)>
<!--
L'attritbuto esito identifica conferma l'invio di un busta soap nel seguente 
modo: 
 SI = esito positivo , codice 0
NO = esito negativo i codice sono da definire.
-->
<!ATTLIST codice	esito (SI | NO) "SI">
<!--
L'elemento descrizione  identifica conferma l'invio di un busta soap.
-->
<!ELEMENT descrizione (#PCDATA)>


Un esempio di evento XML di Acknowledge conforme al DTD  il seguente:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE acknowledgement SYSTEM "Acknowledge.dtd" >
<acknowledgement>
  <codice esito="SI">codice</codice>
  <descrizione>descrizione</descrizione>
</acknowledgement>


4. Prodotti attesi
------------------



5. Bibliografia
---------------
Documenti rilasciati dal Centro Nazionale per lInformatica nella Pubblica
Amministrazione (AIPA-CNIPA):
[AP1] AIPA, "Servizio di cooperazione applicativa basata su eventi", Quaderni 
AIPA Dicembre 1999 
[CN1] SPC, Sistema pubblico di cooperazione: Architettura, Versione 1.0, 
CNIPA, 25 Novembre 2004. 
[CN2] SPC, Sistema pubblico di cooperazione: Porta di Dominio, Versione 1.0, 
CNIPA, 14 Ottobre 2005

Documenti rilasciati dal W3C:
[W1] D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. F. Nielsen,
S. Thatte, D. Winer, Simple Object Access Protocolo (SOAP) 1.1, W3C, 8 Maggio
2000 
[W2] E. Christensen, F. Curbera, G. Meredith, S. Weerawarena, Web Services
Description Language (WSDL) 1.1, W3C, 15 Marzo 200

Normativa di riferimento
[N1] DECRETO DEL PRESIDENTE DELLA REPUBBLICA 28 dicembre 2000, n. 445  
"Disposizioni legislative in materia di documentazione amministrativa. (Testo A)
." pubblicato nella Gazzetta Ufficiale n. 42 del 20 febbraio 2001- Supplemento 
ordinario n. 30
[N2] "Direttiva sulla trasparenza dell'azione amministrativa e gestione 
elettronica dei flussi documentali", Ministero per l'innovazione e le 
tecnologie, 9 Dicembre 2002
[N3] "L'interoperabilit dei sistemi di protocollo informatico in ambiente 
distribuito", AIPA, 18 Ottobre 2000
[N4] Circolare AIPA 7 maggio 2001, n. 28, Articolo 18, comma 2, del decreto del 
Presidente del Consiglio dei ministri 31 ottobre 2000, pubblicato nella Gazzetta 
Ufficiale 21 novembre 2000, n. 272, recante regole tecniche per il protocollo 
informatico di cui al decreto del Presidente della Repubblica 28 dicembre 2000, 
n.445 - Standard, modalit di trasmissione, formato e definizioni dei tipi di 
informazioni minime ed accessorie comunemente scambiate tra le pubbliche 
amministrazioni e associate ai documenti protocollati.
