Om ÅÄÖ i dessa filerAndra KOM-möten frän denna tid
Om ÅÄÖ i dessa filer
Fredag 1988-06-03 02.17.53Standarder (inom) databehandlingsområdet
(Text 502343) 86-03-21 21.34 Jacob Palme QZ Namn: Standarder (inom) databehandlingsområdet I detta möte kan vi diskutera både existerande standard och pågående arbete på att ta fram nya standarder inom databehandlingsområdet. Speciellt aktuellt tidigare i det här mötet har varit standarder för tangentbord, teckenkoder, dokumentformatering, meddelandehantering och datornät. Standardiseringsarbetet inom databehandlingsområdet är en viktig kraft för att forma vår framtid inom detta område. Det handlar inte bara om att registrera det alla accepterar, utan i hög grad om utveckling och nyskapande.
(Text 502343)Standarder (inom) databehandlingsområdet Namn: Standarder (inom) databehandlingsområdet Nummer: Möte 642 Skapelsetid: 83-04-02 09.59 Organisatör: Jacob Palme QZ Antal till-länkar: 1573 Objekt: Text 816781 Typ: Öppet Antal medlemmar: 135 Standarder (inom) databehandlingsområdet har följande medlemmar: Senast inne Osett Namn 88-05-28 16.59 Jacob Palme QZ 88-05-28 19.40 Sven Olofsson QZ 88-05-28 23.14 Jan Engvald LDC 88-06-03 01.24 Torgny Hallenmark LDC 88-06-01 16.02 Björn Carlsson QZ ********* ***** 25 Michael Evans STOCC 88-06-01 20.16 232 Peter Svanberg NADA 86-07-06 01.35 709 Stig Björklund KTH 86-10-17 17.42 565 Sven Erik Enblom 88-05-29 15.40 Peter Olofsson QZ 86-12-17 10.45 522 Lars Collborg FOA2 88-01-22 12.30 155 Knut Smaaland UiO 88-04-29 17.21 6 Gunnar Tidner ABC-klubben 88-05-28 14.32 Johnny Eriksson 88-05-05 02.30 4 Viggo Eriksson 88-03-18 16.05 15 Lars-Henrik Eriksson 85-08-05 02.38 853 Tomas Ljungberg AIDA ********* ***** 1297 Bengt Righard ********* ***** 357 Per Svensson 88-04-21 18.19 214 Tomas Lindgren FOA3 88-05-01 23.33 4 Göran Neider 88-05-29 19.06 Torgny Tholerus QZ 88-06-01 19.15 Bo Kleve LIDAC 87-12-12 00.47 430 Jan Åman 88-05-28 23.55 Lars Enderin QZ ********* ***** 682 Per Danielsson 88-05-02 22.03 4 Henrik Eriksson NADA 88-01-12 10.39 194 Hans Eriksson SICS 87-04-11 15.45 437 Arkivering av KOM-inlägg 88-05-31 00.15 Tommy Ericson KOMunity 88-05-31 14.45 Bo Sundman Metallografi 88-05-02 23.18 4 Lars-Åke Larsson Dapugruppen ********* ***** 1573 Gunnar Mjöberg Digital Equipment 88-05-30 11.59 Lars Sjöström LIDAC ********* ***** 1011 Per Lindberg Servisen ********* ***** 810 Erik Sundström Statskontoret 88-06-02 20.48 212 Nisse Husberg TH Helsingfors 88-05-28 12.58 Lennart Nordström 88-05-29 22.13 Christer Welam - KTH och UUm 87-05-07 16.02 657 Lars Söderström 88-05-27 05.08 3 Bo Thide Inst f rymdfysik Uppsala ********* ***** 1400 Rabbe Fogelholm 88-05-30 15.03 Lars Hellberg Statskontoret 88-05-29 04.23 Överföring från NADJA 88-05-29 23.08 Sture Langemar QZ 88-05-28 16.24 Gert Svensson Datorsystem KTH ********* ***** 237 Alf Bengtsson FOA372 88-03-08 10.05 280 Birgitta Hillgren 88-05-29 03.27 -Hasse Sjöberg 88-05-31 23.50 Carl Crafoord KTH 88-05-31 13.46 Per Sira UiO 88-05-14 01.46 4 Göran Krook 88-06-01 09.53 Göran Stenviken 88-05-29 23.49 Olle Järnefors KTH 88-05-02 13.04 4 Wolf Arfvidson Statskontoret 88-05-02 20.27 4 Johan Lundberg TeleDelta 88-05-31 07.44 Sven-Ingvar Jönsson FOA3 88-05-23 21.05 4 Svante Lindahl (zap@nada.kth.se) 88-05-04 16.51 4 Bo Helmer FOA6 ********* ***** 346 Carl-Göran Gustafsson Statskontoret 88-01-06 00.27 200 Anders Öborn 88-05-07 11.10 4 Lars Rune Larsson Televerket 86-11-12 08.42 580 Jan Lund-Jensen KTHNET 88-05-30 12.05 Malin Edström QZ 88-06-01 13.25 Roger Genhult QZ-DK ********* ***** 960 Per Kjellsson STOCC ********* ***** 447 Christer Lindh SEMS (clindh@sems.se) 88-05-11 18.57 233 Magnus Björklund KOMunity ********* ***** 436 Lars Österdahl Riksmuseet ********* ***** 321 Kjell Larsson ABC-Klubben ********* ***** 708 Per Törnell MAGIS 88-04-09 21.46 241 Ingemar Sjörs FFA 88-05-28 22.22 Matti Rendahl NADA (matti@bion.kth.se) 88-05-28 21.52 Gunnar Engstrand Televerket Stockholm 88-04-18 22.06 15 Mats Forsenberg 88-05-30 22.38 Bengt Forsgren Televerket 88-05-29 16.32 Staffan Ögren Statskontoret ********* ***** 580 Joakim Rehn STOCC 88-05-29 20.27 Bernt Allonen TVT ********* ***** 846 Dag Hjorth Televerket ********* ***** 722 Eva Toller FOA3 88-05-31 08.51 Jörgen Malmborg TeleDelta 87-08-26 17.34 300 Raija Peltonen RRV 87-07-20 00.59 436 Jan Norden ********* ***** 723 Ulf Ergander KI 88-05-28 18.31 Jan Flodin FMV 88-03-28 14.18 39 Tönu Spuhl Tvt 87-12-12 16.25 404 Folke Hermanson Snickars SIS 86-11-25 09.27 526 Erik Bertelsen UNI-C Aarhus. 87-06-10 09.36 569 Lars Göte Johansson BEON 88-05-30 07.49 Jan Erik Wernersson Kristianstad TLO ********* ***** 546 Mattias Söderhielm 88-05-30 17.33 -Mats Ohlin Fst 88-05-30 13.39 Sven Erik Fjällman Statskontoret ********* ***** 50 Örjan Leringe 87-01-17 21.00 501 Helmer Gustavsson Riksantikvarieämbetet 88-05-30 14.54 PETER MAGNUSSON TELDOK 87-01-19 20.26 705 Cecilia Magnusson Statskontoret ********* ***** 499 Håkan Eriksson STOCC 88-06-01 22.04 Johan Stäck KOMMUNDATA 88-05-22 23.11 153 Anders Hillbo NADA 88-06-03 00.02 Krister Holmgren 87-02-23 23.36 480 Kari Jansson Pharmacia 88-05-28 13.21 Patrik Södergren 88-05-01 19.04 72 Stefan Hellberg Televerket/Pt 88-05-04 09.18 4 Sven Fransson Tvt HK ********* ***** 396 MIKAEL BOHLIN IVF 87-04-28 10.57 1573 grupp Standardisering 88-05-31 23.30 Matts Kallioniemi ********* ***** 268 LEIF M WAHLBERG STOCC ********* ***** 290 Johan Waldemarsson Kommundata 88-05-01 19.57 4 Benny Brodda Lingv Su 88-05-31 06.33 Stig Andersson STOCC ********* ***** 366 Bertil Lindberg TvT PQPC 88-05-29 22.30 Paul Hamacher QZ-DEC ********* ***** 302 Håkan Torbjörnsson Tvt Göteborg ********* ***** 96 Tomas Björklund Techno Logic AB ********* ***** 227 Ulf Kronman KIBIC 87-11-19 01.23 212 Håkan Abrahamsson Sthlms. Univ. 88-05-30 20.36 Anne-Marie Eklund Statskontoret 88-05-27 09.51 3 Torbjörn Lundberg Televerket 88-06-02 01.16 201 Arkivering av KOM-inlägg 88-03-17 19.53 15 Patrik Sjövall HKI 88-02-02 09.58 345 Ulf Persson Högskolan i Östersund 88-03-08 10.09 18 Robert Bohagen Kommundata 88-05-30 00.18 Torbjörn Nordlindh Apple Computer AB ********* ***** 129 Sören Janstål Data Research DPU 88-02-27 14.26 299 Per Åkesson Stocc 88-05-30 20.19 Karl Lindström ABC-klubben 88-05-30 23.39 Kent Fihlen Statskonsult ADB-Konstruktion 88-04-25 13.23 63 Anders Löfstrand Televerket Radio
(Text 724056)
(Text 724241)
(Text 724559) 87-10-28 00.44 Tommy Ericson KOMunity Mottagare: SUNET (Swedish University Network) erfarenhetsutbyte <1409> Extra kopia: Standarder (inom) databehandlingsområdet <1341> Extra kopia: Nät (både) datornät (och) terminalnät <1832> Kommentar till: (Text 724241) <2> För kännedom: Bertil Holmqvist Televerket <826> -- Mottaget: 87-11-01 17.17 Sändare: Bertil Thorngren -- Sänt: 87-10-28 22.48 Markerad av någon. Ärende: Sitter och tittar på floran av inlägg. Din fråga är verkligen på sin plats: på väldigt få ställen i den nuvarande debatten i mötet "Sunet erfarenhetsutbyte" ser man ofta "anti-ISO-OSI-uttalanden", tvärt emot vad man på många håll och under lång tid har försökt pusha för. Varför det då? Är inte ISO-OSI bra? Jo, i och för sig, men: 1) Det finns än så länge för få rena OSI-produkter att tillgå. (däremot finns det mycket från USA runt TCP/IP & friends, bara att gå till butiken och köpa...) 2) och därför Händer det för litet på de "rena" OSI-näten (om ni ursäktar denna inexakthet, kan förväxlas med de "nät" man brukar tala om inom skikt 3), man har för få att kommunicera med. Se bara på UUCP/EUNET! 3) Televerkets taxor för X.25-trafik är smärtsamt höga i relation till förhyrda fasta ledningar (till vilket man har protokoll- servers som snurrar på maskiner man fått från Wallenberg och andra för behjärtansvärda forskningsändamål, kanske inte helt sammanfallande, men dom helgar säkert varandra). OSI-ivrarna och -puritanerna månde våndas. Detta leder till att vi omger oss med icke-harmoniserade protokoll och tekniker. Och varför inte? Med distribuerat ansvar blir det en lokal uppgift att följa någon gemensam policy. Först om denna inte hålls tillräckligt smal kommer detta arbete att bli betungande och DÅ (om inte förr) kommer man att börja kräva bättre enhetlighet (=internationella standards). Men än har vi inte hört sista ordet om detta: det finns fortfarande plats för centrala initiativ som kan påskynda OSI-utvecklingen. Fotnot. med avsikt har jag skrivit "ISO-OSI" för att undvika sammanblandning med andra protokoll som passar in (med något mått) ISOs referensmodell - en modell som allt för många har tagit bokstavligt.
(Text 724559) (2 kommentarer)
(Text 725682) 87-10-29 17.52 Bernt Allonen TVT Mottagare: SUNET (Swedish University Network) erfarenhetsutbyte <1423> Kommentar till: (Text 725564) <1> För kännedom: Standarder (inom) databehandlingsområdet <1342> Sändare: Tommy Ericson KOMunity -- Sänt: 87-10-29 22.41 Extra kopia: Nät (både) datornät (och) terminalnät <1835> Sändare: Tommy Ericson KOMunity -- Sänt: 87-10-29 22.41 För kännedom: Nancy TNA <864> Markerad av någon. Ärende: Sitter och tittar på floran av inlägg. Efter att i åtta år ha deltagit i CCITTs och i någon mån ISOs arbete med OSI-modellen skikt 1-4 har jag blivit allergisk mot personer som tycks tro eller anse att; O S I = X . 2 5 Jag har heller aldrig sett något övertygande bevis på för varför jag skulle använda X.25 utanför paketnäten, i t.ex LAN- nät eller kretskopplade nät (DATEX och ISDN). Modellen kan inte heller användas för att välja eller begränsa antalet protokoll på ett viss skikt. Modellen kan inte heller entydigt fördela funktioner mellan skikten. Ett bra exempel på det senare är de protokoll som man nu diskuterar under arbetsnamnet "New Packet Mode" för digitala PABX och ISDN i ECMA och i CCITT SG XVIII. Där räknar man med att uttnyttja LAP-D på skikt 2 med fullt utnyttjande av ett förlängt adressfält som åxå används för multiplexering och "switching". Man behöver därför ingen motsvarighet till X.25 skikt 3 för dataöverföringen. Signalleringen för att sätta upp kopplet sker "utombands" på en egen skikt 2 länk. Både ISO och CCITT har idag stora svårigheter att beskriva detta protokoll med hjälp av modellen. Detta utlöser två typer av kommentarer; 1. Modellen "förbjuder" denna typ av protokoll. 2. Det behövs en ny eller förändrad modell. Det första argumentet är givetvis nonsens.
(Text 725682) (3 kommentarer)
(Text 726399)
(Text 726838)
(Text 727151)
(Text 727200)
(Text 729410)
(Text 729426)
(Text 729692)
(Text 729693)
(Text 730109)
(Text 730225)
(Text 730353)
(Text 730495)
(Text 730498)
(Text 733361) 87-11-12 20.11 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1356> För kännedom: VAX (VMS) erfarenhetsutbyte <2455> Extra kopia: Terminaler erfarenhetsutbyte <2430> Ärende: DEC Multinational Character Set (MCS) Att döma av VT220 Programmer Pocket Guide från 1984 så är denna 8-bits teckenkod, som jag antar DEC strävar efter att införa i alla sina system, *nästan* kompatibel med den internationella standarden ISO 8859-1 (8-bit single-byte coded graphic character set, Latin alphabet No 1). 15 av de 96 platserna för höga grafiska tecken är outnyttjade i MCS. Vad värre är: På 5 av platserna har MCS andra grafiska tecken än ISO 8859-1, varav 3 inte förekommer alls i ISO-koden. Är det någon som vet om DEC kommer att ändra sig efter ISO-stan- darden? (Det kanske redan är gjort, den kodtabell jag har till- gång till är ju flera år gammal.)
(Text 733361) (2 kommentarer)
(Text 733466) 87-11-12 23.32 Lars Sjöström LIDAC Mottagare: Standarder (inom) databehandlingsområdet <1357> För kännedom: VAX (VMS) erfarenhetsutbyte <2456> Kommentar till: (Text 733361) av Olle Järnefors KTH <1> Ärende: DEC Multinational Character Set (MCS) Nya VT320 hade en mystisk mode i set-upen ISO någonting. Ska kolla i den manualen. UNdrar om de inte böjar inse att man måste anpassa sig lite. Dessutom tror jag en TOPS-20 Nisse petat i VT320. Man kan mappa om ~-tangenten att skicka ESCape. Men bara i North American mode och några till. Inte svenska, suck.
(Text 733466) (1 kommentar)
(Text 733568) 87-11-13 10.17 Johnny Eriksson Mottagare: Standarder (inom) databehandlingsområdet <1358> För kännedom: VAX (VMS) erfarenhetsutbyte <2457> Kommentar till: (Text 733466) av Lars Sjöström LIDAC <1> Ärende: DEC Multinational Character Set (MCS) När DEC gjorde VT220 fanns inte ISO 8859/1. Däremot fanns en Draft Proposal till den, och DEC gjorde (i mitt tycke) det bästa man kunde gjort: man följde denna Draft. VT320 lär som sagt ha möjlighet att visa bägge.
(Text 733568) (1 kommentar)
(Text 733572) 87-11-13 10.19 Johnny Eriksson Mottagare: Standarder (inom) databehandlingsområdet <1359> För kännedom: VAX (VMS) erfarenhetsutbyte <2458> Kommentar till: (Text 733568) av Johnny Eriksson <1> Ärende: DEC Multinational Character Set (MCS) Apropå ~ och ESC: I Tops-10 version 7.03 finns monitorkommandot SET ESCAPE nnn, om man säger SET ESCAPE 176 kommer ~ att mappas till ESCAPE i terminaldrivern...
(Text 733572)
(Text 735878) 87-11-17 10.04 Gunnar Mjöberg Digital Equipment Mottagare: Standarder (inom) databehandlingsområdet <1360> För kännedom: VAX (VMS) erfarenhetsutbyte <2460> Kommentar till: (Text 733361) av Olle Järnefors KTH <2> Ärende: DEC Multinational Character Set (MCS) På sikt är ambitionen helt klar att gå från DECMCS till ISO 8859/1. Denna understryks inte minst av att X-Windows och DECwindows kör med ISO 8859/1. (Som tidigare nämnts, kan man på VT300-terminaler välja mellan DECMCS och ISO 8859/1.)
(Text 735878) (1 kommentar)
(Text 736682) 87-11-18 21.53 Tommy Ericson KOMunity Mottagare: Standarder (inom) databehandlingsområdet <1361> För kännedom: VAX (VMS) erfarenhetsutbyte <2462> Kommentar till: (Text 735878) av Gunnar Mjöberg Digital Equipment <1> Ärende: DEC Multinational Character Set (MCS) ==>> ISO 8859/1 Applåd! (Hoppas det drar med sig fler leverantörer...)
(Text 736682)
(Text 744437) 87-12-03 00.48 -KPJ Jaakkola utom tjänsten Mottagare: AMIS erfarenhetsutbyte <2832> Extra kopia: Standarder (inom) databehandlingsområdet <1362> Kommentar till: (Text 743535) av Håkan Ljungqvist QZ <2> Ärende: AMIS via Kermit Metoden är att just trycka på mellanslag efter ^, ', och `. Dessa är s.k diakritiska tecken som enligt nån standard ska bete sig så att de smälter ihop med nästa tecken. T.ex ska man genom att trycka på ~ (två prickar) och A få till Ä (A-med-två-prickar). Om du inte vill ha det så, skall du tala om det för din dator. Den klarar säkert av att slå av det. Har något med tangentbords- avkodningen att skaffa.
(Text 744437)
(Text 745252)
(Text 745255) 87-12-04 11.07 -Mats Ohlin Fst Mottagare: Microsoft Applikationer (MS/PC) DOS <152> För kännedom: Standarder (inom) databehandlingsområdet <1364> Kommentar till: (Text 704540) av Olle Järnefors KTH <3> Markerad av någon. Ärende: Olika 8-bits standardkoder Skamligt av X/OPEN att inte följa ISO. Har de angivit något skäl?
(Text 745255)
(Text 745462) 87-12-04 18.17 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1365> Markerad av någon. Ärende: ODA/ODIF Man säger ofta att ODA/ODIF (standard för att utbyta texter mellan ordbehandlingssystem) inte blir en framgång förrän de stora PC-program- varorna på området (Word Perfekt, Microsoft Word, WordStar o.s.v.) ger stöd för ODA/ODIF. Men de vill väl låsa sina kunder genom att inte stödja ODA/ODIF. Kunde man inte tänka sig istället att fristående leverantörer säljer program som "översätter" från internformatet för ordbehandlingsfiler för de olika PC-systemen, till ODA/ODIF-formatet?
(Text 745462) (3 kommentarer)
(Text 745948) 87-12-05 22.38 Michael Evans STOCC Mottagare: Standarder (inom) databehandlingsområdet <1366> Kommentar till: (Text 745462) av Jacob Palme QZ <1> Markerad av 2 personer. Ärende: ODA/ODIF En del av leverantörerna verkar inte full så kortsiktiga som du anger. Word Perfect levererar exempelvis ett program CONVERT som omvandlar till och från deras format och andra format inkl WordStar och IBM DCA RFT (Document Content Architecture - Revisable Format Text). Om WP-folket kunde se ett tillräckligt stor marknad eller såpass stora PR-vinster, så tror jag att de kommer att lägga till ODA/ODIF till den listan.
(Text 745948) (1 kommentar)
(Text 746152) 87-12-06 15.03 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1367> Kommentar till: (Text 745948) av Michael Evans STOCC <1> Ärende: ODA/ODIF Iden med ODA/ODIF är ju att istället för att de skall behöva tillhandahålla översättare till en massa olika format, så skall var och en bara behöva tillhandahålla en översättare till/från ODA/ODIF. Via ett mellanstadium i ODA/ODIF-format kan texter sedan överföras mellan alla olika slags ordbehandlare!
(Text 746152) (2 kommentarer)
(Text 746882) 87-12-07 22.51 Michael Evans STOCC Mottagare: Standarder (inom) databehandlingsområdet <1368> Kommentar till: (Text 746152) av Jacob Palme QZ <1> Ärende: ODA/ODIF Hos dagens leverantörer av PC ordbehandlare verkar IBMs DCA-RFT redan fylla den funktionen.
(Text 746882)
(Text 747161) 87-12-08 14.27 Lars Hellberg Statskontoret Mottagare: Standarder (inom) databehandlingsområdet <1369> Kommentar till: (Text 746152) av Jacob Palme QZ <2> Ärende: ODA/ODIF Jag tror att Datakonsulterna i Hässleholm har ett sådant konverteringsprogram som via ett mellanformat gör om filer från/till olika textbehandlares format, bl a ODA/ODIF.
(Text 747161) (1 kommentar)
(Text 746518) 87-12-07 13.35 Johan Lundberg TeleDelta Mottagare: SIS (Ag18) Textbehandlingssystem <181> Mottagare: Nancy TNA <894> För kännedom: Standarder (inom) databehandlingsområdet <1370> Sändare: Jacob Palme QZ -- Sänt: 87-12-10 19.19 För kännedom: B3 urval <116> Sändare: -- Sänt: 87-12-11 09.05 Markerad av 2 personer. Subject: rapport från MHS mötet i gloucester 1. Inledning Mötet hölls 28 oktober till 6 november i Gloucester (Fig 1), som ligger i västra England. Detta var det avslutande/sista mötet för den här studieperioden. Ordförande var Jim White från Telenet, USA. 2. Sammanfattning av mötet. Syftet med mötet var att få fram de dokument som skall godkännas av CCITT som rekommendationer. Detta innebar i princip att inga nya funktioner eller förslag till förbättringar kunde accepteras vid detta möte. Resultatet från mötet är sålunda en mer genomarbetad serie av rekommendationer. Följande rekommendationer kommer att ingå i CCITTs blå bok (böcker?) om MHS: ÄCCITT X.400 ö ISO 8505/1Å Message Handling: System and Service Overview. ÄCCITT X.402 ö ISO 8505/2Å Message Handling Systems: Overall Architecture. ÄCCITT X.403Å Message Handling Systems: Conformance Testing. ÄCCITT X.407 ö ISO 8505/4Å Message Handling Systems: Abstract Service Definition Conventions. ÄCCITT X.408Å Message Handling Systems: Encoded information type conversion rules. ÄCCITT X.411 ö ISO 8883/1Å Message Handling Systems: Message Transfer System: Abstract Service Definition and Procedures. ÄCCITT X.413 ö ISO nnnn/1Å Message Handling Systems: Message Store: Abstract Service Definition. ÄCCITT X.419 ö ISO 8505/3Å Message Handling Systems: Protocol Specification. ÄCCITT X.420 ö ISO 9065Å Message Handling Systems: Interpersonal Messaging System. Den uppmärksamme läsaren upptäcker genast att det saknas några rekommendationer jämfört med tidigare utgåvor. Det beror på att vi beslöt att slå samman de dokument som var protokoll- definitioner (X.412 och X.414) med dokument X.419. Många ansåg att det var lämplig att ha dem samlade. Jag anser att denna kosmetiska förändring inte förändrar något i sak. Det blir varken lättare eller svårare att ta till sig X.400(88). 3. Felrapporter Det mesta av texten i dokumenten har funnits tillgänglig en tid och varit föremål för granskning av ett stort antal människor. Trots det så finns det med stor sannolikhet fel kvar som om möjligt bör rättas till innan rekommendationerna ges ut som blå böcker. Därför inrättades en procedur för att rapportera fel. Vid CCITT Studiegrupp VIIs möte i mars 88 kommer förmodligen en lista av korrektioner till de preliminära rekommendationerna att godtas. 4. Conformance Systems överenstämmelse (Conformance på engelska, finns det ett bättre svenskt uttryck?) med X.400 rekommendationerna definieras i avsnittet "Conformance Statement" rekommendation X.419. Conformance för P1 visade sig vara kontroversiellt. Följande gäller för en domän som följer CCITT X.400(88): - RTSE X.410-1984 mode (dvs kompatibelt med X.400(84)). - P1 samtrafik med P1(84)(dvs kompatibelt med X.400(84)). - Lägre skikten oförändrat (dvs TP0 obligatoriskt, resten valbart, kompatibelt med X.400(84)). Följande gäller för en MTA som följer ISO MOTIS: - RTSE normal mode (dvs inte kompatibelt med X.400(84)). - Inga krav på samtrafik med P1(84) (dvs inte garanterat kompatibelt med X.400(84)). - Inga krav på de lägre skikten (dvs inte garanterat kompatibelt med X.400(84)). Jag är lite fundersam på om CCITT har valt rätt väg. Å ena sidan är det mycket viktigt att erhålla stor konnektivitet. Å andra sidan går det inte att testa en produkt i förväg (dvs typgodkännande) enligt CCITTs krav eftersom det ställer krav på en konfiguration snarare än en implementation. Dessutom så är övergången från en generation X.400 till en annan något som är avhängigt kraven från marknaden. Det kan ju tyckas lite onödigt att alla system i t ex Sverige måste kunna tala 84 om ADMDn (t ex Televerket) kan tala 88 och 84. Kravet på konnektivitet ansågs dock viktigare än enklare och eventuellt billigare implementationer. Gissningsvis kommer CCITT i nästa version (1992) att fasa ut X.400(84). 5. <MELLANSLAG> ADMD Ett krav från ISO att under vissa givna förutsättningar inte behöva ange ADMDnamn i en O/R address löstes på följande sätt: Fältet "ADMD" måste finnas i alla O/R Addresser. Värdet <MELLANSLAG> är reserverat då ingen ADMD skall anges. Förutsättningarna för att detta skall kunna tillämpas är att alla ADMD i ett land har avtal sinsemellan och att alla ADMD känner till vilka PRMD som är anslutna till vilken(a) ADMD. Skälet som ISO angett till varför denna möjlighet skall finnas är att en organisation/PRMD kan ha avtal med flera ADMD och inte vill favorisera/ange någon i sina O/R addresser. Konsekvenserna av detta är att de länder där denna procedur tillämpas måste samordnas på nationell basis. Dessutom måste den internationella trafiken hanteras på sådant sätt att det inte påverkar andra länders ADMD. 6. Utökningar av P2 6.1 Ny ContentType för 88 IPM(88) kommer att heta P22 ! En regel finns som säger att P22 endast skall användas då nya (88) funktioner eller datatyper används. I övriga fall skall P2 användas. 6.2 OBJECTIDENTIFIER Utökningar till IPM görs med hjälp av en speciell utökningsdatatyp (HEADING-EXTENSION) vars värde är av typen OBJECTIDENTIFIER. Tidigare var denna av typen INTEGER. Skillnaden innebär att vem som helst kan definiera nya utökningar till IPM. Mottagande system behöver endast agera på de utökningar de känner till. Övriga utökningar kan ignoreras. 6.3 Migrationsstrategi för IPM Som en följd av ovanstående beslut kan följande migrationsstrategi urskiljas. Om ett tillägg anses vara av sådan betydelse att "alla" måste känna till den skapas en ny contenttype. Om en utökning kan ignoreras görs den med hjälp av HEADING-EXTENSION. 7. Implementors Guide Ver 6 !! En ny version av Implementors Guide skall ges ut. Den kommer endast att innehålla en nyhet. Ett fel i X.410 RTS har upptäckts som innebär att under vissa olyckliga omständigheter kan ett meddelande sändas flera gånger. Detta är kanske inte så allvarligt om det är fråga om vanliga meddelanden men om det handlar om t ex en utbetalning av pengar (dåligt exempel) så skulle det innebära en viss förtjänst för mottagaren. 8. Terminal O/R Address och val av Tjänst I X.400(84) infördes möjligheten att skicka meddelanden till adressera en telematikterminal. Det som saknades var möjligheten att indikera viken typ av terminal som meddelandet var avsett för. Det är nödvändigt om det finns flera terminaltyper i samma nät. I t ex Storbritannien och Frankrike har man både teletex och telefax terminaler i samma nät. Ett svenskt bidrag accepterades som en lösning på detta problem. I och med att katalogsystem tas i bruk införs möjligheten att en potentiell mottagare har flera alternativa sätt att ta emot meddelanden, t ex fax mhs telex etc. Denna möjlighet kan styras från två håll, dels vad avsändaren önskar dels vad mottagaren önskar. I samband med att ett meddelande injiceras i MHS finns nu möjligheten att specificera på vilket sätt avsändaren önskar att meddelandet skall levereras. I katalogen kan mottagare ange en lista över de sätt denne/a önskar ta emot meddelanden. 9. Adress för Fysisk leverans av meddelanden Det tidigare förslaget till O/R address för fysisk leverans (postadress) av meddelanden medgav inte antändande av nationella tecken. Detta var givetvis oacceptabelt från svensk sida och ett svenskt förslag att ha möjlighet att antingen använda T.61 eller printablestring accepterades. Det är mycket märkligt att länder som inte är engelskspråkiga accepterade de lösningar som tidigare föreslagits. Vad som är ännu märkligare är att det är lilla Sverige som ensamt får driva den här typen av frågor. Förmodligen beror det väl på att det enbart är tekniker utan kunskap om kulturella skillnader som sitter i dessa kommitt`er.
(Text 746518) (2 kommentarer)
(Text 749045) 87-12-11 22.47 Jan Flodin FMV Mottagare: Standarder (inom) databehandlingsområdet <1371> Kommentar till: (Text 745462) av Jacob Palme QZ <2> Ärende: ODA/ODIF Word har i alla fall öppnat sig mot displaywrite mm med översättning till RFT-format. Jag tror man kommer med SPAG Q113 så småpningom i DTP-system.
(Text 749045)
(Text 749050) 87-12-11 22.48 Jan Flodin FMV Mottagare: Standarder (inom) databehandlingsområdet <1372> Kommentar till: (Text 747161) av Lars Hellberg Statskontoret <1> Ärende: ODA/ODIF Q113?
(Text 749050)
(Text 757086) 88-01-04 11.46 Hans Eriksson SICS Mottagare: Standarder (inom) databehandlingsområdet <1373> Kommentar till: (Text 745462) av Jacob Palme QZ <3> För kännedom: György Endersz <151> Sändare: Jan Flodin FMV -- Sänt: 88-01-04 17.25 Markerad av 2 personer. Ärende: ODA/ODIF Det finns ett IT4 projekt som just utvecklar programvara för att konvertera mellan ODA/ODIF och en del populära format såsom All-In-One, IBM DCA, Microsoft m.m. Jag vet inte mer om det men kan kanske skaka fram ett namn om någon vill nysta vidare.
(Text 757086) (1 kommentar)
(Text 759516) 88-01-09 16.53 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1374> Mottagare: Ordbehandling erfarenhetsutbyte <809> Extra kopia: Mats Ohlin Fst <6757> -- Mottaget: 88-01-11 16.24 Sändare: -Mats Ohlin Fst -- Sänt: 88-01-10 18.39 Ärende: ODA/ODIF Kan någon hjälpa mig svara på hans frågor, det jag inte kunnat svara på själv nedan: (299985) 88-01-09 16.51 /75 lines/ Jacob Palme QZ Receiver: @PLAID: desktop <50> Receiver: @JESSICA.STANFORD.EDU: morgan <2> Comment on: 299909 by @JESSICA.STANFORD.EDU: morgan <1> Subject: Re: ODA/ODIF ------------------------------------------------------------ > From: morgan@jessica.Stanford.EDU > > Yes, let's hear more about ODA/ODIF. As with so many convergences in > our modern world, there is one right around the corner involving word > processing, electronic mail, electronic publishing, hypermedia, > desktop publishing, etc. Yet another opportunity for those with > vision and tenacity to take the collective bull by the horns. I am no expert on ODA/ODIF, but will try to answer what I can, and try to find out more and give more answers later on: > Some interesting initial questions are: > > * How do we get the ODA/ODIF standards documents? You get them from the national standards organisation in your country, that is, for the U.S., the National Bureaux of Standards. > * How does ODA/ODIF compare with IBM's DCA, etc, which seems to be > becoming a defacto interchange standard in this country? I do not know, will try to find out. As we all know, there are three sometimes collaborating but too often competing major international standards making organisations: ISO, CCITT and IBM! A third alternative to ODA/ODIF and DCA is SGML. A difference between ODA/ODIF and SGML is that ODA/ODIF is a binary format, while SGML is a textual format, like RUNOFF, TeX, Scribe etc. SGML was initiated by IBM, but has also been accepted as an ISO standard, so ISO has actually two different standards of this kind, both ODA/ODIF and SGML. ODA/ODIF is however regarded as the major, and most advanced of them. > * How does ODA/ODIF relate to something like PostScript, which > (especially with its soon-to-arrive screen display versions) is an > interchange standard of a different sort? ODA/ODIF is on a higher level than PostScript. It allows both a logical and a physical description of a document at the same time. Graphics is in ODA/ODIF done using some ISO standard for Graphics, I belive GKS (Graphical Kernel System), this is not identical to PostScript. But of course it will be possible to write ODA/ODIF to PostScript translators. I am not sure if the reverse is possible, since PostScript is on a lower level. > * Are there implementations of ODA/ODIF? Well, that is what I was asking about. What I know is that in Europe there are several projects going on for developing ODA/ODIF translators. > * Is ODA/ODIF capable of rendering the sorts of hypermedia things we > (well, I at least) expect to do? I am not sure what you want, but I believe ODA/ODIF has most of the things you might want. I am not sure whether voice and animation is included if you want that also! I will try to find out. > * Is there already a mailing list/newsgroup on this topic anywhere? Not to my knowledge. > * And, um, what do the letters stand for? ODA = Office Document Architecture ODIF = Office Document Interchange Format ODA/ODIF is defined in several levels, so that you can implement only the simpler levels if you do not want to include in your implementation more advanced things like for example graphics. Thus, when you buy an ODA/ODIF implementation, carefully check which level of ODA/ODIF is supported. (299985)------------------------------
(Text 759516)
(Text 759652) 88-01-10 00.53 Jörgen Stiernborg CODE AB Kommentar till: (Text 758718) av Per Norrman Indek/KTH <2> Mottagare: Standarder (inom) databehandlingsområdet <1375> Sändare: Sven Olofsson QZ -- Sänt: 88-01-10 00.57 Ärende: Problem med DOS funktion 4BH NÄÄÄÄÄR! kommer KOM att visa ASCII 92 som bakstreck?
(Text 759652) (2 kommentarer)
(Text 759653) 88-01-10 01.12 Sven Olofsson QZ Mottagare: Standarder (inom) databehandlingsområdet <1376> För kännedom: Jörgen Stiernborg CODE AB <1188> -- Mottaget: 88-01-10 17.55 Kommentar till: (Text 759652) av Jörgen Stiernborg CODE AB <1> Markerad av: Peter Olofsson QZ Ärende: Problem med DOS funktion 4BH På min terminal visas ASCII 92 som bakåtstreck. Men om man väljer att visa dom 7-bitars tecken, som KOM-datorn sänder, enligt svensk 7-bitars teckenstandard (SIS 63 61 27) så kommer tecknet att visas som sista bokstaven i svenska alfabetet (versalt). Jag antar att du önskar att KOM-datorn skulle skicka tecken enligt någon slags 8-bitars teckenstandard så att bakåtstreck och sista bokstaven i svenska alfabetet representerades av olika 8-bitars koder? Finns det någon sådan svensk standard?
(Text 759653) (2 kommentarer)
(Text 759703) 88-01-10 11.50 Tommy Ericson KOMunity Mottagare: Standarder (inom) databehandlingsområdet <1377> Kommentar till: (Text 759652) av Jörgen Stiernborg CODE AB <2> Markerad av någon. Ärende: Problem med DOS funktion 4BH Jag tänkte just fråga vad du menar med att skriva hela 5 Vänster kantparenteser (ASCII 91 decimalt) mellan N och R... - Har man den ena så har man inte den andra (teckenstandarden). Din fråga är annars berättigad, svaret ligger i att gå över till 8-bits teckenstandard (samt att skrota alla gamla 7-bits- baserade terminaler). PortaCOM kommer inom kort att stödja "VT220-standarden", dvs DECs 8-bits, något senare också den "riktiga" ISO-standarden.
(Text 759703) (2 kommentarer)
(Text 759750) 88-01-10 15.24 Matts Kallioniemi Mottagare: Standarder (inom) databehandlingsområdet <1378> För kännedom: Jörgen Stiernborg CODE AB <1190> -- Mottaget: 88-01-10 18.01 Kommentar till: (Text 759653) av Sven Olofsson QZ <1> Ärende: Problem med DOS funktion 4BH Det måste väl inte vara just en svensk standard. Vad är det för fel med ISO's 8859/1 eller vad den nu heter. Supportas av DEC VT320 t ex.
(Text 759750)
(Text 759820) 88-01-10 18.00 Jörgen Stiernborg CODE AB Mottagare: Standarder (inom) databehandlingsområdet <1379> För kännedom: Jörgen Stiernborg CODE AB <1192> -- Mottaget: 88-01-10 18.00 Kommentar till: (Text 759653) av Sven Olofsson QZ <2> Ärende: Problem med DOS funktion 4BH SIS-folket har säkert någon standard där det finns. Annars har väl IBM satt en defacto-standard med sin utvidgade tabell. Duger gott för oss pragmatiker. Tänk själv: 11 000 000 datorer i världen där alla kan producera ett gement ö genoASCII 148 (även om de flesta inte vet vad det är. Jag har ett spel där det gäller att skjuta ner ö-n Ibland kommer det ett Ö, och det ger extra många poäng)
(Text 759820) (1 kommentar)
(Text 761544) 88-01-13 22.28 Lars-Åke Larsson Dapugruppen Mottagare: Standarder (inom) databehandlingsområdet <1380> Kommentar till: (Text 759703) av Tommy Ericson KOMunity <1> Markerad av någon. Ärende: Problem med DOS funktion 4BH Kan du förklara vad VT220-standarden innebär i stort samt vad den "riktiga" ISO-standarden innebär. Hur står dessa standarden i relation till "IBM-PC-standarden"? ASCII/ISO-7bits standard är bekant. (t ex att svenska nationella tecknen läggs på hakparanteserna osv) Men VT220 har jag bara hört nämnas som ett namn och inget annat. Har ISO också kommit med 8-bits standard???
(Text 761544) (2 kommentarer)
(Text 761679) 88-01-14 10.12 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1381> Kommentar till: (Text 761544) av Lars-Åke Larsson Dapugruppen <1> Ärende: Problem med DOS funktion 4BH IBM-pc "standarden har inte mycket likhet med VT220 vad jag vet. Det finns en ISO standard ISO 8859/1 som kodar tecken som en oktett. ISO har också en standard ISO 6937 som kodar en del tecken som en oktett och en del andra t ex åäö som två oktetter. VT220 påstås vara ganska nära 8859 men det finns säkert någon som kan säga vad som skiljer. Nu är det väl så att när man refererar till en terminal t ex VT100 eller VT220 så menar man väl inte bara det kodningssätt varmed tecken överförs på utan en hel del andra saker som antal tecken per rad antal rader tangentbordets utseende etc.
(Text 761679)
(Text 761897) 88-01-14 17.42 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1382> Kommentar till: (Text 761544) av Lars-Åke Larsson Dapugruppen <2> Extra kopia: KOM-systemet (-) grundläggande synpunkter <3298> Sändare: Matts Kallioniemi -- Sänt: 88-01-14 23.25 Markerad av någon. Ärende: Problem med DOS funktion 4BH Angående teckenkod i VT220 kontra ISO-standarder: Se inlägg 733361 med kommentarer i detta möte. Mer allmänt om ISO:s 8-bitskoder: 702671, 704540, 704619. Men skynda sig! Flera av dessa utmärkta inlägg kommer snart att städas bort ur KOM:s databas. IBMPC-koderna (från och med version 3.3 av MSDOS laborerar IBM med fem olika teckenkoder, så kallade code pages) har ingen annan relation till andra 8-bitskoder än att den undre halvan är likadan (nämligen 7-bits ASCII, med hakparenteser etcetera där vi brukar ha svenska bokstäver.
(Text 761897) (1 kommentar)
(Text 761901) 88-01-14 17.43 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1383> För kännedom: Jörgen Stiernborg CODE AB <1194> -- Mottaget: 88-01-19 00.22 Kommentar till: (Text 759820) av Jörgen Stiernborg CODE AB <1> Ärende: Problem med DOS funktion 4BH Din förtröstan på att stora, trygga IBM löser alla problem är nästan rörande, men förhastad. 1) Även om det finns si och så många miljoner IBMPC-kompatibla datorer så existerar miljontals andra smådatorer som _inte_ använder IBMPC-kod. Hört talas om Macintosh? 2) Merparten av all databehandling (i varje fall om man viktar med det ekonomiska värdet) utförs troligen fortfarande på mini- och stordatorer, som använder alla möjliga teckenkoder _utom_ IBMPC-kod. 3) Den i och för sig lyckliga teckenkodsharmoni som funnits inom IBMPC-världen har börjat upplösas. Till senaste versio- nen av MSDOS finns inte mindre än fem delvis olika "utvid- gade ASCII-koder" (code pages). Det beror på vissa klara designmissar i den ursprungliga IBMPC-koden. Kan du till exempel hitta litet danskt ö där? 4) I framtiden kommer behovet att växa starkt av att utbyta data också mellan maskiner av _olika_ typer med olika teckenkod. Därför är det nästan säkert att en allmän tecken- kodsstandard som används i kommunikation _mellan_ olika datorer (även om den inte används som teckenkod _inom_ så många datorsystem) kommer att ta form. 5) Den kodstandarden kommer _inte_ att vara en så kallad indu- stristandard, dikterad av IBM, utan kommer att bygga på de kodstandarder som finns inom ISO:s och CCITT:s OSI-ram. (ISO är den internationella sammanslutningen av världens offi- ciella standardiseringsorgan utanför elområdet. CCITT är televerkens internationella organisation. OSI betyder Open Systems Interconnection och är en samling av inbördes sam- ordnade standarder för alla aspekter på datakommunikation mellan främst olikartade datorsystem.) För detta antagande talar flera saker: a) Historisk erfarenhet: IBM försökte frälsa världen med teckenkoden EBCDIC för tjugo år sedan, samtidigt som den första officiella teckenkodsstandarden, ASCII, fastställ- des. Länge användes EBCDIC på fler datorer än ASCII. Numera kan vi dock se att EBCDIC var en återvändsgränd. Alla nya datorkonstruktioner (inklusive IBM-s egen PC) har teckenkoder som baseras på ASCII. b) Teknik: IBMPC-koden är helt enkelt tekniskt underlägsen de teckenkodsstandarder som utvecklas inom OSI-ramen. (Ännu värre var det med EBCDIC i förhållande till ASCII.) c) Demokrati: En officiell standard från till exempel ISO tillkommer genom en i princip demokratisk process. Allt arbete sker i öppenhet, alla intresserade parter kan delta, både producent- och konsumentintressen är repre- senterade, standardens utformning vägleds av tekniska överväganden, standarden fastställs genom consensus- beslut. En "industristandard" från IBM är ett diktat från en enskild aktör, som etableras med hjälp av de okunnig- aste marknadskrafterna. Den har bestämts av en för utom- stående opåverkbar och ofta helt okänd beslutsprocess inom IBM och kan när som helst ändras på väsentliga punkter av IBM, utan samråd eller ens förvarning. Många så kallade IBM-standarder är utformade med tanke på IBM:s egna marknadsmässiga intressen snarare än tekniska fak- torer. d) Psykologi: Det är lättare att få stridande viljor att enas om en lösning som inte direkt övertas från den starkaste av de inblandade, utan tillkommit genom en mer "objektiv" process. De som medvetet ställt sig utanför IBM-världen, till exempel de som köper minidatorer från Digital eller persondatorer från Apple, har ofta extra psykologiska spärrar mot anpassning till den stora fienden.
(Text 761901) (2 kommentarer)
(Text 761978) 88-01-15 04.24 Tommy Ericson KOMunity Mottagare: Standarder (inom) databehandlingsområdet <1384> För kännedom: Jörgen Stiernborg CODE AB <1195> -- Mottaget: 88-01-19 00.37 Kommentar till: (Text 761901) av Olle Järnefors KTH <1> Ärende: Problem med DOS funktion 4BH Bra sammanfattat, Olle!
(Text 761978)
(Text 762395) 88-01-15 18.11 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1385> Mottagare: SuperKOM erfarenhetsutbyte <906> Kommentar till: (Text 759703) av Tommy Ericson KOMunity <2> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Även i SuperKOM har vi för avsikt att införa hantering av bättre teckenstandard än 7-bits ISO 646(även kallad ASCII). Problemet är att om man inför en sådan avancerad teckenstandard, så måste man för varje användare veta vilken typ av terminal han har, och vilka tecken den terminalen kan visa, så att man kan skriva ut texten läsligt för olika användare med de tecken deras terminal har. Även ISO 646-terminaler kan ibland klara både bakstreck och O med två prickar på en gång, nämligen när de (som de flesta VT100-or) kan växla med SHIFT IN/SHIFT OUT mellan svensk och amerikansk teckenuppsättning. Men tyvärr är olika VT100-or inställda på olika sätt, så det räcker inte att veta att användaren har en VT100 heller. Av dessa skäl tänker vi i första versionen av SuperKOM att bara ha kvar gamla 7-bitskoderna. När vi inför en mera avancerad standard, så vill vi samtidigt införa stöd för att tecknen på vars och en terminal visas med vad den terminalen klarar, och det kräver en del jobb att ta fram konverteringsprogram för att konvertera texten till det vars och en terminal klarar. Att göra en editor för inmatning av text, som klarar alla olika terminalers olika teckenuppsättningar blir ännu värre. När man gör detta, så tror jag att det bästa är att gå in för att internt i databasen ha den mest kvalificerade teckenstandarden, ISO 6937, och sedan konvertera vid utmatningen till skärmen till det varje typ av skärm kan klara.
(Text 762395) (2 kommentarer)
(Text 762681) 88-01-16 01.25 Bo Thide Inst f rymdfysik Uppsala Mottagare: Standarder (inom) databehandlingsområdet <1386> Mottagare: SuperKOM erfarenhetsutbyte <907> Kommentar till: (Text 762395) av Jacob Palme QZ <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Vore det inte bra om varje användare för var och en av de terminaler han använder definierar full 8-bitarstabell som visar hur han/hon vill tolka en viss bitkombination. Man skulle väl kunna tänka sig att ha en tabell a la 'terminfo/termcap' i UNIX (kallad 'charinfo' ?) med denna information. Strängt taget skulle man kunna ha två: en för hur man tolkar varje tangent och en hur man tolkar varje byte som skrivs på skärmen. Detta skulle ge (som en biprodukt) en möjlighet till en viss elementär privat kodning/kryptering... Ex: När jag på mitt tangentbord trycker ner tangenten märkt 'x' vill jag att datorn skall uppfatta detta som 'a'. När jag från datorn får ett bitmönster som svarar mot 'y' skall detta presenteras som tecknet 'b' på skärmen. Jag tror detta är nödvändigt om man skall uppnå full flexibilitet eller har jag fel?
(Text 762681) (2 kommentarer)
(Text 762746) 88-01-16 11.22 Jan Flodin FMV Mottagare: Standarder (inom) databehandlingsområdet <1387> Mottagare: SuperKOM erfarenhetsutbyte <908> Kommentar till: (Text 762681) av Bo Thide Inst f rymdfysik Uppsala <1> För kännedom: IBM PC (och kompatibler) MS WINDOWS <153> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Så är det i Lotus Symphony. En filtertabell ut och en in. Man kan välja vilken tabell som skall användas vid olika kommunikationsfall. Man kan även välja en av tabellerna för läsning/skrivning av sk printfiler från/till diskett/hårddisk. Man man kan mycket lätt skapa egna tabeller, t ex genom att utgå från någon av de föredefinierade. När jag kör KOM via Symphony så använder jag en sådan modifierad tabell där jag låter byta ut de utgående tecken som QZ mår illa av mot något ofarligare, t ex blank eller nul. Symphony använder t ex CTRL-t som markering av nytt stycke i sin ordbehandling. Ge det till QZ och ni vet hur det blir på den egna skärmen! Jag har en annan tabell för körning mo unix-system. Osv. Jag rekommenderar därför varmt sådana privata tabeller i SuperKOM! Många privata problem klaras då lätt upp. Jag önskar att MS Windows hade något motsvarande att erbjuda applikationerna, liksom en modifierbar sorteringsrutin för tecken.
(Text 762746) (2 kommentarer)
(Text 762862) 88-01-16 15.43 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1388> Mottagare: SuperKOM erfarenhetsutbyte <909> Kommentar till: (Text 762681) av Bo Thide Inst f rymdfysik Uppsala <2> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Jag förstår inte riktigt vad du menar med en "8-bitarstabell". Menar du en tabell som en-entydigt översätter 8-bitarstecken i filen till 8-bitarstecken på skärmen. I så fall duger det inte. Om t.ex. den interna representationen i filen är ISO 6937, så är där ofta två tecken för något som bara skall bli ett tecken sänt till datorn. Även omvändningen kan förekomma, tecknet "vänster fyrkantig parentes" skall för vissa terminaltyper översättas till "shift out" (endast om man inte redan är i shift-out-mode) följt av bokstaven Ä, medan tecknet Ä (som i ISO 6937 är två tecken i filen) skall översättas till "shift in" (bara om skärmen inte redan är i shift-in-mod) följt av Ä. Dessutom skall man för den typ av skärm jag tänker på (VT100-kompatibel skärm) sända en initial styrsekvens allra först för att definiera att SHIFT-IN skall ge svensk teckenuppsättning och SHIFT-OUT amerikansk teckenupp- sättning.
(Text 762862) (2 kommentarer)
(Text 762893) 88-01-16 16.56 Bo Thide Inst f rymdfysik Uppsala Mottagare: Standarder (inom) databehandlingsområdet <1389> Mottagare: SuperKOM erfarenhetsutbyte <910> Kommentar till: (Text 762862) av Jacob Palme QZ <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM OK vill du ha 16 bitar så gärna för mig. Men med hjälp av 8 bitar kan man representera samtliga latinska bokstäver som används i VÄsteuropa, Amerika, Afrika och Australien (tex ISO 8859/1). Det finnsa alltså a priori inget behov av 16 bitar för oss svenskar. Shift-in och shift-out för svenska nationella tecken är ett otyg men om de förekommer så kan de läggas in i 16 bitars "ASCII". Annars brukar 16 bitar bara behövas för ostasiatiska språk. Native Language System i UNIX standarden, tagen av X/Open, bygger på 7/8/16 bitars "ASCII", men som sagt, inget hindrar att du använder 16 bitars kod för svenska tecken. Med nuvarande lösningen i NLS måste man dock bestämma sih för 16 bitar fö~r samtliga tecken vilket leder till slöseri med plats. Men som sagt, och som diskuterats tidigare här i KOM shift-in/shift-out-tekniken har sä mänga nackdelar att den bör förvisas till "bit bucket". Observera att dina editorer och övriga program måste kunna hantera 8/16 bitar. I o f s finns det sådana (HP-UX har t.ex både 7 8 och 16 bitarseditorer), men äterigen blir det slöseri att utnyttja 16 biatr för (vissa) svenska tecken!!
(Text 762893) (1 kommentar)
(Text 762921) 88-01-16 17.55 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1390> Mottagare: SuperKOM erfarenhetsutbyte <911> Kommentar till: (Text 762893) av Bo Thide Inst f rymdfysik Uppsala <1> För kännedom: Jan Bjurström FMV <339> -- Mottaget: 88-01-18 17.03 Sändare: Jan Flodin FMV -- Sänt: 88-01-16 19.21 För kännedom: Peder Swenman FFV Elektronik AB <559> -- Mottaget: 88-01-17 18.46 Sändare: Jan Flodin FMV -- Sänt: 88-01-16 19.21 Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Det finns dock flera starka skäl för att använda ISO 6937 och inte 8859 som huvudstandard i meddelandesystem: (1) X.400/84 har T.61 (i huvudsak identiskt med ISO 6937) som del av standarden, medan 8859 inte alls finns med. Det blir alltså lättare att sända texter mellan meddelandesystem som följer X.400 om man har texterna i T.61 än i 8859. (2) T.61/ISO 6937 anses av alla experter vara en kraftfullare standard. Den är gjord så att alla tecken i alla nationella språk världen över som baseras på varianter av latinska alfabetet kan skrivas. (3) Eftersom T.61 är kraftfullare, kan man ha T.61 för internlagring, men ändå sända 8859 till de användare vars terminaler jobbar med 8859. Detta gör att de som har kraftfulla skärmar kan visa alla tecken fullt ut, de som har svagare skärmar får i alla fall allt deras skärm kan klara av. (4) Ledande implementatörer av meddelandesystem sätter IA5 och T.61, men inte 8859, högst i sina implementeringsplaner.
(Text 762921) (3 kommentarer)
(Text 762933) 88-01-16 18.30 Tommy Ericson KOMunity Mottagare: Standarder (inom) databehandlingsområdet <1391> Kommentar till: (Text 762921) av Jacob Palme QZ <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Kan du nämna NÅGON tillverkare av terminaler som har gjort eller har hög prioritet på att bygga T.61/IS 6937-terminaler? Som alla vet finns det redan terminaler som stödjer IS 8859/1. Hur är det på persondatormarknaden - någon som som standard stödjer någon av 8859 eller 6937? Dessutom: ODA/ODIF torde stödja 8859/1, eller hur?
(Text 762933) (2 kommentarer)
(Text 762955) 88-01-16 19.10 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1392> Kommentar till: (Text 762933) av Tommy Ericson KOMunity <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Jag vet inte. Möjligen Siemens. Men det är inte nödvändigt att man internt inom ett meddelandesystem skall ha samma standard som terminalen. Det går också bra om man internt inom systemet har en kraftfullare standard, som man då kan översätta till terminalens standard. När två personer, som båda har 8859-terminaler, sänder brev till varandra, blir det ingen informationsförlust om breven är i format T.61/6937. Väljer man 8859 internt, får man informationsförlust när man vill överföra saker som 8859 inte klarar. Väljer man den mest kraftfulla standarden för intern lagring, T.61/6937, får man ingen informationsförlust. Siemens är inte oviktig. Det är en av Europas allra största dator- tillverkare. ISO 6937 innefattar drygt 300 olika tryckbara tecken, mot bara 192 i ISO 8859. Exempel på tecken som saknas i 8859: L med överstrykning, s med accent, pilar vänster höger upp och ner, 1/8, 3/8, 5/8, 7/8. Jag tror att bl.a. franska och spanska är språk, som innehåller tecken som 8859 inte klarar. Är ej helt säker på den saken.
(Text 762955) (3 kommentarer)
(Text 762986) 88-01-16 19.58 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1393> Kommentar till: (Text 762955) av Jacob Palme QZ <1> Mottagare: SuperKOM erfarenhetsutbyte <912> För kännedom: Jan Bjurström FMV <342> -- Mottaget: 88-01-18 17.04 Sändare: Jan Flodin FMV -- Sänt: 88-01-17 20.08 För kännedom: Peder Swenman FFV Elektronik AB <560> -- Mottaget: 88-01-18 20.33 Sändare: Jan Flodin FMV -- Sänt: 88-01-17 20.08 Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Jag har nu kollat vad som står i CEN/CENELEC functional standard för datorstödda meddelandesystem. Med reservation för att jag inte är säker på att jag har senaste versionen av denna, står det att den enda teckenstandard som man obligatoriskt kräver av alla meddelandesystem är IA5 (=ASCII 7-bitars = ISO 646). T.61 (nästan lik ISO 6937) anger man som obligatorisk för ADMD, men frivillig för privata domäner. Detta innebär väl antagligen att CEPT i sin functional standard, som jag inte kan hitta just nu, har T.61 som obligatorisk. ISO 8859 är överhuvudtaget inte nämnd alls i dessa standarder.
(Text 762986) (1 kommentar)
(Text 762987) 88-01-16 20.01 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1394> Mottagare: SuperKOM erfarenhetsutbyte <913> Kommentar till: (Text 762986) av Jacob Palme QZ <1> Markerad av någon. Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Utöver det vi nu diskuterat, så är det ju för meddelandesystem även intressant med ljud och grafik. Ifråga om grafik finns flera olika standarder att välja på. De flesta som jag bett om råd har dock rekommenderat oss att i SuperKOM välja Postscript, eller en delmängd av Postscript, som grafikstandard. ODA/ODIF använder dock instället en variant av GKS som grafik- standard, tror jag.
(Text 762987) (2 kommentarer)
(Text 762993) 88-01-16 20.37 Jan Engvald LDC Mottagare: Standarder (inom) databehandlingsområdet <1395> Kommentar till: (Text 762955) av Jacob Palme QZ <2> Markerad av någon. Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Jag håller med dig, JP, ISO 6937 är suverän för generell text. Den bör användas för lagringen av texterna. Men det är också en mycket god ide att ha en personlig tabell för att översätta detta till något som är lämpligt för ens egen skärm. Tabellen skall dock ej ha 16 bitars ingång (64 K möjligheter) utan endast 9 bitar (512 möjligheter) eftersom ISO 6937 inte definierar fler tecken (endast ca 300?). Tabellutgångarna bör ha variabel längd, annars är det alltid något fall som man inte förutsett och som ej får plats. I ISO 6937 är det bara en kolumn om 16 st diakritiska tecken som paras ihop med vissa andra tecken (i huvudsak vanliga bokstäver). Jag föreslår därför att tabellens ingångar anordnas enl 256 + 16*x, där x är antalet tecken som kan föregås av något diakritiskt tecken. Och att utgångarna är en godtycklig multipel av 8 bitar, för att klara 8-bits- och 7-bits + paritet-tecken, shift-out/shift-in sekvenser etc. Tabellen för översättning av det inmatade kan nog vara en med 8 bits ingång och 16 bits utgång. Man bör enkelt kunna välja mellan olika tabeller eller ingen översättning alls. (Sådana tabeller borde finnas på alla datorer, när kommer SET TERMINAL/TRANSLATE_FILE= i VAX/VMS.)
(Text 762993) (2 kommentarer)
(Text 763275) 88-01-17 16.59 Alan Sheats Afasiförbundet Mottagare: Standarder (inom) databehandlingsområdet <1396> För kännedom: IBM PC (och kompatibler) MS WINDOWS <156> Kommentar till: (Text 762746) av Jan Flodin FMV <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Hur fungerar tabellerna för sortering enligt nationell lexikografisk ordning i Symphony? Omvandlas all text till en intern kod innan sortering sker eller kollar programmet i tabellen under själva sorterring? Hur är hastigheten? Har du någon uppfattning om hur sortering med Symphony står sig mot sortering med DOS sort eller mot en optimerad quicksort?
(Text 763275) (1 kommentar)
(Text 763418) 88-01-17 20.16 Jan Flodin FMV Mottagare: Standarder (inom) databehandlingsområdet <1397> För kännedom: IBM PC (och kompatibler) MS WINDOWS <157> Kommentar till: (Text 763275) av Alan Sheats Afasiförbundet <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Man får gratis från Lotus repr DataTeam en diskett med 'Single Drivers' att addera till det bibliotek man använder när man installerar Symphony. Där finns drivrutiner för vissa Facitskrivare samt 'Collating drivers' för nordiska tecken. Man kan välja mellan 'numbers first' och 'numbers last'. Hur det går till i programkoden är slöseri med tid för mig att ta reda på. Jag kan gissa att man i källkoden har en funktion man anropar för att ta reda på vad som är större än vad. Den funktionen döljer väl i sig denna tabell, som alltså 'collating driver' installerar. Klassiskt från läroböcker, se t ex Software Tools in Pascal, Kernighan och Plauger. Kolla med DataTeam, även om jag satsar en slant på att dom vet mindre än jag. Du får nog ringa dom på andra sidan Karls Kanal (Cambridge, MASS) eller Datateam i Danmark, där jag vet att dom kan det här.
(Text 763418)
(Text 763472) 88-01-17 21.20 Bo Thide Inst f rymdfysik Uppsala Mottagare: Standarder (inom) databehandlingsområdet <1398> Kommentar till: (Text 762955) av Jacob Palme QZ <3> För kännedom: SuperKOM erfarenhetsutbyte <919> Sändare: Jacob Palme QZ -- Sänt: 88-01-18 16.40 Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM ISO 8859 finns ju i flera varianter. /1 var den jag åsyftade som bäst för svenska och övriga västeuropeiska språk. Jag talar också bara om "8-bitarsterminaler" (med "Meta"/"Altmode" tangenter) i första hand, men inserr problemet med andra, mindre flexibla terminaler. Frågan gäller i mångt och mycket om man skall ha det mest generella/"standardiseringsteoretiskt fulländade" eller det mest flexibla/"användarvänliga" (hemska ord - No flames please, som man säger ...). Faktum är att T.61 inte slagit igenom på UNIX-sidan (ännu). X/Open har definierat 8859/1 som sin standard för Native Language System. Vill minnas att du fick del av mitt utskick i höstas avseende NLS - kolla får du se.
(Text 763472) (2 kommentarer)
(Text 763477) 88-01-17 21.22 Bo Thide Inst f rymdfysik Uppsala Mottagare: Standarder (inom) databehandlingsområdet <1399> Mottagare: SuperKOM erfarenhetsutbyte <916> Kommentar till: (Text 762987) av Jacob Palme QZ <1> Markerad av någon. Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM En del tror ju att Postscript bara kommer att dansa en sommar och att mer seriösa saker som DDL kommmer att ta över. Ho vet.
(Text 763477) (3 kommentarer)
(Text 763515) 88-01-17 22.05 Lars-Åke Larsson Dapugruppen Mottagare: Standarder (inom) databehandlingsområdet <1400> Mottagare: SuperKOM erfarenhetsutbyte <917> Kommentar till: (Text 763477) av Bo Thide Inst f rymdfysik Uppsala <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Det är väl så att marknadsspridningen sätter den reella standarden. Om Postscript inte finns på de billigaste maskinerna så slår det heller knappast igenom på marknaden. Och sedan kommer något nytt smart system ut på marknaden. Och om då inte Postscript redan är allmänt accepterat och utbrett så kommer det nya systemet att ta över om det är bättre. F.n. sätts den reella standarden på laserprintermarknaden av HP Laserjet plus. De stora köpargrupperna är mycket medvetna om hur mycket nytta de får för en viss summa pengar.
(Text 763515) (1 kommentar)
(Text 763540) 88-01-17 22.39 Ragge Sundblad (ragge@nada.kth.se) Mottagare: Standarder (inom) databehandlingsområdet <1401> Mottagare: SuperKOM erfarenhetsutbyte <918> Kommentar till: (Text 763477) av Bo Thide Inst f rymdfysik Uppsala <2> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Så du tillhör de som tror att allt som är flexibelt, genomtänkt och bra är "oseriöst". Du tillhör de som tycker att IBMs maskiner är de som gäller eftersom de är dåliga, gammal "beprövad" teknologi, användarovänliga och inte programmeras av folk som programmerar därför att de tycker att det ger dem något, utan bara därför att de får betalt. Tillhör du också de som tycker att arbetsuppgifter som är roliga inte skall avlönas, utan att meningen är att alla skall vantrivas på sina jobb och inte få hålla på med det de vill?
(Text 763540) (1 kommentar)
(Text 763883) 88-01-18 16.40 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1402> Kommentar till: (Text 763472) av Bo Thide Inst f rymdfysik Uppsala <1> Mottagare: SuperKOM erfarenhetsutbyte <920> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Ur användarsynpunkt spelar det ingen roll vilken teckenstandard som används för lagring av texterna internt i ett meddelandesystem. Användarna berörs normalt bara av den standard i vilken texterna överförs till, och visas på, deras skärmar. Däremot kan fler användare bli mer nöjda om man internt i systemet har den mest flexibla teckenstandarden. Då kan ju fler få se de tecken de vill få se.
(Text 763883) (1 kommentar)
(Text 763889) 88-01-18 16.46 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1403> Mottagare: SuperKOM erfarenhetsutbyte <921> Kommentar till: (Text 763477) av Bo Thide Inst f rymdfysik Uppsala <3> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Utöver Postscript och DDL är tänkbara alternativ för grafik ISO 8632 (Är det samma sak som Computer Graphics Metafile? Är det en delmängd av GKS?), IGES (=International Graphics Exchange Standard, en IBM-produkt trore jag) och NAPDLS. Jag är angelägen att vi på QZ för SuperKOM väljer samma notation för grafik som Komunity Software AB väljer för framtida utveckling av PortaCOM, så att systemen skall kunna tala med varandra.
(Text 763889) (2 kommentarer)
(Text 763933) 88-01-18 17.25 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1404> Mottagare: SuperKOM erfarenhetsutbyte <922> Kommentar till: (Text 763889) av Jacob Palme QZ <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Jag har nu hittat uppgift om att ISO/DIS 8632 innehåller Computer Graphics Metafile, som bygger på GKS. Det är en standard speciellt gjord för att skicka grafik mellan datorer. Men tyvärr inte den enda standarden på detta område!
(Text 763933)
(Text 763934) 88-01-18 17.25 Bo Thide Inst f rymdfysik Uppsala Mottagare: Standarder (inom) databehandlingsområdet <1405> Mottagare: SuperKOM erfarenhetsutbyte <923> Kommentar till: (Text 763883) av Jacob Palme QZ <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Jo, det verkar vara en vettig synpunkt.
(Text 763934)
(Text 763944) 88-01-18 17.33 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1406> För kännedom: SuperKOM erfarenhetsutbyte <924> Kommentar till: (Text 763472) av Bo Thide Inst f rymdfysik Uppsala <2> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Jamen det är ju just det där superteroretiska som är så bra med ISO 6937. Att den klarar en framtida utveckling. Risken är ju annars att vi hamnar i samma soppa en gång till om man väljer standarder utan flexibilitet.
(Text 763944) (2 kommentarer)
(Text 764080) 88-01-18 20.22 Bo Thide Inst f rymdfysik Uppsala Mottagare: Standarder (inom) databehandlingsområdet <1407> För kännedom: SuperKOM erfarenhetsutbyte <925> Kommentar till: (Text 763944) av Johan Lundberg TeleDelta <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Jag är beredd att acceptera argumentet om framtida utveckling om du kan visa på exempel. Jag vet inget om detaljerna i 6937 men vad jag fÖrstår klarar 8859 alla språk med latinska tecken så jag är lite undrande till vad som menas med "framtida utveckling" Nya språk i Europa/nya bokstäver i existerande språk eller vad? Jag är nyfiken på att få veta vad jag kan läsa mer om 6937 bl a eftersom jag är inbalndad lite pÅ ett hörn där man ämnar skriva en emacs-klon med full 8-bitarssupport (alltså i den pragmatiska meningen att ALLA vÄsteuropeiska språk med latinska bokstver skall kunna klaras av). Givetvis kommer det att krävas 8bitarsterminal och meta/alt-tangent (dvs vt100 är ute, men vt220 skall gå). Vi hade i vårt oförstånd trott att det skulle gå med 3 tabeller, en fr 8-bitarstangentbordet, en för 8-bitarskärmen (båda leverantörsberoende) och en för interna representationen (t ex ISO 8859/1 alt. HP ROMAN8). Om detta inte ger full flexibilitet får vi givetvis tänka om...
(Text 764080) (4 kommentarer)
(Text 764121) 88-01-18 21.04 Peter Löthberg (roll@stacken.kth.se) Mottagare: Standarder (inom) databehandlingsområdet <1408> För kännedom: SuperKOM erfarenhetsutbyte <926> Kommentar till: (Text 764080) av Bo Thide Inst f rymdfysik Uppsala <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Måste man speca teckenset x eller y, kan man bara inte ta den smörja användaren producerar och bara (spara) den som 8 bits bytes bara.. Utan att försöka förså vad som står i datadelen. (x400 encrypted)
(Text 764121) (2 kommentarer)
(Text 764240) 88-01-18 22.50 Tommy Ericson KOMunity Mottagare: Standarder (inom) databehandlingsområdet <1409> Kommentar till: (Text 763944) av Johan Lundberg TeleDelta <2> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Det viktigaste är inte att man idag kan välja EN standard som är den oändliga lösningen, utan snarare att man väljer ett standardiseringsFÖRFARENDE som möjliggör en mjuk framtida övergång till någonting (som vi då finner) bättre, samma principer som jag försökte få in i katalogsystemet. Utgående från den pågående debatten kan man se att det finns meriter med både T.61 och 8859/1, båda lär komma att finnas.
(Text 764240)
(Text 764243) 88-01-18 22.53 Tommy Ericson KOMunity Mottagare: Standarder (inom) databehandlingsområdet <1410> För kännedom: SuperKOM erfarenhetsutbyte <927> Kommentar till: (Text 764121) av Peter Löthberg (roll@stacken.kth.se) <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Tja, åtminstone mottagaren bör väl få en liten ledtråd om vad det är... Man ger datatyperna standardiserade (överenskomna) typbeteckningar alltså. Eller via ytterligare ett steg om man i stället kommer överens om hur man skall BESKRIVA en datatyp (inklusive semantik, grafisk representation eller vad som kan behövas).
(Text 764243)
(Text 764288) 88-01-19 00.37 Jörgen Stiernborg CODE AB Mottagare: Standarder (inom) databehandlingsområdet <1411> För kännedom: Jörgen Stiernborg CODE AB <1200> -- Mottaget: 88-01-19 00.37 Kommentar till: (Text 761901) av Olle Järnefors KTH <2> Ärende: Problem med DOS funktion 4BH Jag är ingen IBM-fantast, men jag är pragmatiker. 1. Jodå, jag har hört om TI-99 också. Men Apple har inte ens tiondelen av antalet maskiner i PC-familjen. Dessutom har jag för mig att Apple på punkt efter punkt viker för marknaden... 2. Merparten av all databehandling sker säkert på stordatorer och minidatorer. Men det största ANTALET PERSONER som arbetar med/använder datorer kör PC, både vad gäller antalet individer och deras totala körtid per vecka (och det beror inte på att deras datorer är såvärs mycket långsammare än den första gruppens) 3. Nej, och inget versalt norskt heller. Jättemiss, om vi skall prata historia. 4. Det var just därför president Johnson satte igång arbetet med ASCII-koden på den tid det begav sig. Om vi fortfarande skall prata historia. Och det är just av den anledning du påpekar här som jag förordar mer handling och mindre snack. 5. Det är inte ett diktat från IBM, utan ett förslag från elva miljoner datorförare. 5d. Psykologi, visst. Men hur länge har vi råd att sitta och gulla med de jämförelsevis få det handlar om.
(Text 764288) (3 kommentarer)
(Text 764339) 88-01-19 04.24 Överföring från NADJA Mottagare: Standarder (inom) databehandlingsområdet <1412> Kommentar till: (Text 762993) av Jan Engvald LDC <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Original: (Text 61745) 88-01-18 05.10 (11) Dan Norstedt Sändare: Dan Norstedt -- Sänt: 88-01-18 05.10 Sändare: Dan Norstedt -- Sänt: 88-01-18 05.10 Om man skall få effektivast möjliga utmatning till en VT100 med tecken ur olika teckenuppsättningar räcker inte en tabell, man måste ha en status-variabel som håller rätt på vilken teckenuppsättning som är vald. Sedan är det en annan sak om det är mödan värt. Inmatning på samma terminal är väl värre; hur skall man kunna mata in både t ex vänster hakparantes och 'Ä' med en 8-bits ingång? Prefix-tecken är väl den enda praktiskt användbara metoden (om man inte klarar sig med att definiera om kontroll-tecken).
(Text 764339) (1 kommentar)
(Text 764378) 88-01-19 08.33 Lars Hellberg Statskontoret Mottagare: Standarder (inom) databehandlingsområdet <1413> Mottagare: SuperKOM erfarenhetsutbyte <928> Kommentar till: (Text 763515) av Lars-Åke Larsson Dapugruppen <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Å andra sidan har både HP och IBM annonserat att de ansluter sig till Postscript.
(Text 764378)
(Text 764397) 88-01-19 09.18 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1414> För kännedom: SuperKOM erfarenhetsutbyte <929> Kommentar till: (Text 764080) av Bo Thide Inst f rymdfysik Uppsala <2> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Jag vet inte om det där med latinska alfabet är relevant. Inom EG har man ju faktiskt grekiska att ta hänsyn till. Så det kan mycket väl bli så i en framtid att man kräver att man skall klara av andra teckenmängder än enbart den latinska. Dessutom tror jag att det finns en rad "konstiga" bokstäver inom den "latinska" ramen som inte rymms inom den något begränsade uppsättningen 8859/1. Hur är med de bokstäver man har på island t ex. OK dåligt exempel, det är ju en liten språkgrupp som man kan köra över. Jag har under ett antal år försökt förklara för anglosaxer att det finns något annat än A-Z. För att själv inte begå samma misstag gentemot andra språkgrupper har jag valt att argumentera för det mest flexibla dvs ISO 6937 alt T.61. Det här med teckenmängder är j-lgt känsligt och är inte ett tekniskt problem utan snarare en oförmåga att förstå andra kulturer. (. Vi måste ju hitta på nåt för att konsumera all CPU sekunder vi får till skänks.)
(Text 764397) (2 kommentarer)
(Text 764418) 88-01-19 09.50 Bo Thide Inst f rymdfysik Uppsala Mottagare: Standarder (inom) databehandlingsområdet <1415> För kännedom: SuperKOM erfarenhetsutbyte <930> Kommentar till: (Text 764397) av Johan Lundberg TeleDelta <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Det om latinska bokstäver och ISO8859/x, x=1,2,... har jag läst i officiella dokument, men eftersom jag inte kan alla språk jag talar om har jag inte haft möjlighet att experimentellt kontrollera riktigheten av dokumenten.
(Text 764418) (1 kommentar)
(Text 764431) 88-01-19 10.00 Bo Thide Inst f rymdfysik Uppsala Mottagare: Standarder (inom) databehandlingsområdet <1416> För kännedom: SuperKOM erfarenhetsutbyte <931> Kommentar till: (Text 764418) av Bo Thide Inst f rymdfysik Uppsala <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Finns det någon som skulle vilja sända en fotokopia av ISO 6937 dokumentet vore jag väldigt tacksam. Jag ser i dokumentet om ISO 8859/1 att man refererar till ISO 6937/2, så det finns (minst) två 6937 också... I samma dokument ser jag att: "The coded character set of this part of ISO 8859 (alltså 8859/1, min anm.) contains graphic characters used in AT LEAST (min emfas) the following countries: Argentina, Australia, Austria, Belgium, Belize, Bolivia, Brazil, Canada, Chile, Costa Rica, Cuba, Denmark, Ecuador, Faroe Islands, Finland, France, Germany, Guatemala, Guyana, Honduras, Iceland, Ireland, Italy, Liechtenstein, Luxemburg, Mexico, New Zealand, Nicaragua, Norway, Panama, Paraguay, Peru, Portugal, El Salvador, Spain, Surinam, Sweden, Switzerkand, The Netherlands, United Kingdom, United States, Uruguay, Venezuela" Enligt hörsågen skall 8859/2 ta hand om andra språk som polska, tjeckiska, serbo-kroatiska, turkiska etc... Nån som vet?
(Text 764431) (2 kommentarer)
(Text 764438) 88-01-19 10.21 Bo Thide Inst f rymdfysik Uppsala Mottagare: Standarder (inom) databehandlingsområdet <1417> För kännedom: SuperKOM erfarenhetsutbyte <932> Kommentar till: (Text 764431) av Bo Thide Inst f rymdfysik Uppsala <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM När jag rotade lite till hittade jag 8859/2 också. Citat: The coded character set of this part of ISO 8859 (/2, min anm.) contain graphic characters used in AT LEAST (min emfas) the following countries: "Albania, Austria, Czechoslovakia, Germany, Hungary, Poland, Romania, Switzerland, Yugoslavia". Det som tilltalar mig är X/Opens adaptering av 8859, samtidigt som man har definerat 16 bitar för icke-latinska språk (ostasiatiska bl.a). Som någon sa, det är inte HUR man kodat i 8/16 bitar utan det faktum ATT man kodat i 8/16 bitar som är viktigt så att vi kan slippa shift-in shift-out i framtiden...
(Text 764438) (1 kommentar)
(Text 764974) 88-01-20 09.20 Bo Thide Inst f rymdfysik Uppsala Mottagare: Standarder (inom) databehandlingsområdet <1418> För kännedom: SuperKOM erfarenhetsutbyte <933> Kommentar till: (Text 764438) av Bo Thide Inst f rymdfysik Uppsala <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Ytterligare letande i mina högar gav till resultat att jag även hittade ISOs dokument 6937/1 och 6937/2 . (Kopiorna skickades till mig i höstas av Olle Järnefors, KTH. Tack Olle!)!
(Text 764974)
(Text 767102) 88-01-24 18.04 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1419> Kommentar till: (Text 764339) av Överföring från NADJA <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Vill man kunna mata in både vänster hakparantes och Ä får man väl ha ett editor-kommando som heter "alfabet" med parametrar "svenskt", "amerikanskt" o.s.v.
(Text 767102) (1 kommentar)
(Text 767103) 88-01-24 18.08 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1420> För kännedom: SuperKOM erfarenhetsutbyte <934> Kommentar till: (Text 764121) av Peter Löthberg (roll@stacken.kth.se) <2> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Det är ett viktigt krav du ställer där. Det måste finnas ett sätt att sända en byteström och få fram den oförstörd hos mottagaren. (Jag drabbades nyligen av att ett C-program, som sändes till mig från Frankrike, fick alla å och ä försvunna - de tecknen är viktiga i C! - sedan brevet gått genom en gateway ASCII-EBCDIC och tillbaka igen EBCDIC-ASCII.) I X.400 finns en parameter man kan sätta på ett meddelande som säger att ingen konvertering får ske. Väljer man den parametern, borde man därefter kunna välja godtycklig teckenuppsättning och vara säker på att få tillbaka sin inmatade byteström oförstörd.
(Text 767103)
(Text 767295) 88-01-24 22.48 Bo Thide Inst f rymdfysik Uppsala Mottagare: Standarder (inom) databehandlingsområdet <1421> Kommentar till: (Text 767102) av Jacob Palme QZ <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Nej. Jag kör med 'vi' och har 8-bitarssuppport. Dvs både vänster hakparentes och Ä finns tillgängliga *samtidigt* om jag bara amvänder meta-tangenten när jag behöver ASCII- tecken med decimalvärde över 127 (där nationella tecken ligger i NLS). Något särskilt språk behöver jag inte ange eftersom denna 8-bitarskod räcker för alla västeuropeiska språk på en gång...
(Text 767295)
(Text 762480) 88-01-15 19.51 Ulf Kronman KIBIC Mottagare: Macintosh erfarenhetsutbyte <2976> Extra kopia: Standarder (inom) databehandlingsområdet <1422> Sändare: Olle Järnefors KTH -- Sänt: 88-02-01 05.51 Ärende: När kan jag börja räkna med min Mac SE ? Är det bara jag som har problem med tangentavkodningen i skrivbordskalkylatorn på min Mac SE ? Vid samtal med Apple verkar de inte känna till att minus-tangenten i den numeriska delen av tangentbordet kodas som likhetstecken och därför är oanvändbar i kalkylatorn. När får vi se ett system eller en kalylator (var nu felet ligger) som fixar detta, eller ännu hellre; när slipper vi det nya fåniga ISO-tangentbordet med den löjliga "solen" och den pluttiga returtangenten och de inverterade +/- i den numeriska delen? "Gamla" SE-bordet var mycket bättre. Uffe K
(Text 762480) (1 kommentar)
(Text 762638) 88-01-16 00.02 Martin Gannholm Apple Computer AB Mottagare: Macintosh erfarenhetsutbyte <2977> Kommentar till: (Text 762480) av Ulf Kronman KIBIC <1> Extra kopia: Standarder (inom) databehandlingsområdet <1423> Sändare: Olle Järnefors KTH -- Sänt: 88-02-01 05.52 Ärende: När kan jag börja räkna med min Mac SE ? Problemen med Kalkylatorn är kända och kommer att rättas i nästa System-version (relativt snart i alla fall). Möjligtvis kommer en version innen ett nytt Systekommer. Den "löjliga" solen på det nya SE-tangentbordet är en del av vad man kallar kallar svenska standard, och den övriga layouten rent hårdvarumässigt är ISO-standard. Vad är standarder till för? (rent personligt håller jag kanske inte med om att sol är ett mer användbart tecken än dollar, men vad gör man inte...)
(Text 762638) (2 kommentarer)
(Text 762647) 88-01-16 00.21 Sven Olofsson QZ Mottagare: Macintosh erfarenhetsutbyte <2978> Kommentar till: (Text 762638) av Martin Gannholm Apple Computer AB <1> Extra kopia: Standarder (inom) databehandlingsområdet <1424> Sändare: Olle Järnefors KTH -- Sänt: 88-02-01 05.52 Ärende: När kan jag börja räkna med min Mac SE ? Det är tillåtet inom svensk tangentbordsstandard att byta ut valutatecknet ("solen") till dollartecknet. Fast vad hindrar att man möjliggör för var och en att bestämma vad man änskar för tecken? Att byta tangent-topp är väl en baggis om programvaran klarar resten?
(Text 762647) (1 kommentar)
(Text 762753) 88-01-16 11.52 Ulf Kronman KIBIC Mottagare: Macintosh erfarenhetsutbyte <2979> Kommentar till: (Text 762638) av Martin Gannholm Apple Computer AB <2> Extra kopia: Standarder (inom) databehandlingsområdet <1425> Sändare: Olle Järnefors KTH -- Sänt: 88-02-01 05.53 Ärende: När kan jag börja räkna med min Mac SE ? Skulle den fjuttiga <retur>-tangenten vara standard? Svårt att förstå. Jag tycker nog att det är OK med standards och är också beredd att acceptera att de är en aning förlegade (vem fn. använder "sol" idag?), men tycker att det är beklagligt att Macen genom denna standardanpassning har hamnat i en kompatibilitetstrasselsituation (härligt ord) mellan olika tangentbord som börjar påminna om den på IBM PC - sidan. Styrkan med Macen var väl att man skulle slippa dylikt elände. Finns det någon möjlighet att specialbeställa sina SE med det tangentbord som fanns ett tag våren -87 ? (som dessutom, förutom ÅÄÖ, ser ut som det amerikanska) Sedan tycker jag nog att bristen på ansvar i datasammanhang är lite beklämmande. Vilket bordskalkylatorföretag skulle våga distribuera en felräknande kalkylator? Undrar när vi får se den första bron rasa samman eller en patient bli feldoserad för att någon räknat fel på sin Mac. Borde det inte medfölja ett felmeddelande i "readme"-filen som finns med systemet? Folk kommer inte att kunna ta sina datorer på allvar så länge sånt här kan hända, tro mig. Uffe K
(Text 762753) (4 kommentarer)
(Text 762864) 88-01-16 15.44 Torbjörn Nordlindh Apple Computer AB Mottagare: Macintosh erfarenhetsutbyte <2982> Kommentar till: (Text 762753) av Ulf Kronman KIBIC <1> Extra kopia: Standarder (inom) databehandlingsområdet <1426> Sändare: Olle Järnefors KTH -- Sänt: 88-02-01 05.54 Ärende: När kan jag börja räkna med min Mac SE ? Man får aldrig vara glad länge, när vi fick klagomål på att tangentbordet på Macintosh inte följde Svensk standard, så tyckte vi det var lika bra att göra ett som är exakt enligt standarden utan undantag. Därför har vi solen istället för Dollar. Den tidigare versionen av SE-tangentbordet tillverkas inte längre och därför går det inte att beställa något sådant istället. Däremot går det bra att köpa det stora tangent- bordet som har massor av tangenter och en STOR returtangent. Om vi hade upptäckt felet med kalkylatorn innan vi började leverera disketterna, så hade vi naturligtvis rättat till det.
(Text 762864) (2 kommentarer)
(Text 764419) 88-01-19 09.51 Kjell Krona Arkitektur KTH Mottagare: Macintosh erfarenhetsutbyte <3005> Kommentar till: (Text 762753) av Ulf Kronman KIBIC <3> Extra kopia: Standarder (inom) databehandlingsområdet <1427> Sändare: Olle Järnefors KTH -- Sänt: 88-02-01 05.56 Ärende: När kan jag börja räkna med min Mac SE ? Håller helt med om detta. Som tur var fick jag min SE i somras, med det gamla tangentbordet, och det är jag själaglad för. Att göra en så liten retutangent som på det nya borde vara brottsligt (just nu sitter jag och försöke skriva på ett sådant..). Apple brukar ju inte vara rädd för att sätta sina egna standarder när det är bättre för användaren, så jag förstår inte vad ni skulle vara så hariga nu för.... "Sol"-tecknet borde ha dött ut med ABC. -Kjell
(Text 764419)
(Text 770941) 88-02-01 05.57 Olle Järnefors KTH För kännedom: Standarder (inom) databehandlingsområdet <1428> Kommentar till: (Text 762753) av Ulf Kronman KIBIC <4> Ärende: Kritik mot tangentbordsstandarder Vad jag vet finns det ingen standard som säger att returtangen- ten. ISO-standarderna för tangentbord till terminaler och per- sondatorer håller på att revideras. Det senaste stadnardför- slaget (ISO/TC97/SC18/WG9/N282) säger bara att returtangenten ska finnas omedelbart till höger om teckentangenterna på tan- gentbordets "skrivmaskinsdel" och sträcka sig över både A- raden och Q-raden. Det innebär väl att den i praktiken måste vara minst 2,5 gånger så stor som en vanlig tangent. (Jag arbetar själv ofta med ett tangentbord som har en sådan retur- tangent och har inga problem med det.) Soltecknet är inte ett exempel på en förlegad standard utan på en från början feltänkt standard, som aldrig riktigt slagit igenom. Det heter officiellt "internationellt valutatecken" och är ett helt artificiellt tecken, som vad jag förstår skapades när den amerikanska ASCII-standarden gjordes om till interna- tionell standard (ISO 646), kanske för att dollartecknet ansågs vara ett kulturimperialistiskt påfund som inte kunde föreskri- vas i en internationell standard. Jag har aldrig sett ett enda soltecken i (den av teckenkodsstandarder opåverkade) verklig- heten. Tyvärr finns soltecknet med i alla nya internationella tecken- kodsstandarder, så vi får väl dras med det i all framtid.
(Text 770941) (1 kommentar)
(Text 763085) 88-01-17 00.28 Martin Gannholm Apple Computer AB Mottagare: Macintosh erfarenhetsutbyte <2983> Kommentar till: (Text 762647) av Sven Olofsson QZ <1> Extra kopia: Standarder (inom) databehandlingsområdet <1429> Sändare: Olle Järnefors KTH -- Sänt: 88-02-01 05.58 Ärende: När kan jag börja räkna med min Mac SE ? Tyvärr så är tillverkningen av tangentborden sådan att det är svårt att trycka enskilda tangent-toppar. Den enda möjligheten skulle i så fall vara att man hade 2 olika (fast likadana) tangentbord på lager, vilket är en orimlig situation. Vi placerade dollar-tecknet på alternativ-4 för att det skulle vara lika lätt att skriva det (ett skift) som att skriva skift-4...
(Text 763085) (2 kommentarer)
(Text 770943) 88-02-01 05.59 Olle Järnefors KTH Mottagare: Macintosh erfarenhetsutbyte <3084> Kommentar till: (Text 763085) av Martin Gannholm Apple Computer AB <1> För kännedom: Standarder (inom) databehandlingsområdet <1430> Markerad av någon. Ärende: Tangentbord med fyra nivåer I en ny standard för tangentbord, ISO 8884, som snart kommer att fastställas, definieras faktiskt fyra teckennivåer för tangentbord. Den förutsätter att det finns 47 eller 48 tecken- tangenter och förutom de vanliga skifttangenterna två "additio- nal shift keys", som jag föredrar att kalla "metatangenter". Varje teckentangent ska alltså kunna ge fyra olika tecken. Exempelvis ska C-tangenten nertryckt - utan skifttangenter ge 'c' - med bara SKIFT ge 'C' - med bara META ge centtecken (översstruket 'c') - med både SKIFT och META ge copyrighttecken ('C' i ring). För tangenten 4 tillåter ISO 8884 två varianter: Alternativ 1 Alternativ 2 ------------ ------------ - oskiftad '4' '4' - SKIFT dollartecken soltecken - META 1/4-tecken 1/4-tecken - SKIFT och META soltecken dollartecken Att lägga dollar på Alternativ-4 strider alltså tyvärr mot ISO 8884.
(Text 770943) (2 kommentarer)
(Text 770945) 88-02-01 06.01 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1431> För kännedom: Jörgen Stiernborg CODE AB <1256> -- Mottaget: 88-02-01 23.24 Kommentar till: (Text 764288) av Jörgen Stiernborg CODE AB <1> Ärende: Bra eller dåligt med standarder? Jag är inte säker på att det är fråga om pragmatism eller fanatism. Som jag ser saken är det fråga om två besvärliga bedömnings- och avvägningsfrågor, som det säkert inte finns några alltid gilitiga svar på: a) Ska man välja det alternativ som med stor säkerhet ger minst problem på kort sikt eller ska man försöka se framåt och handla långsiktigt -- alltså ta vissa kortsiktiga nackdelar för att göra stora vinster längre fram -- men med mycket större risk att ta miste? b) Innebär en långt driven standardisering enligt någon de fac- to-standard eller enligt de officiella standarderna över- vägande fördelar eller nackdelar för just den gemensamma teckenkoden i datorsystemet? Fördelar med standardisering är ofta: + att det blir möjligt (eller i varje fall enklare och billig- are) att använda olika komponenter (maskiner eller program) tillsammans + att stödfunktionerna (dokumentation, utbildning, rådgivning, utbyte av ej fungerande enheter, reparationer) kan rationa- liseras + att man som konsument kan välja mellan fler oberoende till- verkare och leverantörer och därmed få lägre pris + att man som producent kan vända sig till en större marknad och eventuellt få större försäljningsmöjligheter + att marknadsekonomins möjligheter att ge effektiv produktion i stor skala av varor och tjänster som utnyttjar i stort sett känd teknik gynnas. Vanliga nackdelar är: - att det blir svårt att dra nytta av det utbud på marknaden som inte följer den standard man valt - att dåliga standarder kan göra vissa önskvärda funktioner omöjliga att implementera - att dåliga standarder kan göra det omöjligt att implementera önskvärda funktioner på tekniskt sett bästa sätt - att de flesta standarder representerar minst fem år gammal teknik - att för hårt genomdrivna standarder rent allmänt kan mot- verka innovationer och sätta en hämsko på den tekniska utvecklingen - att marknadseknomins möjligheter att stimulera innovationer och exploatering av nya produktide'er och ny teknik mot- verkas.
(Text 770945) (2 kommentarer)
(Text 770946) 88-02-01 06.02 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1432> För kännedom: Jörgen Stiernborg CODE AB <1257> -- Mottaget: 88-02-01 23.26 Kommentar till: (Text 764288) av Jörgen Stiernborg CODE AB <2> Ärende: Standarder för teckenkod I fråga om just teckenkoder tror jag att det är särskilt felak- tigt att tro att man bara kan uppnå standardiseringens fördelar om alla tillverkare ansluter sig till en enda teckenkod. Lika fel är slutsatsen att detta -- om det alls kan ske -- bara är möjligt om de små tillverkarna och konsumentgrupperna överger sina nuvarande teckenkodslösningar och övergår till majoritet- ens teckenkod, vare sig man nu kan räkna fram att det är ASCII eller den gamla IBMPC-koden. Jag tror detta av flera skäl: a) Det _kan_ räcka med att man enas om en gemensam teckenkod för datautbyte mellan olikartade system. Sedan kan varje tillverkare inom sitt eget system fortsätta att använda sin egen teckenkod. De som har dåliga interna teckenkoder ger sina kunder sämre funktionalitet och större konverterings- kostnader för externa data. b) De teckenkoder som används i alla dagens populära datortyper (inte bara IBMPC-kompatibla) är tekniskt undermåliga och ett hinder för ökad användning av datorer i många tillämpningar. De är för fattiga, lämpar sig inte för text i oengelska språk, kräver för ovana användare svåra och obegripliga teckenkodskonverteringar, kan inte efter hand kompletteras med tecken som saknas från början. Om därför de internation- ella standardiseringsorganen relativt snabbt kunde "ta fram" en genomtänkt, väl utbyggd internationell teckenkodsstandard som omfattar många fler av de utanför datorvärlden använda skrivtecknen än dagens teckenkodsalternativ, så tror jag att den skulle bli mycket frestande att använda i framtida datorsystem även som intern teckenkod. Jag tror inte att framtida datorkonstruktioner kommer att vara så hårt bundna till IBM:s allt mer föråldrade "industristandarder" (370/MVS och PC/AT) som de tyvärr även inom mikrodatorområdet varit de senaste fem åren. c) I motsats till många andra områden som är föremål för stan- dardiering har vi inom datorområdet fördelen av att arbeta med de flexiblaste maskiner och medier som människan hit- tills hittat på. Om världens länder till exempel skulle kunna komma överens om en gemensam standard för järnvägens spårvidd (troligen då någon sorts medelvärde av den europei- ska och den ryska "normalspårvidden") så skulle enorma över- gångskostnader måsta betalas innan alla järnvägslinjer hade standardiserats och under ombyggnadstiden skulle kompatibi- litetsproblemen bli ännu värre än nu. ("Det måste bli värre innan det kan bli bättre.") Detta så kallade bakåtkompatibilitetsproblem är faktiskt ofta lösbart inom datorområdet. Det borde till exempel vara fullt möjligt att utforma ett nytt operativsystem (OS/3?) för IBMPC-liknande datorer så att det samtidigt och transpa- rent kan arbeta både med den gamla begränsade IBMPC-tecken- koden och en kommande, universell och tekniskt överlägsen ISO-teckenkod. Systemet skulle hålla reda på vilka textfiler som lagrats enligt den gamla koden och vilka enligt den nya. Det skulle också veta vilka program som bara klarar den gamla, vilka som bara klarar den nya och vilka som kan hantera båda teckenkoderna. När ett program ska arbeta med filer med "fel" teckenkod skulle operativsystemet, automa- tiskt och osynligt, utföra nödvändig teckenkodskonvertering.
(Text 770946)
(Text 770947) 88-02-01 06.04 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1433> För kännedom: Jörgen Stiernborg CODE AB <1258> -- Mottaget: 88-02-01 23.27 Kommentar till: (Text 764288) av Jörgen Stiernborg CODE AB <3> Ärende: Är "IBM-standarder" diktat? Givetvis är de så kallade industristandarder som uppstår genom att andra tillverkare härmar IBM diktat från IBM i den meningen IBM helt och hållet på egen hand bestämt vad de ska innehålla och när som helst kan ändra dem. (Jag vill inte kalla en lös- ning för IBM-standard bara för att den kommer från IBM; den måste också tillämpas av andra tillverkare.) De är också diktat så till vida att de inte varit föremål för och vunnit någon omröstning bland dem som de berör, i motsats till alla officiella standarder. Visserligen säger man ibland att marknadsekonomin innebär en sorts demokrati där varje köp- beslut innebär en rösthandling men knappast någon köpare av datorer väljer dator enbart efter vilken teckenkod den an- vänder. Viktigare är dock iakttagelsen att marknadsekonomin fungerar dåligt inom datorbranschen därför att IBM har en så dominerande ställning. IBM är inte störst för att det är den bästa dator- tillverkaren utan för att det är den största tillverkaren och så mycket större än alla konkurrenter. Ingen datortillverkare kan sälja omoderna produkter som bygger på föråldrad teknik -- och gör det -- lika länge som IBM. Många beslut att köpa IBM, särskilt i amerikanska storföretag, grundas inte på en kall jämförelse av olika konkurrerande produkters egenskaper utan beror på någon sorts flockmentalitet i kombination med IBM- märkets trygghetsskapande förmåga. ("Ingen har någonsin blivit avskedad för att han valde att köpa IBM-produkter.") Till detta kommer att IBM aktivt utnyttjat sin marknadsdominans för att klämma åt sina konkurrenter och låsa sina gamla kunder till de egna produkterna med prissättningsknep och plötsliga och tekniskt omotiverade ändringar i sina så kallade industri- standarder. (Hur det går till på stordatorområdet kan man läsa i många desillusionerade artiklar i sådana oberoende facktid- skrifter som Datamation.)
(Text 770947)
(Text 771068) 88-02-01 11.10 Kjell Krona Arkitektur KTH För kännedom: Standarder (inom) databehandlingsområdet <1434> Kommentar till: (Text 770941) av Olle Järnefors KTH <1> Ärende: Kritik mot tangentbordsstandarder Jag förstår inte varför man sak bry sig om en standard som ligger fjärran från verkligheten. Jag tycker det är svårt att se något exempel där en "uttänkt" - till skillnad från da facto-standard - har gjort något positivt för mänskligheten. En da facto-standard har bara så lång livslängd som den förtjänar, till skillnad från s.k. legitimerade standarder, som vi får dras med i decennier efter att de blivit förlegade... - kjell
(Text 771068) (1 kommentar)
(Text 771102) 88-02-01 12.44 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1435> Extra kopia: Benny Brodda Lingv Su <808> -- Mottaget: 88-02-05 20.37 Sändare: Tommy Ericson KOMunity -- Sänt: 88-02-05 02.15 Subject: teckenkonvertering Finns det någon vedertagen svensk standard inom området. Vad jag är ute efter är hur man konverterar åäö dvs nationella tecken. Det är inte någon kodkonvertering jag är ute efter utan hur man i ett alfabet som saknar åäö representerar dessa. De vanligast sättet förefaller vara att man helt enkelt tar bort diakriterna. Vad säger språkforskare om detta. Är det bättre med aa ae och oe än a a o ? De eventuella besvär som en dator kan ha med de olika metoderna är för mig ett sekundärt problem. Någon med erfarenheter?
(Text 771102) (1 kommentar)
(Text 771279) 88-02-01 17.13 Benny Brodda Lingv Su Mottagare: Standarder (inom) databehandlingsområdet <1436> För kännedom: Jörgen Stiernborg CODE AB <1259> -- Mottaget: 88-02-01 23.28 Kommentar till: (Text 770945) av Olle Järnefors KTH <1> Ärende: Bra eller dåligt med standarder? Skulle man inte kunna tänka sig att tangenterna a) var pluggin och b) hade en inbyggd givare. Då kunde man plocka om sitt tangent- bord precis som man ville, och man kunde köpa till lösa tangenter. Detta borde inte vara alltför dyrt o.e. komplicerat.
(Text 771279)
(Text 771529) 88-02-01 23.26 Jörgen Stiernborg CODE AB Mottagare: Standarder (inom) databehandlingsområdet <1437> För kännedom: Jörgen Stiernborg CODE AB <1264> -- Mottaget: 88-02-01 23.26 Kommentar till: (Text 770945) av Olle Järnefors KTH <2> Ärende: Bra eller dåligt med standarder? En bra sammanfattning
(Text 771529)
(Text 771575) 88-02-02 04.28 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1438> Mottagare: SuperKOM erfarenhetsutbyte <936> Kommentar till: (Text 762395) av Jacob Palme QZ <2> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Varför skulle det vara speciellt svårt att göra en generell editor som kan fungera för terminaltyper med olika teckenkoder (när systemet har fullständig kunskap om vilken teckenkod terminalen använder)? Jag tycker för övrigt att det bör vara möjligt även för den som sitter vid en gammaldags terminal med begränsad teckenkod att skriva in tecken som bara finns i SuperKOM:s rikare interna teckenkod. Den kan man ordna genom att tillhandahålla ett särskilt "kompatibilitetsmodus" vid inmatning till SuperKOM, där ett eller ett par ovanliga grafiska 7-bitstecken fungerar som prefixtecken. Skriver man till exempel '&ss' (alltså de tre tecknen mellan apostroferna) tolkar SuperKOM det som ett para- graftecken. '&(/' tolkas som vänster hakparentes, '&Y/' som yen-tecken. För att få ett '&' får man skriva '&&' eller kanske '&.'. För att inte trassla till det för nybörjare ska indata till SuperKOM förstås normalt tas emot utan sådan omtolkning.
(Text 771575) (1 kommentar)
(Text 771576) 88-02-02 04.32 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1439> Mottagare: SuperKOM erfarenhetsutbyte <937> För kännedom: IBM PC (och kompatibler) MS WINDOWS <169> Kommentar till: (Text 762746) av Jan Flodin FMV <2> För kännedom: B3 urval <121> Sändare: -- Sänt: 88-02-02 15.53 Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Det är viktigt inte bara att (avancerade eller djärva) använ- dare själva kan skapa nya konverteringstabeller utan också att denna facilitet görs så användarvänlig som möjligt och att utbyte av tabeller mellan olika användare underlättas. Alltså: + Tabellerna bör kunna ges långa beskrivande namn. + Tillsammans med en tabell ska kunna lagras kommentarer som beskriver vilken utrustning och vilka behov den är avsedd för, hur den fungerar och vem som är upphovsman. + SuperKOM-administratören bör tillhandahålla dels en uppsätt- ning officiellt supporterade tabeller för de vanligaste terminaltyperna, dels en uppsättning fritt tillgängliga tabeller för ovanligare utrustning eller speciella behov som användare bidragit med och som används på egen risk av andra. + Det bör finnas speciella datorkonferenser för erfarenhets- utbyte om SuperKOM:s anpassning till olika terminaltyper direkt kopplade till de olika tabellerna i det systembiblio- teket. + Det ska vara lätt att skapa nya tabeller genom att införa förändringar i någon befintlig tabell. + När man modifierar en tabell bör man ha möjlighet att ange en viss följd av oktettvärden på det sätt man föredrar: med motsvarande tecken, med hexadecimal, decimal, oktal eller binär teckenkod, genom att hänvisa till befintlig defini- tion, eller med flera av dessa metoder, varvid systemet kontrollerar att de ger samma värden. + Med tanke på dem som vill experimentera med egna smarta terminalanpassningar bör det finnas någon metod att komma loss och byta till tabellerna för "stendum terminal" när man har klantat till sina tabeller, som alltid fungerar oavsett gällande terminalanpassning. + Det ska vara lätt att skräddarsy en privat meny för byte mellan de terminaltyper man själv vill kunna växla mellan. + För att underlätta utbyte mellan olika användare bör det finnas en funktion som omformar en given tabell till ett format som är läsbart oberoende av terminaltyp.
(Text 771576) (1 kommentar)
(Text 771577) 88-02-02 04.33 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1440> Mottagare: SuperKOM erfarenhetsutbyte <938> Kommentar till: (Text 762862) av Jacob Palme QZ <2> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Man slipper hålla reda på terminalens skiftstatus om man gör utmatningstabellen så att till exempel vänster hakparentes medför att _tre_ tecken skickas till terminalen: SO 'Ä' SI
(Text 771577) (1 kommentar)
(Text 771578) 88-02-02 04.34 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1441> Mottagare: SuperKOM erfarenhetsutbyte <939> För kännedom: Jan Bjurström FMV <364> -- Mottaget: 88-02-02 23.08 För kännedom: Peder Swenman FFV Elektronik AB <566> -- Mottaget: 88-02-08 22.09 Kommentar till: (Text 762921) av Jacob Palme QZ <2> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Tyvärr är ISO 6937 inte så generell som du anger. Den har bara utformats med hänsyn till europeiska språk och är otillräcklig för vissa afrikanska språk (och troligen också asiatiska språk och indianspråk) som använder det latinska alfabetet. Det finns en internationell standard, kan inte hitta numret just nu, om utvidgning av ISO 646 för afrikanska språk vid bibliografiskt informationsutbyte, som innehåller både ett antal specialbok- stäver och några diakritiska tecken som inte finns i ISO 6937.
(Text 771578) (1 kommentar)
(Text 771579) 88-02-02 04.35 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1442> Mottagare: SuperKOM erfarenhetsutbyte <940> För kännedom: Jan Bjurström FMV <365> -- Mottaget: 88-02-02 23.08 För kännedom: Peder Swenman FFV Elektronik AB <567> -- Mottaget: 88-02-08 22.10 Kommentar till: (Text 762921) av Jacob Palme QZ <3> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Även på svagare skärmar kan det gå att visa alla tecken så att de kan kännas igen av en intelligent läsare. Tankstreck visas lämpligen som teckenparet '--' på en terminal som bara har ISO 646-kod. Vänster hakparentes kan till exempel visas som '(/' eller för att ansluta sig till en konvention i Pascal '(.'. I själva verket tror jag det skulle vara fördelaktigt om en sådan en-till-flera-konvertering var definierad från början i Super- KOM för äldre terminaler. Den som ogillar någon viss tecken- översättning skulle kunna skapa en privat variant av standard- konverteringstabellen som rättar till problemet eller låna någon annans. I en del sammanhang vill man kanske ha en-till-en-konvertering för svagare terminaler, till exempel vid visning av tabeller eller programkod. Det bör därför finnas en alternativ konver- teringstabell där till exempel tankstreck transformeras till bindestreck och vänster hakparentes till 'Ä'.
(Text 771579)
(Text 771580) 88-02-02 04.36 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1443> Kommentar till: (Text 762933) av Tommy Ericson KOMunity <2> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM På den orättvist förkättrade svenska "skoldatorn" Compis -- som både i CP/M-86 och i MSDOS sedan två år haft sådana funktioner för dynamiskt byte av teckenkod som IBM införde för AT- och PS/2-maskinerna först i höstas och Macintosh fortfarande saknar -- finns en teckenkod som är så gott som helt kompatibel med 8- bitskoden ISO 8859-1. (Man växlar till den med operativsystems- kommandot CS US.) Alla grafiska tecken utom två i ISO 8859-1 finns i Compis US- alternativ med samma teckenkod. Undantagen är multiplikations- tecknet (teckenkod "D7, teckenplats 13/7 enligt ISO-notation) och divisionstecknet (kod "F7). Dessutom kan Compis-koden kri- tiseras för att det låga lodstrecket (kod "7C) precis som det höga (kod "A6) har ett "hål" i mitten. Enligt ISO 8859-1 ska det låga vara sammanhängande. Ett större avsteg från kodstandarden, som dock inte behöver ha så stor praktisk betydelse, är att i Compis teckenkod även platser som är reserverade för styrtecken -- "7F (DELETE) och de höga styrtecknen i intervallet "80..9F -- används för grafiska tecken (en salig blandning mer eller mindre användbara tecken som inte finns i ISO 8859-1). Detsamma gäller de båda special- tecknen "non-breaking space" (kod "A0) och "soft hyphen" (kod "AC) i ISO 8859-1. Det kan också noteras att Compis också tillhandahåller en teck- enkod, SW, som är nästan likadan som US-koden men har de svenska bokstäverna flyttade till sina vanliga platser enligt svensk 7- bitskod. De tecken som fanns där -- samma som i ASCII -- intar de platser i den höga halvan av koden som motsvarande svenska bokstav har i ISO 8859-1. Om man använder denna teckenkod på Compis men bara utnyttjar den undre kodhalvan, fungerar datorn som om den hade följt svensk standard för 7-bitskod, allmänna versionen, med soltecken utbytt mot dollartecken.
(Text 771580)
(Text 771581) 88-02-02 04.37 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1444> Mottagare: SuperKOM erfarenhetsutbyte <941> Kommentar till: (Text 762987) av Jacob Palme QZ <2> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Förutom text, ljud och grafik bör SuperKOM förberedas för att i framtiden kunna lagra hypertext och rörlig grafik. Det bör nog också finnas en möjlighet att som del av inlägg lagra en god- tycklig följd av oktetter utan att ange något speciellt sätt för systemet att tolka dem på. När systemet ska visa ett inlägg som till exempel innehåller grafik på en ickegrafisk terminal bör det normalt bara skriva ett systemmeddelande typ "*** Grafiskt objekt i inlägget som inte kan visas på aktuell typ av terminal. Storlek: 4309 oktet- ter. ***" Den som ändå vill få möjlighet att ta del av det grafiska objektet bör dock ha en möjlighet att få dess oktett- innehåll visat i någon portabel form, till exempel hexifierat (1 oktett -> 2 hexadecimala siffror på skärmen) eller i MS- Kermits BOO-format (3 oktetter -> 4 skrivbara 7-bitstecken). Inläggsbegreppet kan eventuellt generaliseras ytterligare så att ett inlägg kan innehålla - element som inte är givna en gång för alla utan hämtas ur en databas som uppdateras, - element som beräknas varje gång någon läser inlägget enligt en viss algoritm - interaktiva element (beställningsfaciliteten i Telebox är ett specialfall av denna ide').
(Text 771581) (1 kommentar)
(Text 771582) 88-02-02 04.38 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1445> Kommentar till: (Text 762993) av Jan Engvald LDC <2> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Jag undrar om du inte håller på att göra samma misstag som de som hårdlödde våra nuvarande 7- och 8-bitskoder i dagens dator- system: Bara tillåta en mycket begränsad utvidgning av den existerande teckenkoden och sedan ägna sig åt en med sjunkande hårdvarupriser allt ointressantare utrymme/exekveringstidsopti- mering. Även om ISO 6937 innehåller betydligt fler tecken än ASCII bör man ha klart för sig att den är utformad för ett visst syfte: överföring av allmän och affärskorrespondensmässig text skriven med latinskt alfabet. Det finns massor av tecken som ofta används utanför datorvärlden och saknas i även denna den mest omfattande officiella teckenkodsstandarden. Exempel: - streckgrafiska tecken för att rita boxar och tabellinjer - ett rikare urval av "punkter" (fyllda och ofyllda ringar, boxar, kvadrater, diamanter, trianglar) för text som upp- delas som det här stycket - fler typer av pilar (med andra riktningar än NVSO och olika typer av huvuden) - andra typer av parenteser än de fyra vanliga i datorsamman- hang - de flesta matematiska tecken (för att inte tala om kemiska och astro(nom/log)iska tecken) - grekiska bokstäver (många träffar på dem redan i gymnasie- skolan) - fonetiska alfabeten (oundgängliga i språkundervisning) - utomeuropeiska alfabeten (ryska, hebreiska, arabiska, japan- ska, kinesiska) Tvivelsutan kommer så småningom standarder även för dessa tecken. Det är troligt att de kommer att organiseras i teckenuppsättningar som man växlar mellan med hjälp av escape- sekvenser och vissa styrtecken. Jag tror därför att SuperKOM:s översättningstabeller för att inte bli alltför rigida för framtida teckenkoder bör organise- ras så att de klarar ingångar och utgångar med varierande och i princip godtyckligt antal oktetter. Dessutom bör en tillstånds- variabel kunna påverka vilken ingång som väljs och kunna ges ett nytt värde i utgången.
(Text 771582) (1 kommentar)
(Text 771583) 88-02-02 04.40 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1446> För kännedom: SuperKOM erfarenhetsutbyte <942> Kommentar till: (Text 764080) av Bo Thide Inst f rymdfysik Uppsala <3> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM 8-bitskoden i ISO 8859-1 duger för de officiella språken i Amerika och Västeuropa, men inte östeuropeiska språk som polska och serbokroatiska eller minoritetsspråk, till exempel samiska och katalanska (med cirka 6 miljoner "användare" enligt Focus 1962). ISO 6937 klarar alla dessa språk men inte en del utom- europeiska språk med latinskt alfabet. Dessutom finns det ett stort antal andra tecken som används i verkligheten utanför datorbranschen som saknas i ISO 6937. Se också inlägg 771582.
(Text 771583) (1 kommentar)
(Text 771584) 88-02-02 04.41 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1447> Mottagare: SuperKOM erfarenhetsutbyte <943> Kommentar till: (Text 763889) av Jacob Palme QZ <2> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM "... NAPDLS ..." Menar du inte NAPLPS?
(Text 771584)
(Text 771589) 88-02-02 04.41 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1448> För kännedom: SuperKOM erfarenhetsutbyte <944> Kommentar till: (Text 764080) av Bo Thide Inst f rymdfysik Uppsala <4> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM För användarvänlig inmatning av den utvidgade teckenmängden behövs förvisso META/Alt-tangent. Det bör dock inte vara så enkelt att META-3 ger det tecken som har 128 enheter högre teckenkod än '3'. I stället bör de nya tecknen fördelas över tangentbordet så att de i största möjlighet kommer på en tangent som de har någon sorts begriplig anknytning till, exempelvis tyska dubbel-s på META-s. ISO är på väg att anta en standard, ISO 8884, som anger hur de nya tecknen i såväl ISO 6937 som 8859-1 och 8859-2 ska placeras på ett tangentbord med fyra teckennivåer. Se också inlägg 770943. Det finns dock inget som hindrar att inmatning av nya tecken möjliggörs också på gammaldags terminaler. Man kan till exempel välja ett sällan använt tecken, till exempel '&', som prefix- tecken som ändrar innebörden av det följande tecknet till något av de nya tecknen.
(Text 771589) (1 kommentar)
(Text 771590) 88-02-02 04.43 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1449> För kännedom: SuperKOM erfarenhetsutbyte <945> Kommentar till: (Text 764397) av Johan Lundberg TeleDelta <2> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM ISO 8859-1 klarar isländska och även följande språk: danska, engelska, finska, franska, färöiska, holländska, iriska, ita- lienska, norska, portugisiska, spanska, svenska, tyska. Det blir ju en rätt stor del av mänskligheten tillsammans och är nog så långt man kan komma med en enkel 8-bitskod utan möjlig- het att växla till andra teckenkodstabeller enligt till exempel ISO 2022. Jag håller med om att datorer lätt kan programmeras att hantera en väsentligt rikare teckenrepertoar om man bara överger den simplistiska principen: Samma följd av 8 bitar ska alltid motsvara ett och samma tecken.
(Text 771590)
(Text 771591) 88-02-02 04.44 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1450> För kännedom: SuperKOM erfarenhetsutbyte <946> Kommentar till: (Text 764431) av Bo Thide Inst f rymdfysik Uppsala <2> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM ISO 6937 innehåller bara en teckenkod (i del 2). Del 1 innehål- ler allmänt svammel och del 3 definierar styrfunktioner för textens utplacering på sidan. Däremot innehåller ISO 8859 flera olika, inkompatibla tecken- koder som man måste välja en av om man inte tror sig klara av eller står ut med teckenkodsväxling. Jag tror att för närvar- ande två 8859-koder är fastställda, 8859-1 (västeuropeiska språk) och 8859-2 (östeuropeiska språk). Det finns språk som ingen av dem klarar men som kan skrivas med 6937-koden, till exempel turkiska.
(Text 771591) (1 kommentar)
(Text 771593) 88-02-02 04.46 Olle Järnefors KTH För kännedom: Standarder (inom) databehandlingsområdet <1451> Kommentar till: (Text 771068) av Kjell Krona Arkitektur KTH <1> För kännedom: B3 urval <122> Sändare: -- Sänt: 88-02-02 15.57 Markerad av någon. Ärende: Kritik mot tangentbordsstandarder Jag antar att du med "uttänkt" menar att standarden (som antas av ett officiellt standardiseringsorgan) inte bara är ett urval av befintliga alternativ på marknaden utan innebär en nykon- struktion, något man inte sett tidigare. I så fall tror jag du har fel: Det finns gott om exempel på att sådana standarder kan vara till nytta för mänskligheten (även om inte alla behöver vara det). Här är några exempel (i några fall är kanske klassificeringen som "uttänkt" diskutabel): + Pappersformaten i A-serien (och de parallella serierna som bygger på samma delningsprincip). + Den bara för tio år sedan beslutade standarden för interna- tionella trebokstavsbeteckningar för all världens valutor. Slog igenom förvånansvärt snabbt och underlättar verkligen viktig kommunikation mellan olika länder när den förstås överallt. + ASCII-koden, som verkligen innebar ett framsteg (både tek- niskt och rent standardiseringsmässigt) på sin tid. Första versionen fastställdes 1968 och senare versioner kan bara särskiljas från den första av experter. Utan ASCII hade vi kanske fortfarande varit hänvisade till teckenkoder som EBCDIC och CDC:s 6-bitars Display Code. Där har vi verkligen de facto-standarder som de som måste använda stordatorer från IBM och Control Data som fått mycket större livslängd än de förtjänat. + FORTRAN 77 innebar onekligen ett stort framsteg för dem som programmerar i FORTRAN jämfört med gamla FORTRAN 66. (Tänk bara, en riktig IF-THEN-ELSE-konstruktion med fullständiga möjligheter till kapsling/nesting, ack ja ...) + När X.400-standarden slår igenom på bred front kan vi för första gången hoppas på tidigare oanade möjligheter till brevöverföring mellan meddelandesystem i de mest väsens- skilda datormiljöer.
(Text 771593) (4 kommentarer)
(Text 771651) 88-02-02 09.08 Johan Lundberg TeleDelta För kännedom: Standarder (inom) databehandlingsområdet <1452> Kommentar till: (Text 771593) av Olle Järnefors KTH <1> Ärende: Kritik mot tangentbordsstandarder Jag skulle gissa att en annan utänkt standard är metersystemet Inte för att jag kommer ihåg exact men det var väl ett påhitt av fransmännen ursprungligen.
(Text 771651)
(Text 771736) 88-02-02 11.50 Kjell Krona Arkitektur KTH För kännedom: Standarder (inom) databehandlingsområdet <1453> Kommentar till: (Text 771593) av Olle Järnefors KTH <2> Ärende: Kritik mot tangentbordsstandarder Men hur fungerar egentligen ASCII idag utanför USA? Jo: det finns en ASCII-standard för snart sagt varje land i Europa, det finns tangentbords-"standarder" där varje land eliminerar bort alla andra, och gör det svårt eller omöjigt att använda utländska program. Den enda vägen ut ur detta har varit när företag som IBM eller Apple, eller konsortier som vi kanske får när UNIX- leverantörerna till slut kan samsas, skapar en da facto-standard som av naturliga skäl fungerar över nationsgränserna - och som utnyttja de möjligheter som finns i moderna datorer. Nu kommer det kanske så småningom en 8-bitars standard för USA/Europa, men hur lång tid skall det ta att etablera en 16-bitars standard? Apple har med sin Script Manager lagt upp linjer för en sådan, som skall göra det möjlgt att hantera alla språkgrupper rikigt - både med tecken och med skrivriktning, ordbrytning o.s.v. Et t sådant arbete görs av naturliga skäl bäst av ett företag som är intresserat av att ha en bred och "homogen" marknad (homogen i bemärkelsen att produkterna inte kan hantera olika omgivningar med så små och enkla föränringar som möjligt). Ett annat exempel är HyperCard, som kommer att kunna programmeras både på det lokala språket och på engelska.... Vad det gäller Fortran 77, hade det nog varit bättre att begrava det i stället för att ge en sådan konstgjord andning. jag kan förstå att min ibland kan vilja hålla gamla program igång, även om det nog många gånger hade varit bättre att starta om från scratch, men att börja på nya projekt i Fortan var även i mitten av 70-talet en absurditet... Naturligtvis kan det finns tillfällen när en standard kan vara till nytta, jag var med avsikt lite polemisk.. Men i allmänhet anser jag att en standard gör alltid för lite och för sent,e eftersom processen att ta fram en standard genom alla diskussioner o.s.v inte kan hålla takt med utvecklingen, och eftersom själva situtationen med "consensus" alltid befordrar konservatism. - Kjell
(Text 771736) (4 kommentarer)
(Text 771762) 88-02-02 13.20 Jan Michael Rynning (jmr@nada.kth.se) För kännedom: Standarder (inom) databehandlingsområdet <1454> Kommentar till: (Text 771593) av Olle Järnefors KTH <3> Ärende: Kritik mot tangentbordsstandarder - Förkortningar som DKr och SFr används fortfarande, utan problem. - Utan ASCII (och futtinutton varianter) hade vi sluppit konvertera fram och tillbaka mellan ASCII och EBCDIC. Man behöver inte vara expert för att se skillnad mellan olika versioner och varianter av ASCII, men tvingas man försöka konvertera mellan dem är det en fördel. Undrar hur det kommer sig att mina DEC-10-manualer beskriver de ändringar som infördes i ASCII 1965, om första ver- sionen kom 1968 ... - IF-THEN-ELSE-konstruktioner kunde man även ha i FORTRAN 66, även om man fick skriva dem med GOTO. Dessbättre kan de flesta FORTRAN 77-kompilatorer även kompilera FORTRAN 66-program, så man inte behöver slänga bort tid på att konvertera. CERN lär ha spenderat åtskilliga CPU- månader och manårtionden på övergången, tid som sanner- ligen kunde använts bättre! - När X.400 någon gång i framtiden blir färdigt kommer man att kunna göra det man kunnat göra sedan åratal. Vilken tur att det finns folk som återuppfinner hjulet! Det är precis det vi behöver.
(Text 771762) (3 kommentarer)
(Text 771934) 88-02-02 19.21 Bo Thide Inst f rymdfysik Uppsala Mottagare: Standarder (inom) databehandlingsområdet <1455> För kännedom: SuperKOM erfarenhetsutbyte <947> Kommentar till: (Text 771583) av Olle Järnefors KTH <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Jaha, där ser man. Alltid lär man sig något nytt :-) F.ö. tycker jag dina inlägg här är väldigt klargörande och nyttiga. Hoppas de manar till eftertänksamhet inte bara hos mig.... !
(Text 771934)
(Text 771946) 88-02-02 19.31 Bo Thide Inst f rymdfysik Uppsala Mottagare: Standarder (inom) databehandlingsområdet <1456> För kännedom: SuperKOM erfarenhetsutbyte <948> Kommentar till: (Text 771589) av Olle Järnefors KTH <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Jo, jag tycker också att meta-tecken (liksom vanliga) skall sitta på "bra" ställen, dvs där jag vill ha dem. Det skall finnas en sädan flexibilitet att om jag trycker ner meta-x skall jag kunna bestämma att datorn skall uppfatta detta som en stjärna (*), säg. Eller om jag vill mata in boksatven 'a' som meta-shift-! skall det vara MIN ensak! Jag har till min oerhörda glädje upptäckt att detta kan fixas (tror jag) i X Windows med 'keycomp' (key mapping compilator). Skall testa så fort jag hinner. I övrigt vill jag dock påpeka fördelen med en "mekanisk" standardtolkning (dvs innan jag speialkonfigurerat mitt tangentbord) med meta-a, meta-b, etc. I vissa program (ex.vis emacs) används dessa tecken mnemoniskt (Ctrl-f = framåt ett tecken, Meta-f = framåt ett ord). Emacs vill då ha Meta-f som f med 8:e biten satt och jag vill inte skriva om emacs' tabeller. Jag antar att det kan finnas fler, vitt spridda program som vill ha det på det "mekaniska" viset med meta-karaktärer.
(Text 771946)
(Text 771948) 88-02-02 19.37 Bo Thide Inst f rymdfysik Uppsala För kännedom: Standarder (inom) databehandlingsområdet <1457> Kommentar till: (Text 771736) av Kjell Krona Arkitektur KTH <1> Ärende: Kritik mot tangentbordsstandarder Unix-världen har redan samsats om 8 och 16-bitarskoder i X/Open och nu tydligen också i POSIX. Systemet finns redan!
(Text 771948)
(Text 772084) 88-02-02 22.36 Olle Järnefors KTH För kännedom: Standarder (inom) databehandlingsområdet <1458> Kommentar till: (Text 771736) av Kjell Krona Arkitektur KTH <2> Ärende: Kritik mot tangentbordsstandarder Jag ville säga att ASCII var ett stort framsteg när den kom för 20 år sedan. Idag är den givetvis helt otillräcklig som teckenkod. Att varje land har en egen standard för var tecknen ska finnas på tangentbordet tycker jag är naturligt: Olika språk använder olika specialbokstäver och en del specialtecken används mycket i en del länder och nästan aldrig i andra. Kanske finns det onödiga skillnader mellan olika nationella standarder, jag har för mig att tyskarna har en annan placering av W och Z än resten av världen. Jag misstänker att vi får vara tacksamma att vi nu i alla fall har lyckats enas om en standard för svenskt tangentbord. Numera är det bara två tangenter (de nordöstraste) som kan ha lite varierande tecken mellan olika persondatorer, terminaler och skrivmaskiner. Jag kommer ihåg vilka stora skillnader som fanns på svenska skrivmaskiner för tjugo år sedan, många saknade till och med tecknet '1'. ISO har förresten en lösning på problemet att olika tecken saknas på de olika nationella tangentborden. Enligt ISO 8884 (ännu inte slutgiltigt fastställd) bör tangentbord ha 48 teckentangenter och dessutom dubbla alternativa skifttangenter (metatangenter). Genom att kombinera skift och meta får man fyra teckennivåer i tangentbordet. Nivå 1 och 2 (oskiftat respektive bara skifttangent nertryckt) följer nationell standard. De ska ge tillgång till de tecken som finns i den invarianta delen av 7-bitskoder enligt ISO 646 (så kallade ASCII-koder), alltså ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 0123456789 !"%&'()*+,-./:;<=>?_ och kan dessutom innehålla specialbokstäver och specialtecken som är vanliga i det aktuella landet. Nivå 3 och 4 (bara metatangent respektive både skift- och meta- tangent nertryckt) har däremot en gemensam internationell lay- out. Den omfattar alla tecken i 8-bitskoderna ISO 6937, 8859-1 och 8859-2 utom de jag räknade upp i förra stycket, inklusive de varianta tecknen i 7-bitskoder (på din terminal ser de ut så här #$@ÄÖÅ^`äöå~ ). Alla dessa tecken får plats genom att bokstäver med diakri- tiska tecken, till exempel 'å', får matas in med två tangent- tryckningar, först en för det diakritiska tecknet, sedan en för basbokstaven. Personligen tycker jag att ISO 8884 är en mycket snygg lösning som bara kan kritiseras i detaljer jag inte har tagit upp här. Och den är överlägsen alla "de facto-standarder" från IBM och Apple och X/OPEN som jag har sett.
(Text 772084)
(Text 772085) 88-02-02 22.37 Olle Järnefors KTH För kännedom: Standarder (inom) databehandlingsområdet <1459> Kommentar till: (Text 771736) av Kjell Krona Arkitektur KTH <3> Extra kopia: Tomas Centerlind KTH <27> -- Mottaget: 88-02-08 12.29 Ärende: Kritik mot tangentbordsstandarder Att standardiseringen av teckenkoder behöver drivas mycket längre än man kommit hittills (ISO 6937) håller jag med om. Däremot är jag inte säker på att den framtida standarden bör vara en 16-bitskod. (Det kan nog bli svårt att övertyga före- tagsledningar och ansvarsbeviljande myndigheter om att skiv- minneskapaciteten måste fördubblas i ett slag, bara för att man ska byta till en ny teckenkodsstandard.) Liksom när det gäller ikoner, mus och gardinmenyer försöker Apple med sin Script Manager göra samma sak som Xerox gjorde ungefär fem år tidigare. Apple har ju blivit mycket kritiserat för att med (hot om) dyra domstolsprocesser försöka stoppa mindre företag som kopierar Macintosh "look and feel" när Macin- tosh eget människa-maskin-gränssnitt är ett (dåligt) plagiat av Xerox "arbetsstationer" från slutet av 70-talet. Tyvärr verkar Apple när det gäller teckenkoder för språk utanför USA och Storbritannien -- ett område där standardisering verkligen har stora fördelar -- inte alls kopiera Xerox generella företags- standard (XC-1-2-2-0) utan gör något helt eget. Det verkar till och med svårt att få fram någon detaljerad information från Apple om Script Manager, som tydligen konstru- eras i hemlighet inom företaget. Tomas Centerlind, som nyligen skrivit ett examensarbete på KTH om hur Carnegie-Mellon Univer- sitys Andrew-system ska kunna anpassas till språk som kräver en rikare teckenkod än 7-bits ASCII, lyckades aldrig få någon teknisk information om Script Manager när han jobbade med detta på CMU i somras och kunde därför inte ta hänsyn till den i sin lösning, FLIP (Foreign Language Interface Package). (Andrew är en påbyggnad på Unix som konstruerats på Carnegie- Mellon University för att koppla ihop deras för närvarande 2000 "arbetsstationer" av olika fabrikat med filbetjänter/file_ser- vers, där alla användarfiler lagras, i ett enda lokalnät/LAN. Fysiskt består det av ett antal Token Ring-nät av IBM-typ sam- manbundna av en Ethernet-ryggrad/backbone.) Tomas erfarenheter visar en allvarlig nackdel med de av dig hyllade de facto-standarderna jämfört med standarder som utfor- mas av officiella standardiseringsorgan: Det är inte bara omöj- ligt för utomstående att påverka deras utformning, de kan också vara ogörligt att ens få reda på vad de innehåller också för vänligt inställda företag och institutioner som vill bygga egna produkter på standardens grund. Detta beteende är nog ofta även företagsekonomiskt olönsamt för de fåtal företag som är stora nog att kunna skapa de facto-standarder, men en naturlig följd av stora privata amerikanska företags sätt att fungera. Apples Script Manager är för företaget Apple inte i första hand en standard utan en kommersiell produkt, som man investerat mycket pengar i och ska använda för att bekriga sina konkurren- ter med, och givetvis hemlighåller man den i det längsta och förbehåller sig rätten att i framtiden införa ändringar utan förvarning och med kommersiella snarare än tekniska motiv. Jag tror inte att Apple kommer att fungera ett dugg bättre än IBM gjort i liknande situationer, om det skulle få samma dominerande marknadsposition och därmed standardbestämmande förmåga som IBM har på stordatorområdet.
(Text 772085) (1 kommentar)
(Text 772086) 88-02-02 22.39 Olle Järnefors KTH För kännedom: Standarder (inom) databehandlingsområdet <1460> Kommentar till: (Text 771762) av Jan Michael Rynning (jmr@nada.kth.se) <1> Ärende: Kritik mot tangentbordsstandarder - Fattar man i en godtycklig bank utanför Norden att 'DKR' betyder danska kronor? - När jag talar om ASCII avser jag den officiella amerikanska standarden ANSI X3.4, "American National Standard Code for Information Interchange", vars första version kom 1968. Den reviderades 1977, tror jag, med mycket små ändringar. Detta är i stor kontrast till IBM:s EBCDIC-kod, som finns i ett stort antal av IBM självt införda varianter för olika pro- duktlinjer och typer av utrustning. - Jag menade förstås att FORTRAN 77 i motsats till 1966 års modell har i språket inbyggda satser IF, ELSE IF, ELSE och END IF, ungefär motsvarande if-then-else-satserna i Ada och Modula-2. Att man kan simulera de flesta styrstrukturer med bara enkelt IF och GOTO är en trivialitet. Min poäng är att riktiga if-then-else-satser gör det _enkelt_ för medelpro- grammeraren att skriva välstrukturerade program, inte att de skulle vara en nödvändig förutsättning för det. - Din kommentar om X.400 är den intressantaste, eftersom jag i det fallet har dåligt på fötterna. Menar du att det redan idag finns alternativ till X.400 som ger samma eller bättre tekniska möjligheter att koppla ihop dagens elektroniska postöar (vilket är det i så fall?) eller menar du att någon de facto-standard med sådan funktionalitet, som vi idag inte vet hur den kommer att se ut, kommer att etab-leras i fram- tiden, innan de tröga standardiseringsbyråkraterna lyckats få X.400 färdigt?
(Text 772086) (1 kommentar)
(Text 772116) 88-02-02 23.04 Johnny Eriksson Mottagare: Standarder (inom) databehandlingsområdet <1461> Mottagare: SuperKOM erfarenhetsutbyte <949> Kommentar till: (Text 771577) av Olle Järnefors KTH <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Om användaren själv vill ha teckenuppsättningen motsvarande SO just den sessionen då? Han slipper också?
(Text 772116) (1 kommentar)
(Text 772152) 88-02-03 00.07 Johnny Eriksson För kännedom: Standarder (inom) databehandlingsområdet <1462> Kommentar till: (Text 772086) av Olle Järnefors KTH <1> Ärende: Kritik mot tangentbordsstandarder DKR? Heter det inte DKK, eller yrar jag? Samt: Jag kan idag, mig veterligen, skicka post världen över, utan att använda X.400. Ibland blir det problem, men det skyller jag på tekniska ofullkomligheter, och inte på standarden som sådan. Tvärt- om, jag kan inte se att adressering enligt X.400 skulle hindrat mina brev att komma bort på vägen...
(Text 772152) (1 kommentar)
(Text 772702) 88-02-04 07.00 Michael Evans STOCC Mottagare: Standarder (inom) databehandlingsområdet <1463> För kännedom: Fikonspråk - översättning från datorslang till svenska <2554> Kommentar till: (Text 682960) av Olle Järnefors KTH <3> Extra kopia: Bertil Hellsen QZ <1869> -- Mottaget: 88-02-04 08.46 Sändare: Peter Olofsson QZ -- Sänt: 88-02-04 08.36 Extra kopia: Urval datorfrågor <139> Sändare: Torgny Tholerus QZ -- Sänt: 88-02-04 10.12 Extra kopia: B3 urval <123> Sändare: Tommy Ericson KOMunity -- Sänt: 88-02-05 01.51 Markerad av någon. Ärende: Tangentbeskrivning för portabla program (Den kommenterade texten från 87-08-09 gällde huruvida man kunde använda samma beteckning för tangenterna mellan olika terminaltyper, exempelvis VT220, Mac, IBM PC och Compis.) Jag har sammanställt en motsvarande lista för IBMs 3270-familj av terminaler, inklusive den moderna 3191. Eftersom det finns flera varianter av tangenter till terminalerna inklusiv APL och Data Entry (som liknar gamla hålkortsstansar), har jag endast tagit med det vanligaste, "Svensk/finsk tangentbord med 122 tangenter". Man skall komma ihåg att 3270-familjen arbetar alltid skärmvis, aldrig teckenvis. Vissa av tangenterna innebär att fälten som har förändrats skickas till värddatorn, tillsammans med en kod som anger vilken sändnings- tangent som trycktes. Dessa är markerade med * nedan. Den aktuella markörpositionen skickas alltid tillsammans med koden för sändnings- tangenten. Andra tangent innebär att endast tangentkoden skickas till värddatorn. Eventuell inmatad data tappas bort. Dessa tangent är markerade med + nedan. IBM 3270 familj namn ------------+ ! Sänd endast kod till värddatorn ---+ ! Sänd data + kod till värddatorn -+ ! ! ! ! ! IBM 3270 --------------+ ! ! ! Beteckning ------+ ! ! ! ! Namn -+ ! ! ! ! ! ! ! ! ! ! ! Mellanslagstangent (BLANK) 2 Blankstegare (i alfabetisk delen) Space (i tangentbordets numerisk del) Returtangent (RETUR) x Radmatare Backtangent (BACK) x Backstegare Tabulatortangent (TAB) x Tabulator Fritangent??? (FRI) x En begränsad variant kallas ExSel (= Extra Selection ??) Radertangent (RADER) x Teckenborttagare Skifttangent (SKIFT) 1 Övre skiftläge Kontrolltangent (KONTR) *** saknas *** Alt-tangent (ALT) 1 Alternativt skiftläge Skiftlåstangent (LÅS) 1 Skiftlås Upptangent (UPP) x Markörstegare uppåt Nertangent (NER) x Markörstegare neråt Vänstertangent (VÄNST) x Markörstegare åt vänster Högertangent (HÖGER) x Markörstegare åt höger Hemtangent (HEM) x Hemlägestangent Förra-tangent (FÖRRA) *** saknas *** Nästa-tangent (NÄSTA) *** saknas *** Sista-tangent (SISTA) *** saknas *** Inmatningstangent (INMAT) *** saknas ???? *** Infogatangent (INFOGA) x Insättningstangent Utskriftstangent (UTSKR) x Print, PrtSc, skriv bild Frystangent (FRYS) x *** saknas *** Bryttangent (Attn) x + Signaltangent Inställningstangent (INST) *** saknas *** Hjälptangent (HJÄLP) *** saknas *** Utförtangent (UTFÖR) x * Enter, sändningstangent ** Obs ** Ogörtangent (OGÖR) *** saknas *** Söktangent (SÖK) *** saknas *** Valtangent (CurSel) x * Markörfältväljare Borttagningstangent (BORT) x + Rensningstangent, Clear Funktionstangenter (PFn) 24 * Programfunktionstangenter Funktionstangenter (PAn) 2 + Tangenter för programåtkomst Andra specialtangenter ---------------------- Dubbelvänster x Markörstegare, dubbel hastighet, åt vänster, vänster ett ord Dubbelhöger x Markörstegare, dubbel hastighet, åt höger, höger ett ord Backtabulator x Backtabulator Raderingstangent (ErInp) x (Tar endast bort inmatad data, ej formuläret) Fältradering (ErEOF) x Fältraderingstangent Duplicering (Dup) x Dupliceringstangent Field Mark x Fältmarkering Återställ (Reset) x Återställningstangent Systembegäran (SysRq) x + Ordradering x (Wrap) x Ordnedflyttning (CrPos) x Markörpositionstangent (ChgFmt)x Ändra dokumentformat Anmärkningar: Jag har inte tagit med de mycket 3270-specifika tangenter så som Device Cancel, Dial, Comm osv (delvis för att jag inte har klart för mig vad de gör).
(Text 772702) (3 kommentarer)
(Text 772819) 88-02-04 11.03 Per Danielsson Mottagare: Standarder (inom) databehandlingsområdet <1464> Mottagare: SuperKOM erfarenhetsutbyte <950> För kännedom: Jan Bjurström FMV <368> -- Mottaget: 88-02-08 11.51 För kännedom: Peder Swenman FFV Elektronik AB <569> -- Mottaget: 88-02-08 22.11 Kommentar till: (Text 771578) av Olle Järnefors KTH <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Vilka latinska bokstäver använder afrikanska språk (vilka språk?), som europeiska språk inte använder?
(Text 772819) (2 kommentarer)
(Text 773233) 88-02-05 02.14 Tommy Ericson KOMunity Mottagare: Standarder (inom) databehandlingsområdet <1465> Extra kopia: Hackers (@) Oden <2560> Kommentar till: (Text 771762) av Jan Michael Rynning (jmr@nada.kth.se) <2> Markerad av någon. Ärende: Kritik mot tangentbordsstandarder "IF-THEN-ELSE-konstruktioner kunde man även ha i FORTRAN 66, även om man fick skriva dem med GOTO." var det roligaste jag hört på länge ... (Real Programmers can write Fortran in any language :-) Beträffande din kommentar om X.400: det är färdigt i formell mening, men det finns fortfarande tekniska problem kvar att lösa. Det väsentliga med X.400 (jämfört med RFC-protokollen) är att man börjat DEFINIERA abstrakta datatyper mer i stället för att låta allt ligga i algoritmdelen. Jag tycker att N. Wirths boktitel "A + D = P" beskriver detta på ett utmärkt sätt: om man minskar på D(ata structures) så måste man öka på A(lgorithms) för att P(rograms) skall vara invariant. Och "för mycket A" leder, som de flesta säkert instämmer i, till s k italiensk (spagetti) kod. Det finns vissa tecken på att det borde vara en multiplikations- operator istf additionsdito i ekvationen...
(Text 773233) (1 kommentar)
(Text 773784) 88-02-05 21.16 Benny Brodda Lingv Su Mottagare: Standarder (inom) databehandlingsområdet <1466> Kommentar till: (Text 771102) av Johan Lundberg TeleDelta <1> Subject: teckenkonvertering Är du säker på att transkriptonen a a o är den vanligaste? Vedrtaget (i telegramspråk o dyl) är ju den andra varianten aa, ae, oe. Den har ju mycket gammal hävd ( tyskan och danskan, t ex), och den kan man ju alltid ta till närhelst det kan uppstå missförstån (eller risk att någon känslig jäkel blir förbenad). Problemet är knappast en fråga för språkvetare/språk- riktighetsivrarer. Däremot blir det störande när man skickar 7-bits ascii och inte tänker på att våra svenska nationalkaraktärer förvandlas till måsvingar, backslashar o dyl. Än värre blir det om man skickar iväg 8-bits via våra internationella nät; det brukar inte bli bra.
(Text 773784) (2 kommentarer)
(Text 773888) 88-02-06 00.54 Alan Sheats Afasiförbundet Mottagare: Standarder (inom) databehandlingsområdet <1467> Mottagare: SuperKOM erfarenhetsutbyte <951> För kännedom: IBM PC (och kompatibler) MS WINDOWS <174> Kommentar till: (Text 771576) av Olle Järnefors KTH <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Jag tänker på tre saker: 1) Man får förutsätta att det finns "lokalintelligens" och att dumma terminaler inte längre existerar. 2) Översättningstabeller har såväl Super-KOM som de uppkopplade användarna möjlighet att använda. 3) Hitintills har terminal- eller kommunikationsprogram varit relativt begränsade vad gäller förmågan att anpassa vad programmet skickar ut till olika "hosts". Även om Super-KOM som "host" kan stödja alla upptänkliga protokoll och teckenuppsättningar, kommer det att finnas luckor, och det som fungerar bäst för Super-KOM blir antagligen något som för vissa användare fungerar allra sämst. Här ligger inte problemet hos värden - så heter "host", visst - utan snarare hos de som tillhandahåller den lokala intelligensen. Den ska inte bara lyssna utan kunna hävda ett protokoll eller en översättningstabell som fungerar bäst för kunden.
(Text 773888)
(Text 774200) 88-02-07 12.04 Jan Michael Rynning (jmr@nada.kth.se) Mottagare: Standarder (inom) databehandlingsområdet <1468> Mottagare: SuperKOM erfarenhetsutbyte <952> För kännedom: Jan Bjurström FMV <369> -- Mottaget: 88-02-08 11.51 För kännedom: Peder Swenman FFV Elektronik AB <570> -- Mottaget: 88-02-08 22.11 Kommentar till: (Text 772819) av Per Danielsson <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Tja, Swahili lär använda exponentsiffran 2 för att beteckna pluralis (som bildas genom att dubblera substantivet - fotfot är således fötter o.s.v.).
(Text 774200) (1 kommentar)
(Text 774313) 88-02-07 16.07 Bo Thide Inst f rymdfysik Uppsala Mottagare: Standarder (inom) databehandlingsområdet <1469> Mottagare: SuperKOM erfarenhetsutbyte <953> För kännedom: Jan Bjurström FMV <370> -- Mottaget: 88-02-08 11.52 För kännedom: Peder Swenman FFV Elektronik AB <571> -- Mottaget: 88-02-08 22.11 Kommentar till: (Text 774200) av Jan Michael Rynning (jmr@nada.kth.se) <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Så vitt jag kommer ihåg har indonesiskan (med latinska bokstäver) en liknande pluraliskonstruktion. (Jag tror att "fötter" skulle heta "fot2" - huruvida man egentligen skall ha 2an upphöjd från linjen vet jag inte).
(Text 774313)
(Text 774316) 88-02-07 16.23 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1470> Mottagare: Nät (både) datornät (och) terminalnät <1880> För kännedom: @KOM.KOMUNITY.SE: Staffan Johansson <40> -- Mottaget: 88-02-08 18.02 Sändare: -- Sänt: 88-02-08 11.35 Ärende: ASN.1/ROS ASN.1/ROS är mycket viktiga begrepp för den som vill bygga upp datornätsprotokoll. Det är standardiserade metoder att bygga upp kommandon för en dator att tala med en annan, inklusive metoder att packa strukturerade data i ett format som passar för att skicka data från en dator till en annan, och ett språk för att speca syntax för sådana datapaket som sänds mellan datorer. Både X.400 och X.500 använder sig av ASN.1/ROS, och troligen kommer ASN.1/ROS att bli standard för alla typer av paket där två datorer talar med varandra via nät. Jag har just fått en kallelse till ett seminarium om ASN.1/ROS där en av protokollets skapare, Doug Steedman, skall tala. 14-15 mars 1988 i London, pris 684.25 pund - inte billigt direkt. Mer info från Technology Appraisals Ltd, Beaufort Road Centre, Beaufort Road, Marble Hill Park, Twickenham, Middlesex TW1 2PQ, United Kingdom, Telefon +1-744 1155.
(Text 774316) (2 kommentarer)
(Text 774344) 88-02-07 18.13 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1471> Kommentar till: (Text 771593) av Olle Järnefors KTH <4> Ärende: Ny-uttänkta standarder kontra standard av känd teknik Mycket av det som görs i internationellt standardiseringsarbete är konstruktion av ny teknik, inte bara sammanfattning av känd teknik. I alla fall är det så inom området meddelandehantering, där jag varit med en del. Jag måste säga att jag upplever det som lite skrämmande hur man konstruerar ny teknik som kommer att beröra miljontals människor utan att ha gjort någon som helst utvärdering av användarvänligheten. Ett skrämmande exempel är de elektroniska brevadresserna. Jag måste antagligen i framtiden på mina visitkort skriva min elektroniska brevadress något i följande stil: Given name: Jacob Surname: Palme Organization: QZ Private domain: KOM.QZ Administrativa domain: TVT Country: SE Det är verkligen inte människovänligt. För att klara av detta problem, har man nu infört ett nytt typ av namn, som kallas för "Directory Name" och skall vara något enklare. Men då får man istället krångel med att det finns två olika namn, och att ibland fungerar bara det ena, ibland bara det andra. Dessutom är "Directory Name" inte så väldigt enkelt det heller.
(Text 774344) (1 kommentar)
(Text 774346) 88-02-07 18.18 Jacob Palme QZ För kännedom: Standarder (inom) databehandlingsområdet <1472> Kommentar till: (Text 771736) av Kjell Krona Arkitektur KTH <4> Ärende: Kritik mot tangentbordsstandarder Det går faktiskt utmärkt att klara av både Å=A med ring och Å=hakparentes på samma skärm även med enbart användning av de olika ASCII-varianterna. Det finns nämligen standardiserade koder för att växla mellan de olika ASCII-varianterna. Problemet är att utrustningsleverantörerna inte följer den standard som finns, just ifråga om växling mellan olika ASCII-varianter. Framförallt Digital med VT100 har förstört saker och ting grundligt genom att leverera svenska VT100-or som ofta är konfigurerade så att ASCII-koderna för växling mellan olika ASCII-varianter ger helt bakvänd effekt. Och alla andra leverantörer kopierar ju VT100 och så blir allt helt förstört. Den här saken diskuterades i en mycket het debatt mellan mig och JMR här i KOM för ett antal år sedan, jag hoppas att inte detta inlägg skall leda till att hela den debatten måste upprepas igen.
(Text 774346) (1 kommentar)
(Text 774350) 88-02-07 18.22 Jacob Palme QZ För kännedom: Standarder (inom) databehandlingsområdet <1473> Kommentar till: (Text 772085) av Olle Järnefors KTH <1> Ärende: Kritik mot tangentbordsstandarder ISO 6937 är *inte* en 16-bitars standard i den meningen att man måste ha fördubblad minneskapacitet. ISO 6937 använder 16 bitar bara för tecken med olika slag av accenter, till vilka de även räknar ÅÄÖ, prickarna och ringarna hanterar de alltså som accenter. Eftersom dessa tecken bara är en mindre del av teckenmängden i de flesta språk, blir det inte alls 16 bitar som behövs per tecken i medeltal.
(Text 774350) (1 kommentar)
(Text 774353) 88-02-07 18.31 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1474> Mottagare: SuperKOM erfarenhetsutbyte <954> Kommentar till: (Text 771575) av Olle Järnefors KTH <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Jag tycker inte särskilt mycket om sådana där konstiga kod- varianter, där användaren måste lära sig att paragraftecken t.ex. heter '&ss". Ett förslag, som jag funderat på en del, är att representera de tecken som inte kan visas på skärmen i följande format: ~<number sign>. Fördel: Användaren behöver bara lära sig en konstig konvention, nämligen att ~<...> betyder något annat än sig själv. Sedan kan man mellan < och > sätta in en människonaturlig ordbeskrivning av tecknet, t.ex. dess officiella namn i standarderna. Nackdel: Det blir en ganska lång sträng. Ö blir t.ex., för skärmar som inte kan visa Ö ~<capital O with diaeresis or umlaut mark> om man skall ta den officiella ord-beskrivningen av detta tecken.
(Text 774353) (2 kommentarer)
(Text 774361) 88-02-07 18.44 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1475> Kommentar till: (Text 771582) av Olle Järnefors KTH <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Det generella sättet är givetvis att inte välja varken ISDO 6937 eller 8859 i dess åtta olika nationella varianter (ja, ISO 8859 är nästan lika illa som ASCII redan i att ha många olika nationella varianter för olika språks behov!) utan att istället ha en enda teckensträng, där man med ISO 2022 styrtecken växlar mellan alla världens olika teckenuppsättningar. Jag har nyss kommit hem från ett möte i Paris där man föreslog att utvidga X.400 med nio nya body part types, en för ISO 6937/2, och åtta för de åtta olika nationella varianterna av ISO 8859. Jag föreslog då vid mötet att man istället bara skulle ha en enda body part type, som kallas för "general string". Den tillåter alla teckenkoder, med 2022-escapesekvenser för byte mellan dem. Dock måste man i en parameterlista knuten till filen räkna upp beteckningar på alla olika teckenuppsättningar man växlar mellan i en text. Detta förslag från min sida gick igenom vid mötet, och jag tycker faktiskt jag bidragit med något positivt för att göra världen lite enklare genom att lägga fram detta förslag. Tyvärr var det i ISO jag la fram förslaget, och de som i realiten bestämmer över X.400 är ju CCITT så "general string" kommer i alla fall i början bara att finnas i ISO-s variant av X.400.
(Text 774361) (3 kommentarer)
(Text 774364) 88-02-07 18.46 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1476> För kännedom: SuperKOM erfarenhetsutbyte <956> Kommentar till: (Text 771591) av Olle Järnefors KTH <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Nej, det finns redan åtta olika ISO 8859-varianter, hörde jag på möte med ISO/IEC JTC 1/SC 18/WG 4 i Paris, där jag var förra veckan. Flera tillkommer säkert...
(Text 774364) (1 kommentar)
(Text 774366) 88-02-07 18.49 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1477> Kommentar till: (Text 773784) av Benny Brodda Lingv Su <1> Subject: teckenkonvertering Den stora nackdelen med AA, AE och OE är att folk i länder där ÅÄÖ inte alls finns sällan begriper denna transkriptionsregel. Transkriptionsprincipen att bara ta bort accenter är däremot något som alla begriper. Därför förordar jag den metoden.
(Text 774366)
(Text 774369) 88-02-07 18.54 Jacob Palme QZ För kännedom: Standarder (inom) databehandlingsområdet <1478> Kommentar till: (Text 771762) av Jan Michael Rynning (jmr@nada.kth.se) <3> Ärende: Kritik mot tangentbordsstandarder Du skriver > - När X.400 någon gång i framtiden blir färdigt kommer man > att kunna göra det man kunnat göra sedan åratal. Vilken > tur att det finns folk som återuppfinner hjulet! Det är > precis det vi behöver. Givetvis så har det funnits några tidigare system före X.400 som internt inom en sluten krets kunnat erbjuda samma funktioner som i X.400. Men det viktiga med X.400 är ju att det är avsett att bli en standard för brevkommunikation mellan många olika system över hela världen. De enda standarder idag som möjliggör brevkommunikation på detta sätt är de olika varianterna av RFC822. Jämfört med dem har X.400 en mängd nya saker som man inte kan göra i RFC822 (vissa av dessa funktioner finns i vissa delnät byggande på RFC822): - Delivery och non-delivery notification - Receipt och non-receipt notification - Kraftfullare teckenstandarder än ASCII o.s.v.
(Text 774369) (1 kommentar)
(Text 774430) 88-02-07 20.21 Jan Flodin FMV Mottagare: Standarder (inom) databehandlingsområdet <1479> Mottagare: Nät (både) datornät (och) terminalnät <1881> Kommentar till: (Text 774316) av Jacob Palme QZ <1> Ärende: ASN.1/ROS Sitter hemma just nu och har inte CCITT-böckerna här, men jag tror det är X.409 som innehåller ASN.1 (dvs samma beskrivning).
(Text 774430) (1 kommentar)
(Text 774571) 88-02-08 01.13 Tommy Ericson KOMunity Mottagare: Standarder (inom) databehandlingsområdet <1480> Mottagare: Nät (både) datornät (och) terminalnät <1882> Kommentar till: (Text 774430) av Jan Flodin FMV <1> För kännedom: Peder Swenman FFV Elektronik AB <572> -- Mottaget: 88-02-10 21.34 Sändare: Jan Flodin FMV -- Sänt: 88-02-09 17.05 För kännedom: Jan Bjurström FMV <372> -- Mottaget: 88-02-10 22.00 Sändare: Jan Flodin FMV -- Sänt: 88-02-09 17.05 Ärende: ASN.1/ROS Ja, X.409 var den första ASN.1-an, men jag tror att den nu har tagits över av ISO TC97/SC21/WG1(?) och heter ISO 8824. Dessutom finns det ett ISO 8824/PDAD1 med utvidgningar till ASN.1, mitt ex är från 1987-07-22, men jag tror att det har kommit in mer tillägg sedan dess. Den som åker till London och verkligen vill lära sig förstå ASN.1 rekommenderas fråga Dough hur macro-faciliteten fungerar. Jag tycker personligen att man tenderar att överskrida det till- tänkta användningsområdet för ASN.1 den sista tiden, det är ett vettigt verktyg för att uttrycka syntax, men semantik är det inte särskilt väl lämpat för, trots skenbarliga abstraktioner åt det objektorienterade hållet.
(Text 774571)
(Text 774579) 88-02-08 01.45 Tommy Ericson KOMunity Mottagare: Standarder (inom) databehandlingsområdet <1481> Mottagare: SuperKOM erfarenhetsutbyte <957> Kommentar till: (Text 774353) av Jacob Palme QZ <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM ANVÄNDAREN bör skyddas från allt krångligt med teckenstandard hit och dit. Det är inte svårt att förklara för någon att "om du använder huggmejsel och stentavla så kan du inte sända post till någon som använder litet modernare verktyg ...", att försöka hitta på en standard för "interworking" tjänar ingen på, på sin höjd den som utformar den.
(Text 774579) (1 kommentar)
(Text 774582) 88-02-08 01.55 Tommy Ericson KOMunity Mottagare: Standarder (inom) databehandlingsområdet <1482> Kommentar till: (Text 774361) av Jacob Palme QZ <1> Ärende: Standardiseringsexplosionen inom OSI Ja, det börjar likna något: med tanke på den takt i vilken standards inom OSI nu börjar välla fram (jfr SFS och lagar!) inser man lätt att det vore bättre att göra EN standard som beskriver hur man beskriver en teckenstandard och sedan låta ISO, CCITT, SIS, AFNOR, NBS osv använda DENNA standard för att skapa de definitioner som idag tyvärr bara är pappersprodukter. Detta betraktelsesätt har jag och Johan Lundberg (och ett fåtal till runt om i världen) med viss, begränsad framgång försökt få in i X.500/ISO 9594.
(Text 774582) (1 kommentar)
(Text 774586) 88-02-08 03.53 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1483> Mottagare: SuperKOM erfarenhetsutbyte <958> Kommentar till: (Text 772116) av Johnny Eriksson <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Då får han välja en annan översättningstabell. Men varför skulle han vilja det? Han får ju tillgång till både vänster hakparantes och versalt Ä i utmatningen från SuperKOM redan med den första tabellen.
(Text 774586)
(Text 774587) 88-02-08 03.54 Olle Järnefors KTH För kännedom: Standarder (inom) databehandlingsområdet <1484> Kommentar till: (Text 772152) av Johnny Eriksson <1> Ärende: Kritik mot tangentbordsstandarder 'DKK' är den förkortning som jag menar numera kan användas utan problem i banker världen över. 'DKr' är den äldre förkortning som Jan Michael Rynning men inte jag menar kan användas utan problem. Se vidare det inlägg du kommenterade och dess före- gångare! För en vanlig stordatoranvändare som inte är mer eller mindre expert på datorbrevnäten -- till exempel mig -- är det _mycket_ svårare att skicka ett datorbrev till någon användare på en annan stordator och mycket större risk för att det inte kommer fram än att lyfta telefonluren och ringa samma person. Det beror uppenbarligen bland annat på för lite standardisering och på att befintliga standarder är dåliga. Som jag har förstått saken är X.400 den standard för datorbrevkommunikation som alla stor- datortillverkare, inklusive IBM, har uttalat att de kommer att ta fram produkter som stöder. Vilket alternativ har du att komma med som är eller kommer att bli bättre eller mera spritt än X.400?
(Text 774587)
(Text 774588) 88-02-08 03.55 Olle Järnefors KTH För kännedom: Standarder (inom) databehandlingsområdet <1485> Kommentar till: (Text 774350) av Jacob Palme QZ <1> Ärende: 16-bitskod? Det är riktigt. Jag skrev ju också om vad som kan komma _efter_ ISO 6937. Kjell Krona har tidigare förutspått en 16-bitskod, eftersom 8 bitar uppenbarligen är för lite för att representera alla tecken man kan vilja ha. Bo Thide har menat att shift- in/shift-out-tekniken är förkastlig (se 762893), vilket jag tolkar som ett indirekt förord för 16-bitskod. Min tro är att det av eknomiska skäl blir nödvändigt att till- handahålla tecken utöver ISO 6937 som nya 8-bits teckenkods- tabeller, som man får växla mellan troligen enligt kodväxlings- standarden ISO 2022, alltså en sorts shift-in/shift-out-teknik. I varje fall tror jag detta gäller för lagring på sekundärminne. Vid hantering av text i processor och primärminne är det möjli- gen realistiskt att ha en 16- eller 24- eller 32-bitskod, där ett fysiskt tecken alltid representeras av en unik bitföljd. Om man använder en mer komplicerad teckenkod, där escape-sekvenser och styrtecken måste användas för byte mellan olika 8-bitskoder, kan ju sådana enkla strängoperationer som - att ta reda på hur många positioner som behövs för visning av en sträng, - att avgöra om två strängar är lika (= ser likadana ut när de visas) - sökning efter delsträngar - sammanfogning/concatentation av strängar inte implementeras på samma enkla sätt som i de flesta av dagens program, som arbetar med en enkel 7- eller 8-bitskod.
(Text 774588) (1 kommentar)
(Text 774589) 88-02-08 03.56 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1486> Mottagare: SuperKOM erfarenhetsutbyte <959> Kommentar till: (Text 774353) av Jacob Palme QZ <2> Ärende: Representation av tecken terminalen inte klarar När det gäller inmatning till SuperKOM är det nog bara ganska sofistikerade användare som kommer att använda en sådan här möjlighet. Jag betvivlar att de kommer att uppleva till exempel (a) Den danske fysikern H C ~<captial O with slash>rsted upptäckte som mer användarvänligt än (b) Den danske fysikern H C &O/rsted upptäckte Snarare tvärtom. Det går _mycket_ fortare att skriva enligt metod (b). Symbolen för det danska ö-et är mer suggestiv, när man läser texten, vilket kanske också gör den lättare att lära sig. Samtidigt får man en mycket bättre uppfattning om hur texten i stort kommer att se ut på en skärm som kan visa danska ö, eftersom de ord som kommer efter förskjuts bara två posi- tioner åt höger i stället för 22. Tre främmande tecken på raden enligt metod (a) och det ryms inte mycket mer. Risken för att man ska skriva något tecken fel i en sekvens av 23 tecken är förstås också mycket större än om det bara behövs tre tecken. Föregående stycke innehåller ungefär 600 tecken varav 33 är 'å', 'ä' eller 'ö'. Om jag hade varit hänvisad till en terminal utan svenska specialbokstäver, tror jag inte att jag hade orkat skriva in ytterligare säg 600 tecken (jag antar att 19 tecken för att representera en svensk specialbokstav enligt (a) - metoden) för att kunna lagra den som en riktig svensk text i SuperKOM, speciellt som det skulle vara väldigt tråkigt att skriva exakt samma 18-teckenskombination ungefär tio gånger i ett så kort stycke text. Däremot skulle inte de 66 extra tecken som behövs enligt metod (b) bara betungande på samma sätt. Om man väljer metod (a) är det mindre lyckat att använda tecknet '~' som "flykttecken", eftersom det inte ingår i den invarianta delen av ISO 646. Det kommer alltså att se olika ut på olika terminaler, i Sverige vanligen som litet tyskt y, tilde eller överstreck, och det blir svårt att skriva en terminaloberoende dokumentation av denna aspekt på systemet.
(Text 774589) (1 kommentar)
(Text 774590) 88-02-08 03.57 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1487> Mottagare: SuperKOM erfarenhetsutbyte <960> Kommentar till: (Text 774579) av Tommy Ericson KOMunity <1> Ärende: ISO 6937 eller 8859 eller IBM PC-tecken i KOM/PortaCOM/SuperKOM Givetvis ska inte den genomsnittlige användaren behöva veta någonting om teckenkoder (så länge han håller sig till sin gamla vanliga terminal). Men därför behöver inte mer kunniga eller djärva användare hindras från att mata in vilket tecken de vill, bara för att de råkar ha blivit hänvisade till en gammaldags terminal.
(Text 774590)
(Text 774591) 88-02-08 03.58 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1488> Kommentar till: (Text 774361) av Jacob Palme QZ <2> Ärende: Generella strängar Eftersom alla ISO-standardiserade teckenkoder har unika escape- sekvenser så kan ju det fungera. En maskin som ska textbehandla en sådan "general string" måste förstås internt kunna översätta mellan alla teckenkoderna; samma tecken kan ju dels förekomma på olika kodplatser i olika koder, dels i vissa koder representeras av en oktett, i andra av två oktetter.
(Text 774591) (1 kommentar)
(Text 774593) 88-02-08 04.00 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1489> Kommentar till: (Text 774364) av Jacob Palme QZ <1> Ärende: Varianter av teckenkoden ISO 8859 Jag känner till två utöver 8859/1 och 8859/2. ISO 8859/3 ska vara en sydeuropeisk teckenkod och ISO 8859/4 en nordeuropeisk. Men är dessa redan officiellt fastställda och vad innehåller de fyra senare delarna av 8859?
(Text 774593) (1 kommentar)
(Text 773775) 88-02-05 21.03 Lars-Åke Larsson Dapugruppen Mottagare: Macintosh erfarenhetsutbyte <3113> Mottagare: Lars-Åke Larsson Dapugruppen <2597> -- Mottaget: 88-02-05 21.03 Kommentar till: (Text 762864) av Torbjörn Nordlindh Apple Computer AB <2> För kännedom: Standarder (inom) databehandlingsområdet <1490> Sändare: Olle Järnefors KTH -- Sänt: 88-02-08 04.01 Ärende: Tangentbords-standard. Standarden här i landet för tangentbord säger väl också att det skall sitta en tangent MELLAN z och skift-tangenten. Den standarden är otroligt olämplig ur ergonomisk synpunkt och förmodligen framsprungen från folk som inte kan skriva maskin ordentligt. - Om man ändå låter händerna cirkla över tangentbordet som två stora örnar som slår till här och var, då spelar det ingen roll var tangenterna sitter. Amerikanska tangentbord brukar däremot inte efterlikna den i detta avseende usla svenska standarden.
(Text 773775) (1 kommentar)
(Text 774604) 88-02-08 04.08 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1491> Kommentar till: (Text 772819) av Per Danielsson <2> Ärende: Afrikanska bokstäver Standarden ISO 6438, "Documentation -- African coded character set for bibliographic information interchange" innehåller 60 afrikanska bokstäver varav jag vid en snabb titt bara hittar fyra i ISO 6937. (Däremot hade jag fel om diakritiska tecken, inga sådana ingår i standarden.) De afrikanska bokstäverna är ofta lätt modifierade bokstäver från grundalfabetet, till exem- pel litet 'n' där det första lodräta strecket fortsätter i en liten sväng bakåt under raden och ett 'n' där det främre strecket svänger ner åt andra hållet. Det finns också spegel- vända C-n och E-n, ett 'E' som ser ut som första bokstaven på de gamla Esso-skyltarna. Bokstäverna har i ISO 6438 namn efter hur det ljud de betecknar alstras. De jag nämnt kallas palatal nasal, alveolar nasal retroflex, öppen medelbakre vokal, medelcentral vokal respek- tive öppen medelfrämre vokal. Standarden räknar upp 88 språk som "were taken into account" när den utarbetades. Det kändaste av dem är swahili men även språken zulu, efik, pedi, nkodo, tumbuka och kikuyu finns med för att ta några ur högen.
(Text 774604) (1 kommentar)
(Text 774728) 88-02-08 13.59 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1492> Kommentar till: (Text 773784) av Benny Brodda Lingv Su <2> Subject: teckenkonvertering Jag vet inte riktigt vad som vanligast. jag tänkte närmast på SKANSKA, SAMHALL och liknande. Jag inbillade mig att förmågan att känna igen ett ord berodde på dess utseende och inte på dess stavning. Är det så att ett ords utseende ändras mer om man tar bort diakriter än om man lägger till en extra bokstav? Någon som vet/har gjort undersökningar?
(Text 774728)
(Text 774743) 88-02-08 14.10 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1493> Kommentar till: (Text 774591) av Olle Järnefors KTH <1> Ärende: Generella strängar Det finns inom OSI modellen något som kallas ASN.1. Det är en abstrakt metod att specificera protokoll för Applikations skiktet. Om jag inte minns fel så lade man till just "General String" som en datatyp till det addendum som är på väg. Det förefaller vara en lösning som håller ett tag men som samtidigt konserverar den soppa som vi har idag med en hel rad olika standarder för nästan samma sak.
(Text 774743) (1 kommentar)
(Text 774752) 88-02-08 14.14 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1494> Mottagare: Nät (både) datornät (och) terminalnät <1883> För kännedom: @KOM.KOMUNITY.SE: Staffan Johansson <41> -- Mottaget: 88-02-08 18.02 Kommentar till: (Text 774316) av Jacob Palme QZ <2> Ärende: ASN.1/ROS ROS är inget nytt precis. Det introducerades med X.400 1984. likaså ASN.1 Rekommenderar att läsa X.409 och X.410 Eller varför inte de nya versionerna X.208/209 och X.19/229 ISO SC 18 har också tänkt ge ut dem men jag kommer inte ihåg nummren på rak arm.
(Text 774752)
(Text 774755) 88-02-08 14.17 Sven Olofsson QZ Mottagare: Standarder (inom) databehandlingsområdet <1495> Markerad av någon. Ärende: Domännamn DEC-10 Odens samling av RFC-dokument har nu utökats med RFC nummer 799, 819, 952, 953, 1032 och 1033. Därmed finns den fullständiga uppsättningen av RFC-er som har med domännamn på Oden. Se filen DOC:DOMAIN.RFC. Detta är listan på domännamns-RFC-erna: RFC Document title --- -------------- 799 Internet Name Domains 819 Domain Naming Convention for Internet User Applications 920 Domain Requirements 921 Domain Name System Implementation Schedule - Revised 952 Internet Host Table Specification 953 Hostnames Server 974 Mail Routing and the Domain System 1032 Domain Administrators Guide 1033 Domain Administration Operations Guide 1034 Domain Names - Concepts and Facilities 1035 Domain Names - Implementation Specification RFC-erna finns sparade på Oden som DOC:<RFC-nummer>.RFC. Se HLP:RFC.HLP för mer information.
(Text 774755)
(Text 774901) 88-02-08 19.22 Bo Thide Inst f rymdfysik Uppsala För kännedom: Standarder (inom) databehandlingsområdet <1496> Kommentar till: (Text 774346) av Jacob Palme QZ <1> Ärende: Kritik mot tangentbordsstandarder Är det verkligen sant att man kan ha både hak-parenteser och svenska a med ring/a med prickar på samma skärm men oilka positioner samtidigt? Nog tycker jag att jag testat med en VT220-kompatibel (GraphOn-250) och andra terminaler och jag kan inte få den effekten. Jag vill minnas att 7-bitars ASCII med shift-out för att byta alfabet gör att samtliga hakparenteser skrivs om nästa gång till svenska vokaler när jag skriver om skärmen med samma innehåll . Minns jag fel? Den effekt du beskriver har jag dock sett fungera på radskrivare från Texas och HP. Jag har tolkat det som att den bit-kombination som beskriver en hakparentes på skÄrmen vid byte av alfabet i stället tolkas som svensk vokal och teckengeneratorn visar den senare. Såvitt jag förstår klarar inte det interna minnet att hantera båda tolkningarna samtidigt. Det gör det omöjligt att använda denna teknik i en editor t.ex. där man hoppar fram och tillbaka i texten (såvida man inte kan lösa det på ett klumpigt sätt med att ständigt skriva om skärmen??).
(Text 774901) (1 kommentar)
(Text 774908) 88-02-08 19.24 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1497> Kommentar till: (Text 774743) av Johan Lundberg TeleDelta <1> Ärende: Generella strängar "General string" duger för alla textformat som är rena textsträngar, med escapesekvenser för byte mellan olika teckenuppsättningar. Däremot kan "general string" inte användas för sådana objekt, som inte bara är ren text. Således kan t.ex. inte ODA/ODIF ingå i General String.
(Text 774908)
(Text 774911) 88-02-08 19.26 Bo Thide Inst f rymdfysik Uppsala För kännedom: Standarder (inom) databehandlingsområdet <1498> Kommentar till: (Text 774588) av Olle Järnefors KTH <1> Ärende: 16-bitskod? Som du vet, finns det en X/open standardmed 16 bitar redan i dag. Även här är det så att man använder 16 bitar BARA OM DET behövs, annars inte. Såvitt jag uppfattat kommer denna standard att accepteras av POSIX och IEEE10002.
(Text 774911) (1 kommentar)
(Text 774914) 88-02-08 19.27 Bo Thide Inst f rymdfysik Uppsala För kännedom: Standarder (inom) databehandlingsområdet <1499> Kommentar till: (Text 774911) av Bo Thide Inst f rymdfysik Uppsala <1> Ärende: 16-bitskod? IEEE1002 skall det vara (eller 1003 - jag minns aldrig exakt, inte heller underkommittens nummer).
(Text 774914)
(Text 774983) 88-02-08 20.50 Peter Löthberg (roll@stacken.kth.se) Mottagare: Standarder (inom) databehandlingsområdet <1500> Kommentar till: (Text 774593) av Olle Järnefors KTH <1> Ärende: Varianter av teckenkoden ISO 8859 Hur är det i 97525/2 ?
(Text 774983)
(Text 775230) 88-02-09 06.24 -KPJ Jaakkola utom tjänsten Mottagare: Standarder (inom) databehandlingsområdet <1501> Mottagare: -KPJ Jaakkola utom tjänsten <3799> -- Mottaget: 88-02-09 06.24 Kommentar till: (Text 773233) av Tommy Ericson KOMunity <1> Markerad av någon. Årende: Absurda datatyper Ja, man kan skriva tabell-drivna program förstås... TITLE timex footab: BLOCK 7 ende: EXIT 1, timex: SETZB 3,4 mlupe: XCTÄEXP<CALLI 14>,<TRN>,<TRN>,<CALLI 23>,<TRN>,<TRN>,<TRN>,<JRST x>Å(3) IDIV ÄEXP ^D31,^D12,^D1,^D1000,^D60,^D60,^D100Å(3) ADD 1,ÄEXP <2,,1>,<2,,1>,<4,,^D1964>,<2,,0>,<2,,0>,<2,,0>,<2,,0>Å(3) MOVE 2,ÄEXP 2,1,0,6,5,4,3Å(3) MOVEM 1,footab(2) AOJA 3,mlupe x: MOVE 2,Ä-5,,7Å HLRZ 5,footab(4) HRRZ footab(4) nout1: IDIVI 12 PUSH 2,1 SOJG 5,nout1 nout2: POP 2, ADDI "0" TTCALL 1, CAME 2,@x JRST nout2 CAIN 4,6 JRST ende TTCALL 1,ÄEXP "-","-"," ",":",":",":"Å(4) AOJA 4,x END ende+1 .
(Text 775230) (1 kommentar)
(Text 775266) 88-02-09 07.51 Lars Hellberg Statskontoret Mottagare: Standarder (inom) databehandlingsområdet <1502> Kommentar till: (Text 774344) av Jacob Palme QZ <1> Ärende: Ny-uttänkta standarder kontra standard av känd teknik Så omständligt är det väl inte? En normal adress: Namn: Jacob Palme Adress: Stockholms Datorcentral, QZ Box 27322 Postadress:S-10254 STOCKHOLM Land: Sweden eller hur det nu formellt strukturellt ser ut är väl i varje fall inte mycket enklare? Säkert kommer man att snart ha möjlighet att t ex förutom SE ha alternativet Sweden o s v.
(Text 775266)
(Text 775314) 88-02-09 09.26 Lars-Henrik Eriksson Mottagare: Standarder (inom) databehandlingsområdet <1503> Mottagare: -KPJ Jaakkola utom tjänsten <3804> -- Mottaget: 88-02-11 07.58 Kommentar till: (Text 775230) av -KPJ Jaakkola utom tjänsten <1> Årende: Absurda datatyper Ja, nog är det absurt alltid. Dessutom skiljer sig utskriften med 24 är, 1 minut och 23 sekunder från något som ligger nära tillhands.
(Text 775314) (1 kommentar)
(Text 775542) 88-02-09 18.25 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1505> Kommentar till: (Text 774582) av Tommy Ericson KOMunity <1> Ärende: Standardiseringsexplosionen inom OSI ISO har ju länge använt denna princip när det gäller teckenstandarder. Det är bara det att de kloka människor som en gång i tiden uppfann X.400 inte ville följa denna gamla goda ISO-konvention, utan måste hitta på det där med olika body parts för varje teckenuppsättning istället.
(Text 775542) (2 kommentarer)
(Text 775548) 88-02-09 18.33 Jacob Palme QZ För kännedom: Standarder (inom) databehandlingsområdet <1506> Kommentar till: (Text 774901) av Bo Thide Inst f rymdfysik Uppsala <1> Ärende: Kritik mot tangentbordsstandarder Jag minns inte om jag prövat på en äkta VT100, men på den VT100- kopia jag använder (en COMEX 3385) går det bra. Och standarden säger då absolut ingenting om att redan utskrivna tecken på skärmen skall byta utseende för att man skickar ESCAPE-sekvenser som byter utseende på efter ESCAPE-sekvensen sända tecken. Men en del terminalleverantörer kanske gjort med standarden dåligt överenstämmande förenklingar?
(Text 775548)
(Text 770940) 88-02-01 05.50 Olle Järnefors KTH För kännedom: Jan Bjurström FMV <362> -- Mottaget: 88-02-02 23.03 För kännedom: Peder Swenman FFV Elektronik AB <565> -- Mottaget: 88-02-08 22.09 Kommentar till: (Text 767105) av Jacob Palme QZ <1> Mottagare: Standarder (inom) databehandlingsområdet <1507> Sändare: Jacob Palme QZ -- Sänt: 88-02-09 18.38 Ärende: För- och efternamn Vad säger standarderna om vad som egentligen skiljer "Given name" och "Surname" åt? Som jag ser det skulle en institution- aliserad uppdelning av personnamn i två delar kunna vara värde- full för att visa vilken del av namnet som är mest signifikant, vilket man bland annat behöver veta när personer ska sorteras in i ett register i bokstavsordning. I de flesta europeiska språk är efternamnet den mest signifikan- ta delen. I till exempel kinesiska är det dock den första delen av namnet som är släktnamn. Mao Tse-tung sorteras in under M i uppslagsböcker. I europeers namn kan det vara svårt att veta var efternamnet börjar, eftersom en del har flera förnamn, andra flera efternamn. Per Brinch Hansens böcker får man söka under både B och H i bibliografier. Uppdelningen i "Given name" och "Surname" borde alltså behållas, om de definierades så här: * Given name = den del av ett personnamn som ska ha lägre prioritet än den följande delen vid sortering. (Kan vara tomt. Måste vara en äkta del av personnamnet.) * Surname = det som återstår av ett personnamn när Given name har tagits bort. (Kan inte var tomt, men kan vara identiskt med hela namnet.) Om Given name och Surname åtskiljs med en punkt skulle i så fall detta vara exempel på korrekta personnamn i datagramadresser: Jacob.Palme Hubert.de Besche Hans von.Hofsten Per.Brinch Hansen Carl Gustaf (eller kanske: H M.Konungen) Deng Xiao-ping
(Text 770940) (2 kommentarer)
(Text 772168) 88-02-03 00.25 -KPJ Jaakkola utom tjänsten För kännedom: Jan Bjurström FMV <367> -- Mottaget: 88-02-08 11.50 För kännedom: Peder Swenman FFV Elektronik AB <568> -- Mottaget: 88-02-08 22.10 Kommentar till: (Text 770940) av Olle Järnefors KTH <1> Mottagare: Standarder (inom) databehandlingsområdet <1508> Sändare: Jacob Palme QZ -- Sänt: 88-02-09 18.38 Ärende: För- och efternamn Hur långa namn får man ha numera? Är det bra att datorknuttar tillåts bestämma hur man ska skriva namn; t.ex har vi ju det amriska sättet att ha mellaninitial, och det finns som _tvingats_ skaffa sin en mellan-initial för att korkade program annars blev upprörda på deras namn, och t.ex fått för sig att efternamnet var initialordet. Varför inte lika gärna gå det ultimata sättet och tilldela varje land ett nummer, varje region ett nummer, och sedan numrera folk med heltal? Tänk vilken underbar kontroll man skulle ha över sina register.
(Text 772168)
(Text 775638) 88-02-09 21.05 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1509> För kännedom: Fikonspråk - översättning från datorslang till svenska <2557> Kommentar till: (Text 772702) av Michael Evans STOCC <1> Markerad av någon. Ärende: Tangentbeskrivning för portabla program Några förtydliganden: De tangentnamn som står i vänstra kolum- nen före rubriken "Andra specialtangenter" är mina förslag till standard för namn på vanliga tangenter. De flesta hoppas jag är självförklarande. Förklaring av vissa namn: * Fritangent är mitt förslag till svenskt namn på den så kallade iskejptangenten (märkt: ESC). * Backtangent, radertangent och borttagningstangent har alla funktionen att radera data. Följande skiljer dem åt: BACK- TANGENTEN sitter i övre högra hörnet av tangentbordets alfa- numeriska del. RADERTANGENTEN finns i närheten av tangent- bordets numeriska del. BORTTAGNINGSTANGENTEN finns i när- heten av markörflyttningstangenterna. * Returtangenten och inmatningstangenten har i huvudsak två funktioner: (a) att flytta aktuell position till början på nästa rad; (b) att indikera att senast inskrivna data är klara att tas om hand av datorn. RETURTANGENTEN återfinns längst till höger bland de alfanumeriska tangenterna. INMAT- NINGSTANGENTEN ligger i närheten av den numeriska delen av tangentbordet. * UTFÖRTANGENTEN har den funktion (b) som jag angett för retur- och inmatningstangenterna. Den finns i närheten av markörflyttningstangenterna.
(Text 775638)
(Text 775639) 88-02-09 21.06 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1510> För kännedom: Fikonspråk - översättning från datorslang till svenska <2558> Kommentar till: (Text 772702) av Michael Evans STOCC <2> Ärende: Tangentbeskrivning för portabla program Några frågor angående 3270-tangentbordet: 1) Finns alla de tangenter du tar upp på äldre modeller än 3191? 2) Stämmer dina tilldelningar med de preciseringar av begreppen backtangent, radertangent, borttagningstangent, returtangent och inmatningstangent som jag har gjort i mitt förra inlägg? (Jag antar att Radmataren på en blocksändande terminal bara flyttar en mellan fält, inte skickar något till värddatorn, så att (RETUR) bara har funktion (a) enligt mitt förra inlägg.) 3) Har en 3270-terminal verkligen bara en skifttangent? 4) Finns det ingen motsvarighet till CTRL-tangenten (som alltså ger vanliga bokstavstangenter kommandofunktion) eller måste all programstyrning utföras med funktionstangenter? 5) Att det inte finns någon frystangent (som stoppar vidare utmatning från värddatorn tills man är beredd att se mer) är ju naturligt på en terminal som arbetar skärmvis. 6) Till vad används signaltangenten? 7) Till vad används rensningstangenten? Rensar den hela skär- men? 8) Vad skiljer i användning de två PA-tangenterna från PF- tangenterna? 9) Har SysRq-tangenten på IBM AT något samband med Systembegä- ran? Vad används den till på 3270-terminaler? Åtminstone två av de andra specialtangenter du tar upp borde nog tas med i min sammanställning av "vanliga tangenter": Kopieringstangent (KOPIA) Dup, Duplicera Märktangent (MÄRK) Mark, Field Mark, Markera
(Text 775639)
(Text 775714) 88-02-09 22.49 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1511> Kommentar till: (Text 775542) av Jacob Palme QZ <1> Ärende: Standardiseringsexplosionen inom OSI Jag är lite fundersam över det förslag som kom fram i Paris. jag trodde att finnesen med bodyparts var att man kunde avvisa meddelande som man inte kan ta emot, t ex om någon skickar mig en fax bodypart så vore det ju bra om min mta sa ifrån att det kan han inte ta emot.
(Text 775714) (2 kommentarer)
(Text 775723) 88-02-09 22.52 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1512> Kommentar till: (Text 775714) av Johan Lundberg TeleDelta <1> Ärende: Standardiseringsexplosionen inom OSI samma torde ju gälla för "general String" förslaget. Om min dator inte kan begripa/återge kanji så är det väl ingen mening med att ta emot det?
(Text 775723) (1 kommentar)
(Text 775775) 88-02-09 23.48 Jörgen Stiernborg CODE AB Mottagare: Standarder (inom) databehandlingsområdet <1513> För kännedom: Fikonspråk - översättning från datorslang till svenska <2561> Kommentar till: (Text 772702) av Michael Evans STOCC <3> Ärende: Tangentbeskrivning för portabla program Det var ett helsickes långt inlägg. Kan vi enas om principen varningsinlägg innan något på mer än 15 rader?
(Text 775775) (2 kommentarer)
(Text 775793) 88-02-10 00.34 Matts Kallioniemi Mottagare: Standarder (inom) databehandlingsområdet <1514> För kännedom: Fikonspråk - översättning från datorslang till svenska <2563> Kommentar till: (Text 775775) av Jörgen Stiernborg CODE AB <1> Ärende: Tangentbeskrivning för portabla program Antalet rader står först i inlägget!
(Text 775793) (1 kommentar)
(Text 776031) 88-02-10 15.05 Mottagare: Standarder (inom) databehandlingsområdet <1515> Kommentar till: (Text 775542) av Jacob Palme QZ <2> Ärende: Standardiseringsexplosionen inom OSI Den internationella trenden vad gäller telebolag i västvärlden verkar att vara mot avmonopolisering av alltfler tjänster och även privatisering av delar eller hela verksamheter. Om denna trend fortsätter så lär väl diverse telebolag och CCITT förlora den "lagstiftade piska" som de hittills till delarr använt för att driva igenom standards påbudsvägen. Iofs kommer väl CCITT genom storleken på de ingående medlemmarna att ha kvar inflytande, men frågan är om inte förslag från ISO och andra organ kommer att få relativt CCITT större betydelse framöver, så det kan kanske vara ide' att hålla fast vid och driva rationella förslag även om inte CCITT skulle inse fördelarna. Har länge haft svårt att inse vad televerken och deras folk har att göra ända upp i OSI-modellens applikationsskikt, annat än som - om än stora - "vanliga" användare av datorer. Tror inte det blir ordning i standardiseringsdjungeln och standards- arbetet rationellt förrän ett organs ord blir "lag", och detta organs sammansättning och dess medlemmars inflytande återspeglande den relativa styrkan mellan de bakomliggande organisationerna. Med styrka menar jag då inte av monopol och lagstiftning skyddade möjligheter att driva igenom saker påbudsvägen, utan marknadsstyrka vad gäller antal användare och tillverkare.
(Text 776031) (2 kommentarer)
(Text 776106) 88-02-10 18.42 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1516> Kommentar till: (Text 775714) av Johan Lundberg TeleDelta <2> Ärende: Standardiseringsexplosionen inom OSI Jag tror, om jag fattade Paris-beslutet rätt, att man skall lägga in object identifier för de teckenkoder man använder i Encoded Information Types-fältet i P1-kuvertet. Den informationen kan då användas för att avgöra om en viss mottagare kan förstå ett visst meddelande eller inte.
(Text 776106)
(Text 776107) 88-02-10 18.46 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1517> Kommentar till: (Text 776031) av <1> Ärende: Standardiseringsexplosionen inom OSI CCITT kan väl ses som en förening av tjänsteleverantörer, som utformar en standard för den tjänst de i samarbete erbjuder sina kunder. Ser man det på det sättet, borde ju CCITT fungera som en underleverantör till ISO, på samma sätt som t.ex. ECMA (= datorleverantörernas standardiseringsorganisation). I praktiken har dock CCITT varit så tung, att ISO istället fått tjäna som underleverantör till ISO. Att CCITT blivit så betydande beror ju på att den service tele- verken tillhandahåller är så viktig. Bidragande är också att CCITT har en process för utarbetande av standarder, som gör att man blir klar fortare med en standard (men sedan ändrar i den vart fjärde år). ISO vill göra något grundligt, och sedan slippa ändra i det så ofta. Detta gör att CCITT-rekommendationerna ofta kommit före ISO- standarderna, och det som kom först har sedan fått gälla.
(Text 776107) (1 kommentar)
(Text 776232) 88-02-10 21.25 Mottagare: Standarder (inom) databehandlingsområdet <1518> Kommentar till: (Text 776107) av Jacob Palme QZ <1> Ärende: Standardiseringsexplosionen inom OSI Ja, men med X.400 och annat så har ju CCITT gett sig in på områden där televerken inte alls tillhandahåller ngn service. Det är som om vägverket skulle ge sig in och standardiserahur innanmätet i bilar ska se ut. Överkapacitet i standardiseringsorgan finns det lämpligare metoder att komma tillrätta med.
(Text 776232) (1 kommentar)
(Text 776286) 88-02-10 22.22 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1519> Kommentar till: (Text 776031) av <2> Ärende: Standardiseringsexplosionen inom OSI Jag gissar att det omvända gäller också? Dvs ISO inte har något att göra i de lägre skikten av OSI modellen. Jag fårstår att det bland datorleverantörer uppfattas som ett hot att ccitt är med och bökar i den akademiska ankdammen som ISO i många fall utgör. Jag skulle vilja påstå att utan ccitt så hade du förmodligen inga osi skikt överhuvudtaget. Då skulle big blue ostört kunna dominera marknaden.
(Text 776286) (2 kommentarer)
(Text 776293) 88-02-10 22.32 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1520> Kommentar till: (Text 776232) av <1> Ärende: Standardiseringsexplosionen inom OSI De televerk som varit inblandade is utvecklingen av X.400 har definitivt ambitionen att tillhandahålla tjänster. Om man resonerade som du hade vi inte haft några andra publika teletjänster utöver röksignaler
(Text 776293)
(Text 776504) 88-02-11 11.46 Mottagare: Standarder (inom) databehandlingsområdet <1521> Kommentar till: (Text 776286) av Johan Lundberg TeleDelta <1> Ärende: Standardiseringsexplosionen inom OSI Jo, men allmänt tror jag det är bättre att standards tas fram av organisationer med praktisk erfarenhet på området ifråga, som svar på ett insett behov av en ny standard. Inte att mer eller mindre nya aktörer klampar in från det teoretiska hållet och lagstiftningsvägen påbjuder hur det skall vara. Den akademiska världen må ha sina speciella egenheter men talar man om ankdammar så tror jag man inte behöver gå utanför monopol- företagens skyddade värld för hitta horribla exempel. Vad gäller X.400 så kan man ju bara titta på det faktum att CCITT lyckats med det intelligenta att göra 88 års version inkompatibel med 84 års så att det kommer att krävas gateways mellan system följande de olika versionerna. I den akademiska världen, liksom bland företag som överlever av egen kraft, är kompatibilitet med tidigare versioner ett måste. Annars fungerar inte saker och ting i den akademiska världen, och inget företag har råd att släppa sitt ansvar för tidigare versioner. Dylika praktiska och marknadsmässiga hänsyn behöver uppenbarligen inte CCITT ta. Likaså vet jag inte om ett fungerande världsomspännande nät i den i den akademiska världen där man kan nå 10 000-tals användare på mer en 10 000 maskiner i alla världsdelar kan betecknas som en ankdam. Då är det nog intressantare att notera det faktum att televerken, som alltså anser sig kompetenta att specificera standards för elektronic post, får betraktas som mer eller mindre isolerade öar vad gäller elektronisk post förbindelser om de nu över huvud taget har några dylika alls. Men per vanlig telefon kan man ju nå deras anställda (även om det kan råda delade meningar om nyttan av detta hos luttrade datapak- felrapportörer), så ledningsdragning och dylikt med standards för inkoppling av utrustning på nätet är kanske en lämpligare nivå för CCITT.
(Text 776504) (1 kommentar)
(Text 776523) 88-02-11 12.41 Peter Svanberg NADA Mottagare: Macintosh erfarenhetsutbyte <3126> För kännedom: Standarder (inom) databehandlingsområdet <1522> Kommentar till: (Text 770943) av Olle Järnefors KTH <2> Ärende: Tangentbord med fyra nivåer "Additional shift key" har föreslagits heta "högerskift" på svenska, syftande på att det är dom tecken som står på den högra halvan av tangenten man då använder (på tangenter som har alla fyra tecknen angivna).
(Text 776523) (1 kommentar)
(Text 776527) 88-02-11 12.53 Peter Svanberg NADA Mottagare: Macintosh erfarenhetsutbyte <3127> Mottagare: Lars-Åke Larsson Dapugruppen <2610> -- Mottaget: 88-02-12 22.29 För kännedom: Standarder (inom) databehandlingsområdet <1523> Kommentar till: (Text 773775) av Lars-Åke Larsson Dapugruppen <1> Ärende: Ingen tangent mellan Z och vänster skift! OBS OBS OBS: Misstaget att i den svenska standarden lägga en tangent mellan Z och vänster skift är förmodligen snart ett minne blott. Det har t o m skickats ut en varning från SIS om att det mesta talar för att den tangenten kommer att flyttas (det är föreslaget i ISO).
(Text 776527)
(Text 776734) 88-02-11 21.33 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1524> Kommentar till: (Text 776504) av <1> Ärende: Standardiseringsexplosionen inom OSI skall jag tolka ditt inlägg så att du anser att x.400 egentligen inte behövs? Att det redan fanns en världsomspännande standard för email? Att du anser att de som arbetat med x.400 är inkompetenta och oerfarna? Att den akademiska emailen ger en säker tjänst helt i klass med andra telekommunikationslösningar typ telefon? Både du och jag vet att det inte är sant så jag fårstår faktiskt inte din negativa inställning till CCITT.
(Text 776734) (1 kommentar)
(Text 776810) 88-02-11 23.54 Mottagare: Standarder (inom) databehandlingsområdet <1525> Kommentar till: (Text 776734) av Johan Lundberg TeleDelta <1> Ärende: Standardiseringsexplosionen inom OSI Mina inlägga ska tolkas som förslag till dem i adekvata positioner att arbeta för principen att standarder för (bl.a.) elektronisk post skall tas fram främst av sådana organisationer vars sammansättning är sådan jag nyligen beskrivit. Att komma ifrån inställningen att CCITTS ord är lag. Att inte släppa bra förslag för att man inte får igenom dem i CCITT. Att dagens de facto standarder behöver utökas eller behöver uppföljare är helt klart, vi lever i en dynamisk värld. Därmed inte sagt att CCITT är det lämpligaste organet för att ta fram dessa. Att göra 88 års X.400 inkompatibel med 84 års anser jag som klart inkompetent och oerfaret. Att telekommunikationslösningar typ telefon fungerar är en förutsättning för att elektronisk post i den akademiska världen fungerar så bra som det trots allt gör. Därmed inte sagt att mina personliga telefonsamtal blir "effektivare" för att jag får en mall att följa av den som säljer förbindelsen till mig.
(Text 776810) (2 kommentarer)
(Text 777268) 88-02-13 14.16 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1526> Kommentar till: (Text 776810) av <1> Ärende: Standardiseringsexplosionen inom OSI Vad menar du med "att göra 88 års X.400 inkompatibelt med 84". Menar du att när man väl en gång gjort en standard, 84 års, skall man aldrig få införa något nytt av något slag i den? I själva verket har ju CCITT ansträngt sig väldigt mycket för att göra 88 års version bakåtkompatibel med 84 års version. En intressant sak att diskutera är problemen med bakåtkompatibilitet för distributionslistor. Där har man valt (mot min vilja) en teknisk lösning som innebär att användare av 84-system ej kan delta i distributionslistor. Ett starkt skäl för att man valt denna tekniska lösning är att man velat ha en enkel funktion hos en brygga från 88 till 84, i princip att bryggan bara tar bort allt den inte begriper. Således: Just får att få enkel bakåt- kompatibilitet hindrar man 84-brevlådor att vara med i distributions- listor.
(Text 777268) (2 kommentarer)
(Text 777314) 88-02-13 18.39 Lars Sjöström LIDAC Mottagare: Standarder (inom) databehandlingsområdet <1527> För kännedom: Fikonspråk - översättning från datorslang till svenska <2575> Kommentar till: (Text 775793) av Matts Kallioniemi <1> Ärende: Tangentbeskrivning för portabla program (. Det första man blir blind på är blindtarmen.)
(Text 777314)
(Text 777498) 88-02-14 16.26 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1528> Kommentar till: (Text 777268) av Jacob Palme QZ <1> Ärende: Standardiseringsexplosionen inom OSI Ja strävan har varit att få en så enkel brygga som möjligt men det är inget som hindrar att man gör den mer kapabel och därmed möjliggör för 84 system att vara med i större utsträckning på DL.
(Text 777498)
(Text 777890) 88-02-15 13.28 Mottagare: Standarder (inom) databehandlingsområdet <1529> Kommentar till: (Text 777268) av Jacob Palme QZ <2> Ärende: Standardiseringsexplosionen inom OSI Givetvis menar jag inte "att när man väl gjort en standard, 84 års, skall man aldrig få införa något nytt av något slag i den". Men det ska inte behövas speciella bryggor mellan olika versioner av en standard. I vissa skeden i den tekniska utvecklingen införs nya koncept och man går ifrån äldre standarder, ngt helt nytt har börjat. Men efter att ha börjat med detta nya så följer man denna nya väg och, speciellt vad gäller en enda standard, gör bara smärre ändringar och utvidgningar i efterföljande versioner. Man får då kontinuiteten och stabiliteten som är hela vitsen med standarder. CCITT har nu alltså tagit fram en "standard" och innan fler än några få implementeringar nått marknaden och olika organisationer brottas med att tolka denna för att ta fram funktionella standards och verifieringsrutiner, ja då är det alltså dags för en ny version från CCITT av "standarden" där man om man ska implementera denna och inte vill släppa tidigare implementeringar dessutom måste implementera en brygga till tidigare versioner. Smart! Vad händer sen med 92 års "standard". Har CCITT till dess kommit på ngt listigt som de inte tänkte på 88, men vars upptagande i "standarden" kräver bryggor till 88 års implementeringar. Jämför t.ex. med att Ethernet-protokollet skulle ändras vart fjärde år, och varje ny version krävde bryggor till system med utrustning som följde den äldre "standarden". Nej, CCITT har nog tagit sig några OSI-protokoll för mycket över huvudet.
(Text 777890) (2 kommentarer)
(Text 778021) 88-02-15 19.28 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1530> Kommentar till: (Text 777890) av <1> Ärende: Standardiseringsexplosionen inom OSI Vad CCITT borde ha gjort, vore att redan i 84 års version lägga in hakar, på vilka framtida tillägg kunde läggas in på ett kompatibelt sätt. Det gjorde man tyvärr inte. I 88 års version har man, på förslag från ISO, lagt in sådana hakar. Vissa CCITT-administratörer tolkar dock 88 års standard på ett sådant sätt att dessa hakar inte kommer att fungera. Trist! Nu har man gjort 88 års version så, att den som har implementerat 84 års version på ett klokt sätt (så att man antingen slänger bort, eller bara ignorerar och vidarebefordrar transparent, alla protokollelement man inte känner igen) kommer att kunna ta emot 88 års saker i 84 års version utan problem. Tyvärr är det många som implementerat 84 års version enligt principen: Allt skall vara strikt enligt standarden och allt som avviker det minsta vägrar mitt system befatta mig med. De som gjort så kan inte hantera 88 utan en brygga. Bryggan blir dock, om man inte kräver mer än 84-funktionalitet, enkel. Vill man försöka få över lite av 88-funktionalitet, t.ex. distributionslistor, även i 84-världen, blir däremot en sådan brygga mycket komplicerad, bl.a. därför att CCITT inte säger hur man skall göra. CCITT-s metod är att man skall göra en ny version av sina standarder vart fjärde år. Och att standarderna skall pressas fram under tidspress för att passa in i CCITT-s 4-åriga planperioder. ISO följer principen att genomarbeta en standard nogrannare, ta mer tid på sig, men sedan inte ändra så mycket i standarden när den är klar.
(Text 778021) (1 kommentar)
(Text 780629) 88-02-21 21.57 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1531> Kommentar till: (Text 777890) av <2> Ärende: Standardiseringsexplosionen inom OSI Vad skönt att läsa sådana visdomsord från en som *aktivt* deltar i ISOs motsvarande arbete. Vad skönt det vore om du hade jobbat inom ISO och bromsat alla förslag om nya ideer mm. Då kanske vi inte hade behövt en ny version. Men vi hade fått leva utan en rad av de faciliteter som du så varmt talar för i andra sammanhang.
(Text 780629) (1 kommentar)
(Text 780630) 88-02-21 22.02 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1532> Kommentar till: (Text 778021) av Jacob Palme QZ <1> Ärende: Standardiseringsexplosionen inom OSI Vilken arbetsprincip som är att föredra är något man kan diskutera i all oändlighet. Om man tar så god tid på sig att tåget gått och ingen av den anledningen längre är intresserad så kan man ju lägga av direkt. Men även CCITTs tidspress är givetvis en nackdel i vissa fall.
(Text 780630)
(Text 780735) 88-02-22 11.42 Mottagare: Standarder (inom) databehandlingsområdet <1533> Kommentar till: (Text 780629) av Johan Lundberg TeleDelta <1> Ärende: Standardiseringsexplosionen inom OSI Trött man blir!
(Text 780735) (1 kommentar)
(Text 780964) 88-02-22 20.40 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1534> Kommentar till: (Text 780735) av <1> Ärende: Standardiseringsexplosionen inom OSI Ja just det. Trött!
(Text 780964) (1 kommentar)
(Text 781992) 88-02-25 04.49 Tommy Ericson KOMunity Mottagare: Standarder (inom) databehandlingsområdet <1535> Kommentar till: (Text 775723) av Johan Lundberg TeleDelta <1> Ärende: Standardiseringsexplosionen inom OSI Visst, men med ökande komplexitet och nya (nytillkommande) datatyper är det inte helt lyckat att förlita sig på att man kommit ihåg att säga åt sin postmästare vilka sorter man vill läsa, jag föredrar definitivt att kunna fatta ett sådant avgörande från fall till fall.
(Text 781992)
(Text 781994) 88-02-25 04.56 Tommy Ericson KOMunity Mottagare: Standarder (inom) databehandlingsområdet <1536> Kommentar till: (Text 776286) av Johan Lundberg TeleDelta <2> Ärende: Standardiseringsexplosionen inom OSI Menar du att "akademiska ankdammen" = "Big Blue" och de andra leverantörerna samt SIS, AFNOR, NBS, osv ? CCITT har gjort ett bra jobb tillsammans med ISO i att driva på OSI. Men - det kan du knappast förneka - det förekommer att experter på de lägre skikten "hänger med" i std-arbetet till nivåer där deras kompetens inte är den mest relevanta.
(Text 781994) (1 kommentar)
(Text 781995) 88-02-25 05.20 Tommy Ericson KOMunity Mottagare: Standarder (inom) databehandlingsområdet <1537> Kommentar till: (Text 776810) av <2> Ärende: Standardiseringsexplosionen inom OSI Förklaringen är inte så enkel som att beskylla några för att göra "inkompetent och oerfaret" jobb, världen är komplexare: 1) CCITTs arbetsform med helt spikade "studieperioder" där det *krävs* ett resultat efter 4 år - om än urdåligt! - tvingar dem som deltar att, då klockan är fem i tolv, kompromissa och acceptera ofullständiga lösningar ("This feature is For Further Study" ser man alltför ofta!). Den som är "Special Rapporteur" skulle knappast få någon fjäder i hatten av att komma tillbaks efter 4 års arbete och säga att "det blev ingenting, vi behöver mer tid". ISOs arbetsformer är i detta avseende bättre. Både ISO och CCITT har för dålig kommunikation mellan mötena. 2) Taktiska/strategiska hänsyn till egna pågående/planerade implementeringar medför att man inte alltid väljer den bästa tekniska lösningen plus en massa annat som ni säkert kan räkna ut själva. En lösning på detta vore att dela upp jobbet så att en grupp fick sätta upp funktionskrav och en annan göra den tekniska utformningen. (IFIP 6.5 brukar göra så.) Slutligen så vet väl alla att CCCITTs ord inte är lag för annat än trafik mellan "Administrations*" - hemma på kammarn får man göra vad man vill. Och X.400 P1+P2 kan man lägga över annat än X.25 om man så önskar. PS Det kan noteras att flera av namnen från RFC-dokument återfinns (eller har återfunnits) i CCITTs SG VII, dom försökte helt säkert göra något bättre än RFC821/82/osv - men 1983 tog slut ...
(Text 781995) (2 kommentarer)
(Text 782032) 88-02-25 09.58 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1538> Kommentar till: (Text 781994) av Tommy Ericson KOMunity <1> Ärende: Standardiseringsexplosionen inom OSI Jodå det instämmer jag helt i. Men det omvända gäller alltför ofta också.
(Text 782032)
(Text 782086) 88-02-25 12.58 Anne-Marie Eklund Statskontoret Mottagare: Standarder (inom) databehandlingsområdet <1539> För kännedom: Jan Bjurström FMV <406> -- Mottaget: 88-03-03 08.55 Sändare: Jan Flodin FMV -- Sänt: 88-02-26 08.03 Ärende: Efterlysning av material! Finns det någon som kan hjälpa mig att komma över skriftligt material om följande organisationer: ECITC - European Committee for IT Certification ICCP - Committee for Information, Computer and Communications Policy ECTEL - European Committee of Telecommunications and Electronic Industries INTUG - ? ITUSA - GAP - Jag vill veta vad de gör, hur de är sammansatta och med vilka de samarbetar, främst vad gäller OSI-standardisering. Material mottas tacksamt på adressen: Anne-Marie Eklund, Statskontoret, R4, Box 45167, 100 26 Sthlm.
(Text 782086) (3 kommentarer)
(Text 782106) 88-02-25 13.39 Mottagare: Standarder (inom) databehandlingsområdet <1540> Kommentar till: (Text 781995) av Tommy Ericson KOMunity <1> Ärende: Standardiseringsexplosionen inom OSI "Bortsett från att det inte fungerar, vad tycker ni..", men framtiden får väl utvisa från vilket håll de-facto standardena kommer.
(Text 782106) (1 kommentar)
(Text 782227) 88-02-25 19.36 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1541> Kommentar till: (Text 781995) av Tommy Ericson KOMunity <2> Ärende: Standardiseringsexplosionen inom OSI ISO-s arbete med textkommunikation-standarder är uppdelat på det sätt du föreslår, med en arbetsgrupp, ISO/IEC/JTC1/SC18/WG1 som skall utforma användarkrav, och en serie andra grupper som gör standarderna. Erfarenhet av denna arbetsform: Synpunkterna från WG1 är ibland ganska tomma och innehållslösa. Övriga grupper lyssnar sällan särskilt mycket på vad WG1 har att säga. Överhuvudtaget är det sällan, både i ISO och CCITT-sammanhang, som jag hör någon säga något om användarkrav eller försök att utforma standarderna för att passa de människor som skall använda dem. Ibland har jag försökt ta upp sådana saker, men då blir jag snabbt tystad med slagordet "Vi standardiserar dator-dator-protokoll, inte användar- interface".
(Text 782227) (3 kommentarer)
(Text 782320) 88-02-25 21.58 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1542> Kommentar till: (Text 782106) av <1> Ärende: Standardiseringsexplosionen inom OSI Staffan, Vad är det du förespråkar egentligen? Jag får svårare och svårare att följa dina inlägg. Vi skall inte ha någon standard. Låt marknadskrafterna styra. Är det en korrekt tolkning?
(Text 782320) (1 kommentar)
(Text 782322) 88-02-25 22.03 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1543> Kommentar till: (Text 782227) av Jacob Palme QZ <1> Ärende: Standardiseringsexplosionen inom OSI CCITT har ett liknande upplägg med sin Studiegrupp I. Det är lite mer formaliserat. De ger nämligen ut rekommendationer för hur tjänsten skall utformas. I princip så skall också de andra studiegrupperna agera som utförande grupper av SG I vilja. I praktiken är det tyvärr ofta tvärtom. Men vad beträffar MHS w3xDså tror jag att dom lyckats hyfsat men jag har inte hunnit detaljgranska vad dom skivit. (ledsen för skräpet, det beror förmodligen på att vi har en av stockholms äldsta telefon växlar här på kungsholmen) Johan
(Text 782322) (1 kommentar)
(Text 782489) 88-02-26 09.15 Mottagare: Standarder (inom) databehandlingsområdet <1544> Kommentar till: (Text 782320) av Johan Lundberg TeleDelta <1> Ärende: Standardiseringsexplosionen inom OSI Ok, sorry, upphör med sidosticken. Att standarder inte behövs har jag aldrig hävdat, däremot att det inte är en helt optimal situation som råder för närvarande inom standardiseringsområdet vad gäller elektronisk post. Tolka istället inläggen som komna ur en viss irritation över sakernas tillstånd. Dock får man väl ha en viss tilltro till framtiden; Marknadskrafter är ju inte det sämsta vad gäller att driva fram det användare vill ha.
(Text 782489) (1 kommentar)
(Text 782558) 88-02-26 13.54 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1545> Kommentar till: (Text 782489) av <1> Ärende: Standardiseringsexplosionen inom OSI Jag vet inte om marknadskrafterna inom datorområdet ger vad användarna vill ha. Är det inte så att det är vad ... vill ha.
(Text 782558)
(Text 782777) 88-02-27 02.38 Tommy Ericson KOMunity Mottagare: Standarder (inom) databehandlingsområdet <1546> Kommentar till: (Text 782227) av Jacob Palme QZ <2> Kommentar till: (Text 782322) av Johan Lundberg TeleDelta <1> Ärende: Standardiseringsexplosionen inom OSI Det är inte nödvändigt att grupperna är DISJUNKTA vad beträffar personer, däremot att man sysslar med en sak i taget!
(Text 782777)
(Text 782778) 88-02-27 02.44 Tommy Ericson KOMunity Mottagare: Standarder (inom) databehandlingsområdet <1547> Kommentar till: (Text 782227) av Jacob Palme QZ <3> Ärende: Standardiseringsexplosionen inom OSI Har du tagit upp dessa saker i WG1 då?
(Text 782778) (1 kommentar)
(Text 782904) 88-02-27 14.08 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1548> Kommentar till: (Text 782778) av Tommy Ericson KOMunity <1> Ärende: Standardiseringsexplosionen inom OSI Nej, du har rätt, formellt borde jag ta upp saker i den gruppen. Problemet är att jag inte har tid och råd att åka till så många olika sådana här grupper. Det är sällan mer än 1-2 personer gemensamma mellan WG1 och WG4, det är väl en orsak till bristande kommunikation. Någon gång, när vi haft gott om tid, har jag föreslagit att vi skall skriva och ställa frågor till WG1. På senaste WG4-mötet fick jag igenom följande text i ett brev från WG4 till WG1: *Title*: Business document interchange ISO JTC 1/SC 18/WG 4 is responsible for MOTIS and for ensuring maximum alignment between MOTIS and the CCITT X.400 recommendation. Since CCITT will, in the next study period (1989- 1992) study "Business Document Interchange" within X.400, liaison betwen ISO and CCITT may be necessary in this area. ISO JTC 1/SC 18/WG 4 asks the following questions to ISO JTC 1/SC 18/WG 1: (1) Is cooperation with CCITT desirable in order to achieve alignment between CCITT X.400 recommendations and MOTIS in the handling of business document interchange. (2) Assuming that the reply to question (1) is yes, how is this cooperation to be handled, and what are the roles of ISO JTC 1/SC 18/WG 3 (The ODA/ODIF group), ISO TC 154/SC 3/WG 3 (the EDI group) and ISO JTC 1/SC 18/WG 4 (The MOTIS group) in this cooperation. (3) Is it desirable, that one and the same MOTIS message can contain both parts, which are Business Documents, and other parts, which are ordinary MOTIS messages? (4) Is it desirable, that a reply to a MOTIS message, which contains a Business Document, can be an ordinary MOTIS message? The replies to these questions should be forwarded also to ISO JTC 1/SC 18/WG 3 and ISO TC 154/SC 3/WG 3.
(Text 782904) (2 kommentarer)
(Text 783237) 88-02-28 16.51 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1549> Extra kopia: Wolf Arfvidson Statskontoret <453> -- Mottaget: 88-03-02 17.29 Ärende: Översättning mellan 7-bits kod och diverse standarder Statskontoret har sänt mig ett förslag till en ny teknisk norm som de avser ge ut som anger hur man skall översätta från 7-bits kod (alltså "SIS 63-61-27-3, Svensk teckenkod med 7 bitar för skrivning av egennamn i officiella sammanhang" till EBCDIC, IBM PC, ISO 8859/1, Videotex och Teletex. Sista tidpunkt för att framföra synpunkter på normen är 14 mars, kopior av förslaget kan man få från Statskontorets rationaliseringsenhet 4, telefon 738 40 00. Handläggare på Statskontoret är Wolf Arvidsson. Det är viktigt att någon kollar detta normförslag ordentligt. Statskontoret har ju tidigare ställt till med stor förvirring genom sin rekommendation att man inte skall följa SIS 63-61-27 (utan använda standarden för egennamn i officiella sammanhang för all text), och då Statskontorets normer har så stort inflytande i Sverige borde deras förslag granskas noga. Jag har två allmänna synpunkter på den här typen av standarder för översättning mellan två teckenkoder: (a) Om man översätter från en kod till en annan, och tillbaka igen, skall man så långt möjligt få tillbaka samma text man började med. Detta innebär alltså att översättningarna bör vara en-till-en, olika koder i ett alfabet bör ej översättas till samma kod i ett annat alfabet eller omvänt. Ibland går ju inte detta, t.ex. vid översättning från ett rikare till ett fattigare alfabet, men då bör i alla fall översättningen vara entydig i ena riktningen, en text i det fattigare alfabet bör efter översättning till det rikare och tillbaka igen vara oförändrad. (b) Man bör klart ange att denna tabell bara gäller texter på svenska. Inom universitetsvärlden får vi ju en hel del texter som ursprungligen producerats som någon ASCII-variant, därefter transporterats via ett EBCDIC-baserat nät (BITNET/EARN) och sedan levereras till slutmottagaren i form av ASCII igen. Det är då väsentligt att man skall få tillbaka samma ASCII-kod som ursprung- ligen sändes, trots transporten via EBCDIC-land. Eftersom de allra flesta ASCII<->EBCDIC-översättare använder den amerikanska översättningstabellen, så har vi inom universitetsvärlden i Sverige i allmänhet valt att använda denna tabell även inom Sverige. Det görs alltså vanligen av t.ex. JNET, UCAR och överföring av inlägg mellan KOM/COM och EARN följer också samma översättningstabell. Fördelen med denna tabell är alltså att man får tillbaka original- texten oförstörd. Men nackdelen är att ÅÄÖ i svenskspråkig text ej översätts från ÅÄÖ i SIS 63 61 27 till ÅÄÖ i EBCDIC och omvänt. Jag har inte kollat Statskontorets norm, men antar att den föreslår en översättning så att svensk text med ÅÄÖ blir läslig i både SIS 63 61 27 och EBCDIC. Och gör man det, förlorar man möjligheten att t.ex. transportera C-program i kompilerbart skick via näten! Finns det något vi inom universitetsvärlden kan/skall göra angående detta?
(Text 783237) (1 kommentar)
(Text 784350) 88-03-02 12.01 Lennart Nordström Mottagare: Standarder (inom) databehandlingsområdet <1550> Kommentar till: (Text 782904) av Jacob Palme QZ <2> Ärende: Standardiseringsexplosionen inom OSI Jag tycker att det var bra att Du ställde frågorna till Sc 21/Wg 1, men förmedla dem gärna även till Gösta Lindberg LME. Han är ordförande i SIS-ITS och har åtagit sig vara aktiv i ISO/IEC JTC 1, Adv. Comm. som träffas första gången i Wash. DC 20-21 april 1988. POLICYPROBLEM skall tas upp i ADV Comm och det är bra om vi får kännedom om sådana. - Själv skall jag försöka göra nytta i ISO/IEC JTC 1, Spec. WG on Strategic Planning. Mata gärna även mig med önskemål och problem. Hälsningar. LNm..
(Text 784350)
(Text 784393) 88-03-02 17.37 Wolf Arfvidson Statskontoret Mottagare: Standarder (inom) databehandlingsområdet <1551> För kännedom: Jan Bjurström FMV <410> -- Mottaget: 88-03-03 08.57 Kommentar till: (Text 782086) av Anne-Marie Eklund Statskontoret <3> Ärende: Efterlysning av material! Statskontoret är medlem av ITUSA och har mycket material därifrån. Övriga nämnda organisationer ser jag som helt ointressanta. (Det finns ju också så många att en del bör lämnas att självdö!)
(Text 784393) (1 kommentar)
(Text 784542) 88-03-02 22.11 Ragge Sundblad (ragge@nada.kth.se) Mottagare: Macintosh erfarenhetsutbyte <3219> För kännedom: Standarder (inom) databehandlingsområdet <1552> Kommentar till: (Text 776523) av Peter Svanberg NADA <1> Ärende: Tangentbord med fyra nivåer Högershift. Vad heter det då att flytta biter i register?
(Text 784542)
(Text 784564) 88-03-02 22.42 Johan Lundberg TeleDelta Mottagare: Standarder (inom) databehandlingsområdet <1553> För kännedom: Jan Bjurström FMV <411> -- Mottaget: 88-03-03 08.57 Kommentar till: (Text 784393) av Wolf Arfvidson Statskontoret <1> Ärende: Efterlysning av material! Kan du berätta vad dessa för mig helt okända förkortningar är för något.
(Text 784564)
(Text 784606) 88-03-02 23.36 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1554> Ärende: Önskemål om bakåtkompatibilitet och förändringar i strid med det, som medför sämre "användar- interface", finns faktiskt även utanför området datorstandardi- sering. För rätt många år sedan bytte Arla utseende på literförpack- ningarna av lättmjölk och lättfil. Det hade varit alldeles utmärkt -- de var säkert efter många års produktion i behov av ansiktslyftning och modärnisering -- om det inte varit så att man då, antagligen som en helt oavsedd bieffekt, kastat om paketens färger. Tidigare var lättmjölkspaketet ljusare och lättfilens mörkare blå; för övrigt ett naturligt val: trögare konsistens => mörkare signalfärg. Sedan dess är det som bekant tvärtom och fortfarande, efter alla dessa år, händer det att jag tar fel förpackning ur kylen och häller fil i teet.
(Text 784606)
(Text 785200) 88-03-04 15.08 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1555> Kommentar till: (Text 783237) av Jacob Palme QZ <1> Extra kopia: @KOM.KOMUNITY.SE: Staffan Johansson <64> -- Mottaget: 88-03-04 18.03 Sändare: -- Sänt: 88-03-04 16.40 Markerad av 3 personer. Ärende: Da capo > (Text 366491) 85-05-17 09.04 Olle Järnefors KTH > Mottagare: Standarder (inom) databehandlingsområdet > Antal rader: 135 > Ärende: EBCDIC <-> ASCII > ------------------------------------------------------------ > Rabbe Fogelholm och jag har försökt sätta oss in i hur EBCDIC- > kodade filer bör konverteras till filer i 7-bits ISO-kod (före- > trädesvis amerikansk och svensk), så kallade ASCII-filer. Frå- > gan har kommit upp därför att en EBCDIC-option skulle införas i > ett program som läser upp filer på ANSI-formaterade band till > en NORD-dator. > > På "ASCII"-sidan finns tre kodvarianter att ta hänsyn till: > (a) amerikansk 7-bitskod (äkta ASCII) > (b) svensk 7-bitskod i allmän version > (c) svensk 7-bitskod i version för egennamn (rekommenderas i > Statskontorets tekniska norm 3:2) > Beträffande "ASCII"-koder kan dollartecken och valutatecken > anses vara ekvivalenta; många terminaler och skrivare har > dollartecken insatt i (b) eller (c). På samma sätt kan nummer- > tecken och paragraftecken anses ekvivalenta i svensk miljö. > (Statskontoret anger att denna användning "inom justitiedepar- > tementets område".) > > Av EBCDIC tycks det tyvärr finnas många fler och svårare inkom- > patibla varianter. Bara genom ett ytligt litteraturstudium, > utan någon praktisk erfarenhet av IBM-stordatorer, har vi iso- > lerat sju varianter. Det skulle vara bra om ni som vet mer kan > tala om ifall även andra kodvarianter används, om några av de > nedan angivna är mycket ovanliga och om vi har missuppfattat > något. > > Det kan för övrigt noteras att en missuppfattning eller ett > feltryck troligen föreligger i "Kermit User Guide" (utgåva 5, > 1984-07-27, KER:KUSER.DOC), appendix I, och i "Kermit Protocol > Manual" (utgåva 5, 1984-04-03, KER:KPROTO.DOC), appendix V. > Både likhets-tecken och tilde anges där ha EBCDIC-koden 7EH. I > övriga EBCDIC-specifikationer som vi har sett har likhetstecken > mycket riktigt koden 7EH men tilde (eller i de svenska variant- > erna: litet tyskt y) kod A1H. (EBCDIC-konvertering diskuteras i > Info-Kermit Digest vol 2, nr 8 och 19, som finns i engelska KOM > 94088 respektive 99593, dock utan att denna sak nämns.) > > Tabell över skillnaderna mellan olika EBCDIC-koder: > Varianter: > (1) ANSI 1968 (inverterbar konvertering till ASCII) > (2) Kermit User Guide (inverterbar konvertering till ASCII) > (3) IBM System/370 > (4) IBM BSC Protocol > (5) Statskontoret äldre > (6) Statskontoret normal > (7) Statskontoret variant (inverterbar konvertering till ASCII) > Kod (1) (2) (3) (4) (5) (6) (7) > 4AH Äa sc sc sp sp # > 4FH ! öa öa öa öa ! ! > 5AH Åa ! ! ! $s $s $s > 5BH $a $a $a $a Ås Ås Ås > 5FH ^a ^a sn sn sn ^a ^s > 6AH öb öa öb ös ös ös > 79H `a `a `a `a `s `s `s > 7BH # # # # Äs Äs Äs > 7CH @a @a @a @a Ös Ös Ös > A1H ~a ~a ~a ~a ~s ~s ~s > ADH Äa Äa > BDH Åa Åa > C0H äa äa äa äa äs äs äs > D0H åa åa åa åa ås ås ås > E0H Öa Öa Öa Öa @s @s @s > FAH öa > Beteckningar: > $a = dollartecken $s = valutatecken > @a = kommersiellt a' @s = versalt E med akut accent > Äa = vänster hakparentes Äs = versalt AE > Öa = inverterat snedstreck Ös = versalt OE > Åa = höger hakparentes Ås = versalt AA > ^a = cirkumflex accent ^s = versalt UE > `a = grav accent `s = gement e med akut accent > äa = vänsterklammer äs = gement ae > öa = vertikalstreck ös = gement oe > åa = högerklammer ås = gement aa > ~a = tilde ~s = gement ue > öb = vertikalstreck med hål > sc = centtecken > sn = negationstecken > sp = paragraftecken > Källor: > (/1/) Communications of the ACM vol 11 nr 11 s 783..789 (1968-11) > (/2/) Kermit User Guide, utgåva 5 (korrigerad här) > (/3/) IBM: System/370 Reference Summary. GX20-1850-5. > Utgåva 6, 1984 > (/4/) IBM: General information -- binary synchronous communi- > cations. System Reference Library TP-09, utgåva 3, 1970 > (/5/) - (/7/) Statskontorets tekniska norm 4:2, 1984-07-02 > ((/1/) och (/3/) som de refereras i inlägg 99593 i engelska KOM.) > > Det kan noteras att (3) har tre vertikalstreck, av vilka två > har exakt samma utseende. EBCDIC-koderna är inte ense om var > utropstecknet ska ligga (saknas helt i (5)). Nummertecken och > valutatecken kan inte behandlas som ekvivalenta i EBCDIC- > koderna. > > Den för alla EBCDIC-varianterna gemensamma delen omfattar > styrtecknen > blanktecknet > de internationella versalerna > de internationella gemena bokstäverna > siffrorna > . , ? : ; - / ' " ( ) % & + = * < > _ > Motsvarande gemensamma del i "ASCII"-koderna innehåller dessa > tecken och dessutom > ! # > > Till sist två teckentabeller: > > "ASCII" EBCDIC > ------- ------ > H:0 1 2 3 4 5 6 7 H:0 1 2 3 4 5 6 7 8 9 A B C D E F > L: L: > 0 ^@^PSP 0?? P?? p 0 ^@^P SP & - ?????? 0 > 1 ^A^Q ! 1 A Q a q 1 ^A^Q / a j?? A J 1 > 2 ^B^R " 2 B R b r 2 ^B^R ^V b k s B K S 2 > 3 ^C^S # 3 C S c s 3 ^C^S c l t C L T 3 > 4 ^D^T?? 4 D T d t 4 d m u D M U 4 > 5 ^E^U % 5 E U e u 5 ^I ^J e n v E N V 5 > 6 ^F^V & 6 F V f v 6 ^H^W f o w F O W 6 > 7 ^G^W ' 7 G W g w 7 DE ^Ä^D g p x G P X 7 > 8 ^H^X ( 8 H X h x 8 ^X h q y H Q Y 8 > 9 ^I^Y ) 9 I Y i y 9 ^Y ?? i r z I R Z 9 > A ^J^Z * : J Z j z A ?????? : ?? > B ^K^Ä + ; K?? k?? B ^K .?? ,?? > C ^L^Ö , < L?? l?? C ^L^Ö ^T < * %?? > D ^M^Å - = M?? m?? D ^M^Å^E^U ( ) _ ' ???? > E ^N^^ . > N?? n?? E ^N^^^F + ; > = > F ^O^_ / ? O _ oDE F ^O^_^G^Z???? ? " > > '??' anger position med varierande grafiskt tecken. > 'DE' anger DELETE. > 'SP' anger blanktecknet. > '^' före ett tecken anger motsvarande styrtecken. > > (Text 366491)------------------------------
(Text 785200)
(Text 790698) 88-03-15 04.00 Olle Järnefors KTH Mottagare: AMIGA - Atari 1040ST - Macintosh - IBM PC/XT/AT - IBM PS/2 <716> Extra kopia: Standarder (inom) databehandlingsområdet <1556> Extra kopia: UNIX erfarenhetsutbyte <1589> Kommentar till: (Text 789677) av Per Andersson Datorsekretariatet KTH <3> Ärende: 8-bitskoder i Unix X/OPEN -- standardiseringsgrupp för "application interfaces" i Unix -- har konstaterat att 7-bits ASCII är oacceptabelt i andra språkmiljöer än engelska. I det "Native Language System" (NLS) som ingår i X/OPEN Portability Guide anges att ISO:s 8-bitskod IS 8859-1 bör användas. I framtiden kommer också andra 8-bitskoder att ingå i NLS. I HP:s Unix-version HP-UX finns en implementation av NLS (Na- tive Language Support) där fyra olika 8-bitskoder användas, ROMAN8, KANA8, GREEK8 och TURKISH8. IS 8859-1 ingår inte här, ROMAN8 är en HP-speciell 8-bitskod för språk med latinskt alfabet.
(Text 790698)
(Text 790706) 88-03-15 04.07 -Olle Järnefors KTH Mottagare: Riktig svenska <2989> För kännedom: Fikonspråk - översättning från datorslang till svenska <2594> Kommentar till: (Text 789562) av Torbjörn Nordlindh Apple Computer AB <5> Extra kopia: Standarder (inom) databehandlingsområdet <1557> Sändare: Sven Olofsson QZ -- Sänt: 88-03-15 07.24 Extra kopia: @KOM.KOMUNITY.SE: Staffan Johansson <110> -- Mottaget: 88-03-15 18.03 Sändare: -- Sänt: 88-03-15 12.57 Extra kopia: Överföres till QOM <316> Sändare: Jacob Palme QZ -- Sänt: 88-03-17 10.28 Extra kopia: Tolkning (och) översättning <14> Sändare: Helge Niska Tolk- och översättarinstitutet -- Sänt: 88-03-24 19.58 Ärende: Datorordlistor Den enda auktoritativa svenska datorordlistan är nog SIS och TNCs Dataordboken. (SIS = Standardiseringskommissionen i Sve- rige. TNC = Tekniska Nomenklaturcentralen.) Jag har sett en del andra ordlistor med svenska datortermer i bokhandeln men de var inte särskilt omfattande eller verkade inte helt tillförlit- liga. (Det var något år sedan.) Några problem med Dataordboken är - att den är rätt omodern (utkom 1984) - att den innehåller många mycket ovanliga termer (vilket beror på att den till stor del bygger på ordlistor som tagits fram i internationellt standardiseringsarbete) - att den å andra sidan saknar de flesta termer inom andra områden, som inte förekommit så mycket i standardiserings- arbetet (till exempel programmeringsteknik och gränssnitt mellan användare och program) - att den saknar många mycket vanliga termer som har oprecis innebörd (till exempel "mainframe/stordator") - att den har svår slagsida mot stordatorer och minidatorer. Det sista problemet beror säkert på att den grupp som revide- rade Dataordboken -- föregående utgåva kom 1977 -- hade repre- sentanter för Televerket, IBM, Statskontoret och Ericsson, men ingen från persondatorbranschen. Datortekniken drabbar allt fler vanliga människor, som inte ska behöva acceptera branschens och datorexperternas fikonspråk eller dåligt (ibland inte alls) översatta engelska uttryck i programmens ledtexter/prompter och bruksanvisningar/manualer. Samtidigt går den tekniska utvecklingen mycket snabbare än på något annat tekniskt område någonsin tidigare. Detta gör att auktoritativa engelsk-svenska ordlistor för datorområdet borde arbetas fram mycket snabbare och aktuali- seras mycket oftare än i den makliga takt med fem- eller tio- åriga revisionsperioder som TNC använder för andra tekniska områden. Det finns också en mycket bredare krets av intresse- rade människor som skulle kunna bidra till ett sådant arbete än i andra teknikområden. Lyckligtvis tillhandahåller datortekniken numera faktiskt prak- tiska möjligheter att hantera en sådan diskussion med många deltagare, något som tidigare inte varit möjligt. En sådan diskussion skulle kunna föras i ett allmänt tillgängligt dator- konferenssystem, ungefär som ett utbyggt "Fikonspråk"-möte, där de personer inom TNC och SIS som sysslar med datorterminologi aktivt deltog. Datorordlistan, med översättningar och definitioner, skulle då vara tillgänglig som textfil eller databas på samma dator för- utom i den vanliga bokformen. Denna datorbaserade datorordlista skulle dock kunna uppdateras mycket oftare än den tryckta ordlistan, som ett resultat av diskussionen i datorkonferensen mellan "språkmänniskorna" från TNC/SIS och "användarna" av datortermer: översättare, representanter för språkmedvetna datorföretag som Apple, forskare och lärare inom datorområdet, systemutvecklare, fackliga representanter, vanliga lekmän. Organisationer som SIS och TNC är dock trögrörliga och har begränsade resurser. Därför tror jag det skulle ha stort värde om ett förslag med denna inriktning framfördes till dem av till exempel Apple, helst tillsammans med andra svenska datorföretag med samma inställning (IBM?, Microsoft?, Expander?, DEC?), tillsammans med utfästelser om aktivt deltagande från före- tagens sida.
(Text 790706) (1 kommentar)
(Text 790766) 88-03-15 09.02 Lennart Nordström Mottagare: Riktig svenska <2992> Mottagare: Lennart Nordström <1096> -- Mottaget: 88-03-15 09.02 För kännedom: Fikonspråk - översättning från datorslang till svenska <2595> Kommentar till: (Text 790706) av -Olle Järnefors KTH <1> Extra kopia: Standarder (inom) databehandlingsområdet <1558> Sändare: Sven Olofsson QZ -- Sänt: 88-03-15 10.29 Extra kopia: @KOM.KOMUNITY.SE: Staffan Johansson <111> -- Mottaget: 88-03-15 18.03 Sändare: -- Sänt: 88-03-15 12.58 Extra kopia: Överföres till QOM <317> Sändare: Jacob Palme QZ -- Sänt: 88-03-17 10.30 Extra kopia: Tolkning (och) översättning <15> Sändare: Helge Niska Tolk- och översättarinstitutet -- Sänt: 88-03-24 19.59 Ärende: Datorordlistor Det pågår just nu en revision av SIS DATAORDBOK med ambitionen att kunna ge ut en ny uppdaterad version vid årsskiftet. Det är riktigt att en sådan måste vårdas och ges ut oftare. Förutom arbetsgruppen med Hans Riesel (KTH) som ordf. så jobbar Ove Oscarsson TNC/SIS-ITS aktivt. Ge honom gärna förslag och impulser. Man når honom på TNC tel. 7358525 eller på SIS-ITS (måndagar) tel 23 04 00. Hälsningar. Lennart Nordström (Statskontoret)
(Text 790766)
(Text 806418) 88-04-25 11.34 Torbjörn Lundberg Televerket Mottagare: Nancy TNA <1089> Mottagare: SIS-Ag21 OSI-modellen och högre skikten <75> Mottagare: Standarder (inom) databehandlingsområdet <1559> För kännedom: Jan Bjurström FMV <454> -- Mottaget: 88-05-02 21.24 Sändare: Jan Flodin FMV -- Sänt: 88-04-26 00.24 Markerad av någon. Ärende: OSI - kurs OMNICOM arrangerar den 16 - 20 maj i stockholm med några ytterst kompetenta lärare. Kursen innehåller följande moduler, som kan plockas separat: -OSI reference model -OSI networking protocols -OSI upper layer protocols -Message handling systems -ASN.1 -Directory -ISDN protocols & technology Varje modul är 1 eller 2 dagar lång. Telefon till Omnicom är +44 438-742424, telex 826903 OMNICM, fax +44 438-740154
(Text 806418) (3 kommentarer)
(Text 806534) 88-04-25 18.36 Jacob Palme QZ Mottagare: EUTECO - European Teleinformatics Conference <7> För kännedom: Standarder (inom) databehandlingsområdet <1560> För kännedom: Jan Bjurström FMV <458> -- Mottaget: 88-05-02 21.27 Sändare: Jan Flodin FMV -- Sänt: 88-04-26 00.26 Markerad av någon. Ärende: Peter Linnington: OSI-Networks, problems and future trends. Problems with standards: Too complex, too many options, take too long to produce. Orsak: Man försöker uppnå en konsensus mellan olika deltagares olika önskemål. En annan orsak är att olika skrivna och oskrivna regler i olika länder tvingar fram olika optioner. För att minska antalet optioner gör man s.k. funktionella standarder, som väljer ut vad man skall göra ur en stor standard. Men dessa tenderar istället att bli för snäva, ge en skärning av det som går att göra i ett antal existerande system, och blir därmed ofta inte tillfredställande. Normalt tar det minst 5 år att utveckla en standard, ca 20 möten behövs innan en standard är klar. Det är därför som CCITT- rekommendationer sällan blir stabila efter en studieperiod: Man får inte in 20 möten på en CCITT-studieperiod. Liaison via papper är inte effektivt, man måste ha liaison via gemensamma möten eller personer som är med i båda grupperna om man skall uppnå effektiv samordning av arbete i olika standardi- seringsgrupper. RARE-COSINE activities: - identify protocols - maintain product information - agree accounting and charging - define addressing and rotuing - support gateways - provide European directories - develop testing tools - make user input to PTTs - prepare documentation Problem areas for OSI: - Management - Naming and adressing Conformance handlar om att observera ett systems beteende på någon viss punkt, och se till att det i just denna punkt beter sig enligt standarden.
(Text 806534)
(Text 806641) 88-04-25 20.37 Johan Lundberg TeleDelta Mottagare: Nancy TNA <1093> Mottagare: SIS-Ag21 OSI-modellen och högre skikten <76> Mottagare: Standarder (inom) databehandlingsområdet <1561> Kommentar till: (Text 806418) av Torbjörn Lundberg Televerket <1> För kännedom: Jan Bjurström FMV <455> -- Mottaget: 88-05-02 21.25 Sändare: Jan Flodin FMV -- Sänt: 88-04-26 00.25 Ärende: OSI - kurs Om jag inte fattat fel så sker detta i samarbete med sifu. Det bör gå bra att ringa dem och höra sig för.
(Text 806641)
(Text 806743) 88-04-25 22.58 Monica Ståhl TELDOK Mottagare: Nancy TNA <1096> Mottagare: SIS-Ag21 OSI-modellen och högre skikten <77> Mottagare: Standarder (inom) databehandlingsområdet <1562> Kommentar till: (Text 806418) av Torbjörn Lundberg Televerket <2> För kännedom: Jan Bjurström FMV <456> -- Mottaget: 88-05-02 21.25 Sändare: Jan Flodin FMV -- Sänt: 88-04-26 00.25 Ärende: OSI - kurs Det är SIFU som arrangerar kurstillfället här i Sverige så det går nogbra att anmäla sig till dom. Vi tänkte bjuda in de fyra lärarna till en enkel buffe (dvs rostbiff och potatissallad) på TeleDelta då vi känner en del av lärarna. Är det någon som tycker att det kunde vara intressant att träffa dem under informella former kan ni väl höra av er till mig. Monica tfn 24 83 69
(Text 806743)
(Text 806748) 88-04-25 23.21 Krister Holmgren Mottagare: Nancy TNA <1097> Mottagare: SIS-Ag21 OSI-modellen och högre skikten <78> Mottagare: Standarder (inom) databehandlingsområdet <1563> Kommentar till: (Text 806418) av Torbjörn Lundberg Televerket <3> För kännedom: Jan Bjurström FMV <457> -- Mottaget: 88-05-02 21.26 Sändare: Jan Flodin FMV -- Sänt: 88-04-26 00.25 Ärende: OSI - kurs Jag fick programmet först i förra veckan. Det är väldigt synd att det kom så sent; mindre än en månad är för lite framförhållning för att kalendern skall vara tillräckligt ren. Det gäller väl många fler än mig, kan jag tro, och programmet verkar ju som sagt intressant. - Den långsamma postgången från utlandet, särskilt när det gäller trycksaker o d, är f ö ett allmänt problem. Ibland får jag program till seminarier etc som redan hållits! Vad göra? Finns det någon databas med dylik information?
(Text 806748) (1 kommentar)
(Text 807076) 88-04-26 21.27 Johan Lundberg TeleDelta Mottagare: Nancy TNA <1102> Mottagare: SIS-Ag21 OSI-modellen och högre skikten <79> Mottagare: Standarder (inom) databehandlingsområdet <1564> För kännedom: Jacob Palme QZ <31837> -- Mottaget: 88-04-27 18.57 Kommentar till: (Text 806748) av Krister Holmgren <1> Ärende: OSI - kurs Det finns en hel del möten av typen News xx på Eurokom. Jag vet inte om de överförs till QZCOM men det kan säkert Jacob Palme svara på.
(Text 807076) (1 kommentar)
(Text 807295) 88-04-27 18.58 Jacob Palme QZ Mottagare: Nancy TNA <1105> Mottagare: SIS-Ag21 OSI-modellen och högre skikten <80> Mottagare: Standarder (inom) databehandlingsområdet <1565> För kännedom: Jacob Palme QZ <31846> -- Mottaget: 88-04-27 18.58 Kommentar till: (Text 807076) av Johan Lundberg TeleDelta <1> Ärende: OSI - kurs EUROKOM tillåter inte vad jag vet någon överföring av inlägg från deras möten till andra system.
(Text 807295) (1 kommentar)
(Text 807703) 88-04-28 20.22 Johan Lundberg TeleDelta Mottagare: SIS-Ag21 OSI-modellen och högre skikten <81> Mottagare: Standarder (inom) databehandlingsområdet <1566> För kännedom: Jacob Palme QZ <31858> -- Mottaget: 88-04-29 17.01 Kommentar till: (Text 807295) av Jacob Palme QZ <1> Ärende: OSI - kurs Varför det? Skulle det undergräva deras verksamhet eller vad?
(Text 807703) (1 kommentar)
(Text 808008) 88-04-29 17.03 Jacob Palme QZ Mottagare: SIS-Ag21 OSI-modellen och högre skikten <82> Mottagare: Standarder (inom) databehandlingsområdet <1567> Kommentar till: (Text 807703) av Johan Lundberg TeleDelta <1> Ärende: OSI - kurs Jag är inte säker på hur de gör just nu. Men i höstas var i alla fall deras policy att man kunde sända saker för kännedom till externa namn, men ej abonnera på mötesutskrifter till externt namn. Deras egen motivering till detta var att de inte hunnit implementera tekniken för att göra det och speciellt för att kunna ta betalt för kostnaderna.
(Text 808008)
(Text 808410) 88-04-30 19.46 @cwi.nl: piet (Piet Beertema) Mottagare: @RUNIT.UNIT.UNINETT: rare-wg1 <2> -- Mottaget: 88-05-01 03.47 Sändare: Överföring (från) EARN -- Sänt: 88-04-30 19.46 För kännedom: Standarder (inom) databehandlingsområdet <1568> Sändare: Jacob Palme QZ -- Sänt: 88-05-01 05.42 Extra kopia: Jan Aston QZ-DK <290> -- Mottaget: 88-05-09 11.51 Sändare: -Hasse Sjöberg -- Sänt: 88-05-05 16.31 Extra kopia: Bruno Billman QZ <2704> -- Mottaget: 88-05-09 14.15 Sändare: Jan Aston QZ-DK -- Sänt: 88-05-09 11.53 Markerad av 2 personer. Ärende: Bad news, folks.... %Original date: 7 Apr 88 0:53 +0100 %TF: DSKD:E86423.MAI %FROM: Piet Beertema <cwi.nl!piet%mcvax.UUCP@norunit.BITNET> %SMTP sender: <JPALME@QZCOM.BITNET> Received: from ODENFILT@SEARN.BITNET; 4/30/88 17:57:36 GMT+1 Received: from QZCOM by SEARN.BITNET (Mailer X1.24) with BSMTP id 5348; Sat, 30 Apr 88 17:57:31 GMT Message-ID: <8804060824.AA01930@sering.cwi.nl> Date: 7 Apr 88 0:53 +0100 From: Piet Beertema <cwi.nl!piet%mcvax.UUCP@norunit.BITNET> Reply-To: Piet Beertema <cwi.nl!piet%mcvax.UUCP@norunit.BITNET>, "Paul van Binst" <P550@QZCOM.BITNET>, "N. Malagardis BNI" <P12195@QZCOM.BITNET>, "QZ. RARE WG1" <QZRARWG1@QZCOM.BITNET>, "Rolf Speth CEC COST11ter" <RSPETH@QZCOM.BITNET>, "Nicholas Newman CEC" <NEWMAN@QZCOM.BITNET> Resent-Reply-To: To: "Paul van Binst" <P550@QZCOM.BITNET>, rare-wg1@RUNIT.UNIT.UNINETT, "N. Malagardis BNI" <P12195@QZCOM.BITNET>, "QZ. RARE WG1" <QZRARWG1@QZCOM.BITNET>, "Rolf Speth CEC COST11ter" <RSPETH@QZCOM.BITNET>, "Nicholas Newman CEC" <NEWMAN@QZCOM.BITNET> cc: "NI Development" <C416@QZCOM.BITNET>, "Mail-network implementation" <C213@QZCOM.BITNET>, amigo_group@XPS.GMD.DBP.DE, "Reseaux Associes (pour la) Recherche Europeene (RARE)" <RAREOPEN@QZCOM.BITNET> bcc: "Jacob Palme QZ" <JPALME@QZKOM.BITNET> Subject: Bad news, folks.... ------- Forwarded Message Received: by sering.cwi.nl; Tue, 5 Apr 88 23:24:43 +0200 (MET) Received: by mcvax.cwi.nl; Tue, 5 Apr 88 23:24:27 +0200 (MET) From: gligor%taec.DEC@decwrl.dec.com Received: from decwrl.dec.com by uunet.UU.NET (5.54/1.14) id AA01494; Tue, 5 Apr 88 10:36:44 EDT Received: by decwrl.dec.com (5.54.4/4.7.34) id AA19821; Tue, 5 Apr 88 06:13:41 PDT Message-Id: <8804051313.AA19821@decwrl.dec.com> Date: 5 Apr 88 15:11 To: aea@mitre-bedford.arpa, piet@sering.cwi.nl Subject: Washington abandons OSI! Mitre employee goes into shock! From: LEROUF::DECWRL::"thumper!kremvax!meese@FALINE.BELLCORE.COM" "1-Apr-88 0 To: iso@NRTC.NORTHROP.COM Subj: OSI abandoned! WASHINGTON -- In a simultaneous announcement that took the computer industry by surprise, OSI leaders today said that they were abandoning their effort to promote the OSI Protocol Suite in favor of the existing US Department of Defense (DoD) ARPANET Protocol Suite. The official reason cited for the decison was a new report from the Office of Technology Assessment stating that the manpower required to fully implement and test even the few OSI protocols that are now defined would consume the entire output of American university computer science programs for the rest of the century, and that printing and distributing the necessary protocol specifications would consume the entire American and Canadian paper supplies for the next five years. However, one high-placed source speaking on condition of anonymity said, ``The whole OSI thing was a practical joke one of the guys cooked up a few years ago. Nobody ever expected anybody to take it seriously. I mean, who would believe an organization supposedly dedicated to tearing down barriers to free and open communications between computers when it's run by a former director of the National Security Agency? I guess computer people are a lot more gullible than we thought. We kept dropping hints, making the whole thing more and more ridiculous. We hoped that people would eventually catch on, but it didn't work. Finally, our consciences got to us.'' In related news, officials at the Mitre Corporation in Bedford, Massachussetts reported that one of their employees, as yet publicly unidentified, froze ``as solid as stone'' when he heard the announcement. Medical experts have as yet been unable to communicate with the victim or get him to relax his facial muscles, which are reportedly locked into what was described as an ``enormous grin''. AP-NR-04-01-88 0001EST ======================================================================== Received: from RELAY.CS.NET by decwrl.dec.com (5.54.4/4.7.34) id AA07428; Mon, 4 Apr 88 23:10:19 PDT Received: from gremlin.nrtc.northrop.com by RELAY.CS.NET id aa12376; 5 Apr 88 2:14 EDT Received: from bboards by gremlin.nrtc.northrop.com id a005966; 4 Apr 88 22:46 PST Received: from nrtc by gremlin.nrtc.northrop.com id a005962; 4 Apr 88 22:45 PST Received: from UCBVAX.Berkeley.EDU by nrtc.nrtc.northrop.com id aa11400; 4 Apr 88 22:46 PST Received: by ucbvax.Berkeley.EDU (5.59/1.26) id AA21378; Sat, 2 Apr 88 11:55:59 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for iso@nrtc.northrop.com (iso@nrtc.northrop.com) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Organization: Soviet Sanctuary for Victims of American Persecution Message-Id: <880401@kremvax.arpa> Sender: iso-request@NRTC.NORTHROP.COM ------- End of Forwarded Message
(Text 808410) (1 kommentar)
(Text 808402) 88-04-30 19.36 @INESC.RIUP: pmv (Pedro Veiga) Mottagare: @RUNIT.UNIT.UNINETT: rare-wg1 <1> -- Mottaget: 88-05-01 03.47 Sändare: Överföring (från) EARN -- Sänt: 88-04-30 19.36 Kommentar till: (Text 808410) av @cwi.nl: piet (Piet Beertema) <1> Sändare: Jacob Palme QZ -- Sänt: 88-05-01 05.43 För kännedom: Standarder (inom) databehandlingsområdet <1569> Sändare: Jacob Palme QZ -- Sänt: 88-05-01 05.45 Markerad av någon. Ärende: Bad news, folks.... %Original date: 7 Apr 88 9:52 +0100 %TF: DSKD:E05827.MAI %FROM: Pedro Veiga <pmv%inesc.riup@norunit.BITNET> %SMTP sender: <JPALME@QZCOM.BITNET> Received: from ODENFILT@SEARN.BITNET; 4/30/88 17:57:27 GMT+1 Received: from QZCOM by SEARN.BITNET (Mailer X1.24) with BSMTP id 5345; Sat, 30 Apr 88 17:57:23 GMT Message-ID: <654*pmv@inesc.riup> Date: 7 Apr 88 9:52 +0100 From: Pedro Veiga <pmv%inesc.riup@norunit.BITNET> Reply-To: Pedro Veiga <pmv%inesc.riup@norunit.BITNET>, "Paul van Binst" <P550@QZCOM.BITNET>, "N. Malagardis BNI" <P12195@QZCOM.BITNET>, "QZ. RARE WG1" <QZRARWG1@QZCOM.BITNET>, "Rolf Speth CEC COST11ter" <RSPETH@QZCOM.BITNET>, "Nicholas Newman CEC" <NEWMAN@QZCOM.BITNET> Resent-Reply-To: To: "Paul van Binst" <P550@QZCOM.BITNET>, rare-wg1@RUNIT.UNIT.UNINETT, "N. Malagardis BNI" <P12195@QZCOM.BITNET>, "QZ. RARE WG1" <QZRARWG1@QZCOM.BITNET>, "Rolf Speth CEC COST11ter" <RSPETH@QZCOM.BITNET>, "Nicholas Newman CEC" <NEWMAN@QZCOM.BITNET> cc: "Mail-network implementation" <C213@QZCOM.BITNET>, "Reseaux Associes (pour la) Recherche Europeene (RARE)" <RAREOPEN@QZCOM.BITNET> bcc: "Jacob Palme QZ" <JPALME@QZKOM.BITNET> Subject: Bad news, folks.... From: LEROUF::DECWRL::"thumper!kremvax!meese@FALINE.BELLCORE.COM" "1-Apr-88 00 00 GMT" 5-APR-1988 08:11 ^ ö ö--------------- What is happening with our computer networks? A message originated the 1st of April just arrived to me the 7th? Regards, --Pedro
(Text 808402)
(Text 816350) 88-05-26 21.57 Johnny Eriksson Mottagare: Standarder (inom) databehandlingsområdet <1570> Markerad av någon. Ärende: Datumformat. Jag skulle vilja veta vilka olika format som används för att skriva datum/klockslag på, inte bara i Sverige, utan även inter- nationellt. Någon som har en referens, gärna till något maskin- läsbart dokument? Bakgrund: Jag ämnar lära AMIS flera olika datumformat.
(Text 816350) (3 kommentarer)
(Text 816539) 88-05-27 12.45 Jacob Palme QZ Mottagare: Standarder (inom) databehandlingsområdet <1571> Kommentar till: (Text 816350) av Johnny Eriksson <2> Markerad av någon. Ärende: Datumformat. RFC822 (DOC:822.RFC) innehåller det datumformat som används i Arpanet Mail. I X.400 kodar man datum/tid i formatet 8805271245Z eller 8805271245-0500 där "Z" resp "-0500" anger tidzon-avvikelse från UTS-tid. Mitt program PUB:CALCAL är skrivet för att förstå indata i flera olika datumformat.
(Text 816539) (1 kommentar)
(Text 816555) 88-05-27 13.22 Jacob Palme QZ Mottagare: PASCAL erfarenhetsutbyte <1736> Extra kopia: Standarder (inom) databehandlingsområdet <1572> Kommentar till: (Text 816539) av Jacob Palme QZ <1> Mottagare: Jacob Palme QZ <32368> -- Mottaget: 88-05-27 15.46 Mottagare: Jacob Palme QZ <32379> -- Mottaget: 88-05-28 18.02 Ärende: Datumformat. Fel av mig. CALCAL förstod inte så många datumformat som jag trodde. Men jag har ett program någonstans, som jag skrivit i Pascal, och som kan förstå datum givet i flera olika format. Om du vill kan jag leta reda på källkoden.
(Text 816555) (1 kommentar)
(Text 816781) 88-05-28 11.26 Olle Järnefors KTH Mottagare: Standarder (inom) databehandlingsområdet <1573> Kommentar till: (Text 816350) av Johnny Eriksson <3> Markerad av: Johnny Eriksson Markerad av någon annan. Ärende: Datumformat. Svensk standard (SIS 01 02 11, 1972) godkänner: 1) 1988-08-12 2) 1988 08 02 3) den 12 augusti 1988 4) den 12 aug 1988 (månadsnamn avhugget till tre tecken) 5) 88-08-12 6) 88 08 12 7) 19880812 8) 880812 Andra "defacto-standarder" i Sverige är: 9) 12/8 1988 10) den 12/8 1988 11) 12/8/1988 12) 12/8/88 13) 1988.08.12 14) 88.08.12 Enligt postens bok "Företagets brev till utlandet" (1976) används i USA: 15) 8-12-88 16) August 12, 1988 Själv har jag i amerikanska brev sett: 17) 8/12/88 (jämför format 12) Storbritannien enligt "Företagets brev till utlandet": 18) 12-8-88 (jämför format 15) 19) 12th August, 1988 Min engelska grammatik godkänner också: 20) August 12th, 1988 21) 12 August, 1988 22) 12 August 1988 Västtyskland enligt "Företagets brev till utlandet": 23) 12. August 1988 24) den 12. August 1988 25) 12. Aug. 1988 26) den 12. Aug. 1988 Frankrike enligt "Företagets brev till utlandet": 18) 12-8-88 27) le 12 aou^t 1988 Spanien enligt "Företagets brev till utlandet": 28) 12.8.88 29) 12 de Agosto de 1.988 (obs punkten i årtalet) Tvivelsutan finns många andra varianter också i bruk. Kanske vore det bästa att göra det möjligt för varje AMISbruk- are att själv definiera exakt det datumformat hon föredrar? Datumformatet kunde specificeras med hjälp av följande element: <y1> första siffran i årtalet <y2> andra siffran i årtalet <y3> tredje siffran i årtalet <y4> fjärde siffran i årtalet <m1> första siffran i månadsnumret <m1e> första siffran i månadsnumret; tom sträng om den är = 0 <m1b> första siffran i månadsnumret; blanktecken om den är = 0 <m2> andra siffran i månadsnumret <m:foo> den <månadsnummer>-te strängen i uppräkningen "foo" <d1> första siffran i dygnsnumret <d1e> första siffran i dygnsnumret; tom sträng om den är = 0 <d1b> första siffran i dygnsnumret; blanktecken om den är = 0 <d2> andra siffran i dygnsnumret << tecknet '<' Formatet 29) 12 de Agosto de 1.988 skulle kunna definieras så här: <d1e><d2> de <m:spanish> de <y1>.<y2><y3><y4> Definitionen av månadsnamnsuppräkningen "spanish" kunde göras så här: <b:spanish>Enero<Febrero<Marzo<Abril<Mayo<Junio<Julio<Agosto <Setiembre<Octubre<Noviembre<Diciembre<e:spanish> Uppräkningarna "swedish", "swedish3" och "english" kunde vara fördefinierade. Denna metod kan givetvis utvidgas för att hantera också årtal utanför intervallet 1000..9999 (inklusive negativa årtal och årtal f Kr) och klockslagsangivelser med olika tidszoner och sommartid/normaltid.
(Text 816781)