From aktive at nuug.no Thu Apr 6 12:38:19 2017 From: aktive at nuug.no (aktive at nuug.no) Date: Thu, 06 Apr 2017 12:38:19 +0200 Subject: Data collection, psychometric profiling and their impact on politics - =?utf-8?Q?Medlemsm=C3=B8te?= 2017-04-04 In-Reply-To: <2flo9xj7cd9.fsf@diskless.uio.no> References: <2flo9xj7cd9.fsf@diskless.uio.no> Message-ID: <2flwpaxu8h0.fsf@diskless.uio.no> Opptaket fra tirsdagens m?te er nettopp publisert p? og kringkastes p? Frikanalen i morgen 14:00. -- Vennlig hilsen Petter Reinholdtsen From aktive at nuug.no Fri Apr 28 16:59:44 2017 From: aktive at nuug.no (aktive at nuug.no) Date: Fri, 28 Apr 2017 16:59:44 +0200 Subject: NUUG =?utf-8?Q?foresl=C3=A5r?= at arkivverket tillater arkivering av epostformatet Message-ID: <2flmvb0lgrj.fsf@diskless.uio.no> Fra : 2017-04-28 - NUUGs h?ringuttalelse til Riksarkivarens forskrift P? s?ndag er det frist for ? komme med innspill til nytt forslag til Riksarkivarens forskrift. Dette er en viktig forskrift som bestemmer hvilke digitale dataformater det er greit ? arkivere i det offentlige Norge for bevaring i hundrevis av ?r. Her f?lger NUUGs uttalelse, som ble levert i dag (fotnoter i innsendt PDF er her gjort om til lenker): H?ringsuttalelse til Riksarkivarens forskrift --------------------------------------------- Vi viser til h?ring sendt ut 2017-02-17, og tillater oss ? sende inn noen innspill til Riksarkivarens arbeid med ny forskrift om utfyllende tekniske og arkivfaglige bestemmelser om behandling av offentlige arkiver (riksarkivarens forskrift). Innspillene f?lger samme rekkef?lge som forskriften, s? langt det lot seg gj?re. Kommaseparert format i ? 5-12 b?r klargj?res -------------------------------------------- Forskriftens ? 5-12 (Tekstfilformater i arkivuttrekk) punkt b) omtaler tegnseparert format (kommaseparert format) uten ? henvise til en fri og ?pen standard som beskriver hva slags format en mener i detalj. Kommaseparerte filer er beskrevet av IETF RFC 4180. For ? sikre en entydig beskrivelse av formatet foresl?r vi at forskriften henviser til denne formatbeskrivelsen. Slik forskriften st?r i dag mangler for eksempel forskriften krav om beskrivelse av hvordan poster som inneholder feltskilletegn, linjeskift, anf?rselstegn og s? videre skal h?ndteres, mens dette er klart beskrevet i RFC 4180. Oversikten over godkjente dokumentformater ved innlevering b?r klargj?res ------------------------------------------------------------------------- Punkt ? 5-16 1a) nevner formatet ?TXT? uten n?rmere beskrivelse, uten ? henvise til ? 5-11 som lister opp godkjente tegnsett, og uten ? forklare hvordan en skal vite hvilket tegnsett som er brukt i ?TXT?-formatet. Hvis poenget er at ?? 5-12 og 5-12 er ment ? beskrive ?TXT?-formatet n?rmere b?r det legges inn en kryssreferanse til ?? 5-11 og 5-12 i punkt 1a. Det er ikke klart fra forskriften konkret hva slag format TXT er. Beskrivelsen ?ren tekst? kan v?re s? mangt, og b?de HTML og XML best?r jo av en ?ren? tekstlig beskrivelse. Er det ment ? v?re tilsvarende text/plain definert i IETF RFC 2046? Der beskrives den som ?"text/plain", which is a generic subtype for plain text. Plain text does not provide for or allow formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup. Plain text is seen simply as a linear sequence of characters, possibly interrupted by line breaks or page breaks. Plain text may allow the stacking of several characters in the same position in the text. Plain text in scripts like Arabic and Hebrew may also include facilitites that allow the arbitrary mixing of text segments with opposite writing directions.?. Vi tror det er lurt at ?TXT? beskrives n?rmere, og at det henvises til klargj?rende spesifikasjoner som for eksempel text/plain i IETF RFC 2046 for ? forklare hva som menes. Punkt ? 5-16 1b) omtaler TIFF som ?tekst med objekter?. Bildeformatet TIFF anses normalt ikke som et tekstformat. Vi antar en her snakker om bilder av papir med tekst. Men TIFF er bilde av tekst, ikke ren tekst og det virker misvisende ? likestille den med TXT, XML og PDF/A. PDF/A kan inneholder innskannede dokumenter i bildeformat, men b?r vel i slike tilfeller anses ? v?re bilder, ikke tekst. Bilde av tekst, uavhengig av om det er pakket inn som TIFF eller PDF, b?r heller legges under punkt 1c. Punkt ? 5-16 1f) nevner ?PCM-basert wave? uten ? beskrive n?rmere hva som menes. Det er dermed uklart hvilken av lydformatene med wave i navnet det refereres til. Hvis det er Waveform Audio File Format definert i Multimedia Programming Interface and Data Specification 1.0 av IBM Corporation og Microsoft Corporation i august 1991 det gjelder, s? er det beste ? referere til en klar og offentlig spesifikasjon, helst en fri og ?pen standard, som beskriver formatet. Punkt ? 5-16 1h) nevner HTML, men nevner ikke hvordan eksterne referanser i HTML (for eksempel skrifttyper, JavaScript-kode, bilder og video) skal h?ndteres for ? kunne gjenskape en web-side. ? 5-19 sier derimot at formatet ikke skal brukes. Kanskje HTML ikke burde v?re p? listen over godkjente dokumentformater, eller i det minste ha en henvisning til ? 5-19? Internett-e-post (IETF RFC 5322) b?r inn som godkjent dokumentformat -------------------------------------------------------------------- Forskriftens ? 5-16 med oversikt over godkjente dokumentformater ved innlevering b?r inneholde Internett-e-post. Det meste av forvaltningens korrespondanse gjennomf?res i dag p? epost, og det b?r v?re mulig ? lagre korrespondansen i originalformatet i stedet for ? konvertere til for eksempel PDF/A. Det gj?r det ogs? mulig ? direkte svare p? epost i arkivet med et epostprogram, ved for eksempel ? hente ut eposten fra arkivet og gj?re den tilgjengelig for epostprogrammet. Vi foresl?r at det legges inn et nytt punkt k) under punktet om websider i ? 5-16. Det nye punktet kan for eksempel lyde slik: k) For Internett-e-post aksepteres f?lgende: RFC822 som spesifisert i IETF RFC 5322. Eventuelle vedlegg lagres i tillegg som separate vedleggsdokumenter i aksepterte dokumentformater der dette er mulig. Vi foresl?r ? bruke ?RFC822? som formatnavn for slik e-post, da IETF RFC 822 (1982-08-13) er opprinnelig beskrivelse av Internett-e-post, siden etterfulgt av IETF RFC 2822 (2001-04) og IETF RFC 5322 (2008-10), med oppdatert beskrivelse av formatet. E-post er omtalt i Noark 5 versjon 3.1 p? sidene 193 til 207. Side 193 dokumenterer det som for oss ser ut til ? v?re en misforst?else: ?Selv om RFC2822 definerer syntaksen for e-posttransaksjoner, er den ingen standard som definerer dataformatet som skal bli brukt n?r e-posttransaksjonen er fanget som dokumenter.? En kan jo ?fange en e-post som et dokument? for lagring ved ? ta vare p? teksten som utgj?r e-posten, dvs. hode og kropp. Det er standard m?te ? ta vare p? e-post, for eksempel i mbox, maildir, mh og en rekke andre kjente m?ter ? ta vare p? e-post, og h?ndteres av ethvert e-postprogram. En e-post lagres tradisjonelt ved ? lagre tekstlinjene som utgj?r e-posten. Formatet er enkelt, der e-postens hode best?r av tekstlinjer med feltnavn, kolon og feltverdi, s? en blank linje og deretter tekstlinjer som utgj?r e-postens kropp. Det er beskrevet i e-postens hode hvordan tekstlinjene i kroppen skal tolkes. Detaljene er beskrevet i detalj i IETF RFC 5322. Krav 8.1.8 i Noark 5 versjon 3.11 (side 195) lyder som f?lger: Ved arkivering av e-post i Noark 5-l?sningen, skal e-posten med eventuelle vedlegg automatisk arkiveres i et enhetlig, samlet format som gjengir b?de e-posthode og e-postmelding. Men det st?r ingenting om hvordan dette skal gj?res, og n?r epost ikke er p? listen over godkjente formater blir det utfordrende. Vi savner dermed informasjon i forskriften om hvordan Noark 5-l?sninger skal ta vare p? e-post uten informasjonstap. Det b?r v?re mulig ? gjenskape hele den originale e-posten slik den s? ut ved mottak hvis en skal kunne sjekke kryptosignaturer (for eksempel der S/MIME (IETF RFC 5751) eller OpenPGP (IETF RFC 4880) er brukt). Det vil ogs? gj?re det mulig ? sjekke hvor e-posten kommer fra ved hjelp av felter brukt av Domain Keys Identified Message (DKIM) i e-posten. DKIM er definert i IETF RFC 6376. Formatet for Internett-e-post er som nevnt spesifisert i IETF RFC 5322, og best?r i grove trekk av et sett med tekstlinjer som e-posthode, en blank linje som skilletegn og s? et sett med tekstlinjer som best?r av e-postens kropp. E-postens kropp kan v?re strukturert i underdeler i tr?d med MIME-formattering og inneholde for eksempel b?de ren tekst, HTML-sider og vedlegg med formater uten en klar og offentlig spesifikasjon (for eksempel propriet?re bin?rformater). E-posten kan ogs? henvise til eksterne filer (for eksempel bilder i HTML-e-post) som kun er tilgjengelig i en tidsbegrenset periode. Arkivering av e-post p? formatet beskrevet i IETF RFC 5322 b?r derfor kanskje ha en del begrensninger n?r det gjelder aksepterte vedlegg, for ? sikre at e-post og tilh?rende vedlegg kan forst?s ogs? i fremtiden, selv n?r det ufrie programmet som kan tolke slike propriet?re bin?rformater er g?tt tapt eller ikke lenger lar seg bruke (noe som kan skje hvis programmet er avhengig av nett-tjenester som ikke lenger eksisterer for ? fungere), eller nett-tjenesten der eksternt henviste filer befant seg er borte, for eksempel hvis det henvises til en Youtube- eller Facebook-side. En naturlig begrensning for slike e-postarkiver kunne v?re ? kreve at e-postvedlegg skal v?re et av de godkjente dokumentformatene omtalt i forskriften. Et sp?rsm?l som m? besvares i den forbindelse er hva som skal gj?res med mottatt arkivverdig e-post som inneholder vedlegg p? formater som ikke er godkjent for arkivering. En konvertering til andre formater f?r arkivering vil ?delegge for kontroll av eventuelle kryptosignaturer i e-posten. Det grunnleggende sp?rsm?let er om arkivet skal ta vare p? informasjon det er uklart hvordan skal tolkes eller ikke. Det tryggeste er kanskje ? b?de ta vare p? originalinformasjonen og i tillegg kreve at der det er mulig blir det lagret omformede utgaver der det er klart hvordan vedleggene skal tolkes. Det b?r ogs? avklares hvor metadata fra en epost lagres i Noark 5-strukturen, men det h?rer kanskje ikke hjemme i forskriften. For ? automatisk kunne finne hvilke e-poster som ?henger sammen? n?r nye e-poster skal arkiveres er det hensiktsmessig ? raskt kunne s?ke opp e-post ved hjelp av e-postens Message-ID. En e-post inneholder referanser til hvilken e-post den er svar p? i e-posthodefeltene In-Reply-To og References. Disse feltene inneholder referanser til tidligere e-post ved hjelp av verdier hentet fra e-posthodefeltet Message-ID. Disse feltverdiene kan dermed brukes til ? finne aktuelle mapper ? foresl? for ? plassere en ny e-post som skal arkiveres. Det vil v?re hensiktsmessig ? standardisere hvilket felt i Noark 5-strukturen dette skal lagres i for ? sikre gjenfinning i deponerte arkiver. En god kandidat for Message-ID kan v?re feltet ?filnavn? fra spesifikasjonen for NOARK 5 Tjenestekatalog side 104. Klargj?re hvordan SMS/MMS skal arkiveres ---------------------------------------- Det st?r ingenting i forslaget til forskrift hvordan ?yeblikksmeldinger som SMS /MMS skal arkiveres. Lagring av SMS/MMS er en utfordring flere etater har i dag, og det er kanskje naturlig ? gi instrukser eller anbefalinger til forvaltningen om hvordan slike meldinger b?r langtidslagres. Kan det v?re en ide ? bestemme et eget XML-basert format for lagring av SMS? Eller kanskje det er mer fornuftig ? arkivere originalmeldingen slik den ble oversendt til mobilen? SMS-formatet er beskrevet og vedlikeholdes av 3GPP som TS 23.041. MMS-formatet er beskrevet og vedlikeholdes av Open Mobile Alliance som OMA MMS. Kanskje XML-format i MMS-spesifikasjonen kan brukes? Uansett b?r det kanskje nevnes hva slags informasjon som b?r registreres for hver SMS? Som et minimum b?r nok selve teksten, sendertelefonnummer, mottaker (e), sendetidspunkt og mottakertidspunkt tas vare p?.