Interrogativi e problemi apertiPratiche operativeProtocollo informaticoRiflessioni teoriche

Segnatura XML, #2: spostare file di grandi dimensioni

Secondo episodio di una serie di tre, dedicata alla segnatura XML per il protocollo interoperabile, con digressioni e variazioni sul tema.

L’istanza che arriva che arriva alla casella di posta certificata del comune spezzettata in 4 o 5 messaggi perché gli allegati sono tanti e pesanti, il link su qualche servizio di file hosting dove qualche problem solver ha (improvvidamente) piazzato file di documenti vitali, il parere da chiedere che – niente da fare – non ne vuole sapere di partire anche se i suoi 47 elaborati grafici li ho aggiunti alla registrazione uno a uno meticolosamente: problemi spiccioli che, per chi ha a che fare con protocollo informatico e PEC, sono tanto quotidiani quanto annosi. Eppure di soluzioni definitive non se ne vedono. Eliminare del tutto la PEC e virare tutto su sportelli e servizi online collegati con il protocollo sarebbe la soluzione concettualmente ideale: vero, pur nella consapevolezza che in un tale scenario occorre comunque ricreare quelle condizioni di certezza dell’invio e delle consegna proprie della posta certificata. Tuttavia, fuori delle situazioni ideali, esistono esigenze di comunicazione che sfuggono al paradigma del servizio online o dell’attività segmentata in task di un workflow, esigenze sporadiche o estemporanee, ineliminabili. Un esempio di questo ultimo caso buttato lì per suggestione non guasta, quanto meno per tenersi alla larga dal tono apodittico: pensiamo a corrispondenza preliminare a una convenzione fra enti in cui ci si scambiamo voluminosi documenti progettuali, magari recuperati dalla digitalizzazione di qualche documento cartaceo. Oppure un consulente incaricato di predisporre qualche documento di pianificazione urbanistica, con relativi elaborati grafici che, notoriamente, tendono a aumentare il loro volume come un gas all’aumentare della temperatura in una trasformazione isobara. Comunque, termodinamica a parte, il problema di scambiarsi un file grande o anche enorme, è valido e affascinante in sé.

Ora, almeno per gli scambi fra AOO (cioè fra pubbliche amministrazioni) la circolare 60 del 2013 risolveva il problema, quanto meno in via teorica. Infatti, con la giusta combinazione dell’attributo “TipoRiferimento” valorizzato a telematico e l’indicazione nell’elemento XML “CollocazioneTelematica” del percorso telematico completo dal quale recuperare il file (=evidenza informatica del documento). era possibile trasmettere file di grande dimensioni con le dovute cautele circa identificazione certa e immodificabilità. Che poi questa possibilità fosse applicata diffusamente nei protocolli informatici degli enti pubblici è un altro discorso. Tant’è che le ultime linee guida sul documento informatico, che con l’allegato 6 fanno piazza pulita della circolare 60 e dettano nuove regole per l’interoperabilità di protocollo, nella loro stesura originale sottoposta a consultazione pubblica e nella versione successivamente licenziata si dimenticano completamente di questa feature della comunicazione fra AOO (anche se, in fase di consultazione la mancanza forse sarebbe potuta emergere). Fortunatamente, dopo la pubblicazione, la segnatura interoperabile è stato oggetto di revisione ed è stata introdotto nuovamente il meccanismo della “CollocazioneTelematica”, mutuato dalla circolare 60 e arricchito: oltre al percorso completo per il recupero del file, si consegna anche una password e si stabilisce un tempo di disponibilità dell’oggetto informatico.

Quindi, una volta che tutti i protocolli informatici di tutti gli enti abbiano implementato correttamente i web service per il protocollo interoperabile, il problema è risolto per comunicazioni fra pubbliche amministrazione. E quando uno dei terminali della comunicazione non è una pubblica amministrazione?

Un opportuno estensione delle regole di interoperabilità di protocollo ne consentirebbe l’applicazione in due scenari ulteriori, che potrebbero eliminare definitivamente, a livello documentale, il problema del trasferimento di file voluminosi:

  • invio di file grandi verso destinatari non pubbliche amministrazioni
  • ricezione di file grandi provenienti da mittenti non pubbliche amministrazioni.

Invio di file grandi verso destinatari non pubbliche amministrazioni

Come premessa, alcuni soggetti non pubblici ben strutturati, dotati di sistemi evoluti di gestione documentale, potrebbero aderire alla convenzione della segnatura del protocollo interoperabile e, eccezion fatta per l’esposizione di web service che richiederebbero l’iscrizione in registri pubblici e la fornitura di determinate garanzie di sicurezza, implementare l’elaborazione automatica della segnatura XML ricevuta via PEC (o e-mail ordinaria) anche per la parte di recupero dei file tramite la “CollocazioneTelematica”.

