1 <?xml version=
"1.0" encoding=
"utf-8"?>
2 <rss version='
2.0' xmlns:lj='http://www.livejournal.org/rss/lj/
1.0/'
>
4 <title>Petter Reinholdtsen - Entries tagged standard
</title>
5 <description>Entries tagged standard
</description>
10 <title>Hva er egentlig en åpen standard?
</title>
11 <link>../../Hva_er_egentlig_en___pen_standard_.html
</link>
12 <guid isPermaLink=
"true">../../Hva_er_egentlig_en___pen_standard_.html
</guid>
13 <pubDate>Sat,
28 Mar
2009 10:
50:
00 +
0100</pubDate>
15 <p
>Jeg møter alle slags interessante mennesker på min vei, og et møte
16 jeg lærte mye av var å treffe på en svært kompetent IT-fyr som
17 benektet ting jeg anser som åpenbart og selvfølgelig når det gjelder
18 standarder. Det var interessant, da det fikk meg til å tenke litt
19 nøyere på hvilke mekanismer som ligger til grunn for at noe oppfattes
20 som en standard. Det hele startet med arbeid rundt integrering av NSS
21 LDAP mot Active Directory, og problemer som oppstår pga. at Active
22 Directory ikke følger LDAP-spesifikasjonen som dokumentert i RFCer fra
23 IETF (konkret, AD returnerer kun et subset av attributter hvis det er
24 mer enn
1500 atributter av en gitt type i et LDAP-objekt, og en må be
25 om resten i bolker av
1500). Jeg hevdet måten dette ble gjort på brøt
26 med LDAP-spesifikasjonen, og henviste til hvor i LDAP-spesifikasjonen
27 fra IETF det sto at oppførselen til AD ikke fulgte
28 LDAP-spesifikasjonen. AD-spesialisten overrasket meg da ved å
29 fortelle at IETF var ikke de som definerte LDAP-spesifikasjonen, og at
30 Active Directory ikke brøt den virkelige LDAP-spesifikasjonen som han
31 mente lå til grunn. Jeg ble spesielt overrasket over denne
32 tilnærmingen til problemstillingen, da til og med Microsoft så vidt
33 jeg kan se anerkjenner IETF som organisasjonen som definerer
34 LDAP-spesifikasjonen. Jeg fikk aldri spurt hvem han mente sto bak den
35 egentlige LDAP-spesifikasjonen, da det var irrelevant for problemet vi
36 måtte løse (få Linux og AD til å fungere sammen). Dette møtet
37 fortalte meg uansett at det ikke er gitt at alle aktører er enige om
38 hva en standard er, og hva som er kilden til en gitt standard. Det er
39 vanskelig å enes om felles standarder før en først enes om hvem som
40 bestemmer hva en gitt standard innebærer.
</p
>
42 <p
>Hva er så en standard? I sin abstrakte form er det noe å samles
43 om. På engelsk er en av betydningene fane brukt i krig, du vet, den
44 type fane en samlet seg rundt på kamplassen i riddertiden. En
45 standard definerer altså et felleskap, noen som har noe felles. Det
46 er naturligvis mange måter å utgjøre et felleskap på. En kan
47 f.eks. enes om å gjøre alt slik som Ole gjør det, og dermed si at Oles
48 oppførsel er standard. Hver gang Ole endrer oppførsel endrer også
49 standarden seg uten noe mer organisering og prosedyre. En variant av
50 dette er å gjøre slik som Ole har gjort det i stedet for slik Ole til
51 enhver til gjør noe. Dette er ofte litt enklere å forholde seg til,
52 da en slipper å sjekke med Ole hver gang for å vite hvordan ting skal
53 gjøres nå, men hvis det Ole gjorde noe dumt den gang en bestemte seg
54 for å følge Ole, så er det vanskeligere å få endret oppførsel for å
55 unngå dette dumme.
</p
>
57 <p
>En kan også ta det et skritt videre, og istedet for å basere seg på
58 enkeltpersoners oppførsel sette seg ned og bli enige om hvordan en
59 skal gjøre ting, dvs. lage et felleskap basert på konsensus. Dette
60 tar naturligvis litt mer tid (en må diskutere ting i forkant før en
61 kan sette igang), men det kan bidra til at den oppførselen en
62 planlegger å benytte seg av er mer gjennomtenkt. Det ender også
63 typisk opp med en beskrivelse av ønsket oppførsel som flere kan forstå
64 - da flere har vært involvert i å utarbeide beskrivelsen.
</p
>
66 <p
>Dette er dessverre ikke alt som trengs for å forstå hva en åpen
67 standard er for noe. Der alle kan se på hvordan folk oppfører seg, og
68 dermed har valget om de vil oppføre seg likt eller ikke, så er det
69 endel juridiske faktorer som gjør det hele mer komplisert -
70 opphavsretten og patentlovgivningen for å være helt konkret. For å gi
71 et eksempel. Hvis noen blir enige om å alltid plystre en bestemt
72 melodi når de møtes, for å identifisere hverandre, så kan
73 opphavsretten brukes til å styre hvem som får lov til å gjøre dette.
74 De har standardisert hvordan de kjenner igjen alle som følger denne
75 standarden, men ikke alle har nødvendigvis lov til å følge den.
76 Musikk er opphavsrettsbeskyttet, og fremføring av musikk i
77 offentligheten er opphavsmannens enerett (dvs. et monopol). Det vil i
78 sin ytterste konsekvens si at alle som skal plystre en
79 opphavsrettsbeskyttet melodi i det offentlige rom må ha godkjenning
80 fra opphavsmannen. Har en ikke dette, så bryter en loven og kan
81 straffes. Det er dermed mulig for opphavsmannen å kontrollere hvem
82 som får lov til å benytte seg av denne standarden. En annen variant
83 er hvis en standard er dokumentert, så er dokumentet som definerer
84 standarden (spesifikasjonen) beskyttet av opphavsretten, og det er
85 dermed mulig for rettighetsinnehaver å begrense tilgang til
86 spesifikasjonen, og slik styre hvem som kan ta i bruk standarden på
89 <p
>Der opphavsretten innvilger et monopol på kunstneriske uttrykk med
90 verkshøyde, innvilger patentlovgivningen monopol på ideer. Hvis en
91 slik patentert idé (fortrinnsvis uttrykt i en teknisk innretning, men
92 det er kompliserende faktorer som gjør at det ikke er et krav) trengs
93 for å ta i bruk en standard, så vil den som innehar patent kunne styre
94 hvem som får ta i bruk standarden. Det er dermed ikke gitt at alle
95 kan delta i et standard-felleskap, og hvis de kan delta, så er det
96 ikke sikkert at det er på like vilkår. F.eks. kan rettighetsinnehaver
97 sette vilkår som gjør at noen faller utenfor, det være seg av
98 finansielle, avtalemessige eller prinsipielle årsaker. Vanlige slike
99 vilkår er
"må betale litt for hver kunde/bruker
" som utelukker de som
100 gir bort en løsning gratis og
"må gi fra seg retten til å håndheve
101 sine egne patentrettigheter ovenfor rettighetshaver
" som utelukker
102 alle som ønsker å beholde den muligheten.
</p
>
104 <p
>En åpen standard innebærer for meg at alle kan få innsikt i en
105 komplett beskrivelse av oppførsel som standarden skal dekke, og at
106 ingen kan nektes å benytte seg av standarden. Noen mener at det
107 holder at alle med tilstrekkelig finansiering kan få tilgang til
108 spesifikasjonen og at en kun har finansielle krav til bruk.
109 Pga. denne konflikten har et nytt begrep spredt seg de siste årene,
110 nemlig fri og åpen standard, der en har gjort det klart at alle må ha
111 komplett og lik tilgang til spesifikasjoner og retten til å gjøre bruk
112 av en standard for at en standard skal kunne kalles fri og åpen.
</p
>
117 <title>Standardize on protocols and formats, not vendors and applications
</title>
118 <link>../../Standardize_on_protocols_and_formats__not_vendors_and_applications.html
</link>
119 <guid isPermaLink=
"true">../../Standardize_on_protocols_and_formats__not_vendors_and_applications.html
</guid>
120 <pubDate>Mon,
30 Mar
2009 11:
50:
00 +
0200</pubDate>
122 <p
>Where I work at the University of Oslo, one decision stand out as a
123 very good one to form a long lived computer infrastructure. It is the
124 simple one, lost by many in todays computer industry: Standardize on
125 open network protocols and open exchange/storage formats, not applications.
126 Applications come and go, while protocols and files tend to stay, and
127 thus one want to make it easy to change application and vendor, while
128 avoiding conversion costs and locking users to a specific platform or
129 application.
</p
>
131 <p
>This approach make it possible to replace the client applications
132 independently of the server applications. One can even allow users to
133 use several different applications as long as they handle the selected
134 protocol and format. In the normal case, only one client application
135 is recommended and users only get help if they choose to use this
136 application, but those that want to deviate from the easy path are not
137 blocked from doing so.
</p
>
139 <p
>It also allow us to replace the server side without forcing the
140 users to replace their applications, and thus allow us to select the
141 best server implementation at any moment, when scale and resouce
142 requirements change.
</p
>
144 <p
>I strongly recommend standardizing - on open network protocols and
145 open formats, but I would never recommend standardizing on a single
146 application that do not use open network protocol or open formats.
</p
>
151 <title>Hvorfor jeg ikke bruker eFaktura
</title>
152 <link>../../Hvorfor_jeg_ikke_bruker_eFaktura.html
</link>
153 <guid isPermaLink=
"true">../../Hvorfor_jeg_ikke_bruker_eFaktura.html
</guid>
154 <pubDate>Thu,
23 Apr
2009 23:
00:
00 +
0200</pubDate>
156 <p
>Telenors annonsering om å kreve
35 kroner i gebyr fra alle som
157 ønsker papirfaktura har satt sinnene i kok, og pressedekningen så
158 langt snakker om at eldre og folk som ikke behersker data vil få en
159 urimelig ekstrakostnad. Jeg tror ikke jeg passer inn i noen av de
160 kategoriene, men velger å holde meg unna eFaktura - som er det
161 Telenor ønsker å få folk over på - pga. systemets egenskaper.
</p
>
163 <p
>Slik jeg har sett eFaktura til forbrukere så langt, så sender
164 selger en elektronisk beskjed til kundens bank, som legger ut
165 informasjon om fakturaen i nettbanken for godkjenning. Personlig
166 ville jeg sett det som mer naturlig at det gikk en elektronisk beskjed
167 fra selger til kunde, dvs meg, og at jeg så kunne bruke den videre
168 mot banken eller andre hvis jeg ønsket dette. Mine innkjøp og
169 regninger er jo en sak mellom meg og mine leverandører, ikke en sak
170 mellom min bank og mine leverandører. Kun hvis jeg ønsker å betale
171 fakturaen skal banken involveres. En faktura bør jo inn i
172 regnskapet, og jeg ønsker mulighet til å legge det inn der. Når
173 fakturaen sendes til banken i stedet for meg, blir det vanskeligere.
174 Hele eFaktura-modellen virker på meg som en umyndiggjøring av meg
177 <p
>I tillegg har jeg ikke vært i stand til å finne
178 eFaktura-formatets spesifikasjon, og det ser ut til at utsending av
179 slike krever dyre avtaler med bankene for å få lov til å sende ut
180 eFaktura til kunder. Jeg ser vel helst at fakturering på
181 elektroniske formater kan gjøres f.eks. via epost eller HTTP uten å
182 måtte betale mellommenn for retten til å lever ut en faktura, og
183 liker rett og slett ikke dagens faktureringsmodeller.
</p
>
188 <title>Standarder fungerer best når en samler seg rundt dem
</title>
189 <link>../../Standarder_fungerer_best_n__r_en_samler_seg_rundt_dem.html
</link>
190 <guid isPermaLink=
"true">../../Standarder_fungerer_best_n__r_en_samler_seg_rundt_dem.html
</guid>
191 <pubDate>Tue,
19 May
2009 11:
30:
00 +
0200</pubDate>
193 <p
>En standard er noe man samler seg rundt, ut fra ideen om at en får
194 fordeler når mange står sammen. Jo flere som står sammen, jo
195 bedre. Når en vet dette, blir det litt merkelig å lese noen av
196 uttalelsene som er kommet inn til
197 <a href=
"http://www.regjeringen.no/nb/dep/fad/dok/horinger/horingsdokumenter/
2009/horing---referansekatalog-versjon-
2/horingsuttalelser.html?id=
549423">høringen
198 om versjon
2 av statens referansekatalog over standarder
</a
>. Blant
199 annet Abelia, NHO og Microsoft tror det er lurt med flere standarder
200 innenfor samme område. Det blir som å si at det er fint om Norge
201 standardiserte både på A4- og Letter-størrelser på arkene, ulik
202 sporvidde på jernbaneskinnene, meter og fot som lengemål, eller
203 høyre- og venstrekjøring - slik at en kan konkurrere på hvilken
204 standard som er best. De fleste forstår heldigvis at dette ikke
205 bidrar positivt.
</p
>
210 <title>Microsofts misvisende argumentasjon rundt multimediaformater
</title>
211 <link>../../Microsofts_misvisende_argumentasjon_rundt_multimediaformater.html
</link>
212 <guid isPermaLink=
"true">../../Microsofts_misvisende_argumentasjon_rundt_multimediaformater.html
</guid>
213 <pubDate>Fri,
26 Jun
2009 15:
30:
00 +
0200</pubDate>
216 <a href=
"http://www.regjeringen.no/upload/FAD/Vedlegg/Hoeringer/Refkat_V2/MicrosoftNorge.pdf
">Microsoft
217 sin høringsuttalelse
</a
> til
218 <a href=
"http://www.regjeringen.no/nb/dep/fad/dok/horinger/horingsdokumenter/
2009/horing---referansekatalog-versjon-
2.html?id=
549422">forslag
219 til versjon
2 av statens referansekatalog over standarder
</a
>, lirer
220 de av seg følgende FUD-perle:
</p
>
222 <p
><blockquote
>"Vorbis, OGG, Theora og FLAC er alle tekniske
223 spesifikasjoner overordnet styrt av xiph.org, som er en
224 ikke-kommersiell organisasjon. Etablerte og anerkjente
225 standardiseringsorganisasjoner, som Oasis, W3C og Ecma, har en godt
226 innarbeidet vedlikeholds- og forvaltningsprosess av en standard.
227 Det er derimot helt opp til hver enkelt organisasjon å bestemme
228 hvordan tekniske spesifikasjoner videreutvikles og endres, og disse
229 spesifikasjonene bør derfor ikke defineres som åpne
230 standarder.
"</blockquote
></p
>
232 <p
>De vokter seg vel for å nevne den anerkjente
233 standardiseringsorganisasjonen IETF, som er organisasjonen bak HTTP,
234 IP og det meste av protokoller på Internet, og RFC-standardene som
235 IETF står bak. Ogg er spesifisert i
236 <a href=
"http://ietf.org/rfc/rfc3533.txt
">RFC
3533</a
>, og er uten
237 tvil å anse som en åpen standard. Vorbis er
238 <a href=
"http://ietf.org/rfc/rfc5215.txt
">RFC
5215</a
>. Theora er
240 under standardisering via IETF, med
241 <a href=
"http://svn.xiph.org/trunk/theora/doc/draft-ietf-avt-rtp-theora-
00.txt
">siste
242 utkast publisert
2006-
07-
21</a
> (riktignok er dermed teksten ikke
243 skrevet i stein ennå, men det blir neppe endringer som ikke er
244 bakoverkompatibel). De kan være inne på noe når det gjelder FLAC da
245 jeg ikke finner tegn til at
<a
246 href=
"http://flac.sourceforge.net/format.html
">spesifikasjonen
247 tilgjengelig på web
</a
> er på tur via noen
248 standardiseringsorganisasjon, men i og med at folkene bak Ogg, Theora
249 og Vorbis også har involvert seg i Flac siden
2003, så ser jeg ikke
250 bort fra at også den organiseres via IETF. Jeg kjenner personlig lite
253 <p
>Uredelig argumentasjon bør en holde seg for god til å komme med,
254 spesielt når det er så enkelt i dagens Internet-hverdag å gå
255 misvisende påstander etter i sømmene.
</p
>
260 <title>Regjerningen forlater prinsippet om ingen royalty-betaling i standardkatalogen versjon
2</title>
261 <link>../../Regjerningen_forlater_prinsippet_om_ingen_royalty_betaling_i_standardkatalogen_versjon_2.html
</link>
262 <guid isPermaLink=
"true">../../Regjerningen_forlater_prinsippet_om_ingen_royalty_betaling_i_standardkatalogen_versjon_2.html
</guid>
263 <pubDate>Mon,
6 Jul
2009 21:
00:
00 +
0200</pubDate>
265 <p
>Jeg ble glad da regjeringen
266 <a href=
"http://www.digi.no/
817635/her-er-statens-nye-it-standarder
">annonserte
</a
>
268 <a href=
"http://www.regjeringen.no/upload/FAD/Vedlegg/IKT-politikk/Referansekatalogen_versjon2.pdf
">statens
269 referansekatalog over standarder
</a
>, men trist da jeg leste hva som
270 faktisk var vedtatt etter
271 <a href=
"http://www.regjeringen.no/nb/dep/fad/dok/horinger/horingsdokumenter/
2009/horing---referansekatalog-versjon-
2.html
">høringen
</a
>.
272 De fleste av de valgte åpne standardene er gode og vil bidra til at
273 alle kan delta på like vilkår i å lage løsninger for staten, men
274 noen av dem blokkerer for de som ikke har anledning til å benytte
275 spesifikasjoner som krever betaling for bruk (såkalt
276 royalty-betaling). Det gjelder spesifikt for H
.264 for video og MP3
277 for lyd. Så lenge bruk av disse var valgfritt mens Ogg Theora og Ogg
278 Vorbis var påkrevd, kunne alle som ønsket å spille av video og lyd
279 fra statens websider gjøre dette uten å måtte bruke programmer der
280 betaling for bruk var nødvendig. Når det nå er gjort valgfritt for
281 de statlige etatene å bruke enten H
.264 eller Theora (og MP3 eler
282 Vorbis), så vil en bli tvunget til å forholde seg til
283 royalty-belastede standarder for å få tilgang til videoen og
286 <p
>Det gjør meg veldig trist at regjeringen har forlatt prinsippet om
287 at alle standarder som ble valgt til å være påkrevd i katalogen skulle
288 være uten royalty-betaling. Jeg håper det ikke betyr at en har mistet
289 all forståelse for hvilke prinsipper som må følges for å oppnå
290 likeverdig konkurranse mellom aktørene i IT-bransjen. NUUG advarte
292 <a href=
"http://wiki.nuug.no/uttalelser/
200901-standardkatalog-v2
">sin
293 høringsuttalelse
</a
>, men ser ut til å ha blitt ignorert.
</p
>
projects / homepage.git / blob