Source: http://www.interlex.it/testi/aipacr28.htm
Timestamp: 2017-12-12 06:30:43+00:00

Document:
Circolare AIPA CR/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
Per interoperabilità dei sistemi di protocollo informatico si intende la possibilità di trattamento automatico, da parte di un sistema di protocollo ricevente, delle informazioni trasmesse da un sistema di protocollo mittente, allo scopo di automatizzare altresì le attività ed i processi amministrativi conseguenti (articolo 55, comma 4, del decreto del Presidente della Repubblica 28 dicembre 2000, n. 445, ed articolo 15 del decreto del Presidente del Consiglio dei ministri 31 ottobre 2000, pubblicato nella Gazzetta Ufficiale del 21 novembre 2000, n. 272).
Per realizzare l'interoperabilità dei sistemi di protocollo informatico gestiti dalle pubbliche amministrazioni distribuite sul territorio è necessario, in primo luogo, stabilire una modalità di comunicazione comune, che consenta la trasmissione telematica dei documenti sulla rete. Ai sensi del D.P.C.M. 31 ottobre 2000, il mezzo di comunicazione telematica di base è la posta elettronica, con l'impiego del protocollo SMTP e del formato MIME per la codifica dei messaggi. Per le amministrazioni che sottoscrivono il contratto di interoperabilità alla Rete unitaria nella pubblica amministrazione, il servizio di posta elettronica da utilizzare per l'interscambio di documenti soggetti alla registrazione di protocollo, è quello offerto dal fornitore del servizio di interoperabilità il quale è tenuto al rispetto del protocollo sopra richiamato ed alla gestione dei messaggi in formato MIME.
Oltre ad una modalità di comunicazione comune, l'interoperabilità dei sistemi di protocollo richiede anche una efficace interazione dei sistemi di gestione documentale. In questo senso, le regole tecniche di cui al D.P.C.M. 31 ottobre 2000 stabiliscono che ogni messaggio di posta elettronica protocollato debba riportare alcune informazioni archivistiche fondamentali, per facilitare il trattamento dei documenti da parte del ricevente. Tali informazioni sono incluse nella segnatura informatica di ciascun messaggio protocollato e sono codificate in formato XML.
Con la presente circolare, resa disponibile anche sul sito internet dell'Autorità per l'informatica http://www.aipa.it, vengono indicati, secondo quanto prescrive l'articolo 18, comma 2, del D.P.C.M. 31 ottobre 2000, le modalità di trasmissione dei documenti informatici, il tipo ed il formato delle informazioni archivistiche di protocollo minime ed accessorie comunemente scambiate tra le pubbliche amministrazioni e associate ai messaggi di posta elettronica protocollati. Per la sua redazione, l'Autorità si è avvalsa della collaborazione di diverse pubbliche amministrazioni, che hanno individuato attraverso l'esperienza maturata durante la progettazione e la messa in esercizio dei propri sistemi di protocollo informatico diversi problemi operativi e hanno fornito corrispondenti suggerimenti solutivi.
Le modalità tecniche ed il formato definiti verranno adeguati con cadenza annuale, in relazione all'evoluzione tecnologica e alle eventuali ulteriori esigenze che le amministrazioni dovessero manifestare a seguito della loro applicazione. Roma, 7 maggio 2001
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.
Al fine di agevolare la lettura, vengono riportate le definizioni di alcuni termini utilizzati. AOO: Area Organizzativa Omogenea è un insieme definito di unità organizzative di una amministrazione, che usufruiscono, in modo omogeneo e coordinato, di comuni servizi per la gestione dei flussi documentali. In particolare, ciascuna AOO mette a disposizione delle unità organizzative clienti il servizio di protocollazione dei documenti in entrata ed in uscita, utilizzando una unica sequenza numerica, rinnovata ad ogni anno solare, propria alla AOO stessa.
Casella istituzionale: la casella di posta elettronica istituita da una AOO, attraverso la quale vengono ricevuti i messaggi protocollati (D.P.C.M. 31 ottobre 2000, articolo 15, comma 3).
Firma digitale: la firma digitale intestata ad una persona fisica, la cui coppia di chiavi è stata pubblicamente certificata ai sensi del D.P.R. n. 445/2000.
Identificatore di prima registrazione di un documento protocollato: le informazioni identificative di registrazione associate ad un documento, originariamente formato all'esterno della pubblica amministrazione, all'atto della sua prima protocollazione in ingresso; nel caso di un documento formato all'interno di una pubblica amministrazione, le informazioni identificative di registrazione associate al documento all'atto della sua protocollazione in uscita.
Informazioni identificative di registrazione: le informazioni specificate nell'articolo 9, comma 1, del D.P.C.M. 31 ottobre 2000, che identificano una registrazione di protocollo.
Manuale di gestione: il documento che descrive il sistema di gestione e conservazione di documenti di una AOO (D.P.C.M. 31 ottobre 2000, articolo 5).
Messaggio di aggiornamento di conferma: un messaggio che contiene una comunicazione di aggiornamento, riguardante un messaggio protocollato ricevuto in precedenza.
Messaggio di annullamento di protocollazione: un messaggio che contiene la comunicazione di annullamento di una protocollazione in ingresso di un messaggio ricevuto in precedenza.
Messaggio di conferma di ricezione: un messaggio che contiene la conferma della avvenuta protocollazione, in ingresso, di un messaggio protocollato da una AOO ricevente. Un messaggio di conferma di ricezione si differenzia da altre forme di ricevuta di consegna generate dal servizio telematico di posta elettronica in quanto segnala l'avvenuta protocollazione del messaggio e, quindi, la sua effettiva presa in carico, da parte dell'amministrazione ricevente e non il semplice recapito del messaggio presso la casella di posta elettronica del destinatario.
Messaggio di notifica di eccezione: un messaggio che notifica la rilevazione di una anomalia in un messaggio ricevuto.
Messaggio protocollato: un messaggio inviato da una AOO mittente per il quale esiste una corrispondente registrazione di protocollo in uscita.
Messaggio: un generico messaggio di posta elettronica.
Normativa sul documento informatico: l'impianto normativo che regolamenta la formazione dei documenti informatici da parte delle pubbliche amministrazioni e in particolare: il D.P.R. n. 445/2000, il D.P.C.M. 8 febbraio 1999, il D.P.C.M. 31 ottobre 2000, la circolare dell'Autorità per l'informatica AIPA/CR/24 del 19 giugno 2000, recante specifiche tecniche per l'interoperabilità tra certificatori e la delibera AIPA 23 novembre 2000, n. 51, recante regole tecniche in materia di formazione e conservazione di documenti informatici delle pubbliche amministrazioni ai sensi dell'articolo 9, comma 4, del D.P.R. n. 445/2000.
Segnatura informatica: l'insieme delle informazioni archivistiche di protocollo, codificate in formato XML ed incluse in un messaggio protocollato, come previsto dall'articolo 18, comma 1, del D.P.C.M. 31 ottobre 2000.
Sistema di gestione informatica dei documenti (abbr. sistema informatico): l'insieme delle risorse fisiche, delle reti di comunicazione e dei sistemi software utilizzato e gestito da un'amministrazione o unità organizzativa per il supporto alle attività amministrative (D.P.R. n. 445/2000, articolo 1).
Sistema informatico mittente: il sistema informatico di una AOO che riveste il ruolo di mittente di messaggi di posta elettronica.
Sistema informatico ricevente: un sistema informatico di una AOO che riveste il ruolo di ricevente di messaggi di posta elettronica. Più precisamente, il sistema informatico ricevente gestisce la casella istituzionale della AOO cui appartiene (D.P.C.M. 31 ottobre 2000, articolo 15,comma 3).
2. Composizione dei messaggi protocollati
a) un documento informatico primario;
b) un numero qualsiasi di documenti informatici allegati; c) una segnatura informatica.
Il documento informatico primario, inviato da una AOO di una amministrazione ad una AOO di diversa amministrazione, deve essere sottoscritto secondo le norme stabilite dal D.P.R. n. 445/2000. I documenti informatici allegati che compongono il messaggio o i documenti primari riguardanti scambi tra AOO della stessa amministrazione possono, eventualmente, essere sottoscritti secondo le modalità indicate all'articolo 5 della delibera AIPA 23 novembre 2000, n. 51. Ciascuna amministrazione indica nel manuale di gestione le tipologie di documenti informatici - diversi da quelli primari destinati ad altra amministrazione - per i quali è prevista l'apposizione di una firma digitale, quelle per le quali non è prevista sottoscrizione e quelle a rilevanza interna, per le quali sono ammesse firme digitali difformi da quanto previsto dal D.P.R. n. 445/2000.
L'elenco delle tipologie di documenti che devono essere obbligatoriamente sottoscritti per consentirne la protocollazione in uscita e i ruoli amministrativi che hanno facoltà di firma sono indicati nel manuale di gestione e sono resi disponibili dalle pubbliche amministrazioni ai propri uffici di protocollo anche in formato elettronico, per l'elaborazione automatica. Il grado di completezza e dettaglio con il quale predisporre l'elenco precedente viene valutato dalle amministrazioni con riguardo alla complessità organizzativa che tale adempimento comporta.
Il controllo della validità amministrativa della firma è di responsabilità dell'amministrazione mittente. In particolare, è responsabilità del sistema di protocollo mittente verificare, prima di procedere alla protocollazione in uscita di un messaggio, che il documento primario rechi una sottoscrizione valida sotto il profilo amministrativo, ossia che il soggetto sottoscrittore abbia la facoltà di firmare il documento, in relazione al ruolo svolto ed alla tipologia di atto sottoscritto.
Nella segnatura informatica sono contenute 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.
Alcune informazioni archivistiche fondamentali devono essere obbligatoriamente riportate nella segnatura informatica, mentre altre restano opzionali. Le informazioni fondamentali includono l'identificatore della registrazione di protocollo in uscita, effettuata dal sistema di protocollo informatico della AOO mittente, e quelle che consentono di interpretare correttamente l'organizzazione ed il contenuto del messaggio dal punto di vista amministrativo.
Tutte le informazioni contenute nella segnatura dovranno essere conservate nel sistema di gestione dei documenti della AOO mittente e, limitatamente alle informazioni effettivamente trattate, in quello delle AOO destinatarie.
3. Scambio di messaggi protocollati tra AOO
Il processo di trasmissione di un messaggio di posta elettronica tra due AOO si svolge secondo il seguente schema di base:
a) presso il sistema informatico mittente viene formato un messaggio di posta elettronica. Se destinato ad altra amministrazione, esso includerà almeno un documento firmato digitalmente, corrispondente al documento primario;
b) il sistema di protocollo mittente effettua la verifica amministrativa sulle sottoscrizioni presenti nei documenti trasmessi. La protocollazione in uscita viene effettuata solo se tale verifica ha esito positivo;
c) il messaggio viene protocollato in uscita ed in esso viene inclusa la segnatura informatica; d) il messaggio protocollato viene trasmesso dal sistema informatico mittente al sistema di posta elettronica;
e) il sistema di posta elettronica trasmette il messaggio protocollato al sistema informatico ricevente;
f) il messaggio viene protocollato in ingresso dal sistema informatico ricevente. La registrazione viene effettuata utilizzando le informazioni provenienti dalla AOO mittente contenute nella segnatura informatica. Qualora richiesto dalla AOO mittente, il sistema informatico ricevente crea e invia un messaggio di conferma di ricezione;
g) nel caso in cui il sistema rilevi delle anomalie nel messaggio ricevuto, esso genera ed invia un messaggio di notifica di eccezione, contenente la descrizione delle anomalie riscontrate;
h) i documenti informatici contenuti nel messaggio vengono avviati al trattamento presso le unità organizzative o presso gli uffici utenti della AOO ricevente. Ciascuna AOO ricevente stabilisce se e come utilizzare le informazioni opzionali contenute nella segnatura per automatizzare i processi di assegnazione e trattamento dei documenti (le possibili scelte della AOO sulle modalità di trattamento delle informazioni opzionali dovranno, comunque, essere riportate nel manuale di gestione);
i) determinati eventi riguardanti il trattamento presso la AOO ricevente (per esempio, l'attivazione di un procedimento) possono essere accompagnati da un messaggio di aggiornamento, generato automaticamente dal sistema informatico ricevente, qualora ciò sia richiesto dalla AOO mittente;
l) l'eventuale annullamento, a posteriori, della protocollazione viene seguito da un messaggio di comunicazione dell'annullamento stesso alla AOO mittente, il quale viene generato automaticamente dal sistema informatico ricevente.
Un messaggio di posta elettronica può contenere riferimenti esterni a documenti informatici reperibili per via telematica, ovvero a documenti cartacei inviati parallelamente al messaggio protocollato con strumenti tradizionali. Tali riferimenti esterni possono riguardare sia il documento primario che i documenti allegati.
4. Formato di codifica
Come stabilito dall'articolo 15, comma 1, del D.P.C.M. 31 ottobre 2000, i messaggi scambiati tra le AOO devono essere compatibili con i sistemi di posta elettronica che adottano lo standard SMTP, descritto nelle specifiche pubbliche RFC 821 e RFC 822.
I dati contenuti nell'intestazione SMTP, ad esempio la data di invio e il mittente, non sono significativi ai fini del trattamento automatico delle informazioni, che sarà svolto dalla AOO destinataria esclusivamente attraverso l'elaborazione della segnatura informatica.
I messaggi sono codificati in base allo standard MIME, descritto nelle specifiche pubbliche RFC 2045, RFC 2046, RFC 2047, RFC 2048 e RFC 2049. Tale forma di codifica rappresenta anche la modalità fondamentale di aggregazione di documenti informatici, ai fini della trasmissione in un unico messaggio.
Ciascuna parte di un messaggio è codificata come una body part, univocamente identificata nella struttura MIME che codifica il messaggio. Si definisce come nome di una body part il primo dei valori effettivamente specificati nell'ordine di precedenza descritto dalla seguente lista:
a) il valore del parametro filename dell'attributo Content-Disposition della body part MIME;
b) il valore del parametro name dell'attributo Content-Type della body part MIME. Il nome di ciascuna body part rappresenta l'elemento di collegamento indispensabile tra la segnatura informatica e l'insieme dei documenti informatici aggregati nella struttura MIME.
L'uso dei nomi ha anche lo scopo di rendere irrilevante l'ordinamento delle body part all'interno della struttura MIME.
5. Messaggio protocollato
Un messaggio protocollato è codificato come una struttura MIME, le cui body part corrispondono alle parti componenti.
La segnatura informatica è contenuta in una body part avente nome Segnatura.xml. Tale body part contiene un documento XML strutturato nel modo previsto dalla Document Type Definition (DTD) allegata, ovvero la sua versione più recente, ed avente un root element di tipo <Segnatura>. L'uso del nome Segnatura.xml per una body part è riservato a questo unico scopo. Ogni variazione, in termini di caratteri maiuscoli e minuscoli, del nome di una body part deve essere evitata.
Le amministrazioni che intendono scambiare ulteriori informazioni riguardanti la gestione dei processi o altre esigenze amministrative non previste nella DTD di cui alla presente circolare possono includere nel messaggio uno o più documenti informatici, strutturati secondo un formato direttamente concordato tra le parti, senza estendere o modificare la DTD stessa.
In generale, tutte le body part di un messaggio protocollato devono avere un nome univoco, che viene utilizzato nella segnatura informatica per descrivere l'organizzazione del messaggio (per esempio per distinguere il documento primario dagli eventuali allegati). È, tuttavia, possibile che un messaggio protocollato contenga una body part priva di nome. Tale body part viene interpretata come il testo del messaggio e, nel caso di comunicazioni tra AOO della stessa amministrazione, può rappresentare il documento primario del messaggio stesso, qualora la segnatura informatica contenga un'esplicita indicazione in questo senso.
Dal punto di vista amministrativo, la descrizione del significato di ciascuna body part del messaggio protocollato è contenuta nella segnatura informatica. Più precisamente, la segnatura informatica contiene l'elenco di tutti i documenti contenuti nel messaggio protocollato che hanno una rilevanza formale.
6. Messaggi di ritorno
Data la descrizione dello schema di base di scambio di messaggi, oltre ai messaggi di posta elettronica protocollati in uscita dalle AOO mittenti e in ingresso da quelle riceventi, si può identificare una seconda tipologia fondamentale di messaggi nello scambio di posta elettronica tra due AOO, ossia i messaggi di ritorno.
Essi sono costituiti da un messaggio di posta elettronica generato dalla AOO ricevente in risposta al verificarsi di determinati eventi. Ciascun messaggio di ritorno può fare riferimento ad un solo messaggio protocollato.
I messaggi di ritorno, inviati da una AOO ricevente a scopo informativo, sono scambiati in base allo stesso standard SMTP previsto per i messaggi di posta elettronica protocollati in uscita da una AOO e sono codificati secondo lo stesso standard MIME. Valgono, inoltre, le stesse convezioni per l'identificazione univoca delle body part del messaggio.
È possibile distinguere quattro tipi di messaggio di ritorno:
a) messaggio di conferma di ricezione;
b) messaggio di notifica di eccezione;
c) messaggio di aggiornamento di conferma;
d) messaggio di annullamento protocollazione.
6.1 Messaggio di conferma di ricezione
Il messaggio di conferma di ricezione ha lo scopo di comunicare alla AOO mittente l'avvenuta protocollazione, in ingresso, del messaggio protocollato ricevuto. Il messaggio riporta anche alcune informazioni archivistiche aggiuntive, quale l'identificatore della registrazione di protocollo dei documenti ricevuti, come effettuata dalla AOO ricevente.
Il messaggio di conferma di ricezione è inviato soltanto su esplicita richiesta della AOO mittente. Tale richiesta viene indicata nella segnatura informatica del messaggio protocollato originario. Una conferma di ricezione è codificata come una struttura MIME che contiene almeno una body part avente nome Conferma.xml. Tale body part contiene un documento XML strutturato nel modo previsto dalla DTD allegata ed avente un root element di tipo <ConfermaRicezione>. Il nome Conferma.xml è riservato a questa finalità, analogamente a quanto previsto per la segnatura informatica.
Una conferma di ricezione può contenere altri documenti informatici e, inoltre, riferimenti esterni a documenti informatici reperibili per via telematica, previa indicazione riportata nel file Conferma.xml. Non possono essere inclusi documenti informatici che siano non strettamente inerenti al messaggio protocollato o, comunque, aventi una rilevanza tale da necessitare una registrazione di protocollo separata.
6.2 Messaggio di notifica di eccezione
Il messaggio di notifica di eccezione ha lo scopo di comunicare alla AOO mittente le anomalie che il messaggio protocollato ricevuto presenta.
Alcuni esempi di messaggi di notifica di eccezione ricorrono nelle seguenti ipotesi:
a) il messaggio protocollato è corrotto o uno dei documenti informatici inclusi non è leggibile;
b) la descrizione del messaggio protocollato riportata nella segnatura informatica non
corrisponde alla struttura di codifica (per esempio ad un documento descritto come allegato non corrisponde alcuna body part all'interno del messaggio);
c) il formato della segnatura informatica non è conforme alla DTD di cui alla presente circolare ovvero alla sua versione più recente;
d) nel caso di comunicazione tra diverse amministrazioni il documento principale non risulta sottoscritto;
e) la descrizione del destinatario contenuta nella segnatura informatica è errata;
f) la verifica di integrità di uno dei documenti informatici ha dato esito negativo.
A questi motivi di anomalie se ne possono aggiungere altri, propri della AOO ricevente, che dovranno essere indicati nel proprio manuale di gestione. Il motivo che ha generato l'eccezione viene dettagliatamente descritto all'interno del documento XML allegato al messaggio di notifica dell'eccezione.
Un messaggio di notifica di eccezione è codificato come una struttura MIME che contiene una body part avente nome Eccezione.xml. Tale body part contiene un documento XML strutturato nel modo previsto dalla DTD allegata alla presente circolare, ovvero alla sua versione più recente, ed avente un root element di tipo <NotificaEccezione>. Il nome Eccezione.xml è considerato riservato nello stesso modo previsto per la segnatura informatica.
6.3 Messaggio di aggiornamento di conferma
Un messaggio di aggiornamento di conferma ha lo scopo di comunicare alla AOO mittente il verificarsi, presso la AOO ricevente, di un evento rilevante, successivo alla protocollazione in ingresso.
Alcuni esempi di eventi che possono generare messaggi di aggiornamento di conferma sono:
a) l'avvenuta assegnazione del documento o dei documenti trasmessi;
b) l'attivazione di un procedimento;
c) la chiusura di un procedimento.
L'invio dei messaggi di aggiornamento di conferma avviene soltanto su esplicita richiesta della AOO mittente. Tale richiesta viene indicata nella segnatura informatica del messaggio protocollato originario e coincide con la richiesta di conferma di ricezione. L'elenco degli eventi specifici che generano un messaggio di aggiornamento è stabilito dalla AOO ricevente ed indicato nel manuale di gestione. Non è previsto che la AOO mittente possa indicare in modo selettivo gli aggiornamenti che intende ricevere.
Un aggiornamento di conferma è codificato come una struttura MIME che contiene almeno una body part avente nome Aggiornamento.xml. Tale body part contiene un documento XML strutturato nel modo previsto dalla DTD allegata alla presente circolare, ovvero la sua versione più recente, ed avente un root element di tipo <AggiornamentoConferma>. Il nome Aggiornamento.xml è considerato riservato nello stesso modo previsto per la segnatura informatica.
Le informazioni riportate nel file Aggiornamento.xml devono includere quelle riportate nell'originaria conferma di ricezione alla quale l'aggiornamento si riferisce. Un aggiornamento di conferma può contenere altri documenti informatici e riferimenti esterni a documenti informatici reperibili per via telematica, nel rispetto delle modalità previste per una conferma di ricezione.
6.4 Messaggio di annullamento protocollazione
Un messaggio di annullamento protocollazione ha lo scopo di comunicare alla AOO mittente l'annullamento di una registrazione di protocollo in ingresso effettuata dalla AOO ricevente. In questo caso, l'invio di un messaggio di annullamento da parte della AOO ricevente è obbligatorio, anche qualora la AOO mittente non abbia richiesto la conferma di ricezione. Un messaggio di annullamento è codificato come una struttura MIME che contiene una body part avente nome Annullamento.xml. Tale body part contiene un documento XML strutturato nel modo previsto dalla DTD allegata alla presente circolare, ovvero la sua versione più recente, ed avente un root element di tipo <AnnullamentoProtocollazione>. Il nome Annullamento.xml è considerato riservato nello stesso modo previsto per la segnatura informatica. Il file Annullamento.xml riporta il motivo dell'annullamento della protocollazione del messaggio e gli estremi del provvedimento amministrativo di annullamento.
7. Riferimenti esterni
Un messaggio protocollato può contenere riferimenti esterni a documenti non contenuti nella struttura MIME che codifica il messaggio. I riferimenti possono riguardare documenti informatici reperibili per via telematica ovvero documenti cartacei inviati, parallelamente al messaggio protocollato, con strumenti tradizionali. Gli eventuali riferimenti esterni a documenti informatici o cartacei devono essere riportati nella segnatura informatica. Non sono invece ammessi i riferimenti esterni MIME codificati da body part aventi un tipo message/external-body.
In ciascun riferimento a documento informatico reperibile per via telematica deve essere indicato lo uniform resource identifier (URI - RFC 1808 e successivi aggiornamenti) univoco per l'accesso. Un simile riferimento può includere anche l'impronta del documento informatico, al fine di garantire l'univocità del documento al quale il messaggio protocollato si riferisce. L'impronta è generata impiegando la funzione di hash, definita nella norma ISO/IEC 10118- 3:1998, Dedicated Hash-Function 3, corrispondente alla funzione SHA-1 (D.P.C.M. 31 ottobre 2000, articolo 17, comma 2).
Quando il riferimento riguarda un documento cartaceo trasmesso con modalità tradizionale, deve essere specificato un identificativo univoco che va riportato anche sul corrispondente documento.
8. Segnatura
Come prescritto dall'articolo 18, comma 1, del D.P.C.M. 31 ottobre 2000, la segnatura informatica è codificata in armonia con lo standard eXtensible Markup Language - XML 1.0 (raccomandazione W3C del 10 febbraio 1998) secondo la DTD di cui alla presente circolare, ovvero la sua versione più recente, e disponibile presso il sito Internet di cui all'articolo 11, comma 3, del D.P.C.M. 31 ottobre 2000.
Una segnatura informatica, la cui struttura è descritta dettagliatamente nella DTD allegata alla presente circolare, si compone di tre sezioni:
a) la sezione intestazione contiene i dati identificativi e le informazioni fondamentali del messaggio;
b) la sezione riferimenti contiene le informazioni relative al contesto generale di cui il messaggio fa parte;
c) la sezione descrizione contiene le informazioni descrittive riguardanti il contenuto del messaggio.
Le due sezioni intestazione e descrizione sono obbligatorie mentre la sezione riferimenti è opzionale.
8.1 Intestazione
La sezione intestazione contiene gli elementi essenziali di identificazione e caratterizzazione amministrativa del messaggio protocollato. La sezione intestazione riporta anche le informazioni relative alla trasmissione del messaggio.
In particolare, la sezione contiene l'identificatore della registrazione relativa al messaggio protocollato in uscita. Tale identificatore, ai sensi del D.P.R. n. 445/2000, riporta i seguenti dati:
c) indicazione della amministrazione mittente;
d) indicazione della AOO mittente.
Nel caso di un documento trasmesso più di una volta, è obbligatorio riportare nella sezione intestazione anche l'identificatore di prima registrazione. Esso coincide con l'identificatore della prima registrazione di protocollo in ingresso, relativo ad un documento originariamente formato all'esterno della pubblica amministrazione, o con l'identificatore della prima registrazione di protocollo in uscita, relativo ad un documento formato all'interno della pubblica amministrazione.
L'identificatore di prima registrazione deve poter essere utilizzato anche negli accessi ai registri di protocollo informatizzati.
Nella sezione riferimenti sono riportati gli eventuali riferimenti ad altri messaggi protocollati e/o relativi a contesti procedurali o procedimenti.
Per contesto procedurale si intende lo svolgimento di attività amministrative in qualche modo collegate funzionalmente tra loro da parte di una o più unità organizzative associate alla stessa AOO. Le azioni svolte nell'ambito di un contesto procedurale sono finalizzate alla produzione di un risultato, finale o intermedio, destinato ad aver valore anche all'esterno delle unità organizzative coinvolte. Invece, nel procedimento amministrativo, così come disciplinato dalla legge n. 241/1990, il complesso di atti e di operazioni tra loro funzionalmente collegati è preordinato all'adozione di un provvedimento amministrativo finale.
L'indicazione dei riferimenti ad altri messaggi protocollati e/o contesti procedurali è funzionale all'attivazione, da parte dell'AOO ricevente, di procedure automatiche o semi automatiche per il trattamento dei documenti trasmessi. Ad esempio, nel caso di procedimenti complessi che coinvolgono più AOO, eventualmente appartenenti a diverse amministrazioni, la presenza di un esplicito riferimento, nei messaggi scambiati, può facilitare l'identificazione automatica o semi-automatica dei fascicoli nei quali collocare i documenti trasmessi o i soggetti a cui assegnarne il trattamento.
8.3 Descrizione
La sezione descrizione contiene le informazioni che descrivono l'organizzazione strutturata e il contenuto del messaggio protocollato.
In particolare, contiene l'indicazione dettagliata del documento primario del messaggio protocollato che può coincidere con il testo del messaggio, ovvero consistere in un documento contenuto in una body part con nome.
La sezione descrizione contiene anche l'elenco dettagliato degli eventuali documenti allegati al documento primario. Tale elenco può anche includere la descrizione dell'organizzazione in fascicoli e sotto-fascicoli dei documenti trasmessi.
Lo scambio per via telematica di messaggi protocollati tra AOO presenta, in generale, esigenze specifiche in termini di sicurezza. Può essere necessario, infatti, garantire alla AOO ricevente la possibilità di verificare l'autenticità di provenienza e l'integrità del messaggio. Possono sussistere, inoltre, motivi validi per la trasmissione del messaggio in forma cifrata, ad esempio nell'ipotesi di protezione di dati personali sensibili previsti dalla legge n. 675/1996.
La firma digitale apposta sui documenti informatici inclusi nel messaggio garantisce i requisiti di autenticità, integrità e non ripudio dei singoli documenti. Ulteriori aspetti, quali l'integrità delle parti non firmate - come ad esempio la segnatura - e la riservatezza dell'intero messaggio richiedono l'adozione di altre soluzioni.
Per la trasmissione di messaggi di posta elettronica su reti telematiche non sicure, le AOO possono adottare sistemi di autenticazione e cifratura dei messaggi che hanno a riferimento tecniche basate su chiave pubblica, previa indicazione di ciò nel piano della sicurezza della AOO, previsto dell'articolo 4, comma 1, lettera c, del D.P.C.M. 31 ottobre 2000, e con esplicito riferimento alle regole di interoperabilità di cui alla circolare AIPA/CR/24 del 19 giugno 2000. Per lo scambio su rete sicura (come la Rete unitaria delle pubbliche amministrazioni o altra rete dedicata), l'uso di messaggi securizzati è in generale non necessario.

References: Articolo 18
 articolo 15

ARTICOLO 18
 articolo 15
 articolo 5
 articolo 1
 articolo 15
 articolo 17