Per tutti gli altri, invece, per i quali ci si attende una gestione manuale dei messaggi ricevuti, sarebbe sufficiente veicolare nel corpo del messaggio o in apposito allegato (magari insieme alla segnatura umanamente interpretabile) le stesse informazioni presenti nella segnatura XML in caso di file messi a diposizione su un’area pubblica:

  • nome dei file;
  • loro descrizione;
  • impronta di ciascuno;
  • percorso completo;
  • password di accesso;
  • tempo a disposizione per il download.

All’obiezione di inviare una password in chiaro nel testo di una email si può osservare che lo stesso avviene nel caso di segnatura XML inviata via PEC o e-mail a una pubblica amministrazione. E, del resto, se qualcuno entrasse in possesso della password con un accesso abusivo al messaggio e-mail, allo stesso modo avrebbe avuto accesso a quello stesso messaggio con gli stessi file allegati.

A scanso di fraintendimenti, conviene sottolineare o ricordare la funzione della specificazione dell’impronta di ciascun file, che è duplice:

  • da un lato consentire la verifica immediata, dopo il download, che il file è effettivamente quello indicato e non ha subito alterazioni durante la sua peramenza nell’area pubblica;
  • dall’altro consentire di associare il file alla comunicazione anche a distanza di tempo: l’impronta contenuta nel messaggio ricevuto via PEC, individuato come sicuramente proveniente dall’amministrazione, lega il file recuperato esternamente a quella comunicazione e mette al riparo entrambe le parti da future contestazioni (“il file che mostri non è quello che ti ho inviato/che ho scaricato”).

Invio di file grandi verso la pubblica amministrazione

La PEC – anche non si è detto ma si è dato per assodato – ha dei limiti intrinseci (e commerciali) per la dimensione degli allegati. Per aggirare il problema ed evitare invii spezzettati in più PEC, operativamente e concettualmente ingestibili per l’ufficio protocollo, si potrebbe semplicemente utilizzare l’interfaccia web service esposta dall’amministrazione destinataria e allestire un servizio online generico, che consenta all’utente esterno (cittadino o impresa) di inviare una comunicazione all’amministrazione con stesso valore di una PEC (o di una raccomandata). I requisiti/caratteristiche del servizio esposto all’utente esterno potrebbero essere:

  • autenticazione SPID/CIE (per identificare il mittente ed evitare spam e abusi);
  • possibilità per l’utente di scrivere un messaggi di accompagnamento;
  • possibilità per l’utente di caricare un numero indefinito di file e per ciascuno di inserire una breve descrizione;
  • invio via PEC all’indirizzo PEC/e-mail del mittente di una ricevuta completa dell’elenco dei file caricati e delle relative impronte (per consentire al mittente la verifica dell’integrità dei file trasmessi e consolidare il legame fra file e comunicazione tramite l’intervento di un garante terzo, il gestore della PEC).

Tralasciamo qui ulteriori requisiti che riguardano meccanismi che, in assenza di firme digitali, consentano di legare i contenuti inviati al mittente utilizzando la sessione SPID (la cosiddetta firma SPID o espedienti analoghi), o la possibilità di consultare comunicazioni precedentemente inviate e vederne lo stato di registrazione e lavorazione.

Lato amministrazione, l’ufficio protocollo vede le comunicazioni ricevute in un’apposita sezione, esattamente come adesso vede i messaggi PEC/e-mail presenti nelle caselle istituzionali. I puristi potrebbero obiettare che, a questo punto, tanto vale gestire in automatico anche la registrazione della comunicazione e la sua assegnazione all’ufficio competente: in altri termini sarebbe preferibile esporre all’utente esterno (cittadino o impresa) non tanto un servizio online neutro per inviare una comunicazione voluminosa, ma un servizio online strutturato che distinguesse fra i vari procedimenti attivabili e introducesse anche un certo livello di interazione con il sistema informativo dell’amministrazione. Tutto corretto, ma forse questo è uno di quei casi in cui può convenire compiere un passo alla volta. Anzi, a ben vedere, poiché come anticipato in apertura esistono esigenze comunicative che sfuggono alla serializzazione di un servizio online, la soluzione proposta avrebbe sempre la sua utilità residuale: tanto vale allora implementarla subito, visto la sua relativa semplicità e indipendenza dal sistema informativo complessivo. Per specializzarsi c’è tempo…

Condividi

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *