From psv@nada.kth.se Wed Nov 18 09:32:21 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12885; Wed, 18 Nov 92 09:32:36 +0100 Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12862; Wed, 18 Nov 92 09:32:21 +0100 Message-Id: <9211180832.AA12862@nada.kth.se> To: nordpost@nada.kth.se, systemgruppen@nada.kth.se, ber@kth.se, jw@sics.se, howard@ericsson.se, matti@bion.kth.se, orjan@sans.kth.se, perham@sans.kth.se, dan@sics.se, schoultz@admin.kth.se, sveno@dsv.su.se, perixon@dsv.su.se, lindberg@cs.chalmers.se, bc@sunic.sunet.se, Hans.wassen@udac.uu.se, bok@lidac.liu.se, fj@dc.luth.se, roland@biovax.umdc.umu.se, Ake.Bladh@data.hkr.se, Anna-Karin.Sundberg@dc.luth.se, Arne.Sundstrom@ldc.lu.se, Bjorn.Hagvall@dc.luth.se, Bo.Elander@imi.ki.se, Bolennart.Svensson@hb.se, Borje.Josefsson@dc.luth.se, Carl-Erik.Lundgren@data.slu.se, hans.wallberg@umdac.umu.se, Kurt.Stromberg@b-byr.lu.se, Leif.Sanner@uadm.uu.se, Maria.Gronberg@umdac.umu.se, Rune.Sjo@ldc.lu.se, Sven.Arvidson@udac.uu.se, TorTi@lidac.liu.se, Ulla.Linde@udac.uu.se, nordlof@adm.gu.se, dane@admin.kth.se, fuerstenbach@presidency.su.se, gucgd@gd.chalmers.se, gucul@gd.chalmers.se, kbeskow@admin.kth.se, sblund@cs.umu.se, tor@dsv.su.se, torsten@ae.chalmers.se, Torleif_Olhede@f087039025.fax.sunet.se, Torsten_Olsson@f031721778.fax.sunet.se, Magnus.Persson@LDC.lu.se, olle@vhs.se, per.wallentinsson@udac.uu.se, per_wernheim@f087286625.fax.sunet.se, tvw@cs.umu.se, christer.welam@umdac.umu.se, Bjorn_Forselius@F02381971.fax.sunet.se, fredrik@dc.luth.se, Ivo.Mischke@imi.ki.se, robert@eva.slu.se, tingsell@hum.gu.se, airborn@noatun.sunet.se, kankkune@cs.helsinki.fi, mats@sics.se, Pekka.Nikander@ngs.fi, kimcm@login.dkuug.dk Subject: Diskussionsgrupp om datorpostteknik i Norden, t.ex. MIME-inf|rande Date: Wed, 18 Nov 92 09:32:20 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*101 Härmed inbjudes till att återuppta datorförmedlade diskussioner ("brevlista") om datorpostteknik i Norden. Aktuellt just nu är: * Hur inför vi MIME i Sverige? Hur undviks att MIME får dåligt rykte genom att folk drabbas av f=F6rf=E4rligt sv=E5rl=E4sta brev? (Tidigare hade denna grupp adressen "mailchar@nada.kth.se". Den adressen fungerar fortfarande.) OBS! För att låta nyinbjudna hinna anmäla sig vore det bra om alla som redan är med kunde vänta några dagar med att skriva inlägg. Jag tänkte f.ö. inleda själv med en kort rekapitualtion av föreliggande problem och förslag. Beskrivning av brevlistan: NAMN: Datorpostteknik i Norden ADRESS FÖR PRENUMERATION: nordpost-anmodan@nada.kth.se (mer information nedan) ADRESS FÖR INLÄGG: nordpost@nada.kth.se SYFTE: Förbättra "Internet-Mail"-hanteringen i Sverige (och Norden). ÄMNESOMRÅDEN: Diskussion om speciella aspekter på datorposthantering för Norden. Även intilliggande ämnen kan bli aktuella, t.ex. News. Nyheter om standardiseringsarbetet internationellt. MÅLGRUPP: Aktiva deltagare: Tekniskt insatta personer som har grundläggande kunskaper om datorposthantering, teckenkoder osv. Passiva deltagare: Alla intresserade. SPRÅK: Svenska, danska, norska, "skandinaviska" och vid behov engelska. TECKEN I BREV: Använd dom nordiska sjubitsteckenkoderna (inte åtta- bitstecken). Var extra tydlig när du refererar till tecken som inte finns i alla nordiska sjubitskoder. BREVLISTTYP: Helt öppen - alla inkommande brev går (efter normala tillägg av brevhuvudfält) direkt ut till alla mottagare. Hur man prenumererar ==================== Via datorpost: Om du har en egen datorpostadress och läser din datorpost regelbundet (och inte alltför sällan) kan du delta via datorpost. Skicka ett datorbrev till nordpost-anmodan@nada.kth.se där själva brevtexten innehåller en rad på formen subscribe nordpost brevlåda@domän (personnamn, organisation) Exempel: subscribe nordpost psv@nada.kth.se (Peter Svanberg, Nada, KTH) subscribe nordpost nordpost-lokalt@nada.kth.se (Distributionslista...) Inlägg i diskussionen skickas förstås till nordpost@nada.kth.se Via fax: Om du inte har möjlighet att läsa datorpost men istället har tillgång till en telefaxapparat *och* är beredd på att det under vissa perioder kan komma ganska många fax per dag, kan du delta passivt genom att skicka ett telefaxmeddelande till 08-790 09 30, Brevlistan om datorpost, c/o Peter Svanberg, Nada och uppge ditt faxnummer, och organisation. För att själv kunna göra inlägg i debatten måste du dock få hjälp av någon med datorpostanslutning, som kan skicka inlägget i ditt namn. Ett klart begränsat antal personer kan vara anslutna på detta sätt. Nuvarande deltagare =================== Jan Akalla, Unitech Mats S Andersson, Linköping Förmedling till Dafa-KOM Datacentralen, Högskolan i Luleå Jan Engvald, Lund Johnny Eriksson, SUNET-gruppen Patrik Fältström, Nada, KTH Ole Bjorn Hessen, Norge Olle Järnefors, TS-Data, KTH Stellan Lagerström, Elektro, KTH Erik Naggum, Norge Dan Oscarsson, Lund Peter Rostin, Europen.SE/DynaSoft AB Jan Michael Rynning, Nada, KTH Keld Simonsen, Danmark Peter Svanberg, Nada, KTH Andra deltagare? ================ Denna inbjudan skickas också till en antal andra personer som kan tänkas vara intresserade. Vet *du* någon som borde vara med? Tipsa mig (på samma sätt som för anmälan ovan)! Arkiv ===== Arkivering av alla inlägg kommer att ske. Arkivet kommer att vara nåbart via anonym FTP och efter beställning via datopost. Även gamla (mailchar-)inlägg kommer att vara åtkomliga på detta sätt, liksom en del andra relevanta filer. Mer information om detta kommer inom kort till deltagare och nyanmälda. Välkomna! --- Peter Svanberg Datorpost psv@nada.kth.se Nada, KTH Tfn 08-790 71 46 100 44 STOCKHOLM Fax 08-790 09 30 From psv@nada.kth.se Wed Nov 25 16:04:46 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA06043; Wed, 25 Nov 92 16:04:56 +0100 Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA06022; Wed, 25 Nov 92 16:04:46 +0100 Message-Id: <9211251504.AA06022@nada.kth.se> To: nordpost@nada.kth.se Subject: Nu k|r vi ig}ng! Date: Wed, 25 Nov 92 16:04:41 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*102 Intresset verkar stort för detta ämne - det är drygt 30 enskilda deltagare och 2 "distributionsdeltagare" f.n. Välkomna allihopa! I separata brev kommer följande dokument att skickas: * Kort historik över Internet-datorpost Ett försök att sammanfatta vad som hänt och det nuvarande läget på användar- och standardiseringsfronten. Tyvärr tillät inte tiden att göra det så utförligt som jag velat men det kan förstås förbättras efterhand, särskilt om jag får frågor och synpunkter. * MIME i Sverige, förslag A Princip: Specificera modifiering av UA (brevläs- och brevskrivnings- program) för nordiska behov och främja spridning av desamma. * MIME i Sverige, förslag B Princip: Slussa all svensk datorpost via programvara som konverterar till/från MIME. * Kort referat från mötet med Sunets tekniska referensgrupp, där främst förslag B dryftades. Läs, begrunda, kommentera! --- Peter Svanberg, NADA, KTH From psv@nada.kth.se Wed Nov 25 17:00:43 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA10738; Wed, 25 Nov 92 17:01:40 +0100 Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA10468; Wed, 25 Nov 92 17:00:43 +0100 Message-Id: <9211251600.AA10468@nada.kth.se> To: nordpost@nada.kth.se Subject: Historik och bakgrund In-Reply-To: <9211251504.AA06022@nada.kth.se> from "Peter Svanberg " "Wed, 25 Nov 92 16:04:41 +0100 " Date: Wed, 25 Nov 92 17:00:42 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*103 (Internet-mail-historik.txt1 A 921125 PSv) HISTORIK OCH AKTUELL SITUATION KRING INTERNET MAIL ================================================== Detta är en kort och ofullständig sammanfattning av bakgrund och fakta kring datorpost inom Internet. Kommentarer, rättelser, kompletteringar och frågor är välkomna! I BEGYNNELSEN: RFC 822 och RFC 821 Historien om datorpost i den form detta handlar om började i USA i början på 80-talet. Då fastställdes - för det dåvarande ARPANET, som numera har utvecklats till Internet - följande specifikationer: RFC 822 - Standard for the format of Arpa Internet text messages RFC 821 - Simple Mail Transfer Protocol (SMTP) Detta möjliggjorde standardiserad brevkommunikation. Dessa specifikationer utformades förstås efter amerikanska krav och behov, dvs. inget annat än teckenkoden ASCII (som inte innehåller andra bokstäver än A-Z) fick användas. På lägre nivå föreskrev man också i RFC 821 att endast sju av dom åtta bitarna i överförda oktetter får innehålla data - den åttonde biten ska nollställas. ICKE-AMERIKANSK ANVÄNDNING Ganska snart började andra länder använda datorpostsystem enligt RFC 822 och 821. Dom flesta länder i Europa behöver betydligt fler bokstäver än vad som finns i ASCII. Man har dock i många fall väl etablerade alternativa skrivsätt för "konstiga" bokstäver, till exempel ae, oe och ue för tyskans ä, ö och . Detta tillsammans med att man redan var van och luttrad av teckenfattigdom inom övrig datoranvändning gjorde att man på dom flesta håll nöjde sig med teckenrepertoaren i ASCII. I dom nordiska länderna har vi inte något etablerat och accepterat sätt att byta ut våra kära Å, Ä och Ö. Så fort man började skriva på svenska i datorer _måste_ dessa tecken finnas, något alternativ fanns knappast. Följdaktligen definierade vi tidigt en svensk version av ISO- standarden 646 (en sjubitskod där 10 tecken är utbytbara just för sådana ändamål). För denna standard specialändrades dom flesta terminaler och skrivare som såldes i Sverige. När vi började använda datorpost var det alltså självklart att använda svensk teckenkod även där. Men därmed bröt vi - om man ska vara riktigt noga, och det är somliga amerikaner - mot standarderna. ÅTTABITSTECKENKODER När åttabitskoder började dyka upp i Norden uppstod nya problem. Först i mindre skala med IBM-PC- och Macintosh-datorer, som via undermåliga program skickade ut brevtext kodade med sina egna teckenkoder. Detta blir dock alltmer ovanligt numera. I och med Latin-1-kodens spridning i Unix-världen uppstod större problem. Problemet att man faktiskt varken får skicka (enligt RFC:erna) eller kan förvänta sig att mottagaren kan hantera åttabitstecken, hanterades på olika sätt. I Sverige började vi (främst Dan Oscarsson i Lund) tidigt att experimentera med ett tillägg till SMTP-protokollet: frågan "ISOC " undersöker huruvida mottagaren kan hantera en viss angiven ISO-teckenkod. Om svaret blir något annat än OK så konverteras brevinnehållet till (okodad) sjubitsform, annars skickas brevet som det är. På Sun och hos andra amerikanska leverantörer valde man istället att ignorera förbudet i RFC 821 - man skickar brev med åttabitstecken utan att fråga, dvs. utan att veta något om huruvida mottagaren kan hatera dom eller inte. Resultatet blir att om mottagaren och _varje_ dator som brevet passerar på vägen till mottagaren är en Sun-dator eller någon annan dator vars programvara släpper igenom "höga" tecken, och om mottagaren använder samma teckenkod som avsändaren - då går allt bra. I alla andra fall går det "åt fanders", dvs brevinnehållet förstörs, oftast så att åäö blir edv vilket är näst intill oläsligt för svensk text. IETF UPPMÄRKSAMMAS På ett IETF-möte (IETF=Internet Engineering Task Force) någon gång under 1990 på en s.k. BOF-session ("Birds of a feather" - förutsätt- ningslöst idespånande) började man diskutera hur man _borde_ lösa problemen med "konstiga" tecken i datorpost. Detta ledde till att en arbetsgrupp bildades, vilket i IETF-sammanhang innebär att en brevlista startas som intresserade kan prenumerera på. Ganska snart kom man fram till att det fanns två olika delproblem som borde lösas oberoende av varandra: 1) Utökning av brevformatet så att man på ett bakåtkompatibelt sätt kan skicka annat än bara text med tecken från ASCII-teckenmängden. 2) Utökning av transportprotokollet SMTP så att man på ett bakåtkompatibelt sätt kan skicka brev innehållande åttabitstecken. Som ett resultat av det delades arbetsgruppen upp i två delar. Grupp 1 arbetade (efter _mycket_ diskussioner, > 10 MB brev) fram MIME (= RFC 1341) och RFC 1342 (om icke-ASCII brevhuvudfält, "headers"), som väntas bli Internet-standard under första halvåret 1993. Grupp 2 har nyligen (nov. 1992) på ett IETF-möte i Washington lyckats komma överens om "ESMTP", dvs. en utökning av SMTP-standarden för bl.a. åttabitstransport. MIME I SVERIGE Anledningen till att MIME-övergång är annorlunda för Norden än för USA och i viss mån för övriga Europa är att: * Vi _använder_ "konstiga" tecken flitigt, det gör man inte i USA. * Vi övergår inte från ASCII till Latin-1-kod utan från en blandning av ISO 646-kod och ASCII till Latin-1-kod. Det sistnämnda innebär exempelvis att ett omärkt brev i Sverige kan innehålla antingen text kodad med svensk sjubitskod eller text kodad med ASCII (t.ex. C-källkod) eller både och! --- Peter Svanberg From psv@nada.kth.se Wed Nov 25 17:07:48 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA13061; Wed, 25 Nov 92 17:08:07 +0100 Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12981; Wed, 25 Nov 92 17:07:48 +0100 Message-Id: <9211251607.AA12981@nada.kth.se> To: nordpost@nada.kth.se Subject: MIME i Sverige, f|rslag A In-Reply-To: <9211251600.AA10468@nada.kth.se> from "Peter Svanberg " "Wed, 25 Nov 92 17:00:42 +0100 " Date: Wed, 25 Nov 92 17:07:40 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*104 KTH 1992-10-05 Olle Järnefors Peter Svanberg TS-Data NADA 08-790 71 26 08-790 71 46 ojarnef@ psv@nada.kth.se admin.kth.se SAMMANSTÄLLNING AV IDEER OM MIME PÅ SUNET Problemet Inom kort har vi i värsta fall sju olika sätt att representera svenska bokstäver i datorpost på SUNET: - nationell 7-bitskod - illegal 8859-1 - MIME-brev transportkodade med Quoted-Printable-metoden - MIME-brev transportkodade med Base64 - MIME-brev innehållskodade med charset=mnemonic - illegal IBMPC-kodning - illegal Macintosh-kodning Tekniska möjligheter På grund av de amerikanska MIME-utvecklarnas bristande förståelse för de praktiska problemen med datorpost som bygger på nationella sjubitskoder är teckenkodshanteringen i MIME och RFC 1342 egenligen otillräcklig för nordiska behov. Den enda praktiska utvägen är att försöka kompensera för detta genom mer "intelligens" i datorbrevhanteraren. Det är det möjligheter av detta slag som vi ser: 1) Tillhandahåll flera alternativa konverteringar av tecken före visning på skärmen. Dessa konverteringar ska styras av tabeller som systemadministratör och användare lätt kan justera. Förvald konverteringsmetod bör vara att låta både höga Latin-1-åäö och låga svensk sjubits-åäö visas som åäö. På det viset kommer har man att ha ungefär samma situation som tidigare. Passar inte detta för ett visst brev, t.ex. ett brev som innehåller C-kod, ska användern kunna exekvera ett kommando "växla teckenkod" som då skriver om skärmen med koden ASCII/LA1. 2) Teckenkoden i inkomna brev som man bör sparar "normaliseras" till den teckenkod som används vid visningen, oavsett vad den var när brevet anlände. Motsvarande gäller för operationerna "cut (and paste)" och "forward". 3) När man skickar ett brev till mottagare i Norden ska under övergångstiden normalt Content-Type bli Multipart/Alternative. Den första delen av brevet, som inte ska ha någon explicit angiven Content-Type, ska innehålla brevets text konverterad till svensk 7-bitskod. Det är den del som mottagare med ännu ej MIME-anpassad UA ser först. Som sista mening brevtexten i den första delen läggs en kort varnande text in automatiskt, t.ex.: ---> Efter denna rad följer samma brevtext lagrat på annat sätt <--- Slutligen läggs ett sidbyte in (Ctrl-L) i den första delen av meddelandet. På detta sätt kommer många UA-program att stanna visningen efter varningstexten, och användaren får möjlighet att avbryta. En MIME-anpassad brevhanterare visar bara andra delen av brevet, innehåller den riktiga texten, normalt med Content-Type: Text/Plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-Printable MIME-brev utan särskild del med texten i svensk 7-bitskod bör skickas om man besvarar ett MIME-brev med en MIME-anpassad brevhanterare. 4) Alltför stor ökning av trafiken på grund av skickning av brev med dubblerat innehåll kan minskas om: a) UA-programmet kontrollerar formatet på ett brev man svarar på (reply) och anpassar svarsbrevets format efter det b) UA-program som uppdaterar användarens personliga register över datorpostadresser med ledning av adresser i inkommande brev utökas så att även uppgift om MIME-kunnighet lagras i registret med ledning av formatet på det senast inkomna brevet från en viss adress c) Användaren tillfrågas om andra alternativ då brevet är långt. Programmet bör förstås uppmärksamma om nya mottagare läggs till och i så fall ev. ändra format. 5) En användares verkliga namn kan inte längre tas direkt ur användardatabasen på t.ex. ett UNIX-system, eftersom det kan innehålla åttabitstecken (se nedan). 6) Det format för lagring av åttabitstecken i brevhuvudfältet som föreslagits (RFC 1342) är tyvärr oanvändbart under övergångstiden. Vi föreslår följande förfarande: a) Vi fortsätter att skriva åäö i rubrikraden (Subject) enligt svensk sjubitskod. MIME-modifierade UA-program i Sverige som används i en åttabitsmiljö ska alltså konvertera det användaren skriver i rubrikraden till sjubitstecken innan brevet skickas iväg, och ska konvertera inkommade brevs rubrikrad från svensk sjubitskod till den lokala åttabitskoden. (Brev skrivna på engelska innehåller sälla hakar och klamrar på rubrikraden.) b) Användarens fullständiga namn skrivs dubbelt i avsändar- och mottagarfälten, först en internationellt form, sedan den korrekta formen: From: Olle Jarnefors (=?ISO-8859-1?Q?Olle_J=E4rnefors?=) 7) De konverteringstabeller UA-programmet använder bör följa det system som beskrivs i ÅÄÖ-gruppens kommande slutrapport. Organisatoriska frågor Hur bör en strategi för övergång till MIME i SUNET se ut för att + besvären för datorpostanvändarna ska bli så små som möjligt, + dessa inte ska uppleva att datorpostfunktionen försämras jämfört med tidigare + övergångensperioden ska bli så kort som möjligt? Några ideer om vad SUNET skulle kunna göra som organisation för att övergången till MIME ska bli så snabb och smärtfri som möjligt: * Rekommendera senast ett visst datum alla övergår från att använda svensk sjubitskod eller programvara som skickar höga tecken utan förvarning till att använda MIME (och eventuellt en kommande 8-bitsutvidgning av SMTP-protokollet). * Inom ramen för SUNET-mail-projektet utarbeta en mer utförlig teknisk beskrivning på engelska för övergången till MIME på SUNET, som beskriver nuvarande teckenkodsproblem, hur MIME fungerar i stora drag, vilka krav vi ställer på MIME-kompatibla UA för användning i Sverige samt strategin för övergång till MIME inom SUNET. * Med alla medel påverka stora leverantörer typ Sun att så fort som möjligt ta fram produkter som klarar kraven i den tekniska beskrivningen. * Bidra till eller stimulera framtagning eller anpassning av MIME-kompatibla versioner av de vanligaste UA-programmen under de vanligaste operativsystemen. * Möjliggöra för dem som inte har några möjligheter att uppdatera sin programvara att skicka sin utgående datorpost till en speciell "gateway" som omvandlar den till MIME-korrekt format. (mime-sunet-ideer.txt1 A 921005 PSv) From psv@nada.kth.se Wed Nov 25 17:21:47 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA15938; Wed, 25 Nov 92 17:21:52 +0100 Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA15920; Wed, 25 Nov 92 17:21:47 +0100 Message-Id: <9211251621.AA15920@nada.kth.se> To: nordpost@nada.kth.se Subject: MIME i Sverige, f|rslag B In-Reply-To: <9211251607.AA12981@nada.kth.se> from "Peter Svanberg " "Wed, 25 Nov 92 17:07:40 +0100 " Date: Wed, 25 Nov 92 17:21:46 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*105 KTH 1992-10-06 A Olle Järnefors Peter Svanberg, TS-Data Patrik Fältström 08-790 71 26 NADA ojarnef@ 08-790 71 46,...6274 admin.kth.se psv@nada.kth.se, paf@... MIME I SVERIGE, SLUTSATSER EFTER DISKUSSION PÅ EUROPEN.SE-MÖTE I SALTSJÖBADEN 1992-10-06 Annat förslag till lösning på (några av) problemen med övergång till MIME i Sverige. Identifiera lämpliga "mailgateways" som alltid ska användas vid passage in och ut ur nätet. T ex kan nada.kth.se (Cyklop) ses som en sådan för Nadas del. Eventuellt kan också Swipnet inkluderas i detta system. Ordna registrering på något sätt så att en MTA i SUNET/MIME - dvs. en MTA i SUNET som modifierats enligt detta förslag - uppfattar alla andra MTA:er den kommunicerar som indelade i tre klasser: a) tillhörande SUNET/MIME b) tillhörande SUNET/äldre c) tillhörande "omvärlden" Om ett MIME-brev märkt Content-Type: Text/Plain; charset=ISO-8859-1 ska skickas till en SUNET/äldre-nod, så avlägsnas först de tre MIME-fälten, brevkroppen konverteras till svensk 7-bitskod och brevhuvudfält kodade enligt RFC 1342 konverteras på liknande sätt. Vid skickning till SUNET/äldre ska däremot brev av MIME-typen Content-Type: Text/Plain; charset=US-ASCII skickas vidare utan att ändras. Brev till SUNET/MIME och till omvärlden ska alltid gå igenom utan att ändras. Tänkbar utökning 1 Konvertering även åt andra hållet. Ett pre-MIME-brev som kommer från SUNET/äldre och ska till SUNET/MIME eller SUNET/äldre skulle kunna konverteras automatiskt till Content-Type: Text/Plain; charset=ISO-8859-1 inklusive teckenkodskonvertering av meddelandekropp och Subject:-rad. Fördelar: MIME-kompatibla UA:ar anslutna till SUNET/MIME skulle inte behöva specialfunktioner för att ta hand om pre-MIME-brev kodade med svensk 7-bitskod. Ändå skulle mottagare i SUNET/äldre slippa MIME-konstigheter i dessa brev och mottagare i omvärlden skulle inte märka någon skillnad alls. En SUNET/äldre-användare skulle också kunna skicka pre-MIME-brev kodade med US-ASCII till andra SUNET/äldre-användare, utan att problem uppstår. Nackdel: US-ASCII-brev från SUNET/äldre-användare, t.ex. brev innehållande C-kod eller engelsk text, till SUNET/MIME-användare blir förvanskade genom att hakparenteser etc. ersätts med svenska bokstäver. Tänkbar utökning 2 Ytterligare förslag: SUNET/MIME-MTA:erna skulle också kunna göra något åt höga tecken i inkommande brev, t.ex. tolka dem enligt ISO-8859-1 och konvertera på tillämpligt sätt beroende på om brevet konverteras till pre-MIME-brev eller till ett charset=ISO-8859-1-brev. Tänkbar utökning 3 - mer kontroversiell! Vissa typer av MIME-brev till en sådan nod, bland annat sådana som innehåller typen Image/*, återsänds till avsändaren med kommentaren Mottagaren av det brevet kan inte hantera MIME och kunde kunde inte ta emot hela innehållet i detta brev och mottagaren får ett nytt brev med förklaring och citat av hanterliga delar av brevet. Om detta förslag utvidgas till Nordunet, så måste p.g.a. att olika teckenkodskonverteringa behövs, de moderniserade MTA-erna kunna skilja mellan äldre svensk/finska och äldre dansk/norska system. Kvarstående frågetecken: Är ovanstående förutsättningar för identifiering möjliga att genomföra? Hur får vi fram "gateway"-programvara som utför konvertering på det sätt vi vill? Är detta en tekniskt lämplig lösning som har förutsättningar att fungera? --- Peter Svanberg From psv@nada.kth.se Wed Nov 25 17:25:37 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA16302; Wed, 25 Nov 92 17:25:44 +0100 Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA16264; Wed, 25 Nov 92 17:25:37 +0100 Message-Id: <9211251625.AA16264@nada.kth.se> To: nordpost@nada.kth.se Subject: Referat fr}n SUNETs tekniska referensgrupp In-Reply-To: <9211251621.AA15920@nada.kth.se> from "Peter Svanberg " "Wed, 25 Nov 92 17:21:46 +0100 " Date: Wed, 25 Nov 92 17:25:36 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*106 1992-10-06 kl 22.13 Peter Svanberg Referat från MIME-diskussion på möte med SUNETS tekniska referensgrupp ====================================================================== (Arlanda den 6 oktober 1992) Jag redogjorde kort för vårt förslag. Det mötte spontant negativa reaktioner från framför allt Gunnar Lindberg, Chalmers. Övriga var mer "försiktigt positiva", särskilt UDAC-mannen (Sven Arvidson?) som var med i Uppsala . Han sa att han "fått hicka" när han läste vårt föregående förslag och tyckte detta var mycket bättre. Synpunkter och kommentarer: 1) Man vill kunna styra detta på personnivå - även om min systemadministratör är slö så _ska_ jag kunna få MIME-brev orörda. Detta kan vara ett problem. Normalt måste det förmodligen på postdomännivå bestämmas huruvida den domänen ska anses kunna klara av MIME eller inte. Problemen kan minskas något om man implementerar något lätt installerbart filter som på Sendmail- eller UA-nivå MIME-skalar brev före leverans eller UA-start. Det skulle underlätta för mindre institutioner med MIME-behov för några användare att kunna påstå utåt att dom är MIME-kunniga men köra filtret för alla utom dom MIME-intresserade. Även Conversion-fältet kan hjälpa till i detta fall, men bara för för mottagaren kända och upplysta avsändare. 2) Man kan få problem med att få MTA-er får valdigt mycket att göra, eftersom all post måste gå via dom för konvertering. Situationen i England angavs som avskräckande exempel. Om vi inom Sunet ser till att åtminstone varje högskoleregion har en MTA så torde inte detta bli något stort problem. 3) Vi riskerar att bygga fast oss i en specialhantering lokalt hos oss i Sverige/Norden på ett sätt som strider mot filosofin med MX-records. Bemöttes med "Nja, tycker vi inte om detta kan vi ju alltid stänga av det och får det då inte sämre än förut." Fullt så enkelt är det väl inte - vi kanske då är in en situation där SUNET är fullt av MIME-skickande UA-program så att en avstängning skulle leda till ett ramaskri från alla icke-MIME-are. Detta bör tänkas över mera. Det formella beslutet i referensgruppen blev att det uppdrogs åt Martin Vendell, UDAC att försöka kostnadsberäkna en sådan MTA-ändring, och ev. också det enkla filterprogramet. --------- Har jag glömt något, ni som var där? --- Peter Svanberg From nordpost-request@nada.kth.se Wed Nov 25 18:59:21 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA22160; Wed, 25 Nov 92 18:59:25 +0100 Received: from ifi.uio.no by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA22143; Wed, 25 Nov 92 18:59:21 +0100 Received: from gyda.ifi.uio.no by ifi.uio.no with SMTP id ; Wed, 25 Nov 1992 18:59:15 +0100 Received: by gyda.ifi.uio.no ; Wed, 25 Nov 1992 18:59:15 +0100 From: Erik Naggum Message-Id: <19921125.005@erik.naggum.no> Date: 25 Nov 1992 18:59:14 +0100 To: nordpost@nada.kth.se In-Reply-To: <9211251504.AA06022@nada.kth.se> (Wed, 25 Nov 92 16:04:41 +0100) Subject: Re: Nu k|r vi ig}ng! Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*107 Administrivia: Jeg vil gjerne ha mail sendt til , istedetfor . For|vrig er naggum.uu.no ikke lenger offisielt riktig. Registrert domene er naggum.no. (Sender dette til alle, fordi s} mange p} denne listen trolig husker det gamle domenet mitt.) Om headere i mail til listen, argumenter og forslag til diskusjon: Vennligst ikke |delegg (skriv over) "Reply-To" feltet n}r det postes til listen, eller |delegg andre headere i BITNET-stil. I IBM-verdenen finnes det vanligvis mulighet for } svare til From og til Reply-To som egne kommandoer, og svar til To og CC er ikke s} vanlig. Om dette kom f|r eller etter Eric Thomas' velkjente (og forhatte) LISTSERV, vet jeg ikke, men LISTSERV bruker ihvertfall dette som argumentasjon for } |delegge headere. Jeg har m}ttet implementere en "IBM-mailer" som jeg bruker n}r jeg svarer p} BITNET mail. Internet mail bruker From og Reply-To om avsender, og To og CC om mottager. Svar tilbake til kun avsender skal g} til Reply-To, hvis den finnes, eller From, hvis ikke. Svar til alle mottagere skal g} til Reply-To, eller From, og To og CC. Jeg ser ogs} at en Errors-To header er lagt til, og at Return-Path ikke er det samme som denne, men det samme som From! Dette kan da umulig v{re hensiktsmessig? Jeg foresl}r f|lgende skjematiske funksjon for en mailing list exploder (i mangel av et "nordisk" uttrykk :-): Innkommende: Return-Path: A From: B Reply-To: C To: D Der D er mailinglistens adresse. Utg}ende: Return-Path: D-request From: B Reply-To: C To: D Jeg mener faktisk at "-request" b|r brukes over hele verden, fremfor at man m} vite i hvilket land listen listen har base. F.eks. har jeg allerede glemt hva det var nordpost-request heter. Jeg har mer enn nok med } f} lest posten min om jeg ikke skal kaste bort tid p} } holde vedlike et register over hvor jeg skal sende administrative meldinger. (Legg gjerne til en header, kanskje "Administrivia-To"?) Ved eventuelle sekund{re mottagere (To, CC), ville det v{rt utrolig kjekt om disse kunne fjernes fra mottagerlisten hvis de ogs} er med p} mailing-listen, for } redusere headere og duplikater, men dette er ikke en helt triviell oppgave. De fleste mailere jeg testet dette p} nettopp, ville gitt headere To: nordpost (fra Reply-To) CC: nordpost (fra To) Det er vel neppe i v}rt arbeidsomr}de, men det kunne v{rt kjekt om vi kunne skrevet ned noe om dette, n}r vi f|rst sier noe om hvordan UA'er skal oppf|re seg med MIME. Slik kunne vi l|se flere verdensproblemer p} en enkel m}te. :-) Er det ellers noen motforestillinger om at jeg skriver p} norsk? Siden engelsk er v}rt moderne "nynorsk", er det ikke noe problem } skrive p} engelsk hvis folk heller vil det. Jeg leser godt svensk, for|vrig, men skriver det d}rlig. -- Erik Naggum : ISO 8879 SGML : +47 295 0313 : ISO 10744 HyTime : : ISO 10646 UCS : Memento, terrigena. : ISO 9899 C : Memento, vita brevis. From nordpost-request@nada.kth.se Wed Nov 25 21:19:15 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA00718; Wed, 25 Nov 92 21:19:18 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA00702; Wed, 25 Nov 92 21:19:15 +0100 Received: by dkuug.dk id AA21233 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Wed, 25 Nov 1992 21:19:08 +0100 Date: Wed, 25 Nov 1992 21:19:08 +0100 From: Keld J|rn Simonsen Message-Id: <199211252019.AA21233@dkuug.dk> To: nordpost@nada.kth.se Subject: Re: Referat fr}n SUNETs tekniska referensgrupp X-Charset: ASCII X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*108 I agree wit Erik Naggum that you should rather use nordmail-request as the sender - instead of nordmail-anmodan - which is very Swedish. Keld From psv@nada.kth.se Wed Nov 25 21:51:34 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA01539; Wed, 25 Nov 92 21:51:38 +0100 Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA01522; Wed, 25 Nov 92 21:51:34 +0100 Message-Id: <9211252051.AA01522@nada.kth.se> To: nordpost@nada.kth.se Subject: Re: Referat fr}n SUNETs tekniska referensgrupp In-Reply-To: <199211252019.AA21233@dkuug.dk> from "Keld J|rn Simonsen " "Wed, 25 Nov 1992 21:19:08 +0100 " Date: Wed, 25 Nov 92 21:51:33 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*109 Citat ur brev från: Keld J|rn Simonsen > I agree wit Erik Naggum that you should rather use nordmail-request > as the sender - instead of nordmail-anmodan - which is very Swedish. Jag har redan fått skäll för detta och ber härmed att få meddela: * nordpost-request har hela tiden fungerat parallellt * Att införa nordpost-anmodan var dumt och jag ska inte använda det mer. Nog om detta. From psv@nada.kth.se Wed Nov 25 22:59:34 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA05020; Wed, 25 Nov 92 22:59:38 +0100 Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA05003; Wed, 25 Nov 92 22:59:34 +0100 Message-Id: <9211252159.AA05003@nada.kth.se> To: nordpost@nada.kth.se Subject: Re: Nu k|r vi ig}ng! In-Reply-To: <19921125.005@erik.naggum.no> from "Erik Naggum " "25 Nov 1992 18:59:14 +0100 " Date: Wed, 25 Nov 92 22:59:33 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*110 Citat ur brev från: Erik Naggum > > Jeg vil gjerne ha mail sendt til , istedetfor > . Fixat. > Om headere i mail til listen, argumenter og forslag til diskusjon: > Vennligst ikke ödelegg (skriv over) "Reply-To" feltet når det postes til > listen, eller ödelegg andre headere i BITNET-stil. Görs ej (se nedan), däremot läggs det till om det saknas. > Jeg ser også at en Errors-To header er lagt til, og at Return-Path ikke > er det samme som denne, men det samme som From! Dette kan da umulig > väre hensiktsmessig? Följande görs (beslutat efter noggrannt studium av RFC:er m.m.): Return-Receipt-To: Tas bort (diskutabelt men är väl oftast ett misstag och olämpligt?) Errors-To: Läggs till om sådant fält saknas Sender: Läggs till, ev. befintligt fält byts till Old-... X-Mailing-List: * Läggs till (befintligt fält som Sender) (Med hjälp av detta fält kan man förhindra "loopar" och förenkla sortering av inkommande brev. Sekvensnumret gör det också lätt att se om man missat något inlägg och kan t.o.m. användas som ett bekvämare sätt att referera till debattinlägg än t.ex. Message-Id.) Reply-To: (som ibland inflyttas i Return-Path. Detta var felaktigt , ändrat nu.) Det är dock som vanligt problem med att SMTP-avsändaren inte går att ändra vid "lokal skickning" men det kommer förmodligen att ordna sig när vi nästa vecka börjar använda en separat postdator. (Finns det något enkelt knep att komma förbi detta, förutom att göra sig till "trusted user" för Sendmail?) > Ved eventuelle sekundäre mottagere (To, CC), ville det värt utrolig > kjekt om disse kunne fjernes fra mottagerlisten hvis de også er med på > mailing-listen, for å redusere headere og duplikater, men dette er ikke > en helt triviell oppgave. Det vore bra, har antecknat. Eftersom hantering av brevhuvudfält vid brevlisthantering inte är något med speciella nordiska aspekter och inte hör till det ämne jag bjöd in för att diskutera föreslår jag att ev. kommentarer till detta inlägg helst görs i personliga brev till mig och Erik. Intresserade kan få information från mig om en brevlista om just brevlisthantering som startade för någon månad sedan. > Er det ellers noen motforestillinger om at jeg skriver på norsk? Jag tycker det går utmärkt att läsa och förstå vad du skriver! --- Peter Svanberg, Nada, KTH From owner-nordpost@nada.kth.se Thu Nov 26 08:01:37 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24201; Thu, 26 Nov 92 08:01:40 +0100 Received: from corax.UDAC.UU.SE by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24182; Thu, 26 Nov 92 08:01:37 +0100 Received: from alba.udac.uu.se by corax.udac.uu.se with SMTP id AA19544 (5.65+bind 1.7+ida 1.4.2/IDA-1.4.2 for nordpost@nada.kth.se); Thu, 26 Nov 92 08:01:37 +0100 Received: by alba.UDAC.UU.SE id AA02115 (5.67a8/IDA-1.5 for nordpost@nada.kth.se); Thu, 26 Nov 1992 08:01:36 +0100 Date: Thu, 26 Nov 1992 08:01:36 +0100 From: Martin Wendel Message-Id: <199211260701.AA02115@alba.UDAC.UU.SE> To: nordpost@nada.kth.se Subject: Re: Referat fr}n SUNETs tekniska referensgrupp X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*111 > Det formella beslutet i referensgruppen blev att det uppdrogs }t > Martin Vendell, UDAC att f|rs|ka kostnadsber{kna en s}dan MTA-{ndring, > och ev. ocks} det enkla filterprogramet. > --------- > > Har jag gl|mt n}got, ni som var d{r? M|jligen inte, dock {r mitt namn felstavat: Martin Wendel skall det vara. ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From owner-nordpost@nada.kth.se Thu Nov 26 11:40:00 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA10945; Thu, 26 Nov 92 11:40:03 +0100 Received: from thalamus.sans.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA10925; Thu, 26 Nov 92 11:40:00 +0100 Received: by thalamus.sans.kth.se (5.65c8/SANS-1.0) id AA25346; Thu, 26 Nov 1992 11:40:00 +0100 Date: Thu, 26 Nov 1992 11:40:00 +0100 From: Orjan Ekeberg Message-Id: <199211261040.AA25346@thalamus.sans.kth.se> To: nordpost@nada.kth.se In-Reply-To: Peter Svanberg's message of Wed, 25 Nov 92 16:04:41 +0100 <9211251504.AA06022@nada.kth.se> Subject: MIME i Sverige Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*112 Min spontana reaktion n{r jag l{st igenom de f|rslag som presenterats i denna diskussion {r att alltf|r mycket resurser {gnas }t att f|rs|ka beh}lla den gamla och i strikt mening illegala nationella 7-bits kodningen (ISO-646) vid brev|verf|ring. Jag tycker att det {r viktigt att skilja p} tv} faser: 1) \verg}ngen fr}n dagens blandade halvstandarder, som ofta fungerar bra lokalt i den egna lilla v{rlden med kommunikation mellan likartade datorer, till en fungerande gemensam standard. 2) "Steady-State"-l|snigen. Eftersom MIME tycks bli den internationella standarden och utan alltf|r mycket konstigheter klarar v}ra svenska tecken s} {r det v{l uppenbart att 2) {r en total {verg}ng till MIME. Min tolkning av detta {r inte att alla system ska g} |ver till Latin-1 utan att alla som s{nder och tar emot brev |ver SUNET/Internet vid behov konverterar fr}n/till lokala "standarder" (Mac, PC, ...) s} att allt ut}t sett {r enligt MIME-standarden. Syftet med fas 1) blir d} enligt min mening inte att underl{tta f|r de installationer som vill forts{tta enligt gamla icke-standarder utan att aktivt underl{tta |verg}ngen f|r alla. M}nga system- administrat|rer arbetar (helt riktigt i de flesta fall) enligt principen att man r|r ingenting som inte inneb{r en m{rkbar f|rb{ttring. Genom att bygga upp ett system av konverterings- datorer (f|rslag B) eller tvinga alla som inf|r MIME att ha special- programvara f|r att dubbels{nda brev (f|rslag A) permamentas en i l{ngden oh}llbar situation. Ett f|rsta steg f|r att underl{tta |verg}ngen skulle kunna vara att ordna modifieringar till sendmail (Unix) och motsvarande SMTP-pratande program till andra system som klarar av att skala av och s{tta p} transportkodningen "Quoted-Printable". N{sta steg skulle kunna vara att f} system som inte har Latin-1 som intern standard (Mac, PC,...) att konvertera till/fr}n "charset=ISO-8859-1" i l{mpligt steg. Jag inser att det alltid kommer att finnas system d{r det {r om|jligt att f} in {ndringar i systemprogramvaran (observera dock att detta inte {r lokalt svenska {ndringar), t.ex. n{r alla systemutvecklare omkommit och k{llkoden inklusive alla skyddskopior brunnit upp. F|r s}dana undantag kan man t{nka sig en central "gateway" som tar emot brev adresserade till dessa maskiner, konverterar och sedan skickar direkt till den udda maskinen. Det viktiga {r dock att de som g}tt |ver till MIME inte ska beh|va drabbas. Vi vill absolut inte ha en situation d{r moderna MIME-anpassade system ska beh|va specialanpassas lokalt f|r Sverige. \rjan From owner-nordpost@nada.kth.se Thu Nov 26 13:32:52 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA21398; Thu, 26 Nov 92 13:32:55 +0100 Received: from corax.UDAC.UU.SE by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA21382; Thu, 26 Nov 92 13:32:52 +0100 Received: from alba.udac.uu.se by corax.udac.uu.se with SMTP id AA20404 (5.65+bind 1.7+ida 1.4.2/IDA-1.4.2 for nordpost@nada.kth.se); Thu, 26 Nov 92 13:32:51 +0100 Received: by alba.UDAC.UU.SE id AA02451 (5.67a8/IDA-1.5 for nordpost@nada.kth.se); Thu, 26 Nov 1992 13:32:50 +0100 Date: Thu, 26 Nov 1992 13:32:50 +0100 From: Martin Wendel Message-Id: <199211261232.AA02451@alba.UDAC.UU.SE> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*113 Orjan Ekeberg skriver: > > Min spontana reaktion n{r jag l{st igenom de f|rslag som presenterats > i denna diskussion {r att alltf|r mycket resurser {gnas }t att > f|rs|ka beh}lla den gamla och i strikt mening illegala nationella > 7-bits kodningen (ISO-646) vid brev|verf|ring. (Trots det s} anv{nder vi den ;-) Jag har inget emot att vara illegal s} l{nge det sker lokalt och att bara "legala" brev skickas ut utanf|r det lokala n{tet. Det {r p} detta s{tt jag har satt upp de mailmaskiner jag administrerar h{r p} Uppsala universitet. De anv{nder Keld Simonsens eminenta teckenkonverterings- rutiner som finns i senare releaser av IDA-sendmail. Ca 500 blandade Mac, PC och unixburkar k|r 8bitars mail lokalt utan teckenproblem. > Jag tycker att det {r viktigt att skilja p} tv} faser: > 1) \verg}ngen fr}n dagens blandade halvstandarder, som ofta fungerar > bra lokalt i den egna lilla v{rlden med kommunikation mellan > likartade datorer, till en fungerande gemensam standard. > 2) "Steady-State"-l|snigen. > > Eftersom MIME tycks bli den internationella standarden och utan > alltf|r mycket konstigheter klarar v}ra svenska tecken s} {r det > v{l uppenbart att 2) {r en total {verg}ng till MIME. Min tolkning > av detta {r inte att alla system ska g} |ver till Latin-1 utan > att alla som s{nder och tar emot brev |ver SUNET/Internet vid > behov konverterar fr}n/till lokala "standarder" (Mac, PC, ...) s} > att allt ut}t sett {r enligt MIME-standarden. Inst{mmer. (En reflektion: Gissningsvis {r antalet personer som anv{nder CodePage437 tiofalt fler {n de som anv{nder latin-1. Likv{l pratas det st{ndigt p} n{tet om att |verg} till latin-1 som n{tstandard. Rimligare vore i st{llet att |verg} till ISO10646 n{r den blir f{rdig, eller min privata }sikt att anv{nda MNEMONIC i v{ntan p} ISO10646. Tyv{rr finns ingen av dessa med i MIME idag s} vi f}r v{l h}llas med ISO8859) > Syftet med fas 1) blir d} enligt min mening inte att underl{tta f|r > de installationer som vill forts{tta enligt gamla icke-standarder > utan att aktivt underl{tta |verg}ngen f|r alla. M}nga system- > administrat|rer arbetar (helt riktigt i de flesta fall) enligt > principen att man r|r ingenting som inte inneb{r en m{rkbar > f|rb{ttring. Genom att bygga upp ett system av konverterings- > datorer (f|rslag B) eller tvinga alla som inf|r MIME att ha special- > programvara f|r att dubbels{nda brev (f|rslag A) permamentas en i > l{ngden oh}llbar situation. F|rslag A, {r enligt min mening f|rkastligt eftersom det inneb{r att efterhand som fler och fler k|r MIME m}ste fler och fler brev konverteras till Multipart/Alternative f|r att ta h{nsyn till den minskande skara som inte k|r MIME. Dvs, ju mindre behov desto st|rre arbete. F|rslag B, fungerar ju tv{rtom. D} blir det initialt ett stort konverterings- arbete som avtar efterhand som fler k|r MIME. Slutligen, n{r MIME {r "ensam" standard f|r mail, kan de s.k. konverterings-gatewayarna anv{ndas endast d{r det beh|vs. Man f}r t{nka p} att m}nga {r helt leverant|rsberoende n{r det g{ller mailprogramvara. Jag gissar att det dr|jer l{nge innan exempelvis cc-Mail eller MS-Mail k|r MIME, {n mindre den gatewayprogramvara till SMTP som finns. > Ett f|rsta steg f|r att underl{tta |verg}ngen skulle kunna vara att > ordna modifieringar till sendmail (Unix) och motsvarande SMTP-pratande > program till andra system som klarar av att skala av och s{tta p} > transportkodningen "Quoted-Printable". N{sta steg skulle kunna vara > att f} system som inte har Latin-1 som intern standard (Mac, PC,...) > att konvertera till/fr}n "charset=ISO-8859-1" i l{mpligt steg. Som Peter Svanberg n{nmde i referatet fr}n m|tet med SUNETs tekniska referensgrupp, har jag f}tt i uppdrag att komma med ett kostnadsf|rslag p} just detta. Jag har gjort ett f|rslag, tillsammans med min chef, som {r skickat till Hans Wallberg. > Jag inser att det alltid kommer att finnas system d{r det {r > om|jligt att f} in {ndringar i systemprogramvaran (observera > dock att detta inte {r lokalt svenska {ndringar), t.ex. n{r > alla systemutvecklare omkommit och k{llkoden inklusive alla > skyddskopior brunnit upp. F|r s}dana undantag kan man t{nka sig > en central "gateway" som tar emot brev adresserade till dessa > maskiner, konverterar och sedan skickar direkt till den udda > maskinen. Det viktiga {r dock att de som g}tt |ver till MIME > inte ska beh|va drabbas. Vi vill absolut inte ha en situation > d{r moderna MIME-anpassade system ska beh|va specialanpassas lokalt > f|r Sverige. Oavsett systemutvecklarnas h{lsa kan de vara helt ointresserade av att |verg} till MIME. Det {r helt klart n|dv{ndigt med en MIME\ickeMIME-gateway. ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From psv@nada.kth.se Thu Nov 26 13:53:11 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA22524; Thu, 26 Nov 92 13:53:21 +0100 Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA22500; Thu, 26 Nov 92 13:53:11 +0100 Message-Id: <9211261253.AA22500@nada.kth.se> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige In-Reply-To: <199211261232.AA02451@alba.UDAC.UU.SE> from "Martin Wendel " "Thu, 26 Nov 1992 13:32:50 +0100 " Date: Thu, 26 Nov 92 13:53:10 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*114 Citat ur brev från: Martin Wendel > Som Peter Svanberg n{nmde i referatet fr}n m|tet med SUNETs tekniska > referensgrupp, har jag f}tt i uppdrag att komma med ett kostnadsf|rslag > p} just detta. Jag har gjort ett f|rslag, tillsammans med min chef, som > {r skickat till Hans Wallberg. Finns det något som hindrar att det förslaget publiceras i detta forum? Det vore mycket intressant tycker jag. Innehåller det någon specifikation på vad programvaran måste klara av? Det är viktigt att den är väl genomtänkt. > > Jag inser att det alltid kommer att finnas system d{r det {r > > om|jligt att f} in {ndringar i systemprogramvaran (observera > > dock att detta inte {r lokalt svenska {ndringar), t.ex. n{r > > alla systemutvecklare omkommit och k{llkoden inklusive alla > > skyddskopior brunnit upp. > : > : > Oavsett systemutvecklarnas h{lsa kan de vara helt ointresserade av att > |verg} till MIME. Det {r helt klart n|dv{ndigt med en MIME\ickeMIME-gateway. Tyvärr behöver det inte alls vara så extremt som Örjan beskriver. Väldigt många (dom flesta?) kommersiella Unix-ställen verkar ha som princip att inte använda någon annan programvara än den som leverantören förser dom med. Alltså hjälper det inte dom om _vi_ fixar programvara. Vi måste också påverka leverantörerna att utveckla MIME-program. --- Peter Svanberg, Nada, KTH From paf@nada.kth.se Thu Nov 26 14:27:02 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA26842; Thu, 26 Nov 92 14:27:11 +0100 Received: from sysman.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA26825; Thu, 26 Nov 92 14:27:02 +0100 Received: by sysman.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA07894; Thu, 26 Nov 92 14:27:01 +0100 Date: Thu, 26 Nov 1992 14:16:20 +0100 (MET) From: Patrik Faltstrom Subject: Re: MIME i Sverige To: nordpost@nada.kth.se In-Reply-To: <199211261232.AA02451@alba.UDAC.UU.SE> Message-Id: Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*115 On Thu, 26 Nov 1992, Martin Wendel wrote: > F|rslag B, fungerar ju tv{rtom. D} blir det initialt ett stort konverterings- > arbete som avtar efterhand som fler k|r MIME. Slutligen, n{r MIME {r "ensam" > standard f|r mail, kan de s.k. konverterings-gatewayarna anv{ndas endast d{r > det beh|vs. Man f}r t{nka p} att m}nga {r helt leverant|rsberoende n{r det > g{ller mailprogramvara. Jag gissar att det dr|jer l{nge innan exempelvis > cc-Mail eller MS-Mail k|r MIME, {n mindre den gatewayprogramvara till SMTP > som finns. Det är inte i programvaran för tex MS-Mail som MIME ska hanteras utan i bryggprogramvaran. Det finns ingen anledning att kräva att MS-Mail internt (eller cc-Mail för den delen) ska hantera MIME. Dessa program har ett internt format som fungerar. Däremot kan man kräva att den SMTP-bryggprogramvara som används när brev ska ut från tex MS-Mail till Internet ska packa och koda brev och "attachments" enligt MIME-format och inget annat. Detta har f.ö. redan Microsoft (i sverige) lovat mig är "på väg" i deras SMTP-brygga för MS-Mail. paf From owner-nordpost@nada.kth.se Thu Nov 26 15:38:14 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA02892; Thu, 26 Nov 92 15:38:19 +0100 Received: from corax.UDAC.UU.SE by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA02873; Thu, 26 Nov 92 15:38:14 +0100 Received: from alba.udac.uu.se by corax.udac.uu.se with SMTP id AA20754 (5.65+bind 1.7+ida 1.4.2/IDA-1.4.2 for nordpost@nada.kth.se); Thu, 26 Nov 92 15:38:13 +0100 Received: by alba.UDAC.UU.SE id AA02476 (5.67a8/IDA-1.5 for nordpost@nada.kth.se); Thu, 26 Nov 1992 15:38:12 +0100 Date: Thu, 26 Nov 1992 15:38:12 +0100 From: Martin Wendel Message-Id: <199211261438.AA02476@alba.UDAC.UU.SE> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*116 Peter Svanberg skriver: > > Citat ur brev fr}n: Martin Wendel > > > Som Peter Svanberg n{nmde i referatet fr}n m|tet med SUNETs tekniska > > referensgrupp, har jag f}tt i uppdrag att komma med ett kostnadsf|rslag > > p} just detta. Jag har gjort ett f|rslag, tillsammans med min chef, som > > {r skickat till Hans Wallberg. > > Finns det n}got som hindrar att det f|rslaget publiceras i detta > forum? Det vore mycket intressant tycker jag. Inneh}ller det n}gon > specifikation p} vad programvaran m}ste klara av? Det {r viktigt > att den {r v{l genomt{nkt. Nej, det finns inga hinder. F|rslaget var ganska kortfattat och ej speciellt tekniskt specificerat. Jag kan dock komma med en kortfattad teknisk specifikation h{r: Principen {r att ett godtyckligt MIME-brev skall kunna konverteras till icke-MIME (rfc822), samt det motsatta. Icke-MIME-brev anses inneh}lla text och/eller uuencodedad eller binhexad data. Det g}r inte att bara ta h{nsyn till text eftersom en hel del mail inneh}ller paketerad bin{rkod. Konvertering fr}n MIME till text kan vara till godtyckligt 8bitars teckenset (samma funktionalitet som i nuvarande IDA-sendmail), eller till 7bitars US-ASCII eller ISO646-SE. Konvertering fr}n text till MIME kan vara fr}n godtyckligt 8bitars eller 7bitars teckenset till f|rst Latin1 och vid behov Quoted-Printable (eller Base64 enligt rfc1341). En kombination av ren 8bitars textkonvertering enligt BIT8 (Keld Simonsen) i IDA-sendmail (ej destruktiv konvertering) plus samma teckenkonvertering som i "ISOC"-sendmail (Dan Oskarssons) fr}n 8 till 7 bitar (destruktiv konvertering). Konvertering av kodad icke-text data har tre kodningsformat: MIME:s Base64, uuencode och Binhex. Programvaran skall kunna konvertera mellan dessa tre. Vissa MIME-format har ingen inneb|rd i vanliga mail. Bla m}ste formatet Multipart/Parallell betraktas som Multipart/Mixed vid konvertering fr}n MIME. Samma g{ller f|r Message/External-Body som f|r konverteras till ett meddelande. Stora problem {r det med typen Message/Partial som antagligen m}ste l{mnas som det {r. "Vanliga" brev med text och bin{rkod konverteras till Multipart/Mixed. Image, Audio, Video och Application som {r kodat i Base64 betraktas som bin{rkod och konverteras till uuencode eller binhex. Eftersom jag jobbat en hel del med IDA-sendmail och {r ganska v{l f|rtrogen med hur det fungerar k{nns det naturligt att anv{nda det som bas. Sendmail torde ocks} vara den mest anv{nda centrall|sningen f|r mail, och borde ocks} d{rf|r vara den l{mpligaste basprogramvaran. Det blir ett ganska omfattande kodningsarbete f|r att f} till all funktionalitet. Eftersom jag r{knar med att vissa MIME-gateways kommer att vara ganska h}rt belastade med MIME-konverteringar g{ller det att optimera konverteringsarbetet. Detta skall h}llas i }tanke. En MTA fungerar i princip s} h{r: Ett brev kommer in och skrivs ner p} disken. MTA:n beslutar sig f|r vart det skall skickas, l{ser brevet fr}n disk och skickar iv{g det. Brevet mellanlandar allts} p} disken. En ide kan vara att processa brevet medan det ligger p} disken. Detta inneb{r en hel del arbete med att ta reda p} inkommande format, samt vilket utg}ende format som skall anv{ndas. Ganska mycken I/O mot disken. En b{ttre ide {r att unders|ka brevet medan det kommer in till MTA:n. D} blir utg}ende format ganska givet, eftersom vid iv{gskickandet vet man vilket format det skall s{ndas i. Konverteringen sker vid iv{g- skickandet. Ingen extra I/O mot disken men ungef{r samma CPU-arbete som i f|reg}ende metod. Dessutom l{gger man till funtionaliteten av mailertable som anv{nds f|r att strukturera upp vilka mail-paths som skall ha vilket format. Ett alternativ till detta {r att definiera upp MX f|r MIME.Inst.Domain.SE och l}ta dessa styra. Personligen tror jag dock mer p} mailertable- alternativet. En grund-mailertable f|r hela landet kan ju ocks} distribureras. > > > Jag inser att det alltid kommer att finnas system d{r det {r > > > om|jligt att f} in {ndringar i systemprogramvaran (observera > > > dock att detta inte {r lokalt svenska {ndringar), t.ex. n{r > > > alla systemutvecklare omkommit och k{llkoden inklusive alla > > > skyddskopior brunnit upp. > > : > > : > > Oavsett systemutvecklarnas h{lsa kan de vara helt ointresserade av att > > |verg} till MIME. Det {r helt klart n|dv{ndigt med en MIME\ickeMIME-gateway. > > Tyv{rr beh|ver det inte alls vara s} extremt som \rjan beskriver. > V{ldigt m}nga (dom flesta?) kommersiella Unix-st{llen verkar ha som > princip att inte anv{nda n}gon annan programvara {n den som > leverant|ren f|rser dom med. Allts} hj{lper det inte dom om _vi_ fixar > programvara. Vi m}ste ocks} p}verka leverant|rerna att utveckla > MIME-program. Tycker jag ocks}. Det tyngsta argumentet {r att helt enkelt |verg} till MIME och kr{va att leverant|rernas program skall passa in i den befintliga milj|n. Nathaniel Borenstein p}st}r att bla SUN, Next och Z-mail jobbar p} en MIME-UA, om det st{mmer och dessa sl{pps kommer pressen att bli {n st|rre p} leverant|rerna. ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From owner-nordpost@nada.kth.se Thu Nov 26 19:03:45 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA20703; Thu, 26 Nov 92 19:03:49 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA20687; Thu, 26 Nov 92 19:03:45 +0100 Received: by dkuug.dk id AA29902 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Thu, 26 Nov 1992 19:03:42 +0100 Date: Thu, 26 Nov 1992 19:03:42 +0100 From: Keld J|rn Simonsen Message-Id: <199211261803.AA29902@dkuug.dk> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige X-Charset: ASCII X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*117 > Gissningsvis {r antalet personer som anv{nder CodePage437 tiofalt fler > {n de som anv{nder latin-1. Likv{l pratas det st{ndigt p} n{tet om att > |verg} till latin-1 som n{tstandard. Rimligare vore i st{llet att |verg} > till ISO10646 n{r den blir f{rdig, eller min privata }sikt att anv{nda > MNEMONIC i v{ntan p} ISO10646. Tyv{rr finns ingen av dessa med i MIME > idag s} vi f}r v{l h}llas med ISO8859) MNEMONIC er tilladt i MIME, jfr RFC 1341 og RFC 1345. DKnets tegns{tsgruppe har besluttet at vi vil k|re Mnemonic i Danmark. Keld From owner-nordpost@nada.kth.se Thu Nov 26 19:10:45 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA21054; Thu, 26 Nov 92 19:10:52 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA21038; Thu, 26 Nov 92 19:10:45 +0100 Received: by dkuug.dk id AA00238 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Thu, 26 Nov 1992 19:10:43 +0100 Date: Thu, 26 Nov 1992 19:10:43 +0100 From: Keld J|rn Simonsen Message-Id: <199211261810.AA00238@dkuug.dk> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige X-Charset: ASCII X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*118 > Det {r inte i programvaran f|r tex MS-Mail som MIME ska hanteras utan i > bryggprogramvaran. Det finns ingen anledning att kr{va att MS-Mail > internt (eller cc-Mail f|r den delen) ska hantera MIME. Dessa program har > ett internt format som fungerar. > > D{remot kan man kr{va att den SMTP-bryggprogramvara som anv{nds n{r brev > ska ut fr}n tex MS-Mail till Internet ska packa och koda brev och > "attachments" enligt MIME-format och inget annat. Detta har f.|. > redan Microsoft (i sverige) lovat mig {r "p} v{g" i deras SMTP-brygga > f|r MS-Mail. Jeg k|rer i dag MS-mail via en SMTP gateway, og med sendmail 5.65c8. Det er umodificeret MS-Mail og sendmail5.65c8 konverterer p{nt mellem cp850 og mnemonic. DKnet har idag 12 sites der k|rer pc-tegns{t, og ca 25 der k|rer latin1. Det k|rer fint, kommunikation mellem 850, 8859-1 og dansk 7-bit uden problemer. Der er ikke nogen problemer som med quoted-printable n}r man nedgraderer til 7-bit, og det er ikke nogen problemer med at du skal have opgraderet software hos brugerne. keld From owner-nordpost@nada.kth.se Thu Nov 26 21:05:41 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA25854; Thu, 26 Nov 92 21:05:45 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA25836; Thu, 26 Nov 92 21:05:41 +0100 Received: by dkuug.dk id AA02610 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Thu, 26 Nov 1992 21:05:39 +0100 Date: Thu, 26 Nov 1992 21:05:39 +0100 From: Keld J|rn Simonsen Message-Id: <199211262005.AA02610@dkuug.dk> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A X-Charset: ASCII X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*119 Lidt kommentarer: > 3) N{r man skickar ett brev till mottagare i Norden ska under > |verg}ngstiden normalt Content-Type bli Multipart/Alternative. Den > f|rsta delen av brevet, som inte ska ha n}gon explicit angiven > Content-Type, ska inneh}lla brevets text konverterad till svensk > 7-bitskod. Det {r den del som mottagare med {nnu ej MIME-anpassad > UA ser f|rst. Som sista mening brevtexten i den f|rsta delen l{ggs > en kort varnande text in automatiskt, t.ex.: > > ---> Efter denna rad f|ljer samma brevtext lagrat p} annat s{tt <--- > > Slutligen l{ggs ett sidbyte in (Ctrl-L) i den f|rsta delen av > meddelandet. P} detta s{tt kommer m}nga UA-program att stanna > visningen efter varningstexten, och anv{ndaren f}r m|jlighet att > avbryta. > > En MIME-anpassad brevhanterare visar bara andra delen av brevet, > inneh}ller den riktiga texten, normalt med > Content-Type: Text/Plain; charset=ISO-8859-1 > Content-Transfer-Encoding: Quoted-Printable Det virker noget overfl|digt og irriterende at f} vist det samme brev 2 gange. Det ville v{re bedre at det kun kom en gang og s} at dette format b}de kunne forst}s af MIME og gamle mailere. charset=MNEMONIC giver denne mulighed. > 4) Alltf|r stor |kning av trafiken p} grund av skickning av brev > med dubblerat inneh}ll kan minskas om: > > a) UA-programmet kontrollerar formatet p} ett brev man svarar > p} (reply) och anpassar svarsbrevets format efter det > > b) UA-program som uppdaterar anv{ndarens personliga register |ver > datorpostadresser med ledning av adresser i inkommande brev > ut|kas s} att {ven uppgift om MIME-kunnighet lagras i registret > med ledning av formatet p} det senast inkomna brevet fr}n en > viss adress Hvad med breve til flere adressater? Hvilket format skal den v{lge s}? > c) Anv{ndaren tillfr}gas om andra alternativ d} brevet {r l}ngt. > > Programmet b|r f|rst}s uppm{rksamma om nya mottagare l{ggs till och > i s} fall ev. {ndra format. > 6) Det format f|r lagring av }ttabitstecken i brevhuvudf{ltet som > f|reslagits (RFC 1342) {r tyv{rr oanv{ndbart under |verg}ngstiden. > Vi f|resl}r f|ljande f|rfarande: > > a) Vi forts{tter att skriva }{| i rubrikraden (Subject) enligt > svensk sjubitskod. MIME-modifierade UA-program i Sverige som > anv{nds i en }ttabitsmilj| ska allts} konvertera det anv{ndaren > skriver i rubrikraden till sjubitstecken innan brevet skickas > iv{g, och ska konvertera inkommade brevs rubrikrad fr}n svensk > sjubitskod till den lokala }ttabitskoden. (Brev skrivna p} > engelska inneh}ller s{lla hakar och klamrar p} rubrikraden.) > > b) Anv{ndarens fullst{ndiga namn skrivs dubbelt i avs{ndar- > och mottagarf{lten, f|rst en internationellt form, sedan > den korrekta formen: > > From: Olle Jarnefors > (=?ISO-8859-1?Q?Olle_J=E4rnefors?=) Tjae, hvorfor ikke bruge mnemonic? Det er da langt mere l{seligt. > 7) De konverteringstabeller UA-programmet anv{nder b|r f|lja det > system som beskrivs i ][\-gruppens kommande slutrapport. Er de forskellige fra RFC1345? Hvorfor ikke bruge standard internet RFC 1345 konvertering? keld From psv@nada.kth.se Thu Nov 26 23:23:49 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA01623; Thu, 26 Nov 92 23:23:57 +0100 Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA01604; Thu, 26 Nov 92 23:23:49 +0100 Message-Id: <9211262223.AA01604@nada.kth.se> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A In-Reply-To: <199211262005.AA02610@dkuug.dk> from "Keld J|rn Simonsen " "Thu, 26 Nov 1992 21:05:39 +0100 " Date: Thu, 26 Nov 92 23:23:48 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*120 Citat ur brev från: Keld J|rn Simonsen > > Det virker noget overfl|digt og irriterende at f} vist > det samme brev 2 gange. Det ville v{re bedre at det kun kom en gang > og s} at dette format b}de kunne forst}s af MIME og gamle > mailere. charset=MNEMONIC giver denne mulighed. Jag st&a:ller mig fr&aagande till om MNEMONIC-text f&o:rst&aas och framf&o:r allt accepteras av anv&a:ndarna. Jag tvivlar! Majoriteten vill nog varken ha &a: eller =a4 utan ett riktigt a med två prickar ovanför. > > From: Olle Jarnefors > > (=?ISO-8859-1?Q?Olle_J=E4rnefors?=) > Tjae, hvorfor ikke bruge mnemonic? Det er da langt mere l{seligt. Du menar: From: (=?MNEMONIC?Q?Olle_J&a:rnefors?=) eller hur blir det? Inte är det stor skillnad. Dessutom undrar jag hur det blev med MNEMONICS och MIME. Du skrev i ett annat inlägg: > MNEMONIC er tilladt i MIME, jfr RFC 1341 og RFC 1345. Jag har nu tittat i dom och finner inget om MNEMONICS i MIME-RFC:n. Inte heller finns MNEMONICS med bland teckenkoderna i aktuell IANA-lista (RFC 1340). Jag fick leta långt ner i RFC 1345 för att ens hitta hur man anger MNEMONICS som teckenkod. Min slutsats: Det är inte troligt att det blir MNEMONICS-understöd i MIME-brevhanterare. (Eller har du andra indikationer?) Dvs. lokalt användande av MNEMONICS i Norden skapar bara nya problem för oss. Hur har ni tänkt hantera det i Danmark? > > 7) De konverteringstabeller UA-programmet anv{nder b|r f|lja det > > system som beskrivs i ][\-gruppens kommande slutrapport. > Er de forskellige fra RFC1345? Hvorfor ikke bruge standard internet > RFC 1345 konvertering? Protest! Ur RFC 1345: > Status of the Memo > > This memo provides information for the Internet community. It does > not specify an Internet standard. Att kalla det för "standard internet ... konvertering" är att vilseleda! ÅÄÖ-gruppens tabeller hanterar både repertoartransformation (dvs. hur ska tecken X i repertoar A på bästa sätt representeras med repertoar B som saknar tecknet X?) och kodtransformation och erbjuder _olika_ typer av konvertering för olika ändamål. --- Peter Svanberg From owner-nordpost@nada.kth.se Fri Nov 27 08:10:10 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA03149; Fri, 27 Nov 92 08:10:18 +0100 Received: from oddput.efd.lth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA03133; Fri, 27 Nov 92 08:10:10 +0100 Received: by efd.lth.se (Smail3.1.28.1 #1) id m0muzq0-0002WxC; Fri, 27 Nov 92 08:10 MET Message-Id: To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A In-Reply-To: Your message of "Thu, 26 Nov 92 23:23:48 +0100." <9211262223.AA01604@nada.kth.se> Date: Fri, 27 Nov 92 08:10:00 +0100 From: Joergen Haegg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*121 In message <9211262223.AA01604@nada.kth.se> you write: > >Jag st&a:ller mig fr&aagande till om MNEMONIC-text f&o:rst&aas och >framf&o:r allt accepteras av anv&a:ndarna. Jag tvivlar! Majoriteten >vill nog varken ha &a: eller =a4 utan ett riktigt a med tv} prickar >ovanf|r. Verkar lite dumt att inf|ra ytterligare ett steg innan vi f}r 8859-1 |verallt. Att v{nta p} 10646 tycker jag {r att skjuta hela problematiken p} framtiden. Men brev f}r inte f|rvanskas utan mottagarens vetskap. En eventuell konvertering under transporten ska endast ske om mottagaren vill ha det s}. Kanske det skulle g} att l{gga in en TXT-post i DNS som ber{ttade om mottagaren vill ha n}gon konvertering? D} slipper man centrala tabeller, vilka snabbt kommer ur fas med verkligheten. Om anv{ndaren nisse i dom{nen foo.bar.se vill ha 7 bitar kan han ha en TXT-post nisse.foo.bar.se som ber{ttar att omvandling ska ske. Eller nisse.conv.foo.bar om man vill vara s{ker p} att posten ska vara unik. Man kan {ven ange hela dom{ner, men d} f|rlorar anv{ndaren kontrollen. Sun (och andra misst{nker jag) anv{nder ju numera BIND 4.8.3, vilken st|der TXT-poster. Om man inte vill kompilera den sj{lv :-). Gl|m bara inte att unix MTA inte beh|ver vara lika med sendmail!! -------- Jörgen Hägg jh@efd.lth.se postmaster@efd.lth.se Telnr: 046-107492, 104013(fax) Snigelpost: Hämtställe 7, BOX 118, 221 00 LUND Lunds Tekniska Högskola Paket: E-huset, Ole Römers väg 3, 221 00 LUND HELP! MY TYPEWRITER IS BROKEN! -- E. E. CUMMINGS From owner-nordpost@nada.kth.se Fri Nov 27 08:31:24 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA03961; Fri, 27 Nov 92 08:31:27 +0100 Received: from corax.UDAC.UU.SE by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA03945; Fri, 27 Nov 92 08:31:24 +0100 Received: from alba.udac.uu.se by corax.udac.uu.se with SMTP id AA24574 (5.65+bind 1.7+ida 1.4.2/IDA-1.4.2 for nordpost@nada.kth.se); Fri, 27 Nov 92 08:31:23 +0100 Received: by alba.UDAC.UU.SE id AA03432 (5.67a8/IDA-1.5 for nordpost@nada.kth.se); Fri, 27 Nov 1992 08:31:22 +0100 Date: Fri, 27 Nov 1992 08:31:22 +0100 From: Martin Wendel Message-Id: <199211270731.AA03432@alba.UDAC.UU.SE> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*122 Peter Svanberg skriver: > ][\-gruppens tabeller hanterar b}de repertoartransformation (dvs. hur > ska tecken X i repertoar A p} b{sta s{tt representeras med repertoar > B som saknar tecknet X?) och kodtransformation och erbjuder _olika_ > typer av konvertering f|r olika {ndam}l. L}ter som en icke-reversibel konvertering, dvs information kan g} f|rlorad, st{mmer det? F|rdelen med MNEMONIC som mellanformat f|r konvertering mellan tv} tecken- format {r, enligt min }sikt, att konverteringarna {r reversibla, dvs ingen information f|rst|rs. Naturligtvis m}ste det vara mottagarens val att best{mma om informationen skall bibeh}llas eller om viss information skall f|rst|ras. Finns n}gon rapport, eller liknande, p} }{|-gruppens arbete tillg{nglig |ver n{tet? ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From psv@nada.kth.se Fri Nov 27 08:59:20 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04957; Fri, 27 Nov 92 08:59:25 +0100 Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04939; Fri, 27 Nov 92 08:59:20 +0100 Message-Id: <9211270759.AA04939@nada.kth.se> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A In-Reply-To: <199211270731.AA03432@alba.UDAC.UU.SE> from "Martin Wendel " "Fri, 27 Nov 1992 08:31:22 +0100 " Date: Fri, 27 Nov 92 08:59:20 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*123 Citat ur brev från: Martin Wendel > > Peter Svanberg skriver: > > > ][\-gruppens tabeller hanterar b}de repertoartransformation (dvs. hur > > ska tecken X i repertoar A p} b{sta s{tt representeras med repertoar > > B som saknar tecknet X?) och kodtransformation och erbjuder _olika_ > > typer av konvertering f|r olika {ndam}l. > > L}ter som en icke-reversibel konvertering, dvs information kan g} f|rlorad, > st{mmer det? Man kan välja. > F|rdelen med MNEMONIC som mellanformat f|r konvertering mellan tv} tecken- > format {r, enligt min }sikt, att konverteringarna {r reversibla, dvs ingen > information f|rst|rs. Visst, i likhet med MIME-transportkodningarna. Vad jag invände mot var MNEMONIC som visningsformat. > Naturligtvis m}ste det vara mottagarens val att best{mma om informationen > skall bibeh}llas eller om viss information skall f|rst|ras. Mja, om det går. I en miljö där inget ändras vill man troligen hellre att också breven ser ut som förut än att dom plötsligt börjar se ut s&aa h&a:r. > Finns n}gon rapport, eller liknande, p} }{|-gruppens arbete tillg{nglig > |ver n{tet? Någon slutrapport finns inte ännu men dokumentation om principerna finns. Den håller just på att uppdateras så om några dagar finns en färsk version. --- Peter Svanberg From owner-nordpost@nada.kth.se Fri Nov 27 09:06:33 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA06633; Fri, 27 Nov 92 09:06:38 +0100 Received: from corax.UDAC.UU.SE by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA06614; Fri, 27 Nov 92 09:06:33 +0100 Received: from alba.udac.uu.se by corax.udac.uu.se with SMTP id AA24646 (5.65+bind 1.7+ida 1.4.2/IDA-1.4.2 for nordpost@nada.kth.se); Fri, 27 Nov 92 09:06:31 +0100 Received: by alba.UDAC.UU.SE id AA03454 (5.67a8/IDA-1.5 for nordpost@nada.kth.se); Fri, 27 Nov 1992 09:06:30 +0100 Date: Fri, 27 Nov 1992 09:06:30 +0100 From: Martin Wendel Message-Id: <199211270806.AA03454@alba.UDAC.UU.SE> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*124 Joergen Haegg skriver: > > In message <9211262223.AA01604@nada.kth.se> you write: > > > >Jag st&a:ller mig fr&aagande till om MNEMONIC-text f&o:rst&aas och > >framf&o:r allt accepteras av anv&a:ndarna. Jag tvivlar! Majoriteten > >vill nog varken ha &a: eller =a4 utan ett riktigt a med tv} prickar > >ovanf|r. > > Verkar lite dumt att inf|ra ytterligare ett steg innan vi f}r 8859-1 > |verallt. Jag tvivlar p} att CP437, EBCDIC eller Macintosh teckenset kommer att bytas ut mot ISO8859-1 i den n{rmsta framtiden. > Att v{nta p} 10646 tycker jag {r att skjuta hela problematiken p} > framtiden. Sj{lvklart m}ste man utg} fr}n de teckenset som anv{nds. Problemet {r att om man l}ser in sig i ISO8859-1 kommer hela den h{r problematiken att }terkomma om n}gra }r d} ISO10646 verkligen kommer. > Men brev f}r inte f|rvanskas utan mottagarens vetskap. En eventuell > konvertering under transporten ska endast ske om mottagaren vill ha det s}. Det beror p} vad du menar. Enligt min mening f}r inte informationen i brevet f|rvanskas. D{remot tror jag att mottagaren {r ointresserad av hur sj{lva datat i brevet konverteras. Det kan naturligtvis finnas undantag till detta, d} tycker jag att f|rslaget i rfc1344 (Content-Conversion: prohibited) skall till{mpas, men det blir avs{ndarens sak att avg|ra. > Kanske det skulle g} att l{gga in en TXT-post i DNS som ber{ttade > om mottagaren vill ha n}gon konvertering? > D} slipper man centrala tabeller, vilka snabbt kommer ur fas med > verkligheten. Jag tror att konverteringsinformation i DNS blir en mycket lokal standard, det kan ju r|ra sig om en ganska omfattande beskrivning av teckenformat, bin{rkodningsformat etc. D} {r det b{ttra att slussa mail via en lokal gateway som tar hand om detta. P} detta s{tt blir man oberoende av avs{ndarens behandling av TXT-posterna. Ett s{tt att undvika centrala tabeller {r att varje site sj{lv styr sina mail via MIME-gateways. D} }terst}r problemet endast f|r de maskiner som inte hanterar MX-records. Personligen tycker jag att s}dana maskiner skulle tvingas skicka all mail via n}gon annan maskin, som klarar av MX. Det finns redan idag problem pga av detta och s}dant borde inte f} lov att f|rekomma. > Gl|m bara inte att unix MTA inte beh|ver vara lika med sendmail!! Tyv{rr har du r{tt:-). ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From paf@nada.kth.se Fri Nov 27 09:15:27 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA07311; Fri, 27 Nov 92 09:16:07 +0100 Received: from sysman.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA07255; Fri, 27 Nov 92 09:15:27 +0100 Received: by sysman.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA19624; Fri, 27 Nov 92 09:15:22 +0100 Date: Fri, 27 Nov 1992 09:13:44 +0100 (MET) From: Patrik Faltstrom Subject: Re: MIME i Sverige, f|rslag A To: nordpost@nada.kth.se In-Reply-To: Message-Id: Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*125 On Fri, 27 Nov 1992, Joergen Haegg wrote: > Men brev f}r inte f|rvanskas utan mottagarens vetskap. En eventuell > konvertering under transporten ska endast ske om mottagaren vill ha det s}. Det som diskuteras, och som jag tycker är ok, är att konverteringsinformation läggs i "Received"-raderna i headern. paf From owner-nordpost@nada.kth.se Fri Nov 27 09:28:54 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08085; Fri, 27 Nov 92 09:28:57 +0100 Received: from oddput.efd.lth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08069; Fri, 27 Nov 92 09:28:54 +0100 Received: by efd.lth.se (Smail3.1.28.1 #1) id m0mv14B-0002V7C; Fri, 27 Nov 92 09:28 MET Message-Id: To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A In-Reply-To: Your message of "Fri, 27 Nov 92 09:06:30 +0100." <199211270806.AA03454@alba.UDAC.UU.SE> Date: Fri, 27 Nov 92 09:28:44 +0100 From: Joergen Haegg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*126 In message <199211270806.AA03454@alba.UDAC.UU.SE> you write: >Joergen Haegg skriver: > >> >> In message <9211262223.AA01604@nada.kth.se> you write: >> > >> Att v{nta p} 10646 tycker jag {r att skjuta hela problematiken p} >> framtiden. > >Sj{lvklart m}ste man utg} fr}n de teckenset som anv{nds. Problemet {r att >om man l}ser in sig i ISO8859-1 kommer hela den h{r problematiken att >}terkomma om n}gra }r d} ISO10646 verkligen kommer. Vad jag vet s} ing}r 8859-1 i 10646. B|r inte vara n}got problem. >> Men brev f}r inte f|rvanskas utan mottagarens vetskap. En eventuell >> konvertering under transporten ska endast ske om mottagaren vill ha det s}. > >Det beror p} vad du menar. Enligt min mening f}r inte informationen i brevet >f|rvanskas. D{remot tror jag att mottagaren {r ointresserad av hur sj{lva >datat i brevet konverteras. Det kan naturligtvis finnas undantag till detta, >d} tycker jag att f|rslaget i rfc1344 (Content-Conversion: prohibited) skall >till{mpas, men det blir avs{ndarens sak att avg|ra. Vad jag menar {r att mottagaren ska f} best{mma sj{lv om han/hon vill ha n}gon konvertering. Om mottagaren k{nner f|r att byta till MIME s} ska det g} utan att beh|va konsultera n}gra h|gre makter :-). >> Kanske det skulle g} att l{gga in en TXT-post i DNS som ber{ttade >> om mottagaren vill ha n}gon konvertering? >> D} slipper man centrala tabeller, vilka snabbt kommer ur fas med >> verkligheten. > >Jag tror att konverteringsinformation i DNS blir en mycket lokal standard, >det kan ju r|ra sig om en ganska omfattande beskrivning av teckenformat, >bin{rkodningsformat etc. D} {r det b{ttra att slussa mail via en lokal >gateway som tar hand om detta. P} detta s{tt blir man oberoende av avs{ndarens >behandling av TXT-posterna. Vad vi har talat om {r ju en konvertering lokalt i Norden. PS. Verkar som om breven i denna lista omvandlas till sju bitar. Stämmer det? -------- Jörgen Hägg jh@efd.lth.se postmaster@efd.lth.se Telnr: 046-107492, 104013(fax) Snigelpost: Hämtställe 7, BOX 118, 221 00 LUND Lunds Tekniska Högskola Paket: E-huset, Ole Römers väg 3, 221 00 LUND "The two most common things in the universe are hydrogen and stupidity." From owner-nordpost@nada.kth.se Fri Nov 27 09:32:24 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08256; Fri, 27 Nov 92 09:32:31 +0100 Received: from oddput.efd.lth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08237; Fri, 27 Nov 92 09:32:24 +0100 Received: by efd.lth.se (Smail3.1.28.1 #1) id m0mv17Y-0002V7C; Fri, 27 Nov 92 09:32 MET Message-Id: To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A In-Reply-To: Your message of "Fri, 27 Nov 92 09:13:44 +0100." Date: Fri, 27 Nov 92 09:32:13 +0100 From: Joergen Haegg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*127 In message you write: >On Fri, 27 Nov 1992, Joergen Haegg wrote: > >> Men brev f}r inte f|rvanskas utan mottagarens vetskap. En eventuell >> konvertering under transporten ska endast ske om mottagaren vill ha det s}. > >Det som diskuteras, och som jag tycker {r ok, {r att konverteringsinformation >l{ggs i "Received"-raderna i headern. Medför detta att mottagaren endast får reda på att konvertering har skett? -------- Jörgen Hägg jh@efd.lth.se postmaster@efd.lth.se Telnr: 046-107492, 104013(fax) Snigelpost: Hämtställe 7, BOX 118, 221 00 LUND Lunds Tekniska Högskola Paket: E-huset, Ole Römers väg 3, 221 00 LUND One day the King decided that he would force all his subjects to tell the truth. A gallows was erected in front of the city gates. A herald announced, "Whoever would enter the city must first answer the truth to a question which will be put to him." Nasrudin was first in line. The captain of the guard asked him, "Where are you going? Tell the truth -- the alternative is death by hanging." "I am going," said Nasrudin, "to be hanged on that gallows." "I don't believe you." "Very well, if I have told a lie, then hang me!" "But that would make it the truth!" "Exactly," said Nasrudin, "your truth." From paf@nada.kth.se Fri Nov 27 09:33:56 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08323; Fri, 27 Nov 92 09:34:01 +0100 Received: from sysman.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08306; Fri, 27 Nov 92 09:33:56 +0100 Received: by sysman.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA19691; Fri, 27 Nov 92 09:33:55 +0100 Date: Fri, 27 Nov 1992 09:18:51 +0100 (MET) From: Patrik Faltstrom Subject: Re: MIME i Sverige, f|rslag A To: nordpost@nada.kth.se In-Reply-To: <199211270806.AA03454@alba.UDAC.UU.SE> Message-Id: Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*128 On Fri, 27 Nov 1992, Martin Wendel wrote: > Joergen Haegg skriver: > > Jag tvivlar p} att CP437, EBCDIC eller Macintosh teckenset kommer att > bytas ut mot ISO8859-1 i den n{rmsta framtiden. Nej, men US-ASCII och ISO-646-SE byts redan ut mot ISO-8859-1 och dessutom sammanfaller ISO-8859-1 med UNICODE/10646 i dess första plan. Alltså blir en övergång till ISO-8859-1 ett första enkelt steg mot UNICODE/10646. Att dessutom många av de datorer som används på nätet och kör sendmail hanterar ISO-8859-1 och dessutom Microsoft Windows och Macintoshens MacX (och annan MacTCP-programvara) automatiskt konverterar till ISO-8859-1 talar också för att det är denna kod som ska rekommenderas. Dessutom kräver andra protokoll som gopher och WAIS att man har US-ASCII eller ISO-8859-1. Om man sedan ska använda Keld's MNEMONICS med tabelluppslagning eller Quoted-Printable som räknas ut med en enkel funktion är en annan fråga. Själv tycker jag, precis som andra här, att dessa bägge ska enbart användas som transportkodningar. Ingen kan ha för avsikt att en användare egentligen ska behöva se dessa kodningar. Bägge är mycket skilda från de glyfer som egentligen ska användas. Att Quoted-Printable är enklare att implementera tycker jag talar för att vi ska rekommendera denna kodning, speciellt som denna även omtalas i RFC-1341 som tillämplig om teckenuppsättningen är ISO-8859-1. Det är förresten Quoted-Printable som används i de brevhanterare som använder MIME som jag sett (förutom de sendmail mm som Keld själv skrivit), bla elm och pine. Alltså måste vi åtminstone skicka Quoted-Printable som jag ser det i en framtid på det globala nätet, dvs ut mot världen. Att vi dessutom ska kunna konvertera dansk post med MNEMONICS till Quoted-Printable tycker jag är en "nice feature" som naturligtvis är bra att ha, precis som alla eventuella tillägg man kan lägga in om man orkar. > Det beror p} vad du menar. Enligt min mening f}r inte informationen i brevet > f|rvanskas. D{remot tror jag att mottagaren {r ointresserad av hur sj{lva > datat i brevet konverteras. Det kan naturligtvis finnas undantag till detta, > d} tycker jag att f|rslaget i rfc1344 (Content-Conversion: prohibited) skall > till{mpas, men det blir avs{ndarens sak att avg|ra. Naturligtvis ska inte innehållet förvanskas, men det beror på vad du menar med det. Om du skickar ett 8-bits-brev (icke-MIME) och detta sedan kommer packas in (kodas) med tex Quoted-Printable så kan man se detta som en förvanskning om mottagaren inte kan tolka MIME. Vi har ett aktuellt fall här på NADA just i dagarna med en person som helt plötsligt inte kan skicka brev till Japan med JIS-kodning pga att vi numera ser till att inte skicka ut 8-bits-brev på Internet. Hans brev blir helt enkelt förvanskade. För att det ska fungera för honom måste han koda om sina brev för hand till Shift-JIS, och det är inte helt trivialt att göra för hand. Hade vi Quoted-Printable i varje ände (enkelt att fixa in i brevhanteraren) så skulle hans post komma fram ok. Alltså, redan idag sker det lite för mycket konvretering kanske... paf From paf@nada.kth.se Fri Nov 27 09:39:59 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08483; Fri, 27 Nov 92 09:40:06 +0100 Received: from sysman.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08466; Fri, 27 Nov 92 09:39:59 +0100 Received: by sysman.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA19712; Fri, 27 Nov 92 09:39:54 +0100 Date: Fri, 27 Nov 1992 09:35:40 +0100 (MET) From: Patrik Faltstrom Subject: Re: MIME i Sverige, f|rslag A To: nordpost@nada.kth.se In-Reply-To: Message-Id: Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*129 On Fri, 27 Nov 1992, Joergen Haegg wrote: > In message you write: > >On Fri, 27 Nov 1992, Joergen Haegg wrote: > > > >> Men brev f}r inte f|rvanskas utan mottagarens vetskap. En eventuell > >> konvertering under transporten ska endast ske om mottagaren vill ha det s}. > > > >Det som diskuteras, och som jag tycker {r ok, {r att konverteringsinformation > >l{ggs i "Received"-raderna i headern. > > Medför detta att mottagaren endast får reda på att konvertering har skett? Han får reda på vilken konvertering som skett och vilken dator som har utfört den. Jag har tyvärr inte kvar det brevet där det fanns ett bra exempel, men kanske har Olle eller Peter kvar ett exempel. paf From psv@nada.kth.se Fri Nov 27 09:41:27 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08630; Fri, 27 Nov 92 09:41:36 +0100 Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08587; Fri, 27 Nov 92 09:41:27 +0100 Message-Id: <9211270841.AA08587@nada.kth.se> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A In-Reply-To: from "Joergen Haegg " "Fri, 27 Nov 92 09:28:44 +0100 " Date: Fri, 27 Nov 92 09:41:25 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*130 Citat ur brev från: Joergen Haegg > > PS. Verkar som om breven i denna lista omvandlas till sju bitar. > Stämmer det? Ja, vi kör Dan-ISOC-Sendmail. From owner-nordpost@nada.kth.se Fri Nov 27 09:43:58 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08760; Fri, 27 Nov 92 09:44:00 +0100 Received: from corax.UDAC.UU.SE by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08744; Fri, 27 Nov 92 09:43:58 +0100 Received: from alba.udac.uu.se by corax.udac.uu.se with SMTP id AA24740 (5.65+bind 1.7+ida 1.4.2/IDA-1.4.2 for nordpost@nada.kth.se); Fri, 27 Nov 92 09:43:57 +0100 Received: by alba.UDAC.UU.SE id AA03632 (5.67a8/IDA-1.5 for nordpost@nada.kth.se); Fri, 27 Nov 1992 09:43:54 +0100 Date: Fri, 27 Nov 1992 09:43:54 +0100 From: Martin Wendel Message-Id: <199211270843.AA03632@alba.UDAC.UU.SE> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*131 > Naturligtvis ska inte inneh}llet f|rvanskas, men det beror p} vad du menar > med det. Om du skickar ett 8-bits-brev (icke-MIME) och detta sedan kommer > packas in (kodas) med tex Quoted-Printable s} kan man se detta som en > f|rvanskning om mottagaren inte kan tolka MIME. Vi har ett aktuellt > fall h{r p} NADA just i dagarna med en person som helt pl|tsligt > inte kan skicka brev till Japan med JIS-kodning pga att vi numera > ser till att inte skicka ut 8-bits-brev p} Internet. Hans brev blir > helt enkelt f|rvanskade. F|r att det ska fungera f|r honom m}ste > han koda om sina brev f|r hand till Shift-JIS, och det {r inte helt > trivialt att g|ra f|r hand. Vilket belyser behovet av m|jlighet att anv{nda n}gon form av Content-Conversion: prohibited. ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From paf@nada.kth.se Fri Nov 27 09:51:13 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09074; Fri, 27 Nov 92 09:51:17 +0100 Received: from sysman.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09057; Fri, 27 Nov 92 09:51:13 +0100 Received: by sysman.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA19766; Fri, 27 Nov 92 09:51:12 +0100 Date: Fri, 27 Nov 1992 09:46:32 +0100 (MET) From: Patrik Faltstrom Subject: Re: MIME i Sverige, f|rslag A To: nordpost@nada.kth.se In-Reply-To: <199211270843.AA03632@alba.UDAC.UU.SE> Message-Id: Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*132 On Fri, 27 Nov 1992, Martin Wendel wrote: > Vilket belyser behovet av m|jlighet att anv{nda n}gon form av > Content-Conversion: prohibited. Nej, nej, nej. Nu är du ute på villovägar. Att lägga till "content-conversion: prohibited" kan ALDRIG förhindra att innehållet KODAS i ett sjubitars-brev om det är så att 8-bits-brevet ska ut på en sjubitarskanal. Att koda brevet är inte samma sak som att konvertera! Meningen var att mitt exempel skulle vis precis motsatsen, suck. Dvs att det behövs en kodning, Quoted-Printable, som enkelt kan koda 8-bitstexter över en sjubitarskanal. Detta oavsett vad brevet innehåller. MNEMONICS kräver att du ska veta att det just är JIS som används i brevet, även fast vi normalt (99,99% av användarna) skriver i ISO-8859-1. Om denna enda användare skickar JIS eller någon annan kodning som BIG5 eller så, så kan denna inte skickas enkelt till Japan, även om både avsändare och mottagare är överens om vad brevet innehåller så länge man inte har en metod att generellt (oavsett brevets innehåll) kodar 8-bits-byte i 7-bitars-byte! paf From owner-nordpost@nada.kth.se Fri Nov 27 10:17:20 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12778; Fri, 27 Nov 92 10:17:23 +0100 Received: from corax.UDAC.UU.SE by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12761; Fri, 27 Nov 92 10:17:20 +0100 Received: from alba.udac.uu.se by corax.udac.uu.se with SMTP id AA24811 (5.65+bind 1.7+ida 1.4.2/IDA-1.4.2 for nordpost@nada.kth.se); Fri, 27 Nov 92 10:17:19 +0100 Received: by alba.UDAC.UU.SE id AA03717 (5.67a8/IDA-1.5 for nordpost@nada.kth.se); Fri, 27 Nov 1992 10:17:17 +0100 Date: Fri, 27 Nov 1992 10:17:17 +0100 From: Martin Wendel Message-Id: <199211270917.AA03717@alba.UDAC.UU.SE> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*133 Patrik Faltstrom skriver: > > On Fri, 27 Nov 1992, Martin Wendel wrote: > > > Vilket belyser behovet av m|jlighet att anv{nda n}gon form av > > Content-Conversion: prohibited. > > Nej, nej, nej. Nu {r du ute p} villov{gar. Att l{gga till > "content-conversion: prohibited" kan ALDRIG f|rhindra > att inneh}llet KODAS i ett sjubitars-brev om det {r s} att > 8-bits-brevet ska ut p} en sjubitarskanal. F|rl}t ett alltf|r generellt uttalande. Dock tycker jag att ett Content-Conversion: prohibited f{lt borde k{nnas igen av exempelvis den typen av MIME-gateway som finns i f|rslag B. > Meningen var att mitt exempel skulle vis precis motsatsen, suck. > Dvs att det beh|vs en kodning, Quoted-Printable, som enkelt kan koda > 8-bitstexter |ver en sjubitarskanal. Detta oavsett vad brevet > inneh}ller. Om du talar om Quoted-Printable endast och inte MIME, kunde er anv{ndares problem ocks} l|sas med uuencode eller binhex, vilka torde vara mer v{lk{nda {n Quoted-Printable. Om du pratar om MIME d{remot, f}r man inte gl|mma att ocks} Charset skall specificeras i ett Text-brev, dvs samma krav som MNEMONICs. ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From paf@nada.kth.se Fri Nov 27 10:43:32 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA13652; Fri, 27 Nov 92 10:43:37 +0100 Received: from sysman.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA13636; Fri, 27 Nov 92 10:43:32 +0100 Received: by sysman.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA20091; Fri, 27 Nov 92 10:43:31 +0100 Date: Fri, 27 Nov 1992 10:28:02 +0100 (MET) From: Patrik Faltstrom Subject: Re: MIME i Sverige, f|rslag A To: nordpost@nada.kth.se In-Reply-To: <199211270917.AA03717@alba.UDAC.UU.SE> Message-Id: Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*134 On Fri, 27 Nov 1992, Martin Wendel wrote: > F|rl}t ett alltf|r generellt uttalande. Dock tycker jag att ett > Content-Conversion: prohibited f{lt borde k{nnas igen av exempelvis > den typen av MIME-gateway som finns i f|rslag B. Du behöver inte alls be om ursäkt. En diskussion är en diskussion. Det är viktigt att vi förstår varandra. Jag borde kanske förstått dig i första läget :-) > Om du talar om Quoted-Printable endast och inte MIME, kunde er anv{ndares > problem ocks} l|sas med uuencode eller binhex, vilka torde vara mer v{lk{nda > {n Quoted-Printable. Om du pratar om MIME d{remot, f}r man inte gl|mma att > ocks} Charset skall specificeras i ett Text-brev, dvs samma krav som MNEMONICs. Vad jag egentligen menar är att ponera att vi har följande inte alls helt osannolika scenario: Vi på NADA kör internt ISO-8859-1 med sendmail som hanterar ISOC-modellen. EN av våra användare skickar dock inte ISO-8859-1 utan någon österländsk kodning, säg JIS, som innehåller 8bitarstecken. När vi skickar ut på SUNET har vi registrerat på något sätt (varför inte i nameservern) att vi använder ISO-8859-1 om inget annat sägs. Därför kommer våra brev packas in i MIME-brev med följande header (2 alternativ): Content-Type: text/plain;charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-Printable eller Content-Type: text/plain;charset=MNEMONICS Content-Transfer-Encoding: 7Bit (det är så som jag tolkar att MNEMONICS ska användas i MIME utan att ha lusläst RFC-1345) Det är helt klart att bägge dessa kommer vara felaktiga om man betänker att det inte alls är ISO-8859-1 som fanns i brevet utan JIS. Däremot kan alternativ 1 med stor sannolikhet enklare behandlas i Japan än alternativ 2 (som jag ser det är MNEMONICS mer till för europa än japan och kina). Men, som sagt. Det bästa vore om man dels hade bägge varianterna samt att avsändaren kan välja. (i detta fallet med JIS är det bästa BASE-64-kodning :-) paf From owner-nordpost@nada.kth.se Fri Nov 27 11:24:07 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA17311; Fri, 27 Nov 92 11:24:10 +0100 Received: from corax.UDAC.UU.SE by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA17295; Fri, 27 Nov 92 11:24:07 +0100 Received: from alba.udac.uu.se by corax.udac.uu.se with SMTP id AA24968 (5.65+bind 1.7+ida 1.4.2/IDA-1.4.2 for nordpost@nada.kth.se); Fri, 27 Nov 92 11:24:07 +0100 Received: by alba.UDAC.UU.SE id AA03884 (5.67a8/IDA-1.5 for nordpost@nada.kth.se); Fri, 27 Nov 1992 11:24:05 +0100 Date: Fri, 27 Nov 1992 11:24:05 +0100 From: Martin Wendel Message-Id: <199211271024.AA03884@alba.UDAC.UU.SE> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*135 Patrik Faltstrom skriver: > > Vad jag egentligen menar {r att ponera att vi har f|ljande inte alls > helt osannolika scenario: > > Vi p} NADA k|r internt ISO-8859-1 med sendmail som hanterar ISOC-modellen. > EN av v}ra anv{ndare skickar dock inte ISO-8859-1 utan n}gon |sterl{ndsk > kodning, s{g JIS, som inneh}ller 8bitarstecken. > > N{r vi skickar ut p} SUNET har vi registrerat p} n}got s{tt (varf|r inte > i nameservern) att vi anv{nder ISO-8859-1 om inget annat s{gs. D{rf|r > kommer v}ra brev packas in i MIME-brev med f|ljande header (2 alternativ): > > Content-Type: text/plain;charset=ISO-8859-1 > Content-Transfer-Encoding: Quoted-Printable > > eller > > Content-Type: text/plain;charset=MNEMONICS > Content-Transfer-Encoding: 7Bit > > (det {r s} som jag tolkar att MNEMONICS ska anv{ndas i MIME utan att > ha lusl{st RFC-1345) > > Det {r helt klart att b{gge dessa kommer vara felaktiga om man > bet{nker att det inte alls {r ISO-8859-1 som fanns i brevet utan > JIS. D{remot kan alternativ 1 med stor sannolikhet enklare > behandlas i Japan {n alternativ 2 (som jag ser det {r MNEMONICS mer > till f|r europa {n japan och kina). > > Men, som sagt. Det b{sta vore om man dels hade b{gge varianterna > samt att avs{ndaren kan v{lja. (i detta fallet med JIS {r det > b{sta BASE-64-kodning :-) > Jag tycker att det {r avs{ndarens ansvar att m{rka brevet p} n}got |verens- kommet s{tt om formatet skiljer sig fr}n n}got |verenskommet format. Dvs, om man bygger upp f|rslag B (med MIME-gateways), skall denna gateway antingen k{nna till teckensetet hos avs{ndande maskin, eller f|ruts{tta ett default teckenset (exempelvis ISO8859-1). Ett undantag skall g|ras: N{r MIME-gatewayen hittar information om teckensetet i brevet, skall denna information anv{ndas. Om inte detta f}r g{lla har ingenting vunnits. Det kommer att forts{tta att skickas brev med text utan k{nt format, d{r denna text likav{l kan betraktas som data vilket som helst. J{mf|r situationen idag d} det {r upp till mot- tagaren att tolka en '{' (jag skrev en krullparantes om n}gon av er konverterar) som skall betraktas {n som a med tv} prickar, {n som krullparantes. Jag tycker, att m{rka en JIS-text som ISO8859-1 {r principiellt helt f|rkastligt (att det sen kan fungera i praktiken {r en annan sak). ISO8859-1 skall inte anv{ndas f|r att markera att meddelandet kan vara i 8bitarsformat utan f|r att markera att meddelandet {r i ISO8859-1-format. ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From owner-nordpost@nada.kth.se Sun Nov 29 22:12:50 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA03901; Sun, 29 Nov 92 22:12:54 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA03885; Sun, 29 Nov 92 22:12:50 +0100 Received: by dkuug.dk id AA14264 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Sun, 29 Nov 1992 22:12:47 +0100 Date: Sun, 29 Nov 1992 22:12:47 +0100 From: Keld J|rn Simonsen Message-Id: <199211292112.AA14264@dkuug.dk> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A X-Charset: ASCII X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*136 > Citat ur brev fr}n: Keld J|rn Simonsen > > > > Det virker noget overfl|digt og irriterende at f} vist > > det samme brev 2 gange. Det ville v{re bedre at det kun kom en gang > > og s} at dette format b}de kunne forst}s af MIME og gamle > > mailere. charset=MNEMONIC giver denne mulighed. > > Jag st&a:ller mig fr&aagande till om MNEMONIC-text f&o:rst&aas och > framf&o:r allt accepteras av anv&a:ndarna. Jag tvivlar! Majoriteten > vill nog varken ha &a: eller =a4 utan ett riktigt a med tv} prickar > ovanf|r. Jeg enig med dig i at folk helst vil have de rigtige bogstaver, og derfor er det ikke blot et forslag at bruge mnemonics, som jeg er ude efter, men et lidt st|rre ops{t ala jeres alternativ B. Jeg vil i|vrigt foresl} at bruge MNEM, ikke MNEMONIC, MNEM bruger intro-tegn space-backspace (alts} to tegn), og det er noget lettere at l{se end "&". > > > From: Olle Jarnefors > > > (=?ISO-8859-1?Q?Olle_J=E4rnefors?=) > > > Tjae, hvorfor ikke bruge mnemonic? Det er da langt mere l{seligt. > > Du menar: > > From: (=?MNEMONIC?Q?Olle_J&a:rnefors?=) Noget i retning af: From: (=?MNEM?Q?Olle_J a:rnefors?=) Nej, det er ikke p{nt! > > eller hur blir det? Inte {r det stor skillnad. Dessutom undrar jag > hur det blev med MNEMONICS och MIME. Du skrev i ett annat inl{gg: > > > MNEMONIC er tilladt i MIME, jfr RFC 1341 og RFC 1345. > > Jag har nu tittat i dom och finner inget om MNEMONICS i MIME-RFC:n. Nej det er rigtigt, det var der en st|rre diskussion om. > Inte heller finns MNEMONICS med bland teckenkoderna i aktuell > IANA-lista (RFC 1340). Jag fick leta l}ngt ner i RFC 1345 f|r att ens > hitta hur man anger MNEMONICS som teckenkod. Min slutsats: Det {r inte > troligt att det blir MNEMONICS-underst|d i MIME-brevhanterare. (Eller > har du andra indikationer?) Dvs. lokalt anv{ndande av MNEMONICS i > Norden skapar bara nya problem f|r oss. Hur har ni t{nkt hantera det i > Danmark? Ja, MNEM og MNEMONIC mangler i RFC 1340. Jeg har skrevet til dem og bedt om at f} det rettet. St|tten til MNEMONICs beh|ver blot at v{re minimal. Jeg mener elm vil lave det. Ogs} sendmail vil blive rettet til. Det burde ikke v{re noget problem at sende MNEMONICS breve ud i verden. > > > > 7) De konverteringstabeller UA-programmet anv{nder b|r f|lja det > > > system som beskrivs i ][\-gruppens kommande slutrapport. > > > Er de forskellige fra RFC1345? Hvorfor ikke bruge standard internet > > RFC 1345 konvertering? > > Protest! Ur RFC 1345: > > > Status of the Memo > > > > This memo provides information for the Internet community. It does > > not specify an Internet standard. > > Att kalla det f|r "standard internet ... konvertering" {r att > vilseleda! Nej, nu er det dig der vildleder. I ovenn{vnte forstand er MIME heller ikke nogen "standard". Der er en RFC p} omr}det, der behandler tegns{tskonvertering, nemlig RFC 1345, og den har v{ret igennem en st|rre diskussion p} nettet. Den kan kun v{re "informational" da den citerer en lang r{kke standarder, som man ikke kan lave om p}, og derfor kan IETF ikke lave den til en internet standard, da de ikke kan {ndre de af andre standarder givne specifikationer. > ][\-gruppens tabeller hanterar b}de repertoartransformation (dvs. hur > ska tecken X i repertoar A p} b{sta s{tt representeras med repertoar > B som saknar tecknet X?) och kodtransformation och erbjuder _olika_ > typer av konvertering f|r olika {ndam}l. Ja, og jeg forst}r at de er meget svensk orienterede. Jeg tror ikke de kan bruges i Danmark. > --- > Peter Svanberg > Keld From owner-nordpost@nada.kth.se Sun Nov 29 22:21:43 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04063; Sun, 29 Nov 92 22:21:50 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04046; Sun, 29 Nov 92 22:21:43 +0100 Received: by dkuug.dk id AA14406 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Sun, 29 Nov 1992 22:21:42 +0100 Date: Sun, 29 Nov 1992 22:21:42 +0100 From: Keld J|rn Simonsen Message-Id: <199211292121.AA14406@dkuug.dk> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A X-Charset: ASCII X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*137 > Vad jag vet s} ing}r 8859-1 i 10646. B|r inte vara n}got problem. Jo, ISO 10646 er et problem, fordi den er totalt inkompatibelt i kodning med andre ISO standarder. Du kan f} en kode over som to bytes, hvoraf den ene er en null byte, og dette vil ofte give problemer med C baseret software. Faktisk vil hele ISO 8859-1 repertoiret komme med en NULL-byte pr tegn. Keld From owner-nordpost@nada.kth.se Sun Nov 29 22:31:21 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04257; Sun, 29 Nov 92 22:31:25 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04241; Sun, 29 Nov 92 22:31:21 +0100 Received: by dkuug.dk id AA14586 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Sun, 29 Nov 1992 22:31:19 +0100 Date: Sun, 29 Nov 1992 22:31:19 +0100 From: Keld J|rn Simonsen Message-Id: <199211292131.AA14586@dkuug.dk> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A X-Charset: ASCII X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*138 > Vad jag egentligen menar {r att ponera att vi har f|ljande inte alls > helt osannolika scenario: > > Vi p} NADA k|r internt ISO-8859-1 med sendmail som hanterar ISOC-modellen. > EN av v}ra anv{ndare skickar dock inte ISO-8859-1 utan n}gon |sterl{ndsk > kodning, s{g JIS, som inneh}ller 8bitarstecken. Tjae, s}vidt jeg ved bruger japanerne ikke 8-bit til email. De har en fast etableret 7-bits kodning...? Hvis det er en anden kodning, burde man blot angive det som charset. Keld From owner-nordpost@nada.kth.se Sun Nov 29 23:01:43 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA05752; Sun, 29 Nov 92 23:01:48 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA05735; Sun, 29 Nov 92 23:01:43 +0100 Received: by dkuug.dk id AA15245 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Sun, 29 Nov 1992 23:01:34 +0100 Date: Sun, 29 Nov 1992 23:01:34 +0100 From: Keld J|rn Simonsen Message-Id: <199211292201.AA15245@dkuug.dk> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A X-Charset: ASCII X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*139 PAF skriver: > Om man sedan ska anv{nda Keld's MNEMONICS med tabelluppslagning eller > Quoted-Printable som r{knas ut med en enkel funktion {r en annan fr}ga. > Sj{lv tycker jag, precis som andra h{r, att dessa b{gge ska enbart > anv{ndas som transportkodningar. Ingen kan ha f|r avsikt att en > anv{ndare egentligen ska beh|va se dessa kodningar. B{gge {r mycket > skilda fr}n de glyfer som egentligen ska anv{ndas. Problemet er at transportkodningen er den som vises p} maskiner, som ikke har MIME-mailere. S} derfor er det n{rmest n|dvendigt, hvis MIME og ikke-MIME verdenen skal kunne leve sammen, at transportformatet er l{seligt. Dette er hele design-ide'en bag mnemonics: at sikre at {ldre programmel stadig kan benyttes til udveksling af post p} rimelig fornuftig m}de. Mnemonics er her langt t{ttere p} hvad der egentlig skal anvendes. Forskellen p} mnemonics og hvad der sker i dag p} DKnet er meget lille, { bliver vist som ae og } som aa (hvilket desv{rre er ret normalt at skrive anyway i Danamrk), | bliver vist som o/ , hvor det ofte skrives oe. Quotet-Printable er efter min bedste mening r{dselsfuldt at l{se. Jeg forst}r at ][\ gruppen har nogle specifikationer her, som nok er mere l{sevenlige end mnemonics, og tilpasset de enkelte landes kultur, Jeg synes det ville v{re fint at indbygge dette i diverse MUAs. Men dette foruds{tter jo at nyt MIME-programmel findes, og s} er alt jo nemt. Min pointe er at for at holde ny MIME og gammel ikke-MIME verden sammen, m} man v{lge et MIME-transportformat der er mest brugervenligt over for ikke-MIME verdenen, og det er IMHO charset=MNEM > Att Quoted-Printable {r enklare att implementera tycker jag talar > f|r att vi ska rekommendera denna kodning, speciellt som denna > {ven omtalas i RFC-1341 som till{mplig om teckenupps{ttningen > {r ISO-8859-1. Det {r f|rresten Quoted-Printable som anv{nds i > de brevhanterare som anv{nder MIME som jag sett (f|rutom de > sendmail mm som Keld sj{lv skrivit), bla elm och pine. Allts} > m}ste vi }tminstone skicka Quoted-Printable som jag ser det > i en framtid p} det globala n{tet, dvs ut mot v{rlden. Tjae, jeg vil tro at det meste af verdenen uden for Norden vil v{re ikke-MIME i en lang tid fremover, og at sende Quoted-Printable ud til dem vil ikke v{re s{rligt venligt over for denne verden. Quoted-Printable er ul{seligt. MTA-er som jeg regner med vil have menmonics support snart (de har allerede en foreg}ende support) indbefatter sendmail, pp og pmdf. Elm regner jeg ogs} med vil have mnemonics suport. Keld From owner-nordpost@nada.kth.se Sun Nov 29 23:12:15 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA05878; Sun, 29 Nov 92 23:12:21 +0100 Received: from ifi.uio.no by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA05862; Sun, 29 Nov 92 23:12:15 +0100 Received: from gyda.ifi.uio.no by ifi.uio.no with SMTP id ; Sun, 29 Nov 1992 23:12:13 +0100 Received: by gyda.ifi.uio.no ; Sun, 29 Nov 1992 23:12:12 +0100 From: Erik Naggum Message-Id: <19921129.008@erik.naggum.no> Date: 29 Nov 1992 23:12:10 +0100 To: nordpost@nada.kth.se In-Reply-To: <199211292121.AA14406@dkuug.dk> (Sun, 29 Nov 1992 22:21:42 +0100) Subject: Re: MIME i Sverige, f|rslag A Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*140 | Jo, ISO 10646 er et problem, fordi den er totalt inkompatibelt i kodning | med andre ISO standarder. Du kan f} en kode over som to bytes, hvoraf | den ene er en null byte, og dette vil ofte give problemer med C | baseret software. Faktisk vil hele ISO 8859-1 repertoiret komme | med en NULL-byte pr tegn. Det er derfor vi har UTF-1. UTF-1 ble spesifisert nettopp p} grunn av intense reaksjoner fra folk som ville ha eksisterende 8-bits kanaler til } virke som tidligere. Dette har de etter min mening lykkes i, s} det argument som her presenteres b|r snarest mulig forlates. For ISO 8859-1s vedkommende, vil UTF arte seg slik: Tegnsett nr 2 (ISO 6429:1992 i C0) vil benytte en byte som tidligere. Tegnsett nr 6 (ISO 646:1991 IRV i G0) vil benytte en byte som tidligere. Tegnsett nr 100 (ISO 8859-1:1987 i G1) vil f} en prefix byte 0xA0. Verre er det ikke. From owner-nordpost@nada.kth.se Sun Nov 29 23:57:19 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA06812; Sun, 29 Nov 92 23:57:23 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA06795; Sun, 29 Nov 92 23:57:19 +0100 Received: by dkuug.dk id AA16509 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Sun, 29 Nov 1992 23:57:18 +0100 Date: Sun, 29 Nov 1992 23:57:18 +0100 From: Keld J|rn Simonsen Message-Id: <199211292257.AA16509@dkuug.dk> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A X-Charset: ASCII X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*141 > | Jo, ISO 10646 er et problem, fordi den er totalt inkompatibelt i kodning > | med andre ISO standarder. Du kan f} en kode over som to bytes, hvoraf > | den ene er en null byte, og dette vil ofte give problemer med C > | baseret software. Faktisk vil hele ISO 8859-1 repertoiret komme > | med en NULL-byte pr tegn. > > Det er derfor vi har UTF-1. UTF-1 ble spesifisert nettopp p} grunn av > intense reaksjoner fra folk som ville ha eksisterende 8-bits kanaler til > } virke som tidligere. Dette har de etter min mening lykkes i, s} det > argument som her presenteres b|r snarest mulig forlates. > Ja, det er rigtigt at UTF-1 l|ser problemet. UTF-1 er blot ikke en rigtig "normativ" del af 10646 standarden. S} vi b|r holde os for |je, at det ikke er "UNICODE" kodning som vi s} b|r udveksle post i, men et eller andet UTF format, - der er flere p} vej, bl.a. et til POSIX, som formentlig bliver normativ standard. Keld From owner-nordpost@nada.kth.se Mon Nov 30 00:21:26 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08744; Mon, 30 Nov 92 00:21:30 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08727; Mon, 30 Nov 92 00:21:26 +0100 Received: by dkuug.dk id AA20918 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Mon, 30 Nov 1992 00:21:23 +0100 Date: Mon, 30 Nov 1992 00:21:23 +0100 From: Keld J|rn Simonsen Message-Id: <199211292321.AA20918@dkuug.dk> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag B X-Charset: ASCII X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*142 > Annat f|rslag till l|sning p} (n}gra av) problemen med |verg}ng > till MIME i Sverige. > > Identifiera l{mpliga "mailgateways" som alltid ska anv{ndas vid > passage in och ut ur n{tet. T ex kan nada.kth.se (Cyklop) ses som en > s}dan f|r Nadas del. Eventuellt kan ocks} Swipnet inkluderas i detta > system. > > Ordna registrering p} n}got s{tt s} att en MTA i SUNET/MIME - dvs. en > MTA i SUNET som modifierats enligt detta f|rslag - uppfattar alla > andra MTA:er den kommunicerar som indelade i tre klasser: > > a) tillh|rande SUNET/MIME > b) tillh|rande SUNET/{ldre > c) tillh|rande "omv{rlden" > > Om ett MIME-brev m{rkt > > Content-Type: Text/Plain; charset=ISO-8859-1 > > ska skickas till en SUNET/{ldre-nod, s} avl{gsnas f|rst de tre > MIME-f{lten, brevkroppen konverteras till svensk 7-bitskod och > brevhuvudf{lt kodade enligt RFC 1342 konverteras p} liknande s{tt. Problemet med en inddeling i SUNET/{ldre er, at du aldrig ved om nogen nu har installeret den nyeste elm version med MIME support, og du derfor |del{gger support un|digt. I danmark har vi ogs} en del DKnet/{ldre - dvs ikke-MIME sites der k|rer 8-bit, faktisk ca 1/3 af vores sites er 8-bits. Disse f}r og sender 8-bit mail - som s} konverteres til 7-bits ASCII eller dansk 7-bit n}r de kommer uden for disse maskiners r{kkevidde. Dette sker p} dkuug.dk, som alts} k|rer som en slags konverter for gammel non-MIME mail. Det vil nok v{re bedre at konvertere om til MNEM tegns{t eller til ISO646-SE tegns{t med en RFC1345 Mnemonic-Intro: header, sam bibeholde de andre headere. P} den m}de udelukker du ikke eventuelle maskiner fra MIME muligheder. Din modtageradresse kunne v{re en mailliste, med mange MIME-folk p}, andre steder, s} bibeholdelse af informationen er meget |nskv{rdig. > Vid skickning till SUNET/{ldre ska d{remot brev av MIME-typen > > Content-Type: Text/Plain; charset=US-ASCII > > skickas vidare utan att {ndras. > > Brev till SUNET/MIME och till omv{rlden ska alltid g} igenom > utan att {ndras. Tjae, her g|r vi det for 8-bit non-MIME at vi omkoder det til 7-bit MNEM. > > T{nkbar ut|kning 1 > > Konvertering {ven }t andra h}llet. Ett pre-MIME-brev som kommer fr}n > SUNET/{ldre och ska till SUNET/MIME eller SUNET/{ldre skulle kunna > konverteras automatiskt till > > Content-Type: Text/Plain; charset=ISO-8859-1 > > inklusive teckenkodskonvertering av meddelandekropp och Subject:-rad. > Nackdel: US-ASCII-brev fr}n SUNET/{ldre-anv{ndare, t.ex. brev > inneh}llande C-kod eller engelsk text, till SUNET/MIME-anv{ndare blir > f|rvanskade genom att hakparenteser etc. ers{tts med svenska > bokst{ver. I danmark har det voldt f{rrest problemer at anse { for at v{re en kr|lle-parantes i konverteringen dansk 7-bit til 8859-1. > > > T{nkbar ut|kning 2 > > Ytterligare f|rslag: SUNET/MIME-MTA:erna skulle ocks} kunna g|ra n}got > }t h|ga tecken i inkommande brev, t.ex. tolka dem enligt ISO-8859-1 > och konvertera p} till{mpligt s{tt beroende p} om brevet konverteras > till pre-MIME-brev eller till ett charset=ISO-8859-1-brev. Ja, noget s}dant g|r vi i Danmark. > > T{nkbar ut|kning 3 - mer kontroversiell! > > Vissa typer av MIME-brev till en s}dan nod, bland annat s}dana som > inneh}ller typen Image/*, }ters{nds till avs{ndaren med kommentaren > > Mottagaren av det brevet kan inte hantera MIME och kunde > kunde inte ta emot hela inneh}llet i detta brev > > och mottagaren f}r ett nytt brev med f|rklaring och citat av > hanterliga delar av brevet. Det er alts} farligt at tro at man ved alt om modtageren. Hvad hvis det nu er en, der har sin egen MUA, eller post der skal videre, fx til distributionslister? > > > > > Kvarst}ende fr}getecken: > > [r ovanst}ende f|ruts{ttningar f|r identifiering m|jliga att > genomf|ra? > > Hur f}r vi fram "gateway"-programvara som utf|r konvertering > p} det s{tt vi vill? Jeg er ved at lave en ny sendmail med MIME og RFC1345 specifikationer. keld From owner-nordpost@nada.kth.se Mon Nov 30 08:48:41 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA25986; Mon, 30 Nov 92 08:48:45 +0100 Received: from malmo.trab.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA25970; Mon, 30 Nov 92 08:48:41 +0100 Received: by malmo.trab.se (5.65+bind 1.7+ida 1.4.2/TRM-1-NS); Mon, 30 Nov 92 08:48:39 +0100 (MET) Date: Mon, 30 Nov 92 08:48:39 +0100 From: Dan Oscarsson Message-Id: <9211300748.AA08172@malmo.trab.se> To: nordpost@nada.kth.se Subject: teckenuppsattningar Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*143 Jag hoppas de flesta vill ha en framtid med EN teckenkodning som används världen över, I dag finns det en tänkbar sådan: ISO 10646. Därmed bör vi för meddelande överföring (MTA till MTA) rekommendera att använda ISO 10646 eller därav äkta delmängd. Tänkbara är då ISO 8859-1, UCS-2 och UCS-4. Till att börja med bör inom norden ISO 8859-1 vara nog. När det gäller UCS-2 och UCS-4 bör dessa sändas enl. MIME i "network order" eller kodat. För kodning är inte de nuvarande i MIME helt bra, tyvärr. Dessutom finns det former typ UTF som ej heller är riktigt bra, UTF är ej ISO 8859-1 kompatibel så filer man har i ISO 8859-1-format kan ej direkt användas, ej heller kan ett filnamn i UTF-format användas i de flesta OS. Det hade behövts ett bättre kodningsförslag. Lokalt på ett ställe (dvs. UA <-> MTA) kan naturligtvis vilken teckenkod som helst användas (Mac, PC, Mnemonics etc), men då den lämnar MTA:n bör någon av ovan angivna mängder användas. Genom att enbart ha en teckenkodning som standard så är det störst sannolikhet att leverantörerna av MTA:er och UA:er stödjer den. Dan From paf@nada.kth.se Mon Nov 30 09:34:18 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA29257; Mon, 30 Nov 92 09:34:24 +0100 Received: from sysman.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA29238; Mon, 30 Nov 92 09:34:18 +0100 Received: by sysman.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14955; Mon, 30 Nov 92 09:34:14 +0100 Date: Mon, 30 Nov 1992 09:31:05 +0100 (MET) From: Patrik Faltstrom Subject: Re: MIME i Sverige, f|rslag A To: nordpost@nada.kth.se In-Reply-To: <199211292121.AA14406@dkuug.dk> Message-Id: Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*144 On Sun, 29 Nov 1992, Keld J|rn Simonsen wrote: > Jo, ISO 10646 er et problem, fordi den er totalt inkompatibelt i kodning > med andre ISO standarder. Du kan f} en kode over som to bytes, hvoraf > den ene er en null byte, og dette vil ofte give problemer med C > baseret software. Faktisk vil hele ISO 8859-1 repertoiret komme > med en NULL-byte pr tegn. Det är riktigt att 10646 inte fungerar ihop med den standard som finns för strängdefinitioner i C. ANSI är också den som jag anser har det starkaste nej-rösten mot 10646. Men, kunde inte detta lösa sig om man definierar om en "char" till två byte, och därmed att strängslut är '\0\0'? Det kommer alltid minst vara två byte per tecken, och två nullbyte efter varandra Får man i 32-bitarsversionen av 10646 se till att det inte finns med. (det här är en hel annan diskussion än MIME i sverige, men kanske finns det fler intresserade av detta med teckenstandardproblemet på listan också?) paf From paf@nada.kth.se Mon Nov 30 09:38:15 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA29482; Mon, 30 Nov 92 09:38:19 +0100 Received: from sysman.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA29466; Mon, 30 Nov 92 09:38:15 +0100 Received: by sysman.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14961; Mon, 30 Nov 92 09:38:14 +0100 Date: Mon, 30 Nov 1992 09:34:41 +0100 (MET) From: Patrik Faltstrom Subject: Re: MIME i Sverige, f|rslag A To: nordpost@nada.kth.se In-Reply-To: <199211292131.AA14586@dkuug.dk> Message-Id: Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*145 On Sun, 29 Nov 1992, Keld J|rn Simonsen wrote: > Tjae, s}vidt jeg ved bruger japanerne ikke 8-bit til email. > De har en fast etableret 7-bits kodning...? Det trodde jag också, men så enkelt verkar det inte vara. Jag vet inte exakt hur det går till, men när personen här på NADA får brev från Japan så kommer det en del 8-bits tecken. Dessa är främst BIG5-kodning av importerade kinesiska tecken i japanska verkar det som, men jag vet inte exakt vad som händer. Det kommer 8-bits-byte från Japan i varja fall. paf From owner-nordpost@nada.kth.se Mon Nov 30 09:45:21 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA00180; Mon, 30 Nov 92 09:45:25 +0100 Received: from corax.UDAC.UU.SE by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA00160; Mon, 30 Nov 92 09:45:21 +0100 Received: from alba.udac.uu.se by corax.udac.uu.se with SMTP id AA11347 (5.65+bind 1.7+ida 1.4.2/IDA-1.4.2 for nordpost@nada.kth.se); Mon, 30 Nov 92 09:45:17 +0100 Received: by alba.UDAC.UU.SE id AA04885 (5.67a8/IDA-1.5 for nordpost@nada.kth.se); Mon, 30 Nov 1992 09:45:15 +0100 Date: Mon, 30 Nov 1992 09:45:15 +0100 From: Martin Wendel Message-Id: <199211300845.AA04885@alba.UDAC.UU.SE> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag B X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*146 Keld J|rn Simonsen skriver: > > Problemet med en inddeling i SUNET/{ldre er, at du aldrig ved om > nogen nu har installeret den nyeste elm version med MIME support, > og du derfor |del{gger support un|digt. Det {r d{rf|r inte rimligt att l}ta all konvertering ske centralt. Om man kan delegera ansvaret (att h}lla reda p} vilken maskin som k|r vad) till de lokala administrat|rerna och l}ta dem k|ra en egen gateway, borde problemen kunna minimeras. Centralt st|d skall naturligtvis finnas kvar f|r att hj{lpa dem som inte {r kapabla att sk|ta egen gateway. > I danmark har vi ogs} en del DKnet/{ldre - dvs ikke-MIME sites > der k|rer 8-bit, faktisk ca 1/3 af vores sites er 8-bits. > Disse f}r og sender 8-bit mail - som s} konverteres til 7-bits > ASCII eller dansk 7-bit n}r de kommer uden for disse maskiners r{kkevidde. Dette > sker p} dkuug.dk, som alts} k|rer som en slags konverter for > gammel non-MIME mail. > > Det vil nok v{re bedre at konvertere om til MNEM tegns{t eller > til ISO646-SE tegns{t med en RFC1345 Mnemonic-Intro: header, sam > bibeholde de andre headere. > P} den m}de udelukker du ikke eventuelle maskiner fra MIME muligheder. > Din modtageradresse kunne v{re en mailliste, med mange MIME-folk > p}, andre steder, s} bibeholdelse af informationen er meget |nskv{rdig. > Detta {r den stora f|rdelen med MNEM som MIME med Quoted-Printable inte kan motsvara. (Huruvida MNEM eller Quoted-Printable {r mer l{ttl{st {r v{l beroende p} om man {r van vid att l{sa hexkod eller inte;) Det finns dock ett problem med MNEM och ISO646-SE som man inte f}r gl|mma bort. Text g}r alldeles utm{rkt att skriva i ISO646-SE men uuencodade eller BinHexade filer m}ste skrivas i ISO646-US (dessa format kan inte representeras i ISO646-SE eftersom ISO646-SE saknar tecknen {,},| etc). Tyv{rr ger MNEMONICs problem med uuencodade eller binhexade filer eftersom {,},| etc resentereras som mnemoniska tecken. Hur har ni l|st detta i Danmark? > > > > T{nkbar ut|kning 2 > > > > Ytterligare f|rslag: SUNET/MIME-MTA:erna skulle ocks} kunna g|ra n}got > > }t h|ga tecken i inkommande brev, t.ex. tolka dem enligt ISO-8859-1 > > och konvertera p} till{mpligt s{tt beroende p} om brevet konverteras > > till pre-MIME-brev eller till ett charset=ISO-8859-1-brev. > > Ja, noget s}dant g|r vi i Danmark. Kan man dra slutsatsen att majoriteten av de om{rkta 8bitars breven verkligen {r ISO8859-1? Har n}gon unders|kt detta? > > > > T{nkbar ut|kning 3 - mer kontroversiell! > > > > Vissa typer av MIME-brev till en s}dan nod, bland annat s}dana som > > inneh}ller typen Image/*, }ters{nds till avs{ndaren med kommentaren > > > > Mottagaren av det brevet kan inte hantera MIME och kunde > > kunde inte ta emot hela inneh}llet i detta brev > > > > och mottagaren f}r ett nytt brev med f|rklaring och citat av > > hanterliga delar av brevet. > > Det er alts} farligt at tro at man ved alt om modtageren. > Hvad hvis det nu er en, der har sin egen MUA, eller post der skal > videre, fx til distributionslister? Jag tycker att en typ Image, Adio, Video etc borde betraktas som en bin{rfil i det h{r fallet och konverteras till uuencode eller binhex och p} s} s{tt ge mottagaren en chans att tolka dem. > > > > Hur f}r vi fram "gateway"-programvara som utf|r konvertering > > p} det s{tt vi vill? > > Jeg er ved at lave en ny sendmail med MIME og RFC1345 specifikationer. > Det vore intressant att veta ungef{r vilka specifikationer den skall uppfylla. ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From psv@nada.kth.se Mon Nov 30 17:54:52 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA27545; Mon, 30 Nov 92 17:54:58 +0100 Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA27527; Mon, 30 Nov 92 17:54:52 +0100 Message-Id: <9211301654.AA27527@nada.kth.se> To: nordpost@nada.kth.se Subject: Var tydlig med teckenangivelser! Date: Mon, 30 Nov 92 17:54:51 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*147 > I danmark har det voldt f{rrest problemer at anse { for at v{re > en kr|lle-parantes i konverteringen dansk 7-bit til 8859-1. > ... (dessa format kan inte representeras i ISO646-SE eftersom > ISO646-SE saknar tecknen ä,å,ö etc). Tyvärr ger MNEMONICs problem med > uuencodade eller binhexade filer eftersom ä,å,ö etc resentereras som > mnemoniska tecken. ... Snälla, undvik formuleringar som blir onödigt svårtydda om dom blir konverterade till sjubit. From psv@nada.kth.se Mon Nov 30 18:04:55 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA29650; Mon, 30 Nov 92 18:05:13 +0100 Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA29614; Mon, 30 Nov 92 18:04:55 +0100 Message-Id: <9211301704.AA29614@nada.kth.se> To: nordpost@nada.kth.se Subject: MNEMONICS roll Date: Mon, 30 Nov 92 18:04:53 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*148 Detta är vad som enligt förslag B händer vid sänding av MIME-brev in till Sverige. UA-sänd (1) MTA-sänd (2) MTA-mellan ("gateway") Sverige (3) icke-MIME-MTA-mottag (4) övriga MTA-mottag (6) Sverige UA-mottag (5) UA-mottag (7) (1) MIME, Text/Plain, Latin-1 (2) Ingen ändring (3) Brev till (4): Konv. MIME Latin-1 -> icke-MIME Svensk sjubit övriga brev: Ingen ändring (4) och (5) får sjubitsbrev som förut (6) och (7) får MIME, Latin-1 Keld: > Stötten til MNEMONICs behöver blot at väre minimal. > Jeg mener elm vil lave det. Også sendmail vil blive rettet til. > Det burde ikke väre noget problem at sende MNEMONICS breve ud i verden. Här talar du både om UA:er och om MTA:er. Menar du att ibland kommer MNEMONICS nå UA:n och ibland ska den konverteras i MTA:n? Förklara gärna hur det fungerar. För att en mottagare ska kunna förstå ett MNEMONICS-kodat brev krävs alltså att hans MTA har MNMEMONICS-konvertering påslaget eller att mottagaren kör en UA med MNEMONICS-understöd? Keld: > Problemet er at transportkodningen er den som vises på maskiner, > som ikke har MIME-mailere. Så derfor er det närmest nödvendigt, > hvis MIME og ikke-MIME verdenen skal kunne leve sammen, at > transportformatet er läseligt. Dette er hele design-ide'en > bag mnemonics: at sikre at äldre programmel stadig kan benyttes > til udveksling af post på rimelig fornuftig måde. Detta förutsätter att man _inte_ gör som i B-förslaget, eller att B-förslaget inte kan täcka in alla icke-MIME-mottagare. Keld: > Tjae, jeg vil tro at det meste af verdenen uden for Norden vil väre > ikke-MIME i en lang tid fremover, og at sende Quoted-Printable ud til > dem vil ikke väre särligt venligt over for denne verden. > Quoted-Printable er uläseligt. _Det_ var en intressant aspekt. Kommer det under lång tid att anses ohyfsat att skicka MIME + QUOTED-PRINTABLE ut i världen (icke-Norden), medan det anses mindre ohyfsat att skicka MIME + MNEM(ONICS)? Oavsett om MIME-mottagare kan avkoda det senare eller inte? > Problemet med en inddeling i SUNET/äldre er, at du aldrig ved om > nogen nu har installeret den nyeste elm version med MIME support, > og du derfor ödelägger support unödigt. Om samtliga UA i en domän har MIME-understöd är det inte längre en SUNET/äldre. Om bara några UA har det får dom inte tillgång till inkommande MIME-brev, nej. Det är en nackdel med denna lösning. > Det vil nok väre bedre at konvertere om til MNEM tegnsät eller > til ISO646-SE tegnsät med en RFC1345 Mnemonic-Intro: header, sam > bibeholde de andre headere. > På den måde udelukker du ikke eventuelle maskiner fra MIME muligheder. > Din modtageradresse kunne väre en mailliste, med mange MIME-folk > på, andre steder, så bibeholdelse af informationen er meget önskvärdig. Du menar att man i (3) istället för att ta bort Content-Type: Text/Plain; charset=ISO-8859-1 skulle den bytas till Content-Type: Text/Plain; charset=X-SEN... eller X-MNEM och en rad X-Mnemonic-Intro: 8200 (om MNEM används) skulle läggas till? Tja, förutom att gamla-UA-användare får ytterligare två eller tre skräpbrevhuvudrader när dom läser post så är väl detta ingen nackdel. --- Peter Svanberg From psv@nada.kth.se Mon Nov 30 18:06:47 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA29769; Mon, 30 Nov 92 18:06:55 +0100 Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA29742; Mon, 30 Nov 92 18:06:47 +0100 Message-Id: <9211301706.AA29742@nada.kth.se> To: nordpost@nada.kth.se Subject: "Intro"-tecken i MNEMONICS Date: Mon, 30 Nov 92 18:06:41 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*149 Keld: > Forskellen på mnemonics og hvad der sker i dag på DKnet er meget lille, > ä bliver vist som ae ... Att ha (1D hex) som "intro" tycker jag inte om - mitt terminalprogram (NCSA Telnet för Mac) tycker det är inledning på Tektronix-grafiksekvens! Är det bara jag som klagat på det? From owner-nordpost@nada.kth.se Mon Nov 30 20:49:44 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA10747; Mon, 30 Nov 92 20:50:27 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA10692; Mon, 30 Nov 92 20:49:44 +0100 Received: by dkuug.dk id AA02769 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Mon, 30 Nov 1992 20:49:36 +0100 Date: Mon, 30 Nov 1992 20:49:36 +0100 From: Keld J|rn Simonsen Message-Id: <199211301949.AA02769@dkuug.dk> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A X-Charset: ASCII X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden* PAF skriver: > > On Sun, 29 Nov 1992, Keld J|rn Simonsen wrote: > > > Jo, ISO 10646 er et problem, fordi den er totalt inkompatibelt i kodning > > med andre ISO standarder. Du kan f} en kode over som to bytes, hvoraf > > den ene er en null byte, og dette vil ofte give problemer med C > > baseret software. Faktisk vil hele ISO 8859-1 repertoiret komme > > med en NULL-byte pr tegn. > > Det {r riktigt att 10646 inte fungerar ihop med den standard som finns > f|r str{ngdefinitioner i C. ANSI {r ocks} den som jag anser har det > starkaste nej-r|sten mot 10646. > > Men, kunde inte detta l|sa sig om man definierar om en "char" till > tv} byte, och d{rmed att str{ngslut {r '\0\0'? Det kommer alltid > minst vara tv} byte per tecken, och tv} nullbyte efter varandra Jo, det kunne man godt, og det er ISO 10646-folkenes svar til C folkenes klager. Problemet er med eksisterende software, det er jo ikke s} let blot at lave char om fra 8 til 16 bit. Man skal bl.a have kildeteksten... Og en modificeret compiler... > F}r man i 32-bitarsversionen av 10646 se till att det inte finns med. Dette forstod jeg ikke helt. Mener du at man skulle kunne fjerne problemet med null-bytes i 32-bit versionen af 10646? 32-bits versionen er allerede defineret, og den har ogs} null-byte problemet. Men et format UTF er defineret, hvor alle bytes der har kontroltegns koder, ogs} precist er disse kontroltegn. For|vrigt er ISO C folkene rimeligt glade for 10646, det passer p{nt ind i deres widechar streng-koncept. Keld From owner-nordpost@nada.kth.se Mon Nov 30 21:28:11 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA13170; Mon, 30 Nov 92 21:28:58 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA13142; Mon, 30 Nov 92 21:28:11 +0100 Received: by dkuug.dk id AA04368 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Mon, 30 Nov 1992 21:27:55 +0100 Date: Mon, 30 Nov 1992 21:27:55 +0100 From: Keld J|rn Simonsen Message-Id: <199211302027.AA04368@dkuug.dk> To: nordpost@nada.kth.se Subject: Re: "Intro"-tecken i MNEMONICS X-Charset: ASCII X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden* > Keld: > > Forskellen p} mnemonics og hvad der sker i dag p} DKnet er meget lille, > > { bliver vist som ae ... > > Att ha (1D hex) som "intro" tycker jag inte om - mitt > terminalprogram (NCSA Telnet f|r Mac) tycker det {r inledning p} > Tektronix-grafiksekvens! [r det bara jag som klagat p} det? Jeg havde en anden klage fra en Ungarer, men ikke nogen klager i Danmark. jeg vil ogs} hellere bruge MNEM, som bruger space-backspace (to tegn) som introduktionstegn, det burde v{re mere sikkert og p{nere. keld From owner-nordpost@nada.kth.se Mon Nov 30 23:36:42 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA18126; Mon, 30 Nov 92 23:37:29 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA18111; Mon, 30 Nov 92 23:36:42 +0100 Received: by dkuug.dk id AA08036 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Mon, 30 Nov 1992 23:36:35 +0100 Date: Mon, 30 Nov 1992 23:36:35 +0100 From: Keld J|rn Simonsen Message-Id: <199211302236.AA08036@dkuug.dk> To: nordpost@nada.kth.se Subject: Re: MNEMONICS roll X-Charset: ASCII X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden* > > Detta {r vad som enligt f|rslag B h{nder vid s{nding av MIME-brev > in till Sverige. > > UA-s{nd (1) > > MTA-s{nd (2) > > MTA-mellan ("gateway") Sverige (3) > > icke-MIME-MTA-mottag (4) |vriga MTA-mottag (6) > Sverige > > UA-mottag (5) UA-mottag (7) > > > (1) MIME, Text/Plain, Latin-1 > (2) Ingen {ndring > (3) Brev till (4): Konv. MIME Latin-1 -> icke-MIME Svensk sjubit > |vriga brev: Ingen {ndring > > (4) och (5) f}r sjubitsbrev som f|rut > (6) och (7) f}r MIME, Latin-1 > > > Keld: > > St|tten til MNEMONICs beh|ver blot at v{re minimal. > > Jeg mener elm vil lave det. Ogs} sendmail vil blive rettet til. > > Det burde ikke v{re noget problem at sende MNEMONICS breve ud i verden. > > H{r talar du b}de om UA:er och om MTA:er. Menar du att ibland kommer > MNEMONICS n} UA:n och ibland ska den konverteras i MTA:n? F|rklara > g{rna hur det fungerar. > > F|r att en mottagare ska kunna f|rst} ett MNEMONICS-kodat brev kr{vs > allts} att hans MTA har MNMEMONICS-konvertering p}slaget eller att > mottagaren k|r en UA med MNEMONICS-underst|d? Det er ikke n|dvendigt at have en MTA eller UA der kender til mnemonics. Det er pointen, at et brev i menonics burde kunne l{ses af en slutbruger uden at have noget nyt programmel til det. Dvs. mnemonics kan behandles af eksisterende MTA og UA-er. Det vil selvf|lgeligt v{re godt om der var st|tte for mnemonics, s} fx hvis brugeren har 8-bit support at hun kan f} sit brev vist med de rigtige tegn. Denne support kan ligge flere steder: 1. UA: denne kan have MIME support med mnemonics konvertering - tegnene kommer s} p{nt frem. den kan ogs} blot have mnemonics support i form af et filter, fx mailx mailerens pager - s}dan k|rer jeg med det nu. Pagerens output kan v{re afh{ngig af forskellig terminaludrustning, fx PC, Mac, X eller gammel 7bit. Hvis man ikke har en UA, der forst}r mnemonics, kan man g|re det i en MTA. 2. MTA: MTA-en kan konvertere til et format som UA-en kan forst}. Mange UA-er kan allerede nu k|re 8-bit uden videre, afh{ngigt af hvilken editor, der bruges. Hvis mail bliver sendt til en site, kan MTA-en rekode al mnemonic mail til latin-1 og de forskellige UA-er kan s} bare h}ndtere dette 8-bits tegns{t. Dette kan v{re en fordel kun at opdatere MTA-en, hvis man har flere UA-er, hvoraf en eller flere ikke har mime support endnu eller hvor man ikke kan f} kildeteksten til UA-en eller af andre }rsager ikke kan opdatere sine UA-er. 3. Man kan ogs} have en rel{-MTA, som sender post frem i et format som den lokale MTA og UA-er forst}r. Det er fx hvad dkuug.dk g|r over for vores 40 8-bits UUCP og SMTP kunder. Fx SunOS 4.1.1 kunder via UUCP, kan f} Latin-1 sendt fra dkuug.dk. Eller Microsoft Mail kunder kan via SMTP sende PC850 tekst ind, som s} konverteres p} dkuug.dk til andet tegns{t. I dette tilf{lde er der ingen modifikation af software p} den aktuelle site, men al ops{tning foreg}r p} en rel{-MTA. Nemt for brugeren! > Keld: > > Problemet er at transportkodningen er den som vises p} maskiner, > > som ikke har MIME-mailere. S} derfor er det n{rmest n|dvendigt, > > hvis MIME og ikke-MIME verdenen skal kunne leve sammen, at > > transportformatet er l{seligt. Dette er hele design-ide'en > > bag mnemonics: at sikre at {ldre programmel stadig kan benyttes > > til udveksling af post p} rimelig fornuftig m}de. > > Detta f|ruts{tter att man _inte_ g|r som i B-f|rslaget, eller att > B-f|rslaget inte kan t{cka in alla icke-MIME-mottagare. Jeg er ikke helt med. Forklar n{rmere hvor du ser problemer. > Keld: > > Tjae, jeg vil tro at det meste af verdenen uden for Norden vil v{re > > ikke-MIME i en lang tid fremover, og at sende Quoted-Printable ud til > > dem vil ikke v{re s{rligt venligt over for denne verden. > > Quoted-Printable er ul{seligt. > > _Det_ var en intressant aspekt. Kommer det under l}ng tid att anses > ohyfsat att skicka MIME + QUOTED-PRINTABLE ut i v{rlden (icke-Norden), > medan det anses mindre ohyfsat att skicka MIME + MNEM(ONICS)? Oavsett > om MIME-mottagare kan avkoda det senare eller inte? MIME-modtagere burde kunne afkode MNEMONICS, som jo er en MIME specifikation. Quoted-Printable i r} form er efter min bedste mening ul{seligt, i hvertfald for dansk, svensk, finsk, norsk, tysk, fransk. I|vrigt syens jeg at vores diskussion her p} denne email-liste k|rer fint, mht tegns{t! Hurra for gammel 7-bits mail! > > Problemet med en inddeling i SUNET/{ldre er, at du aldrig ved om > > nogen nu har installeret den nyeste elm version med MIME support, > > og du derfor |del{gger support un|digt. > > Om samtliga UA i en dom{n har MIME-underst|d {r det inte l{ngre en > SUNET/{ldre. Om bara n}gra UA har det f}r dom inte tillg}ng till > inkommande MIME-brev, nej. Det {r en nackdel med denna l|sning. > > > Det vil nok v{re bedre at konvertere om til MNEM tegns{t eller > > til ISO646-SE tegns{t med en RFC1345 Mnemonic-Intro: header, samt > > bibeholde de andre headere. > > P} den m}de udelukker du ikke eventuelle maskiner fra MIME muligheder. > > Din modtageradresse kunne v{re en mailliste, med mange MIME-folk > > p}, andre steder, s} bibeholdelse af informationen er meget |nskv{rdig. > > Du menar att man i (3) ist{llet f|r att ta bort > > Content-Type: Text/Plain; charset=ISO-8859-1 > > skulle den bytas till > > Content-Type: Text/Plain; charset=X-SEN... eller X-MNEM Content-Type: Text/Plain; charset=SE Der er ikke "X-" foran, idet en svensk 7-bit er defineret hos IANA. > > och en rad > > X-Mnemonic-Intro: 8200 Der er ikke noget X- p}, "Mnemonic-Intro:" header er veldefineret i en RFC, nemlig RFC1345. Alts}: Mnemonic-Intro: 8200 > > (om MNEM anv{nds) skulle l{ggas till? Tja, f|rutom att > gamla-UA-anv{ndare f}r ytterligare tv} eller tre skr{pbrevhuvudrader > n{r dom l{ser post s} {r v{l detta ingen nackdel. De kan i flere mailere blot fjernes, ligesom "Received:" headere ofte fjernes. keld . . From owner-nordpost@nada.kth.se Mon Nov 30 23:56:19 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA18666; Mon, 30 Nov 92 23:57:02 +0100 Received: from ifi.uio.no by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA18627; Mon, 30 Nov 92 23:56:19 +0100 Received: from driva.ifi.uio.no by ifi.uio.no with SMTP id ; Mon, 30 Nov 1992 23:56:14 +0100 Received: by driva.ifi.uio.no ; Mon, 30 Nov 1992 23:56:14 +0100 From: Erik Naggum Message-Id: <19921130.003@erik.naggum.no> Date: 30 Nov 1992 23:56:13 +0100 To: nordpost@nada.kth.se In-Reply-To: <199211302027.AA04368@dkuug.dk> Subject: Re: "Intro"-tecken i MNEMONICS Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden* [Keld J|rn Simonsen] | | Jeg havde en anden klage fra en Ungarer, men ikke nogen klager i | Danmark. Er ikke dette det samme som "det virker for meg", og "ingen har klaget p} det hittil"? Begge t|r v{re godt kjente argumenter blant d}rlige programmerere som ikke vet hva de driver med. | jeg vil ogs} hellere bruge MNEM, som bruger space-backspace (to | tegn) som introduktionstegn, det burde v{re mere sikkert og p{nere. Keld, du m} forst} at n}r du introduserer en spesiell notasjon, som MNEM(ONICS), kan du ikke late som om du ikke gj|r det. Du m} la det v{re opp til brukerne p} hver side } bli enige om en l|sning som virker for dem, og ikke p}legge dem konverteringer som de ikke vet om. Hvis de blir enige om at &aa er en a med ring, er det greit. Hvis de skal bli lurt til } tro at avsenderen sendte noe s} dumt som " ^Haa" (for det er det mange vil se), vil de g} bort fra nasjonale tegn og over til } bruke "aa" fordi "nasjonale tegn ikke virker". SPACE BACKSPACE forventer at alle displays behandler BACKSPACE som "g} ett steg tilbake", og ikke viser det frem som "^H". Likeledes forventet ditt forrige fors|k at en kontroll-kode "ikke er i bruk" av noen, noe sted. Ingen av disse forventningene kan sies } holde, og du m} ha mot til } si at "her bruker vi en notasjon, fordi r} tekst ikke holder m}l". Mitt egentlige argument er at Internet mail ikke lenger er ukodet tekst, men m} tolkes som en "character data stream". Dette kan gj|res p} mange m}ter, og UA'ene m} gj|res sterke nok til } tolke en eller annen kodet form, uansett. Hvorfor vi da ikke bruker ISO 2022 har jeg aldri skj|nt, men det er vel fordi det er en internasjonal standard, allerede, og da er det naturligvis mye morsommere } lage sin egen standard. (Dette er b}de et stikk til Keld og til hele MIME-prosjektet, som jeg efterhvert synes ser mer og mer "hjemmelagd" ut, og ulikt mors kj|ttkaker, er ikke det et kompliment.) From owner-nordpost@nada.kth.se Tue Dec 1 00:03:14 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA19943; Tue, 1 Dec 92 00:03:56 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA19924; Tue, 1 Dec 92 00:03:14 +0100 Received: by dkuug.dk id AA08838 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Tue, 1 Dec 1992 00:03:11 +0100 Date: Tue, 1 Dec 1992 00:03:11 +0100 From: Keld J|rn Simonsen Message-Id: <199211302303.AA08838@dkuug.dk> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag B X-Charset: ASCII X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden* > Keld J|rn Simonsen skriver: > > > > > > Problemet med en inddeling i SUNET/{ldre er, at du aldrig ved om > > nogen nu har installeret den nyeste elm version med MIME support, > > og du derfor |del{gger support un|digt. > > Det {r d{rf|r inte rimligt att l}ta all konvertering ske centralt. Om > man kan delegera ansvaret (att h}lla reda p} vilken maskin som k|r vad) > till de lokala administrat|rerna och l}ta dem k|ra en egen gateway, > borde problemen kunna minimeras. Centralt st|d skall naturligtvis finnas > kvar f|r att hj{lpa dem som inte {r kapabla att sk|ta egen gateway. Ja, det lyder meget fornuftigt, men en yderligere konklusion kunne v{re at al konvertering skulle v{re informationsbevarende. S} er det ikke s} v{sentligt hvad en central konvertering g|r, man kan altid f} den rigtige information frem. > > Det finns dock ett problem med MNEM och ISO646-SE som man inte f}r gl|mma bort. > Text g}r alldeles utm{rkt att skriva i ISO646-SE men uuencodade eller > BinHexade filer m}ste skrivas i ISO646-US (dessa format kan inte > representeras i ISO646-SE eftersom ISO646-SE saknar tecknen {,},| etc). > Tyv{rr ger MNEMONICs problem med uuencodade eller binhexade filer eftersom > {,},| etc resentereras som mnemoniska tecken. > > Hur har ni l|st detta i Danmark? Vi har l|st det ved at sige at koderne i 7-bits dansk egentlig er ASCII-koderne. Hermed elimineres problemerne med uuencode og C programmmer mv, men det giver det problem, at 7bits dansk bliver til kr|llede paranteser i iso 8859-1 etc. Tegns{ttet kaldes "US-DK" Latin-1 til 7bits dansk overs{tter b}de de kr|llede paranteser mv og de danske 8-bits {|} (og vistnok ogs} svenske }{|) til de rigtige danske tegn. Det er lidt et hack, man hvad kan man g|re? Vi bruger jo faktisk (b}de i Sverige og Danmark og Norge og Finland) den samme bin{re kode i 7-bit, n}r vi mener et bogstav eller et ASCII tegn. S} vores brug af tegns{t er tvetydigt defineret. Ovenst}ende er default. Man kan s{tte sit tegns{t explicit i sin UA, og det k|rende programmel vil s} respektere dette. Dette vil give rigtig konvertering fra dansk 7-bit af danske bogstaver til 8859-1 - fra tegns{ttet DK. > > > > T{nkbar ut|kning 2 > > > > > > Ytterligare f|rslag: SUNET/MIME-MTA:erna skulle ocks} kunna g|ra n}got > > > }t h|ga tecken i inkommande brev, t.ex. tolka dem enligt ISO-8859-1 > > > och konvertera p} till{mpligt s{tt beroende p} om brevet konverteras > > > till pre-MIME-brev eller till ett charset=ISO-8859-1-brev. > > > > Ja, noget s}dant g|r vi i Danmark. > > Kan man dra slutsatsen att majoriteten av de om{rkta 8bitars breven > verkligen {r ISO8859-1? Har n}gon unders|kt detta? DKnets registrerede 8-bits sites er 1/3 PC og 2/3 latin-1. Vi regner med flere Mac-brugere snart. Jeg vil tro at rimeligt mange brugere vil k|re ikke-latin-1, s} mange at det vil give problemer. > > > Jeg er ved at lave en ny sendmail med MIME og RFC1345 specifikationer. > > > > Det vore intressant att veta ungef{r vilka specifikationer den skall > uppfylla. Det er en opdatering af sendmail5.65c8, med udskiftning af non-standard headers med MIME standard headers. Desuden vil konvertering kun ske p} text/plain. keld From owner-nordpost@nada.kth.se Tue Dec 1 00:55:53 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA21769; Tue, 1 Dec 92 00:56:42 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA21751; Tue, 1 Dec 92 00:55:53 +0100 Received: by dkuug.dk id AA12048 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Tue, 1 Dec 1992 00:55:50 +0100 Date: Tue, 1 Dec 1992 00:55:50 +0100 From: Keld J|rn Simonsen Message-Id: <199211302355.AA12048@dkuug.dk> To: nordpost@nada.kth.se Subject: Re: "Intro"-tecken i MNEMONICS X-Charset: ASCII X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden* > [Keld J|rn Simonsen] > | > | Jeg havde en anden klage fra en Ungarer, men ikke nogen klager i > | Danmark. > > Er ikke dette det samme som "det virker for meg", og "ingen har klaget > p} det hittil"? Begge t|r v{re godt kjente argumenter blant d}rlige > programmerere som ikke vet hva de driver med. Tjae, jeg havde unders|gt det rimeligt l{nge, og ikke fundet problemer med det; control-} var ogs} hvad man brugte som default escape tegn i forskellige telnet implementationer. Men, jo, der var nogle problemer i det, og derfor lavede jeg sammen med nogle andre space-backspace specifikationen. Jeg synes ikke at man kan sige at jeg har v{ret ligeglad med resten af verden! > | jeg vil ogs} hellere bruge MNEM, som bruger space-backspace (to > | tegn) som introduktionstegn, det burde v{re mere sikkert og p{nere. > > Keld, du m} forst} at n}r du introduserer en spesiell notasjon, som > MNEM(ONICS), kan du ikke late som om du ikke gj|r det. Du m} la det > v{re opp til brukerne p} hver side } bli enige om en l|sning som virker > for dem, og ikke p}legge dem konverteringer som de ikke vet om. Hvis de > blir enige om at &aa er en a med ring, er det greit. Hvis de skal bli > lurt til } tro at avsenderen sendte noe s} dumt som " ^Haa" (for det er > det mange vil se), vil de g} bort fra nasjonale tegn og over til } bruke > "aa" fordi "nasjonale tegn ikke virker". SPACE BACKSPACE forventer at > alle displays behandler BACKSPACE som "g} ett steg tilbake", og ikke > viser det frem som "^H". Likeledes forventet ditt forrige fors|k at en > kontroll-kode "ikke er i bruk" av noen, noe sted. Ingen av disse > forventningene kan sies } holde, og du m} ha mot til } si at "her bruker > vi en notasjon, fordi r} tekst ikke holder m}l". intro-tegnet er jo valgbart, s} den enkelte bruger kan v{lge hvad der passer vedkommende bedst, endda i forskellige situationer. Notationen som jeg har opfundet og promoverer, har som et af sine fremmeste m}l, at den skulle (med m}ske lidt besv{r, men med s} lidt besv{r som muligt) v{re l{sbar af en slutbruger, samtidig med at al information bibeholdtes. Derfor er det vigtigt at overfl|dig og generende information s}som intro-specifikation kan g|res usynlig for slutbrugeren fx ved l{sning. > Mitt egentlige argument er at Internet mail ikke lenger er ukodet tekst, > men m} tolkes som en "character data stream". Dette kan gj|res p} mange > m}ter, og UA'ene m} gj|res sterke nok til } tolke en eller annen kodet > form, uansett. Hvorfor vi da ikke bruker ISO 2022 har jeg aldri skj|nt, > men det er vel fordi det er en internasjonal standard, allerede, og da > er det naturligvis mye morsommere } lage sin egen standard. (Dette er > b}de et stikk til Keld og til hele MIME-prosjektet, som jeg efterhvert > synes ser mer og mer "hjemmelagd" ut, og ulikt mors kj|ttkaker, er ikke > det et kompliment.) Tjae, mnemonics er da mit barn, og ikke en ISO standard, men det arbejder jeg p}, som du ved! Mnemonics har en fuktionalitet som eksisterende ISO tegns{t og mekanismer som 2022 ikke har, nemlig at du kan pr{sentere og generere en masse tegn med minimalt udstyr; et invariant ISO 646 repertoire er alt du beh|ver for at v{re i luften. Mnemonics l{gger sig op af alle de tegns{tsstandarder som jeg har kunnet komme i n{rheden af, s} den er en stor bruger af ISO standarder. Jeg ser den faktisk som det bindemiddel, der kan f} alle (n{sten!) de eksisterende tegns{tsstandarder til at spille sammen, p} alt (n{sten!) udstyr. Og det er IMHO da et fremskridt! Ellers er noget af det f|rste og vanskeligste forhindring for at kommunikere mellem maskiner og flytte programmer nemlig tegns{t. 2022 har ikke den egenskab. Du kan ikke f} vist ethvert tegn p} en nogenlunde m}de, idet dit udstyr ikke kan fx vise et gr{sk lille pi. Du kan ikke l{se nogenlunde flydende latin, gr{sk, kyrillisk, arabisk, hebr{isk, japansk kana, medmindre du har udstyr der underst|tter det rigtige tegns{t. Men du kan da nok generere et tegn i fuld 2022 ved at indtaste de rigtige escape-sekvenser og s} den rigtige kode, det er nok noget mere bsv{rligt end at bruge mnemonics. It can be done - jeg kender en del almindelige sekret{rer der indtaster gr{ske bogstaver som PC ALT-123 eller WordPerfect tegns{tskoder. Men MIMEs richtext er da ustandardiseret og kunne nok have v{ret mere gennemt{nkt og lavet fuldt kompatibelt med SGML uden st|rre arbejde. MIMEs bodytyper er s} vidt jeg ved p{nt overensstemmende med X.400 - nogen beskylder MIME for at v{re en indf|relse af X.400 af bagvejen. S} jeg deler din anskuelse at vi b|r bruge internationale standarder, men for at f} ny funktionalitet m} man alts} lave noget nyt! Keld From psv@nada.kth.se Tue Dec 1 02:22:50 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA26750; Tue, 1 Dec 92 02:22:57 +0100 Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA26730; Tue, 1 Dec 92 02:22:50 +0100 Message-Id: <9212010122.AA26730@nada.kth.se> To: nordpost@nada.kth.se Subject: Re: MNEMONICS roll In-Reply-To: <199211302236.AA08036@dkuug.dk> from "Keld J|rn Simonsen " "Mon, 30 Nov 1992 23:36:35 +0100 " Date: Tue, 01 Dec 92 02:22:49 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*150 Citat ur brev från: Keld J|rn Simonsen > > > Keld: > > > Problemet er at transportkodningen er den som vises p} maskiner, > > > som ikke har MIME-mailere. S} derfor er det n{rmest n|dvendigt, > > > hvis MIME og ikke-MIME verdenen skal kunne leve sammen, at > > > transportformatet er l{seligt. Dette er hele design-ide'en > > > bag mnemonics: at sikre at {ldre programmel stadig kan benyttes > > > til udveksling af post p} rimelig fornuftig m}de. > > > > Detta f|ruts{tter att man _inte_ g|r som i B-f|rslaget, eller att > > B-f|rslaget inte kan t{cka in alla icke-MIME-mottagare. > > Jeg er ikke helt med. Forklar n{rmere hvor du ser problemer. Jag syftade på att med B-förslaget borde ingen icke-MIME-mottagare i Sverige få någon MIME-post - allt avkodas dessförinnan. > MIME-modtagere burde kunne afkode MNEMONICS, som jo er en MIME specifikation. Nu är vi ute på hal is igen: Då varken MIME-RFC:n eller aktuellt IANA-dokument nämner MNEMOMICS tycker jag inte du har rätt att kalla det en MIME-specifikation! > Quoted-Printable i r} form er efter min bedste mening ul{seligt, > i hvertfald for dansk, svensk, finsk, norsk, tysk, fransk. Jo men det är entydigt avkodbart endast med hjälp av teckenkodsstandarden. För att avkoda MNEMONICS krävs MNEMONICS-tabellerna, som är betydligt mindre spridda. > > skulle den bytas till > > > > Content-Type: Text/Plain; charset=X-SEN... eller X-MNEM > > Content-Type: Text/Plain; charset=SE > > Der er ikke "X-" foran, idet en svensk 7-bit er defineret hos IANA. Jag har inte fått svar på SMTP-listan om detta ännu, men min (och andras) tolkning av MIME och IANA-dokumentet är att bara det som står som "Character set" med hänvisning MIME-RFC:n får användas utan "X-" framför. > > och en rad > > > > X-Mnemonic-Intro: 8200 > > Der er ikke noget X- p}, "Mnemonic-Intro:" header er veldefineret i > en RFC, nemlig RFC1345. Alts}: Ännu tydligare här: En "informational RFC" kan knappast definiera nya officiella brevhuvudfält! > > gamla-UA-anv{ndare f}r ytterligare tv} eller tre skr{pbrevhuvudrader > > n{r dom l{ser post > > De kan i flere mailere blot fjernes, ligesom "Received:" headere ofte > fjernes Visst, men jag tror väldigt många användare inte vet hur man gör det utan får stå ut med 10-15 skräprader innan texten kommer! From owner-nordpost@nada.kth.se Tue Dec 1 02:25:06 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA26856; Tue, 1 Dec 92 02:25:48 +0100 Received: from ifi.uio.no by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA26843; Tue, 1 Dec 92 02:25:06 +0100 Received: from driva.ifi.uio.no by ifi.uio.no with SMTP id ; Tue, 1 Dec 1992 02:25:05 +0100 Received: by driva.ifi.uio.no ; Tue, 1 Dec 1992 02:25:04 +0100 From: Erik Naggum Reply-To: Erik Naggum Message-Id: <19921201.005@erik.naggum.no> Date: 01 Dec 1992 02:25:03 +0100 To: Keld J|rn Simonsen Cc: nordpost@nada.kth.se In-Reply-To: <199211302355.AA12048@dkuug.dk> References: <199211302355.AA12048@dkuug.dk> Subject: Re: "Intro"-tecken i MNEMONICS Errors-To: owner-nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden* [Keld J|rn Simonsen] | | Tjae, jeg havde unders|gt det rimeligt l{nge, og ikke fundet problemer | med det; control-} var ogs} hvad man brugte som default escape | tegn i forskellige telnet implementationer. Men, jo, der var nogle | problemer i det, og derfor lavede jeg sammen med nogle andre | space-backspace specifikationen. Jeg synes ikke at man kan | sige at jeg har v{ret ligeglad med resten af verden! Hva var galt med AMPERSAND (&), da? Dette er et helt harml|st tegn som overhode ikke kan tenkes } bli tolket som noe spesielt, med mindre man g}r inn for det spesielt. INFORMATION SEPARATOR THREE (0x1D), SPACE (0x20), og BACKSPACE (0x08) har allerede definert semantikk, noe du }penbart ignorerer. Jeg betrakter det som } v{re likeglad med de deler av verden som f|lger dem spesifikasjonene for dem, og ogs} med de som ikke gj|r det, men bruker det til egne ting. | intro-tegnet er jo valgbart, s} den enkelte bruger kan v{lge hvad der | passer vedkommende bedst, endda i forskellige situationer. Dette er jo farlig, og ingen fordel i det hele tatt! Hva om jeg setter intro-tegnet til ESCAPE, og sender C WITH CEDILLA? "ESC c" er en RESET kommando i henhold til ISO 6429. Kjekt, hva? Intro-tegnet m} v{re et grafisk tegn, og m} ikke ha noen allerede definert semantikk, og dette m} v{re et uomtvistelig krav til opplegget ditt. | Derfor er det vigtigt at overfl|dig og generende information s}som | intro-specifikation kan g|res usynlig for slutbrugeren fx ved | l{sning. Det er "usynlig" jeg reagerer p}. Det m} inng}tte og klare avtaler mellom avsender og mottager(e) til for } definere hva som er "usynlig". Det som er "usynlig" for en, er katastrofalt for en annen. Du ser ikke ut til } ville forst} eller ta hensyn til dette, noe jeg m} uttrykke min meget sterke avstandtagen til. | Tjae, mnemonics er da mit barn, og ikke en ISO standard, men det | arbejder jeg p}, som du ved! Det var nettopp det jeg mente. Du vil lage din egen, fremfor } bruke en eller flere allerede eksisterende. | Mnemonics har en fuktionalitet som eksisterende ISO tegns{t og | mekanismer som 2022 ikke har, nemlig at du kan pr{sentere og | generere en masse tegn med minimalt udstyr; et invariant ISO 646 | repertoire er alt du beh|ver for at v{re i luften. Der finnes standarder for dette allerede. SGML har f.eks. v{rt en standard siden 1986, og har en meget mer generell mekanisme til dette enn du har "funnet opp". Der kan en _bruker_ definere bindingen mellom et tegn og dens "kortform", og tegn som er lite brukt kan f} lange navn, mens tegn som er mye brukt kan f} korte navn. I tillegg kan numeriske tegn-referanser brukes i et gitt tegnsett. Dette er sv{rt generelt, og drar naturligvis med seg noe mer ballast enn ditt opplegg, men jeg vil faktisk _heller_ ha litt ballast, enn } ha faste koder p} to tegn jeg ikke klarer } huske fra en dag til en annen. SGML bruker & som "entity reference open", og ; som "entity reference close", slik at ditt navn f.eks. blir "Keld Jørn Simonsen" hvis man bruker langt navn, eller bare "Keld J&o;rn Simonsen", om man bruker et kort navn. Det man trenger da, er en mekanisme for } beskrive hvilke tegn ser brukt, og her har (surprise!) SGML ogs} en mekanisme ferdig til bruk for de som vil. Jeg sier ikke at vi skal dra med oss hele SGML (for det er dog ganske store sakene), men vi kan slippe } finne opp hjul p}ny n}r de allerede er der, er runde, og rimelig velpolert. | Ellers er noget af det f|rste og vanskeligste forhindring for at | kommunikere mellem maskiner og flytte programmer nemlig tegns{t. Det er vi allerede enige om, alle sammen (bortsett fra Ned Freed og Nathaniel Borenstein, da). Imidlertid er det ikke en _tegnsett_-standard, per se, du driver og snekrer p}. Det er en "markup language" standard, p} samme m}te som RichText er det. Begge to er "re-inventions of the wheel", dvs av standarder fra ISO/IEC JTC 1/SC 18, og s{rlig WG 8. Grunnen til at disse er lite kjent, er at de bygger bro mellom to verdener, tekst- og tegnsett-verdenen p} den ene side, og formelle sprog-verdenen p} den andre. Standardene er sv{rt kompliserte og abstrakte, og folk p} hver siden av broen kjenner seg ikke igjen f|r de g}r ganske n{rme. Du kan jo ta en prat med Hugh Tucker p} DS og se om han kan fortelle deg litt om SGML og "character entity references". Hils fra meg. | 2022 har ikke den egenskab. Du kan ikke f} vist ethvert tegn p} en | nogenlunde m}de, idet dit udstyr ikke kan fx vise et gr{sk lille pi. Nei, det er s}visst riktig. ISO 2022 og alle tegnsettene den kan henvise til, er ikke standarder for } vise frem noe som helst, men for } kode tegn. Det er viktig } forst} at der m} v{re en _fremvisningsmodul_ i tillegg til en _kodingsmodul_ i et slikt system. Se gjerne p} det som at tegnsettkodingen foreg}r p} ISO Reference Model for Open Systems Interconnection layer 6, (Re-)Presentation, og at fremvisningen foreg}r p} layer 7, Application. Jeg f}r hele tiden f|lelsen av at du fors|ker } blande disse sammen til ett lag. | S} jeg deler din anskuelse at vi b|r bruge internationale | standarder, men for at f} ny funktionalitet m} man alts} lave noget | nyt! Det er jo ikke noe nytt, sier jeg, og det har jeg sagt mange ganger. Problemet er allerede l|st, men ikke av ISO/IEC JTC 1/SC 2. Det er l|st av SC 18, derimot. Not Invented Here syndromet er utbredt i ISO, som andre steder, men det f}r da v{re grenser for hvor meget tid og penger man skal kaste ut av vinduet for } promovere sine egne "pets". En annen ting som jeg stadig kommer tilbake om MNEMONICS, er at det ikke er mulig } debugge kodetabellene dine, og dermed heller ikke mulig } vite at tekster med MNEMONICS i dem inneholder de tegn man vil. Hvilken aksent er det som kodes med "!", og hvilket tegn er "a1"? Hvor lett er det ikke } skrive "a1" n}r man ville ha "a!"... Jeg synes dette opplegget ditt er noenlunde smart opp til og med ISO 8859-1, men det _skalerer_ ikke utover en h}ndfull koder, og valget av "invariant ISO 646" er ikke veldig smart, det heller. Aksent grave blir "!", og circumflex blir ">" (eller var det "<"?), f.eks. Dette gj|r ting veldig vanskelig } forholde seg til. Jeg tror, summa summarum, at MNEM(ONICS) har en god ide som utgangspunkt, men at det er blitt forvokst, har sprengt sine rammer fullstendig, og derfor har utspilt sin rolle, ihvertfall som en "lesbar" koding. From psv@nada.kth.se Tue Dec 1 03:12:31 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA28773; Tue, 1 Dec 92 03:12:42 +0100 Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA28755; Tue, 1 Dec 92 03:12:31 +0100 Message-Id: <9212010212.AA28755@nada.kth.se> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A In-Reply-To: <199211292112.AA14264@dkuug.dk> from "Keld J|rn Simonsen " "Sun, 29 Nov 1992 22:12:47 +0100 " Date: Tue, 01 Dec 92 03:12:31 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*159 Jag glömde visst att kommentera detta: Citat ur brev från: Keld J|rn Simonsen > > > > This memo provides information for the Internet community. It does > > > not specify an Internet standard. > > > > Att kalla det f|r "standard internet ... konvertering" {r att > > vilseleda! > > Nej, nu er det dig der vildleder. I ovenn{vnte forstand er MIME heller > ikke nogen "standard". Nej, inte ännu men det kommer att bli en formell "Internet standard", men det kommer inte RFC 1345 att bli. Det är skillnad! > Der er en RFC p} omr}det, der behandler > tegns{tskonvertering, nemlig RFC 1345, og den har v{ret igennem > en st|rre diskussion p} nettet. Den kan kun v{re "informational" > da den citerer en lang r{kke standarder, som man ikke kan lave om p}, > og derfor kan IETF ikke lave den til en internet standard, da de > ikke kan {ndre de af andre standarder givne specifikationer. Det må vara hur det vill med anledningen - en RFC som inte är en Internetstandard har lägre sannolikhet att bli implementerad och går inte att hänvisa till när man ställer krav på ett program. > > ][\-gruppens tabeller hanterar b}de repertoartransformation (dvs. hur > > ska tecken X i repertoar A p} b{sta s{tt representeras med repertoar > > B som saknar tecknet X?) och kodtransformation och erbjuder _olika_ > > typer av konvertering f|r olika {ndam}l. > > Ja, og jeg forst}r at de er meget svensk orienterede. > Jeg tror ikke de kan bruges i Danmark. Dom är i viss mån påverkade av svenska förhållanden (ganska lite tror jag!) men vi har talat om att också göra det möjligt att lägga in sådana anpassningar för andra språk. From owner-nordpost@nada.kth.se Tue Dec 1 23:32:31 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA16890; Tue, 1 Dec 92 23:32:34 +0100 Received: from HERON.DAFA.SE by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA16872; Tue, 1 Dec 92 23:32:31 +0100 X400-Received: by /PRMD=QZ/ADMD=TEDE/C=SE/; Relayed; 01 Dec 92 23:25:37+0100 Date: 01 Dec 92 23:25:37+0100 From: Jacob Palme SKHB Message-Id: <1236849*JPALME@SKHB.dafa.se> To: "Nordpost (diskussion om elektronisk post i de nordiska landerna)" Subject: Anpassning av Nordunett till MIME Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*161 SuperKOM {r ett datorst|tt konferenssystem som jag varit med om att utveckla. I SuperKOM kan meddelanden i dag lagras i f|ljande teckenstandarder: MSDOS Flerspr}kig (CP850) Macintosh ISO Latin 1 (ISO 8859-1) T.61 IA5 (D47) (Svensk IA5 i normalversion) IA5 (E47) (Svensk IA5 i egennamnsversion) Ett meddelande lagras i den teckenstandard som finns hos den som skriver meddelandet. Konvertering till mottagarens teckenstandard g|rs s} sent som m|jligt innan visningen f|r mottagaren. SuperKOM har idag inte st|d f|r MIME, utan alla meddelanden skickas f|r n{rvarande ut till Internet i sin SuperKOM-interna teckenform utan konvertering. (Jag vet att det {r illegalt, men vi {r i alla fall inte ensamma om att g|ra s}!) Det {r troligt att vi anpassar SuperKOM till MIME, inte f|r intern anv{ndning inne i SuperKOM, men v{l vid kommunikation fr}n SuperKOM till Internet mail och omv{nt. Kommer det att g} bra att g|ra det med de olika l|sningar som diskuteras f|r anpassning av Nordunett till MIME? From owner-nordpost@nada.kth.se Tue Dec 1 23:32:27 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA16869; Tue, 1 Dec 92 23:32:35 +0100 Received: from HERON.DAFA.SE by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA16853; Tue, 1 Dec 92 23:32:27 +0100 X400-Received: by /PRMD=QZ/ADMD=TEDE/C=SE/; Relayed; 01 Dec 92 23:18:57+0100 Date: 01 Dec 92 23:18:57+0100 From: Jacob Palme SKHB Message-Id: <1236848*JPALME@SKHB.dafa.se> To: "Nordpost (diskussion om elektronisk post i de nordiska landerna)" Subject: e-mail-adresser for personer med nordiska bokstaver i namn Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*160 Jag har inte helt begripit hela diskussionen om |verg}ng till MIME i Nordunett, men har {nd} n}gra synpunkter. F|rslag som inneb{r att e-mail-adresserna i meddelandehuvudena skall se konstiga ut gillar jag inte. Om n}gon heter "]ke Gr|nvall" s} tycker jag att en bra e-mail-adress {r n}got i stil med "]ke Gr|nvall" eller "]ke Gr|nvall" N}got i stil med det f|ljande tycker jag vore ett stort steg bak}t: "]ke Gr|nvall" From paf@nada.kth.se Wed Dec 2 10:47:32 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA00855; Wed, 2 Dec 92 10:47:37 +0100 Received: from sysman.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA00844; Wed, 2 Dec 92 10:47:32 +0100 Received: by sysman.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08002; Wed, 2 Dec 92 10:47:30 +0100 Date: Wed, 2 Dec 1992 10:39:52 +0100 (MET) From: Patrik Faltstrom Subject: Re: e-mail-adresser for personer med nordiska bokstaver i namn To: nordpost@nada.kth.se In-Reply-To: <1236848*JPALME@SKHB.dafa.se> Message-Id: Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*162 On 1 Dec 1992, Jacob Palme SKHB wrote: > Jag har inte helt begripit hela diskussionen om |verg}ng till > MIME i Nordunett, men har {nd} n}gra synpunkter. > > F|rslag som inneb{r att e-mail-adresserna i meddelandehuvudena > skall se konstiga ut gillar jag inte. > > Om n}gon heter "]ke Gr|nvall" s} tycker jag att en bra > e-mail-adress {r n}got i stil med > > "]ke Gr|nvall" > eller > "]ke Gr|nvall" > > N}got i stil med det f|ljande tycker jag vore ett stort > steg bak}t: > > "]ke Gr|nvall" Adresserna kommer inte ändras enligt MIME. MIME (RFC-1341) talar endast om hur brevkroppens innehåll ska specificeras. Däremot finns det en annan RFC (RFC-1342) som talar om hur man kodar texten i en header-rad. I ditt exempel kan adressen se ut som: Däremot kommentaren, dvs hans utskrivna namn, ser annorlunda ut: To: =?ISO-8859-1?Q?=C5ke Gr=F6nvall?= From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Test of RFC-1342 in headers Detta kan man kanske tycka är fult, men det är bara en transportkodning!! Meningen är, precis som med Quoted-Printable, att användaren inte ska se transportkodningen! Det blandas ihop, precis som Erik Naggum säger, lite för mycket vad som är transportkodning och vad man ska visa för användaren om en font saknas. paf From owner-nordpost@nada.kth.se Wed Dec 2 14:08:19 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04599; Wed, 2 Dec 92 14:09:01 +0100 Received: from cyklop.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04521; Wed, 2 Dec 92 14:08:19 +0100 Received: from othello.admin.kth.se by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09741; Wed, 2 Dec 92 14:08:15 +0100 Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b) id AA18831; Wed, 2 Dec 92 14:08:14 +0100 Received: by mercutio.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0) id AA06222; Wed, 2 Dec 92 14:09:16 +0100 Date: Wed, 2 Dec 92 14:09:16 +0100 Message-Id: <9212021309.AA06222@mercutio.admin.kth.se> From: Olle Jarnefors To: Datorpostteknik i Norden Cc: Peter Svanberg , Olle Jarnefors In-Reply-To: <9212010122.AA26730@nada.kth.se> "Tue, 01 Dec 92 02:22:49 +0100" (From: Peter Svanberg ) Subject: Re: MNEMONICS roll Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden* Citat ur brev fr}n: Peter Svanberg > Citat ur brev fr}n: Keld J|rn Simonsen Citat ur brev fr}n: Peter Svanberg > > MIME-modtagere burde kunne afkode MNEMONICS, som jo er en MIME specifikation. > > Nu {r vi ute p} hal is igen: D} varken MIME-RFC:n eller aktuellt > IANA-dokument n{mner MNEMOMICS tycker jag inte du har r{tt att kalla > det en MIME-specifikation! Det man kan s{ga {r att de MNEMONICS-specifikationen {r MIME-anpassad och allts} l{tt kan anv{ndas i MIME-formaterade datorbrev. D[remot {r det bruket av MIME inte sanktionerat av IETF. Citat ur MIME-RFC:n 1341, b|rjan av avsnitt 7.1.1: An initial list of predefined character set names can be found at the end of this section. Additional character sets may be registered with IANA as described in Appendix F, although the standardization of their use requires the usual IAB review and approval. I den officiella f|rteckningen |ver av IANA registrerade "Assigned Numbers", RFC 1340, finns m{rkligt nog tv} olika listor p} "Character Sets". I den f|rsta av dem, som explicit specificerar "Character Sets ... for MIME mail" finns bara de teckenkodsnamn som {r angivna i MIME-RFC:n. Den andra listan omfattar namnen i Kelds RFC 1345 p} de tabellerade teckenkoderna (till exempel de n}got m{rkliga namnen "SEN_850200_B" och "SEN_850200_C" f|r de tv} svenska 7-bitskoderna) men _inte_ teckenkodsnamnet "mnem" eller namnen av typen "mnemonic+charset+intro" p} de m}nga speciella mnemoniska teckenkoderna. > > > skulle den bytas till > > > > > > Content-Type: Text/Plain; charset=X-SEN... eller X-MNEM > > > > Content-Type: Text/Plain; charset=SE > > > > Der er ikke "X-" foran, idet en svensk 7-bit er defineret hos IANA. > > Jag har inte f}tt svar p} SMTP-listan om detta {nnu, men min (och > andras) tolkning av MIME och IANA-dokumentet {r att bara det som st}r > som "Character set" med h{nvisning MIME-RFC:n f}r anv{ndas utan "X-" > framf|r. RFC 1341 {r otvetydig p} den h{r punkten (slutet av avsnitt 7.1.1:): No other character set name may be used in Internet mail without the publication of a formal specification and its registration with IANA as described in Appendix F, or by private agreement, in which case the character set name must begin with "X-". > > Der er ikke noget X- p}, "Mnemonic-Intro:" header er veldefineret i > > en RFC, nemlig RFC1345. Alts}: > > [nnu tydligare h{r: En "informational RFC" kan knappast definiera > nya officiella brevhuvudf{lt! Icke-officiella f{ltnamn _beh|ver_ inte inledas med "X-". Men om namnet g|r det s} kan det inte komma att bli omdefinierat av n}gon framtida Internet-standard. Ut|ver de brevhuvudf{lt som RFC 822 definierar till}ts tv} olika typer av f{lt (avsnitt 4.1): extension-field = user-defined-field = Vidare s{gs (avsnitt 4.7.4 och 4.7.5): A limited number of common fields have been defined in this document. As network mail requirements dictate, addi- tional fields may be standardized. To provide user-defined fields with a measure of safety, in name selection, such extension-fields will never have names that begin with the string "X-". Names of Extension-fields are registered with the Network Information Center, SRI International, Menlo Park, California. Individual users of network mail are free to define and use additional header fields. Such fields must have names which are not already used in the current specification or in any definitions of extension-fields, and the overall syntax of these user-defined-fields must conform to this specification's rules for delimiting and folding fields. Due to the extension-field publishing process, the name of a user- defined-field may be pre-empted Note: The prefatory string "X-" will never be used in the names of Extension-fields. This provides user-defined fields with a protected set of names. M{rkligt nog finns det ingen lista p} Extension-Fields i RFC 1340 fr}n IANA, som |vertagit registreringen fr}n ovann{mnda NIC. Vi f}r d{rf|r g} p} det andra kriteriet, att Extension-Fields ska vara standardiserade. Mig veterligt finns det bara ett ytterligare standardiserat f{lt. RFC 1123 (Host requirements) s{ger n{mligen (avsnitt 5.2.13): The set of optional header fields is hereby expanded to include the Content-Type field defined in RFC-1049 [SMTP:7]. This field "allows mail reading systems to automatically identify the type of a structured message body and to process it for display accordingly". [SMTP:7] A User Agent MAY support this field. N{r MIME har blivit en definitiv Internet-standard kommer ocks} de brevhuvudf{lt som MIME specificerar att bli Extension-Fields. F|r n{rvarande {r de att betrakta som User-Defined-Fields. S} sm}ningom ska jag ta upp de tv} egendomliga sakerna med RFC 1340 p} l{mplig ietf-brevlista: > att det finns tv} olika listor |ver Character Sets. > att det saknas en lista |ver Extension Fields. From owner-nordpost@nada.kth.se Wed Dec 2 19:55:43 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09099; Wed, 2 Dec 92 19:55:48 +0100 Received: from cyklop.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09083; Wed, 2 Dec 92 19:55:43 +0100 Received: from HERON.DAFA.SE by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA07052; Wed, 2 Dec 92 19:55:42 +0100 X400-Received: by /PRMD=QZ/ADMD=TEDE/C=SE/; Relayed; 02 Dec 92 19:52:00+0100 Date: 02 Dec 92 19:52:00+0100 From: Lennart Borgman AB_Draco Message-Id: <847070*Lennart.Borgman@AB_Draco.dafa.se> In-Reply-To: <9211251607.AA12981@nada.kth.se> To: nordpost@nada.kth.se, Mailchar nordiskt mote om teckenstandarder i elektronisk post Subject: Folj RFC:erna! Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*163 Jag {r bara en intresserad lyssnare i sammanhanget, men jag vill nog g|ra en del kommentarer ang}ende den speciella nordiska hanteringen i alla fall. Att inf|ra en speciell hantering av mail i norden inneb{r s} vitt jag f|rst} att vi kommer att f} dras med denna v{ldigt l{nge. Programmen i sin reviderade form(s} fattar jag det) kommer att finnas kvar l}ngt efter det att vi har n}got st|rre behov av dem. Detta kan komma att st|ra mail-trafiken. Jag skulle f|redra att man inte g|r n}got alls med breven, bara sl{pper igenom dem med alla 8-bitars tecken. De som fr{mst kommer att lida av det h{r tror jag {r de som har kvar 7-bitars hanteringen av svenska tecken. Vi har under l}ng tid haft latin-1 h{r och och det {r ganska l{tt att l{sa text med {}| (jaha, det var inte l{tt att skriva in snirkelparenteser, min terminal-emulator konverterar tecken n{r jag k|r mot DAFA- KOM.) Det ger ju s} att s{ga en skjuts fram}t mot latin-1. Att bygga in speciell hantering som underl{ttar att ha kvar 7-bitars svenska tecken konserverar ju tv{rt om de datormilj|er som har kvar denna teckenkodning. Men det l}ter ju v{ldigt bra att man kommit |verens om att vi ska kunna skicka 8-bitar. From owner-nordpost@nada.kth.se Wed Dec 2 20:26:00 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09514; Wed, 2 Dec 92 20:26:04 +0100 Received: from cyklop.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09498; Wed, 2 Dec 92 20:26:00 +0100 Received: from HERON.DAFA.SE by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09290; Wed, 2 Dec 92 20:25:54 +0100 X400-Received: by /PRMD=QZ/ADMD=TEDE/C=SE/; Relayed; 02 Dec 92 20:19:46+0100 Date: 02 Dec 92 20:19:46+0100 From: Lennart Borgman AB_Draco Message-Id: <847071*Lennart.Borgman@AB_Draco.dafa.se> In-Reply-To: <9212010212.AA28755@nada.kth.se> To: nordpost@nada.kth.se, Mailchar nordiskt mote om teckenstandarder i elektronisk post Subject: Internetstandard =? RFC Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*164 Kan n}gon v{nlig sj{l f|rklara skillnaden mellan "Internetstandard" (vad det nu {r) och RFC:er. Jag trodde att det vara samma sak? From owner-nordpost@nada.kth.se Wed Dec 2 20:58:38 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09769; Wed, 2 Dec 92 20:58:42 +0100 Received: from cyklop.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09753; Wed, 2 Dec 92 20:58:38 +0100 Received: from othello.admin.kth.se by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09993; Wed, 2 Dec 92 20:58:32 +0100 Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b) id AA25207; Wed, 2 Dec 92 20:58:31 +0100 Received: by mercutio.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0) id AA07826; Wed, 2 Dec 92 20:59:33 +0100 Date: Wed, 2 Dec 92 20:59:33 +0100 Message-Id: <9212021959.AA07826@mercutio.admin.kth.se> From: Olle Jarnefors To: Datorpostteknik i Norden Cc: Olle Jarnefors In-Reply-To: "Mon, 30 Nov 1992 09:31:05 +0100 (MET)" (From: Patrik Faltstrom ) Subject: Re: MIME i Sverige, f|rslag A Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*165 > Det {r riktigt att 10646 inte fungerar ihop med den standard som finns > f|r str{ngdefinitioner i C. ANSI {r ocks} den som jag anser har det > starkaste nej-r|sten mot 10646. > - - - > (det h{r {r en hel annan diskussion {n MIME i sverige, men kanske finns > det fler intresserade av detta med teckenstandardproblemet p} listan > ocks}?) Det finns en s{rskild brevlista f|r fr}gor ang}ende ISO 10646, Unicode och eventuella andra f|rs|k till mer l}ngsiktig l|sning av teckenkodsproblemen, . Denna diskussion b|r {ga rum p} den listan. (Ingenting verkar ha h{nt p} den sedan 1 juni i }r men den b|r fortfarande fungera.) From owner-nordpost@nada.kth.se Wed Dec 2 21:07:12 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09924; Wed, 2 Dec 92 21:07:18 +0100 Received: from cyklop.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09904; Wed, 2 Dec 92 21:07:12 +0100 Received: from othello.admin.kth.se by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA11428; Wed, 2 Dec 92 21:07:06 +0100 Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b) id AA25265; Wed, 2 Dec 92 21:07:05 +0100 Received: by mercutio.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0) id AA07887; Wed, 2 Dec 92 21:08:07 +0100 Date: Wed, 2 Dec 92 21:08:07 +0100 Message-Id: <9212022008.AA07887@mercutio.admin.kth.se> From: Olle Jarnefors To: Datorpostteknik i Norden Cc: Olle Jarnefors In-Reply-To: "Fri, 27 Nov 1992 09:35:40 +0100 (MET)" (From: Patrik Faltstrom ) Subject: Re: MIME i Sverige, f|rslag A Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*166 > > Medf|r detta att mottagaren endast f}r reda p} att konvertering har skett? > > Han f}r reda p} vilken konvertering som skett och vilken dator som > har utf|rt den. > > Jag har tyv{rr inte kvar det brevet d{r det fanns ett bra exempel, men kanske > har Olle eller Peter kvar ett exempel. Enligt senaste utkastet : Internet Draft December 1, 1992 : Expires 5/31/93 : : : Transition of Internet Mail from : Just-Send-8 : to 8Bit-SMTP/MIME ska det g|ras s} h{r: : Trace information should be added to the document as indicated in : [2], with a convert clause "rfc822-to-8bit", "rfc822-to-base-64" or : "rfc822-to-quoted-printable" e.g., : : Received: from dbc.mtview.ca.us by dbc.mtview.ca.us : convert rfc822-to-8bit; Tue, 01 Sep 1992 01:18:00 -0700 From owner-nordpost@nada.kth.se Wed Dec 2 21:48:13 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA10316; Wed, 2 Dec 92 21:48:18 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA10300; Wed, 2 Dec 92 21:48:13 +0100 Received: by dkuug.dk id AA26060 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Wed, 2 Dec 1992 21:48:10 +0100 Date: Wed, 2 Dec 1992 21:48:10 +0100 From: Keld J|rn Simonsen Message-Id: <199212022048.AA26060@dkuug.dk> To: nordpost@nada.kth.se Subject: Re: MNEMONICS roll X-Charset: ASCII X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*167 > > MIME-modtagere burde kunne afkode MNEMONICS, som jo er en MIME specifikation. > > Nu {r vi ute p} hal is igen: D} varken MIME-RFC:n eller aktuellt > IANA-dokument n{mner MNEMOMICS tycker jag inte du har r{tt att kalla > det en MIME-specifikation! Ja det har du ret i. Men jeg mener det er en fejl at IANA ikke har registreret det. Det var klart aftalen at de skulle. Jeg har nu fremsendt en anmodning om registrering til IANA. Dvs, jeg sendte en i sidste uge til jon postel, og en til i dag til IANA. Jeg kan ikke tro andet end at det vil v{re valid MIME specifikation inden l{nge. > > Quoted-Printable i r} form er efter min bedste mening ul{seligt, > > i hvertfald for dansk, svensk, finsk, norsk, tysk, fransk. > > Jo men det {r entydigt avkodbart endast med hj{lp av > teckenkodsstandarden. F|r att avkoda MNEMONICS kr{vs > MNEMONICS-tabellerna, som {r betydligt mindre spridda. Tjae, lige nu tror jeg da at mnemonics er mere udbredt i Norden end MIME. > > > skulle den bytas till > > > > > > Content-Type: Text/Plain; charset=X-SEN... eller X-MNEM > > > > Content-Type: Text/Plain; charset=SE > > > > Der er ikke "X-" foran, idet en svensk 7-bit er defineret hos IANA. > > Jag har inte f}tt svar p} SMTP-listan om detta {nnu, men min (och > andras) tolkning av MIME och IANA-dokumentet {r att bara det som st}r > som "Character set" med h{nvisning MIME-RFC:n f}r anv{ndas utan "X-" > framf|r. Ja, jeg undrer mig en del over de manglende svar, man altid f}r fra IEFT folk :-) :-( Olle har svaret p} det med X-Mnemonic-Intro:, men jeg er da ogs} noget forvirret over hvordan IETF behandler ting, procedurem{ssigt. keld From owner-nordpost@nada.kth.se Wed Dec 2 21:56:18 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA10421; Wed, 2 Dec 92 21:56:23 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA10405; Wed, 2 Dec 92 21:56:18 +0100 Received: by dkuug.dk id AA26190 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Wed, 2 Dec 1992 21:56:13 +0100 Date: Wed, 2 Dec 1992 21:56:13 +0100 From: Keld J|rn Simonsen Message-Id: <199212022056.AA26190@dkuug.dk> To: nordpost@nada.kth.se Subject: Re: MIME i Sverige, f|rslag A X-Charset: ASCII X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*168 Peter Svanberg skrev: > Citat ur brev fr}n: Keld J|rn Simonsen > > > > > > This memo provides information for the Internet community. It does > > > > not specify an Internet standard. > > > > > > Att kalla det f|r "standard internet ... konvertering" {r att > > > vilseleda! > > > > Nej, nu er det dig der vildleder. I ovenn{vnte forstand er MIME heller > > ikke nogen "standard". > > Nej, inte {nnu men det kommer att bli en formell "Internet standard", > men det kommer inte RFC 1345 att bli. Det {r skillnad! Ja, der er forskel. Men rfc 1345 giver blot specifikationer for tegns{t, og en konvertering imellem disse (bl.a.) Ideen er at rfc1345 skal refereres i MIME, og det kunne den ikke fordi den ikke var f{rdig de MIME skulle publiceres (var begrundelsen). > > Der er en RFC p} omr}det, der behandler > > tegns{tskonvertering, nemlig RFC 1345, og den har v{ret igennem > > en st|rre diskussion p} nettet. Den kan kun v{re "informational" > > da den citerer en lang r{kke standarder, som man ikke kan lave om p}, > > og derfor kan IETF ikke lave den til en internet standard, da de > > ikke kan {ndre de af andre standarder givne specifikationer. > > Det m} vara hur det vill med anledningen - en RFC som inte {r > en Internetstandard har l{gre sannolikhet att bli implementerad och > g}r inte att h{nvisa till n{r man st{ller krav p} ett program. Jo, man kan godt henvise til den, det var da forslaget at RFC1341 skulle henvise til RFC1345, som var informational. > > > ][\-gruppens tabeller hanterar b}de repertoartransformation (dvs. hur > > > ska tecken X i repertoar A p} b{sta s{tt representeras med repertoar > > > B som saknar tecknet X?) och kodtransformation och erbjuder _olika_ > > > typer av konvertering f|r olika {ndam}l. > > > > Ja, og jeg forst}r at de er meget svensk orienterede. > > Jeg tror ikke de kan bruges i Danmark. > > Dom {r i viss m}n p}verkade av svenska f|rh}llanden (ganska lite tror > jag!) men vi har talat om att ocks} g|ra det m|jligt att l{gga in > s}dana anpassningar f|r andra spr}k. OK. Jeg har set nogle tidligere udgaver af ][\ gruppens arbejde, og jeg tror det udm{rket kan modificeres til at blive brugt andre steder end Sverige, hvis der er faciliteter derfor. Keld From owner-nordpost@nada.kth.se Wed Dec 2 23:27:14 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA11369; Wed, 2 Dec 92 23:27:22 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA11353; Wed, 2 Dec 92 23:27:14 +0100 Received: by dkuug.dk id AA28316 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Wed, 2 Dec 1992 23:26:36 +0100 Date: Wed, 2 Dec 1992 23:26:36 +0100 From: Keld J|rn Simonsen Message-Id: <199212022226.AA28316@dkuug.dk> To: enag@ifi.uio.no Subject: Re: "Intro"-tecken i MNEMONICS Cc: nordpost@nada.kth.se X-Charset: ASCII X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*169 > [Keld J|rn Simonsen] > | > | Tjae, jeg havde unders|gt det rimeligt l{nge, og ikke fundet problemer > | med det; control-} var ogs} hvad man brugte som default escape > | tegn i forskellige telnet implementationer. Men, jo, der var nogle > | problemer i det, og derfor lavede jeg sammen med nogle andre > | space-backspace specifikationen. Jeg synes ikke at man kan > | sige at jeg har v{ret ligeglad med resten af verden! > > Hva var galt med AMPERSAND (&), da? Dette er et helt harml|st tegn som > overhode ikke kan tenkes } bli tolket som noe spesielt, med mindre man > g}r inn for det spesielt. Ja, Ampersand er da et godt tegn, det er ogs} derfor jeg har valgt det som default i rfc 1345. SGML har det ogs} som indledningstegn. > INFORMATION SEPARATOR THREE (0x1D), SPACE > (0x20), og BACKSPACE (0x08) har allerede definert semantikk, noe du > }penbart ignorerer. Jeg betrakter det som } v{re likeglad med de deler > av verden som f|lger dem spesifikasjonene for dem, og ogs} med de som > ikke gj|r det, men bruker det til egne ting. Ja, det er ogs} derfor jeg er ved at g} v{k fra IS3. Jeg mener jeg bruger semantiken for SPACE og BACKSPACE - som defineret i 646 og 6429. > | intro-tegnet er jo valgbart, s} den enkelte bruger kan v{lge hvad der > | passer vedkommende bedst, endda i forskellige situationer. > > Dette er jo farlig, og ingen fordel i det hele tatt! Hva om jeg setter > intro-tegnet til ESCAPE, og sender C WITH CEDILLA? "ESC c" er en RESET > kommando i henhold til ISO 6429. Kjekt, hva? Intro-tegnet m} v{re et > grafisk tegn, og m} ikke ha noen allerede definert semantikk, og dette > m} v{re et uomtvistelig krav til opplegget ditt. Ja, det er farligt med ESC, og det er ogs} n{vnt i RFC-en. Jeg synes det er en fordel at man kan usynligg|re introduktionstegnet, det g|r mnemonics meget l{ttere at l{se, men man kan da v{lge noget andet hvis man vil. > > | Tjae, mnemonics er da mit barn, og ikke en ISO standard, men det > | arbejder jeg p}, som du ved! > > Det var nettopp det jeg mente. Du vil lage din egen, fremfor } bruke en > eller flere allerede eksisterende. Jeg bruger alts} en masse ISO standarder, Erik, men bare ikke SGML! Ikke fordi jeg ikke vil, men fordi jeg ikke har f}et sat mig fuldt ind i den. Jeg kunne godt t{nke mig at bruge SGML til beskrivelse af tegns{t, men du har vist allerede lavet arbejdet.... Jeg har tegns{tsbeskrivelser der er i overensstemmelse med POSIX standarden, som ogs} n{vnt tidligere. > | Mnemonics har en fuktionalitet som eksisterende ISO tegns{t og > | mekanismer som 2022 ikke har, nemlig at du kan pr{sentere og > | generere en masse tegn med minimalt udstyr; et invariant ISO 646 > | repertoire er alt du beh|ver for at v{re i luften. > > Der finnes standarder for dette allerede. SGML har f.eks. v{rt en > standard siden 1986, og har en meget mer generell mekanisme til dette > enn du har "funnet opp". Der kan en _bruker_ definere bindingen mellom > et tegn og dens "kortform", og tegn som er lite brukt kan f} lange navn, > mens tegn som er mye brukt kan f} korte navn. I tillegg kan numeriske > tegn-referanser brukes i et gitt tegnsett. Dette er sv{rt generelt, og > drar naturligvis med seg noe mer ballast enn ditt opplegg, men jeg vil > faktisk _heller_ ha litt ballast, enn } ha faste koder p} to tegn jeg > ikke klarer } huske fra en dag til en annen. Det lyder rimeligt smart, m}ske noget for ][\ gruppen? Mit er ikke faste koder p} to tegn, der er ca 500 der har 3 tegn eller mere, og ca 20.000 kinesiske/japanske koder p} 5 tegn. > > SGML bruker & som "entity reference open", og ; som "entity reference > close", slik at ditt navn f.eks. blir "Keld Jørn Simonsen" hvis > man bruker langt navn, eller bare "Keld J&o;rn Simonsen", om man bruker > et kort navn. Det man trenger da, er en mekanisme for } beskrive hvilke > tegn ser brukt, og her har (surprise!) SGML ogs} en mekanisme ferdig til > bruk for de som vil. Jeg sier ikke at vi skal dra med oss hele SGML > (for det er dog ganske store sakene), men vi kan slippe } finne opp hjul > p}ny n}r de allerede er der, er runde, og rimelig velpolert. jeg vil gerne kigge lidt p} det - jeg har da SGML standarden, og jeg har t{nkt p} at lave en omformattering af mine tabeller til SGML format. Jeg har dog lige noget andet jeg skal have ordnet f|rst....:-( Har du allerede lavet et s}dan program, Erik, og ku jeg evt f} det? > Imidlertid er det ikke en _tegnsett_-standard, per se, du driver og > snekrer p}. Det er en "markup language" standard, p} samme m}te som > RichText er det. Begge to er "re-inventions of the wheel", dvs av > standarder fra ISO/IEC JTC 1/SC 18, og s{rlig WG 8. Grunnen til at > disse er lite kjent, er at de bygger bro mellom to verdener, tekst- og > tegnsett-verdenen p} den ene side, og formelle sprog-verdenen p} den > andre. Standardene er sv{rt kompliserte og abstrakte, og folk p} hver > siden av broen kjenner seg ikke igjen f|r de g}r ganske n{rme. Du kan > jo ta en prat med Hugh Tucker p} DS og se om han kan fortelle deg litt > om SGML og "character entity references". Hils fra meg. Nej, det er ikke en tegns{tsstandard jeg er ved at lave. Men det er bl.a en tegnnavngivningsstandard. Du ved jo godt at mit arbejde kommer fra noget troff arbejde, som jo ikke er meget forskelligt funktionelt fra SGML. Der er flere niveauer i det jeg arbejder p}, og jeg synes faktisk at jeg har kunnet lave meget med de redskaber jeg har lavet. > | 2022 har ikke den egenskab. Du kan ikke f} vist ethvert tegn p} en > | nogenlunde m}de, idet dit udstyr ikke kan fx vise et gr{sk lille pi. > > Nei, det er s}visst riktig. ISO 2022 og alle tegnsettene den kan > henvise til, er ikke standarder for } vise frem noe som helst, men for } > kode tegn. Det er viktig } forst} at der m} v{re en _fremvisningsmodul_ > i tillegg til en _kodingsmodul_ i et slikt system. Se gjerne p} det som > at tegnsettkodingen foreg}r p} ISO Reference Model for Open Systems > Interconnection layer 6, (Re-)Presentation, og at fremvisningen foreg}r > p} layer 7, Application. > > Jeg f}r hele tiden f|lelsen av at du fors|ker } blande disse sammen til > ett lag. ja, jeg blander kodning og pr{sentation sammen, fordi det er det som brugerne/kunderne desv{rre er n|dt til at operere med. Dvs jeg er udm{rket klar over at der er forskelle p} de to niveauer, men for en masse brugere er der desv{rre ikke noget fremvisningslag. Derfor skal repr{sentationslaget gerne kunne bruges som fremvisningslag ogs}. > En annen ting som jeg stadig kommer tilbake om MNEMONICS, er at det ikke > er mulig } debugge kodetabellene dine, og dermed heller ikke mulig } > vite at tekster med MNEMONICS i dem inneholder de tegn man vil. Hvilken > aksent er det som kodes med "!", og hvilket tegn er "a1"? Hvor lett er > det ikke } skrive "a1" n}r man ville ha "a!"... Tjae, hvor er problemet? Du har tidligere talt om at det var sv{rt overskuelige. Jeg har dem som sagt ogs} i POSIXformat som nok er lettere at l{se korrektur p}. Det er altid muligt at skrive fejl. fejlen kunne ogs} v{re af typen e-acute istedet for a-acuet, eller e-ecute... > Jeg synes dette > opplegget ditt er noenlunde smart opp til og med ISO 8859-1, men det > _skalerer_ ikke utover en h}ndfull koder, Tjae, jeg synes det fungerer godt ogs} for Kyrillisk, gr{sk, arabisk, h{braisk, japansk kana mm - m}ske ikke s} godt mht specialtegn, men det kunne man {ndre. Jeg f|ler mig fristet til at bruge lange navne for matematiske tegn, s}som "approximately-equal" - man kan godt have flere navne for samme tegn, blot de er entydige (et navn m} ikke betyde to forskellige tegn...). > og valget av "invariant ISO > 646" er ikke veldig smart, det heller. Aksent grave blir "!", og > circumflex blir ">" (eller var det "<"?), f.eks. Dette gj|r ting veldig > vanskelig } forholde seg til. I nordisk sammenh{ng er invariant 646 da yderst heldigt! Det er egentligt ikke s} vigtigt n}r du l{ser ting om du ser at det nu er et < eller > . fx co>te' - de fleste franskm{nd ville kunne l{se det uden accenter og g{tte ordet ud fra sammenh{ngen. Det v{sentlige her ved mnemonics er at du f}r et "o" og et "e" og lidt kriskrams, og ikke hex koder. fx c=F4t=E3 (ca..) Hex koder forstyrrer virkelig l{sningen. Det g|r specialtegn som !"()<>-:+,. ikke i n{r samme grad. Og det er rart at du f}r basetegnet. Huskereglen er at accenterne kan v{re drejet 90 grader, -lagt ned, og indersiden stadig ind mod det tegn det h|rer til. > Jeg tror, summa summarum, at MNEM(ONICS) har en god ide som utgangspunkt, > men at det er blitt forvokst, har sprengt sine rammer fullstendig, og > derfor har utspilt sin rolle, ihvertfall som en "lesbar" koding. > > Tjae, jeg mener det virker fint for dansk/svensk/norsk/finsk/tysk fransk/portugisk/spansk og russerne er ogs} glade for den kyrilliske udgave! Keld From owner-nordpost@nada.kth.se Thu Dec 3 08:40:37 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA16436; Thu, 3 Dec 92 08:40:43 +0100 Received: from malmo.trab.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA16419; Thu, 3 Dec 92 08:40:37 +0100 Received: by malmo.trab.se (5.65+bind 1.7+ida 1.4.2/TRM-1-NS); Thu, 3 Dec 92 08:40:29 +0100 (MET) Date: Thu, 3 Dec 92 08:40:29 +0100 From: Dan Oscarsson Message-Id: <9212030740.AA22617@malmo.trab.se> To: nordpost@nada.kth.se Subject: Re: MNEMONICS roll Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*170 Jag tycker det är för mycket prat om menmonics. Kan vi inte gå över till viktigare saker? T.ex. om hur vi skall införa MIME. Jag tycker dessutom att vi skall satsa på ISO-standarder och inget annat. ISO 8859-1 och ISO 10646 går lika bra att använda som mnemonics och quoted-printable-kodningen är bara lite svårare att läsa än mnemonics. Ingen av dem borde man se, så normalt bör det inte göra något. Inom norden borde ISO 8859-1 räcka till en början. Därefter kan vi även börja använda ISO 10646. Dan From owner-nordpost@nada.kth.se Thu Dec 3 09:04:51 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA16703; Thu, 3 Dec 92 09:04:56 +0100 Received: from oddput.efd.lth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA16687; Thu, 3 Dec 92 09:04:51 +0100 Received: by efd.lth.se (Smail3.1.28.1 #1) id m0mxBY5-0002WuC; Thu, 3 Dec 92 09:04 MET Message-Id: To: nordpost@nada.kth.se Subject: Re: MNEMONICS roll Reply-To: nordpost@nada.kth.se In-Reply-To: Your message of "Thu, 03 Dec 92 08:40:29 +0100." <9212030740.AA22617@malmo.trab.se> Date: Thu, 03 Dec 92 09:04:31 +0100 From: Joergen Haegg Errors-To: owner-nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*171 In message <9212030740.AA22617@malmo.trab.se> you write: > >Jag tycker det {r f|r mycket prat om menmonics. Kan vi inte g} |ver till >viktigare saker? T.ex. om hur vi skall inf|ra MIME. Riktigt. >Jag tycker dessutom att vi skall satsa p} ISO-standarder och inget annat. >ISO 8859-1 och ISO 10646 g}r lika bra att anv{nda som mnemonics och >quoted-printable-kodningen {r bara lite sv}rare att l{sa {n mnemonics. >Ingen av dem borde man se, s} normalt b|r det inte g|ra n}got. Vi kan väl börja med 8859-1, sen får vi se hur det går med 10646. Jag börjar undra om man verkligen har tänkt till, att ha ett nolltecken som inleder 8859-1 verkar inte smart. Nåja, det är en helt annan sak. Vad händer egentligen med ESMTP, vad är det folk bråkar om? Är det inte bara att släppa igenom åtta bitar, eller innehåller den mer än så? -------- Jörgen Hägg jh@efd.lth.se postmaster@efd.lth.se Telnr: 046-107492, 104013(fax) Snigelpost: Hämtställe 7, BOX 118, 221 00 LUND Lunds Tekniska Högskola Paket: E-huset, Ole Römers väg 3, 221 00 LUND My pen is at the bottom of a page, Which, being finished, here the story ends; 'Tis to be wished it had been sooner done, But stories somehow lengthen when begun. -- Byron From owner-nordpost@nada.kth.se Thu Dec 3 12:02:14 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA18712; Thu, 3 Dec 92 12:02:27 +0100 Received: from cyklop.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA18672; Thu, 3 Dec 92 12:02:14 +0100 Received: from HERON.DAFA.SE by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA18776; Thu, 3 Dec 92 12:02:07 +0100 X400-Received: by /PRMD=QZ/ADMD=TEDE/C=SE/; Relayed; 03 Dec 92 11:56:32+0100 Date: 03 Dec 92 11:56:32+0100 From: Jacob Palme SKHB Message-Id: <1236849*JPALME@SKHB.dafa.se> To: Datorpostteknik i Norden , "Nordpost (diskussion om elektronisk post i de nordiska landerna)" Subject: Anpassning av Nordunett till MIME Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*173 SuperKOM {r ett datorst|tt konferenssystem som jag varit med om att utveckla. I SuperKOM kan meddelanden i dag lagras i f|ljande teckenstandarder: MSDOS Flerspr}kig (CP850) Macintosh ISO Latin 1 (ISO 8859-1) T.61 IA5 (D47) (Svensk IA5 i normalversion) IA5 (E47) (Svensk IA5 i egennamnsversion) Ett meddelande lagras i den teckenstandard som finns hos den som skriver meddelandet. Konvertering till mottagarens teckenstandard g|rs s} sent som m|jligt innan visningen f|r mottagaren. SuperKOM har idag inte st|d f|r MIME, utan alla meddelanden skickas f|r n{rvarande ut till Internet i sin SuperKOM-interna teckenform utan konvertering. (Jag vet att det {r illegalt, men vi {r i alla fall inte ensamma om att g|ra s}!) Det {r troligt att vi anpassar SuperKOM till MIME, inte f|r intern anv{ndning inne i SuperKOM, men v{l vid kommunikation fr}n SuperKOM till Internet mail och omv{nt. Kommer det att g} bra att g|ra det med de olika l|sningar som diskuteras f|r anpassning av Nordunett till MIME? From owner-nordpost@nada.kth.se Thu Dec 3 12:02:13 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA18705; Thu, 3 Dec 92 12:02:26 +0100 Received: from cyklop.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA18671; Thu, 3 Dec 92 12:02:13 +0100 Received: from HERON.DAFA.SE by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA18775; Thu, 3 Dec 92 12:02:07 +0100 X400-Received: by /PRMD=QZ/ADMD=TEDE/C=SE/; Relayed; 03 Dec 92 11:49:15+0100 Date: 03 Dec 92 11:49:15+0100 From: Jacob Palme SKHB Message-Id: <1236848*JPALME@SKHB.dafa.se> To: Datorpostteknik i Norden , "Nordpost (diskussion om elektronisk post i de nordiska landerna)" Subject: e-mail-adresser for personer med nordiska bokstaver i namn Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*172 Jag har inte helt begripit hela diskussionen om |verg}ng till MIME i Nordunett, men har {nd} n}gra synpunkter. F|rslag som inneb{r att e-mail-adresserna i meddelandehuvudena skall se konstiga ut gillar jag inte. Om n}gon heter "]ke Gr|nvall" s} tycker jag att en bra e-mail-adress {r n}got i stil med "]ke Gr|nvall" eller "]ke Gr|nvall" N}got i stil med det f|ljande tycker jag vore ett stort steg bak}t: "]ke Gr|nvall" From owner-nordpost@nada.kth.se Fri Dec 4 16:29:29 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA06676; Fri, 4 Dec 92 16:29:43 +0100 Received: from othello.admin.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA06659; Fri, 4 Dec 92 16:29:29 +0100 Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b) id AA08920; Fri, 4 Dec 92 16:29:27 +0100 Received: by mercutio.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0) id AA14680; Fri, 4 Dec 92 16:30:25 +0100 Date: Fri, 4 Dec 92 16:30:25 +0100 Message-Id: <9212041530.AA14680@mercutio.admin.kth.se> From: Olle Jarnefors To: Datorpostteknik i Norden Cc: Olle Jarnefors In-Reply-To: <847071*Lennart.Borgman@AB_Draco.dafa.se> "02 Dec 92 20:19:46+0100" (From: Lennart Borgman AB_Draco ) Subject: Re: Internetstandard =? RFC Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*174 > Kan n}gon v{nlig sj{l f|rklara skillnaden mellan "Internetstandard" > (vad det nu {r) och RFC:er. Jag trodde att det vara samma sak? RFC:er (Requests for Comment) {r en serie dokument av intresse f|r "the Internet community" som ges ut av IAB (the Internet Activities Board). Bara en minoritet av RFC:erna specificerar officiella Internet-standarder, men alla Internet-standarder {r publicerade i form av en (eller ibland ett par) RFC:er. Man kan h{mta RFC:er med anonym FTP fr}n till exempel sunic.sunet.se. Det tar ibland en viss tid innan nya RFC:er l{ggs upp d{r. D} kan kan f|rs|ka med de mer officiella RFC-arkiven p} bland andra src.doc.ic.ac.uk och nis.nsf.net. RFC 1111 {r RFC:n om RFC:er. D{r st}r bland annat: Each RFC must include on its first page the "Status of this Memo" section which contains a paragraph describing the intention of the RFC. This section is meant to convey the status granted by the RFC Editor and the Internet Activities Board (IAB). There are several reasons for publishing a memo as an RFC, for example, to make available some information for interested people, or to begin or continue a discussion of an interesting idea, or to make available the specification of a protocol. The following sample paragraphs may be used to satisfy this requirement: Proposed Protocol This RFC suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. Specification This RFC specifies a standard for the Internet community. Hosts on the Internet are expected to adopt and implement this standard. Discussion The purpose of this RFC is to focus discussion on particular problems in the Internet and possible methods of solution. No proposed solutions this document are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the adoption of standards. Information This RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers. Status In response to the need for maintenance of current information about the status and progress of various projects in the Internet community, this RFC is issued for the benefit of community members. The information contained in this document is accurate as of the date of publication, but is subject to change. Subsequent RFCs will reflect such changes. Den senaste |versikten av standardiseringen av Internet- protokoll finns i RFC 1360, utgiven i september 1992, som sj{lv utg|r Internet STD 1. D{rifr}n har jag tagit f|ljande tabeller: 6.2. Standard Protocols Protocol Name Status RFC STD * ======== ===================================== ======== ==== === = -------- IAB Official Protocol Standards Req 1360 1 * -------- Assigned Numbers Req 1340 2 * -------- Host Requirements - Communications Req 1122 3 -------- Host Requirements - Applications Req 1123 3 -------- Gateway Requirements Req 1009 4 IP Internet Protocol Req 791 5 as amended by:-------- -------- IP Subnet Extension Req 950 5 -------- IP Broadcast Datagrams Req 919 5 -------- IP Broadcast Datagrams with Subnets Req 922 5 ICMP Internet Control Message Protocol Req 792 5 IGMP Internet Group Multicast Protocol Rec 1112 5 UDP User Datagram Protocol Rec 768 6 TCP Transmission Control Protocol Rec 793 7 TELNET Telnet Protocol Rec 854,855 8 FTP File Transfer Protocol Rec 959 9 SMTP Simple Mail Transfer Protocol Rec 821 10 MAIL Format of Electronic Mail Messages Rec 822 11 CONTENT Content Type Header Field Rec 1049 11 NTP Network Time Protocol Rec 1119 12 DOMAIN Domain Name System Rec 1034,1035 13 DNS-MX Mail Routing and the Domain System Rec 974 14 SNMP Simple Network Management Protocol Rec 1157 15 SMI Structure of Management Information Rec 1155 16 MIB-II Management Information Base-II Rec 1213 17 EGP Exterior Gateway Protocol Rec 904 18 NETBIOS NetBIOS Service Protocols Ele 1001,1002 19 ECHO Echo Protocol Rec 862 20 DISCARD Discard Protocol Ele 863 21 CHARGEN Character Generator Protocol Ele 864 22 QUOTE Quote of the Day Protocol Ele 865 23 USERS Active Users Protocol Ele 866 24 DAYTIME Daytime Protocol Ele 867 25 TIME Time Server Protocol Ele 868 26 TFTP Trivial File Transfer Protocol Ele 1350 33* RIP Routing Information Protocol Ele 1058 34* [Note: an asterisk at the end of a line indicates a change from the previous edition of this document.] - - - 6.3. Network-Specific Standard Protocols Protocol Name State Status RFC ======== ===================================== ======= ====== ===== IP-FR Multiprotocol over Frame Relay Prop Ele 1294 IP-SMDS Transmission of IP Datagrams over SMDS Prop Ele 1209 ARP Address Resolution Protocol Std Ele 826 RARP A Reverse Address Resolution Protocol Std Ele 903 IP-ARPA Internet Protocol on ARPANET Std Ele BBN1822 IP-WB Internet Protocol on Wideband Network Std Ele 907 IP-X25 Internet Protocol on X.25 Networks Std Ele 877 IP-E Internet Protocol on Ethernet Networks Std Ele 894 IP-EE Internet Protocol on Exp. Ethernet Nets Std Ele 895 IP-IEEE Internet Protocol on IEEE 802 Std Ele 1042 IP-DC Internet Protocol on DC Networks Std Ele 891 IP-HC Internet Protocol on Hyperchannel Std Ele 1044 IP-ARC Internet Protocol on ARCNET Std Ele 1051 IP-SLIP Transmission of IP over Serial Lines Std Ele 1055 IP-NETBIOS Transmission of IP over NETBIOS Std Ele 1088 IP-IPX Transmission of 802.2 over IPX Networks Std Ele 1132 IP-FDDI Transmission of IP over FDDI Draft Ele 1188 - - - 6.4. Draft Standard Protocols Protocol Name Status RFC ======== ===================================== ============== ===== FINGER Finger Protocol Elective 1288 BGP3 Border Gateway Protocol 3 (BGP-3) Elective 1267,1268 OSPF2 Open Shortest Path First Routing V2 Elective 1247 POP3 Post Office Protocol, Version 3 Elective 1225 Concise-MIB Concise MIB Definitions Elective 1212 IP-FDDI Internet Protocol on FDDI Networks Elective 1188 TOPT-LINE Telnet Linemode Option Elective 1184 PPP Point to Point Protocol Elective 1171 BOOTP Bootstrap Protocol Recommended 951,1084 TP-TCP ISO Transport Service on top of the TCP Elective 1006 NICNAME WhoIs Protocol Elective 954 - - - 6.5. Proposed Standard Protocols Protocol Name Status RFC ======== ===================================== ============== ===== X.25 and ISDN in the Packet Mode Elective 1356* TABLE-MIB IP Forwarding Table MIB Elective 1354* ------- Administration of SNMP Elective 1353* SNMP-SEC SNMP Security Protocols Elective 1352* SNMP-ADMIN SNMP Administrative Model Elective 1351* TOS Type of Service in the Internet... Elective 1349* ------- Representation of Non-ASCII Text... Elective 1342* MIME Multipurpose Internet Mail Extensions Elective 1341* PPP-LINK PPP Link Quality Monitoring Elective 1333* PPP Point-to-Point Protocol (PPP) Elective 1331* ------- X.400 1988 to 1984 downgrading Elective 1328* ------- Mapping between X.400(1988)... Elective 1327* TCP-EXT TCP Extensions for High Performance Elective 1323* ------- Def. Man. Objs Parallel-printer-like... Elective 1318* ------- Def. Man Objs RS-232-like... Elective 1317* ------- Def. Man. Objs. Character Stream... Elective 1316* FRAME-MIB Management Information Base for Frame.. Elective 1315* NETFAX File Format for the Exchange of Images.. Elective 1314* SIP-MIB SIP Interface Type MIB Elective 1304 IARP Inverse Address Resolution Protocol Elective 1293 DECNET-MIB DECNET MIB Elective 1289 BRIDGE-MIB BRIDGE-MIB Elective 1286 FDDI-MIB FDDI-MIB Elective 1285 ETHER-MIB Ethernet MIB Elective 1284 ------- Encoding Network Addresses... Elective 1277 ------- Replication and Distributed Operations.. Elective 1276 ------- COSINE and Internet X.500 Schema... Elective 1274 RMON-MIB Remote Network Monitoring MIB Elective 1271 BGP-MIB Border Gateway Protocol MIB (Version 3) Elective 1269 ICMP-ROUT ICMP Router Discovery Messages Elective 1256 OSPF-MIB OSPF Version 2 MIB Elective 1253 IPSO DoD Security Options for IP Elective 1108 AT-MIB Appletalk MIB Elective 1243 OSI-UDP OSI TS on UDP Elective 1240 STD-MIBs Reassignment of Exp MIBs to Std MIBs Elective 1239 OSI-NSAP Guidelines for OSI NSAP Allocation Elective 1237 IPX-IP Tunneling IPX Traffic through IP Nets Elective 1234 DS3-MIB DS3 Interface Objects Elective 1233 DS1-MIB DS1 Interface Objects Elective 1232 802.5-MIB IEEE 802.5 Token Ring MIB Elective 1231 802.4-MIP IEEE 802.4 Token Bus MIB Elective 1230 GINT-MIB Extensions to the Generic-Interface MIB Elective 1229 PPP-EXT PPP Extensions for Bridging Elective 1220 OIM-MIB-II OSI Internet Management: MIB-II Elective 1214 IP-SMDS IP Datagrams over the SMDS Service Elective 1209 IP-ARCNET Transmitting IP Traffic over ARCNET Nets Elective 1201 IS-IS OSI IS-IS for TCP/IP Dual Environments Elective 1195 IP-MTU Path MTU Discovery Elective 1191 CMOT Common Management Information Services.. Elective 1189 IP-CMPRS Compressing TCP/IP Headers Elective 1144 ISO-TS-ECHO Echo for ISO-8473 Elective 1139 SUN-NFS Network File System Protocol Elective 1094 SUN-RPC Remote Procedure Call Protocol Elective 1057 NNTP Network News Transfer Protocol Elective 977 RLP Resource Location Protocol Elective 887 [Note: an asterisk at the end of a line indicates a change from the previous edition of this document.] - - - 6.6. Telnet Options For convenience, all the Telnet Options are collected here with both their state and status. Protocol Name Number State Status RFC STD ======== ===================================== ===== ====== ==== ==== TOPT-BIN Binary Transmission 0 Std Rec 856 27 TOPT-ECHO Echo 1 Std Rec 857 28 TOPT-RECN Reconnection 2 Prop Ele ... TOPT-SUPP Suppress Go Ahead 3 Std Rec 858 29 TOPT-APRX Approx Message Size Negotiation 4 Prop Ele ... TOPT-STAT Status 5 Std Rec 859 30 TOPT-TIM Timing Mark 6 Std Rec 860 31 TOPT-REM Remote Controlled Trans and Echo 7 Prop Ele 726 TOPT-OLW Output Line Width 8 Prop Ele ... TOPT-OPS Output Page Size 9 Prop Ele ... TOPT-OCRD Output Carriage-Return Disposition 10 Prop Ele 652 TOPT-OHT Output Horizontal Tabstops 11 Prop Ele 653 TOPT-OHTD Output Horizontal Tab Disposition 12 Prop Ele 654 TOPT-OFD Output Formfeed Disposition 13 Prop Ele 655 TOPT-OVT Output Vertical Tabstops 14 Prop Ele 656 TOPT-OVTD Output Vertical Tab Disposition 15 Prop Ele 657 TOPT-OLD Output Linefeed Disposition 16 Prop Ele 658 TOPT-EXT Extended ASCII 17 Prop Ele 698 TOPT-LOGO Logout 18 Prop Ele 727 TOPT-BYTE Byte Macro 19 Prop Ele 735 TOPT-DATA Data Entry Terminal 20 Prop Ele 1043 TOPT-SUP SUPDUP 21 Prop Ele 734 TOPT-SUPO SUPDUP Output 22 Prop Ele 749 TOPT-SNDL Send Location 23 Prop Ele 779 TOPT-TERM Terminal Type 24 Prop Ele 1091 TOPT-EOR End of Record 25 Prop Ele 885 TOPT-TACACS TACACS User Identification 26 Prop Ele 927 TOPT-OM Output Marking 27 Prop Ele 933 TOPT-TLN Terminal Location Number 28 Prop Ele 946 TOPT-3270 Telnet 3270 Regime 29 Prop Ele 1041 TOPT-X.3 X.3 PAD 30 Prop Ele 1053 TOPT-NAWS Negotiate About Window Size 31 Prop Ele 1073 TOPT-TS Terminal Speed 32 Prop Ele 1079 TOPT-RFC Remote Flow Control 33 Prop Ele 1080 TOPT-LINE Linemode 34 Draft Ele 1184 TOPT-XDL X Display Location 35 Prop Ele 1096 TOPT-EXTOP Extended-Options-List 255 Std Rec 861 32 - - - 6.7. Experimental Protocols Protocol Name Status RFC ======== ===================================== ============== ===== DNS NSAP DNS NSAP RRs Elective 1348* RMCP Remote Mail Checking Protocol Elective 1339* MSP2 Message Send Protocol 2 Elective 1312* DSLCP Dynamically Switched Link Control Elective 1307 -------- X.500 and Domains Elective 1279 SNMP-OSI SNMP over OSI Elective 1283 IN-ENCAP Internet Encapsulation Protocol Limited Use 1241 CLNS-MIB CLNS-MIB Limited Use 1238 CFDP Coherent File Distribution Protocol Limited Use 1235 SNMP-DPI SNMP Distributed Program Interface Limited Use 1228 SNMP-MUX SNMP MUX Protocol and MIB Limited Use 1227 IP-AX25 IP Encapsulation of AX.25 Frames Limited Use 1226 ALERTS Managing Asynchronously Generated Alerts Limited Use 1224 MPP Message Posting Protocol Limited Use 1204 ST-II Stream Protocol Limited Use 1190 SNMP-BULK Bulk Table Retrieval with the SNMP Limited Use 1187 DNS-RR New DNS RR Definitions Limited Use 1183 NTP-OSI NTP over OSI Remote Operations Limited Use 1165 EHF-MAIL Encoding Header Field for Mail Elective 1154 DMF-MAIL Digest Message Format for Mail Elective 1153 RDP Reliable Data Protocol Limited Use 908,1151 -------- Mapping between X.400(88) and RFC-822 Elective 1148 TCP-ACO TCP Alternate Checksum Option Not Recommended 1146 -------- Mapping full 822 to Restricted 822 Elective 1137 IP-DVMRP IP Distance Vector Multicast Routing Not Recommended 1075 TCP-LDP TCP Extensions for Long Delay Paths Limited Use 1072 IMAP2 Interactive Mail Access Protocol Limited Use 1176,1064 IMAP3 Interactive Mail Access Protocol Limited Use 1203 VMTP Versatile Message Transaction Protocol Elective 1045 COOKIE-JAR Authentication Scheme Not Recommended 1004 NETBLT Bulk Data Transfer Protocol Not Recommended 998 IRTP Internet Reliable Transaction Protocol Not Recommended 938 AUTH Authentication Service Not Recommended 931 LDP Loader Debugger Protocol Not Recommended 909 NVP-II Network Voice Protocol Limited Use ISI-memo PVP Packet Video Protocol Limited Use ISI-memo [Note: an asterisk at the end of a line indicates a change from the previous edition of this document.] 6.8. Informational Protocols Protocol Name Status RFC ======= ==================================== =============== ===== ------- Replication Requirements... Elective 1275* PCMAIL Pcmail Transport Protocol Elective 1056* MTP Multicast Transport Protocol Elective 1301 SNMP-IPX SNMP over IPX Elective 1298 BSD Login BSD Login Elective 1282 DIXIE DIXIE Protocol Specification Limited Use 1249 IP-X.121 IP to X.121 Address Mapping for DDN Limited Use 1236 OSI-HYPER OSI and LLC1 on HYPERchannel Limited Use 1223 HAP2 Host Access Protocol Limited Use 1221 SUBNETASGN On the Assignment of Subnet Numbers Limited Use 1219 SNMP-TRAPS Defining Traps for use with SNMP Limited Use 1215 DAS Directory Assistance Service Limited Use 1202 MD4 MD4 Message Digest Algorithm Limited Use 1186 LPDP Line Printer Daemon Protocol Limited Use 1179 [Note: an asterisk at the end of a line indicates a change from the previous edition of this document.] 6.9. Historic Protocols Protocol Name Status RFC ======= ===================================== ============== ===== PPP-INIT PPP Initial Configuration Options Not Recommended 1172* MSP Message Send Protocol Not Recommended 1159* -------- Mail Privacy: Procedures Not Recommended 1113* -------- Mail Privacy: Key Management Not Recommended 1114* -------- Mail Privacy: Algorithms Not Recommended 1115* -------- Mapping X.400(84) and RFC-822 Not Recommended 987,1026* NFILE A File Access Protocol Elective 1037* HOSTNAME HOSTNAME Protocol Elective 953* SFTP Simple File Transfer Protocol Elective 913* SUPDUP SUPDUP Protocol Elective 734* BGP Border Gateway Protocol Not Recommended 1163,1164 MIB-I MIB-I Not Recommended 1156 SGMP Simple Gateway Monitoring Protocol Not Recommended 1028 HEMS High Level Entity Management Protocol Not Recommended 1021 STATSRV Statistics Server Not Recommended 996 POP2 Post Office Protocol, Version 2 Not Recommended 937 RATP Reliable Asynchronous Transfer Protocol Not Recommended 916 HFEP Host - Front End Protocol Not Recommended 929 THINWIRE Thinwire Protocol Not Recommended 914 HMP Host Monitoring Protocol Not Recommended 869 GGP Gateway Gateway Protocol Not Recommended 823 RTELNET Remote Telnet Service Not Recommended 818 CLOCK DCNET Time Server Protocol Not Recommended 778 MPM Internet Message Protocol Not Recommended 759 NETRJS Remote Job Service Not Recommended 740 NETED Network Standard Text Editor Not Recommended 569 RJE Remote Job Entry Not Recommended 407 XNET Cross Net Debugger Not Recommended IEN-158 NAMESERVER Host Name Server Protocol Not Recommended IEN-116 MUX Multiplexing Protocol Not Recommended IEN-90 GRAPHICS Graphics Protocol Not Recommended NIC-24308 [Note: an asterisk at the end of a line indicates a change from the previous edition of this document.] From owner-nordpost@nada.kth.se Sat Dec 5 23:56:30 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA19384; Sat, 5 Dec 92 23:56:36 +0100 Received: from ifi.uio.no by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA19368; Sat, 5 Dec 92 23:56:30 +0100 Received: from gyda.ifi.uio.no by ifi.uio.no with SMTP id ; Sat, 5 Dec 1992 23:56:28 +0100 Received: by gyda.ifi.uio.no ; Sat, 5 Dec 1992 23:56:27 +0100 From: Erik Naggum Reply-To: Erik Naggum Message-Id: <19921205.011@erik.naggum.no> Date: 05 Dec 1992 23:56:27 +0100 To: nordpost@nada.kth.se In-Reply-To: [fa.nordpost] <199212022226.AA28316@dkuug.dk> References: <199212022226.AA28316@dkuug.dk> Subject: Re: "Intro"-tecken i MNEMONICS Errors-To: owner-nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*175 [Keld J|rn Simonsen] | | Du ved jo godt at mit arbejde kommer fra noget troff arbejde, som jo | ikke er meget forskelligt funktionelt fra SGML. Eh. Jo. Forskjellen er meget stor. SGML er et beskrivelsessprog, mens troff er et prosesseringssprog. SGML beskriver "generalized markup", mens troff har makroer for } utf|re spesifikke funksjoner for layout. Jeg orker ikke } svare p} alle de andre tingene jeg er uenig med deg i. Punktvise motargumenter blir s} forbannet lite interessante efterhvert, s{rlig n}r motparten ikke _vil_ forst}. From owner-nordpost@nada.kth.se Mon Dec 7 19:12:55 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA06989; Mon, 7 Dec 92 19:13:00 +0100 Received: from cyklop.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA06973; Mon, 7 Dec 92 19:12:55 +0100 Received: from HERON.DAFA.SE by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA13420; Mon, 7 Dec 92 19:12:53 +0100 X400-Received: by /PRMD=QZ/ADMD=TEDE/C=SE/; Relayed; 07 Dec 92 19:02:43+0100 Date: 07 Dec 92 19:02:43+0100 From: Lennart Borgman AB_Draco Message-Id: <847074*Lennart.Borgman@AB_Draco.dafa.se> In-Reply-To: <9212041530.AA14680@mercutio.admin.kth.se> To: Datorpostteknik i Norden , Mailchar nordiskt mote om teckenstandarder i elektronisk post Subject: Tack! Hur hittar man mer info? Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*176 Tack s} mycket f|r infon om vad RFC egentligen {r och hur man hittar dem. Detta {r s{kerligen fel m|te, men jag skulle vilja st{lla en vidare fr}ga, eftersom det finns folk med i konferensen som {r intresserade av standarder. Jag upplever det som sv}rt att hitta vettig information om standarder eller "gryende" standarder. Internet verka ha en viss diskussion om detta. [r den vettig {ven f|r den som inte g|r standarder, utan s} att s{ga mer tillh|r dem som standarden g|rs f|r? Finns det n}gra vettiga tidskrifter som f|ljer utvecklingen? Det sv}ra upplever jag {r att f} grep om strukturen p} olika f|reslagna, justitie och de facto standarder. Kan t ex DCE strukturm{ssigt ers{tta LanManager? G}r DCE tillr{ckligt l}ngt i specifikationerna, eller kommer det att finnas en flora av motsvarigheter i DCE till olika LM-tj{nster? From owner-nordpost@nada.kth.se Wed Dec 9 18:31:57 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04399; Wed, 9 Dec 92 18:32:03 +0100 Received: from cyklop.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04375; Wed, 9 Dec 92 18:31:57 +0100 Received: from HERON.DAFA.SE by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA03783; Wed, 9 Dec 92 18:31:54 +0100 X400-Received: by /PRMD=QZ/ADMD=TEDE/C=SE/; Relayed; 09 Dec 92 18:30:38+0100 Date: 09 Dec 92 18:30:38+0100 From: Jacob Palme SKHB Message-Id: <1242514*JPALME@SKHB.dafa.se> To: Datorpostteknik i Norden Subject: MIME i mail resp news Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*177 Det h{r med |verg}ng till MIME: G{ller det enbart Internet mail och inte Usenet News? Man borde ju ha samma behov av b{ttre teckenstandarder i News som i Mail! From owner-nordpost@nada.kth.se Wed Dec 9 18:31:57 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04413; Wed, 9 Dec 92 18:32:12 +0100 Received: from cyklop.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04376; Wed, 9 Dec 92 18:31:57 +0100 Received: from HERON.DAFA.SE by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA03782; Wed, 9 Dec 92 18:31:54 +0100 X400-Received: by /PRMD=QZ/ADMD=TEDE/C=SE/; Relayed; 09 Dec 92 18:30:35+0100 Date: 09 Dec 92 18:30:35+0100 From: Jacob Palme SKHB Message-Id: <1242513*JPALME@SKHB.dafa.se> To: Datorpostteknik i Norden Subject: Att automatiskt ta reda pa i vilket sprak en text ar skriven Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*178 Jag skrev f|r n}gra }r sedan ett program som tittade p} en text och listade ut om texten var skriven p} svenska eller engelska. Principen var att programmet r{knade p} frekvensen av f|rekomsten av de 20 vanligaste orden i resp. spr}k, allts} t.ex. "och" f|r svensk text. Det visade sig vara mycket enkelt, {ven p} mycket korta texter, att automatiskt och korrekt avg|ra vilket spr}k texten var skriven p}. Om det allts} {r s} att man har behov av att lista ut spr}ket f|r ett meddelande f|r att veta hur man skall visa vissa tecken- koder p} sk{rmen, s} {r detta i allm{nhet l{tt! Ett undantag dock: Om inl{gg inneh}ller en blandning av text i flera spr}k, eller om de delvis inneh}ller datorprogram i n}got artificiellt spr}k, i s} fall hade mitt program helt naturligt sv}rt att lista ut vilket spr}k inl{gget var skrivet p}. From owner-nordpost@nada.kth.se Mon Dec 21 01:31:39 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA29120; Mon, 21 Dec 92 01:31:45 +0100 Received: from othello.admin.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA29104; Mon, 21 Dec 92 01:31:39 +0100 Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b) id AA00555; Mon, 21 Dec 92 01:31:38 +0100 Received: by mercutio.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0) id AA24421; Mon, 21 Dec 92 01:32:06 +0100 Date: Mon, 21 Dec 92 01:32:06 +0100 Message-Id: <9212210032.AA24421@mercutio.admin.kth.se> From: Olle Jarnefors To: Datorpostteknik i Norden Cc: Olle Jarnefors In-Reply-To: <1242513*JPALME@SKHB.dafa.se> "09 Dec 92 18:30:35+0100" (From: Jacob Palme SKHB ) Subject: Re: Att automatiskt ta reda pa i vilket sprak en text ar skriven Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*179 > Jag skrev f|r n}gra }r sedan ett program som tittade p} en text och > listade ut om texten var skriven p} svenska eller engelska. Principen > var att programmet r{knade p} frekvensen av f|rekomsten av de 20 > vanligaste orden i resp. spr}k, allts} t.ex. "och" f|r svensk > text. > > Det visade sig vara mycket enkelt, {ven p} mycket korta texter, > att automatiskt och korrekt avg|ra vilket spr}k texten var skriven > p}. > > Om det allts} {r s} att man har behov av att lista ut spr}ket > f|r ett meddelande f|r att veta hur man skall visa vissa tecken- > koder p} sk{rmen, s} {r detta i allm{nhet l{tt! > > Ett undantag dock: Om inl{gg inneh}ller en blandning av text > i flera spr}k, eller om de delvis inneh}ller datorprogram i > n}got artificiellt spr}k, i s} fall hade mitt program helt naturligt > sv}rt att lista ut vilket spr}k inl{gget var skrivet p}. Alldeles r{tt. Det {r en s} enkel och effektiv metod att genomsk}da vilket spr}k en text {r skriven p} att det {r egendomligt att den inte utnyttjas i v{rst m}nga datorprogram. (Jag vet inget enda.) H{r {r en frekvensordnad lista p} de 50 vanligaste orden i svenska spr}ket enligt en unders|kning av en mycket stor m{ngd tidningstext som utf|rdes vid G|teborgs universitet i slutet p} 60-talet: och i att en som det av {r den p} f|r med de till har inte ett om man han men sig kan s} var fr}n ocks} sin eller vi vid under d{r jag detta skulle {n nu n{r mycket vara skall hade andra |ver }r mot hans d} alla Jacob oroar sig f|r att den h{r metoden inte kan anv{ndas om ett meddelande inneh}ller en blandning av text p} olika spr}k. Men titta till exempel p} den text av Jacob som jag har citerat h{r ovan. Varenda rad utom en (den som best}r av ordet "text") inneh}ller minst ett av de tio vanligaste svenska orden. Ett spr}kanalysprogram torde allts} kunna analysera ett inl{gg rad f|r rad. Ytterligare en sak b|r uppm{rksammas: Med samma teknik {r det l{tt att avg|ra om en text p} svenska {r kodad med svensk 7-bitskod, Latin-1 (ISO 8859-1), IBMPC-kod eller Macintosh-kod. Bara att leta efter de olika oktettf|ljder som de vanligaste orden med }{| ({r p} f|r s} fr}n ocks} d{r {n n{r |ver) ger i de olika teckenkoderna. H{r {r en hj{lpreda f|r den som vill prova detta praktiskt. ][\-|versikt: 7 8 P M R N = = = = = = 5B [ 7 = sv7 = svensk 7-bitskod (SS 63 61 27) 5C \ 8 = la1 = Latin-1 (ISO 8859-1) 5D ] P = pc = IBMPC-koder 7B { M = mac = Macintosh-koder 7C | R = r8 = ROMAN-8 (HP) 7D } N = nxt = NeXT-kod (Postscript-kod) 80 [ 81 ] 84 { 85 \ [ 86 } ] 8A { 8C } 8E [ 8F ] 94 | 96 \ 99 \ 9A | C4 [ C5 ] CC { CE | D0 ] D4 } D6 \ D8 [ D9 { DA \ } E4 { E5 } F0 | F6 | From owner-nordpost@nada.kth.se Mon Dec 21 13:59:14 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04238; Mon, 21 Dec 92 13:59:20 +0100 Received: from kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04222; Mon, 21 Dec 92 13:59:14 +0100 Received: from HERON.DAFA.SE by kth.se (5.65+bind 1.7+ida 1.4.2/6.0) id AA05091; Mon, 21 Dec 92 13:59:13 +0100 X400-Received: by /PRMD=QZ/ADMD=TEDE/C=SE/; Relayed; 21 Dec 92 13:46:06+0100 Date: 21 Dec 92 13:46:06+0100 From: Jacob Palme SKHB Message-Id: <1242598*JPALME/O=SU/OU=DSV/@NONE.SE> In-Reply-To: <9212210012.AA24328@mercutio.admin.kth.se> To: Datorpostteknik i Norden , "Olle J{rnefors" Subject: Re: MIME i mail resp news Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*180 Om man anv{nder MIME s} har man v{l inget st|rre behov av en 8 bitars transportmekanism, ty d} kodas ju allt {nd} i 7-bits-form? From owner-nordpost@nada.kth.se Mon Dec 21 14:14:27 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04383; Mon, 21 Dec 92 14:14:31 +0100 Received: from cyklop.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04367; Mon, 21 Dec 92 14:14:27 +0100 Received: from HERON.DAFA.SE by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14303; Mon, 21 Dec 92 14:14:24 +0100 X400-Received: by /PRMD=QZ/ADMD=TEDE/C=SE/; Relayed; 21 Dec 92 14:02:05+0100 Date: 21 Dec 92 14:02:05+0100 From: Jacob Palme SKHB Message-Id: <1242599*JPALME/O=SU/OU=DSV/@NONE.SE> In-Reply-To: <9212210032.AA24421@mercutio.admin.kth.se> To: Datorpostteknik i Norden , Mailchar nordiskt mote om teckenstandarder i elektronisk post Subject: Re: Att automatiskt ta reda pa i vilket sprak en text ar skri Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*181 Jag testk|rde mitt program f|r att lista ut spr}ket p} en text p} ett antal filer i den s.k. QINFO-databasen p} QZ, en databas som jag hade lagt upp och som bestod av intressanta texter ur e-mail m.m. Mitt program ber{knade en kvot f|r svenska och en f|r engelska, om kvoten f|r det ena spr}ket var tillr{ckligt mycket h|gre {n f|r det andra, ans}g programmet att det var i det spr}ket. Det fungerade perfekt f|r alla texter som verkligen inneh|ll vanligt spr}k. Men f|r n}gra texter som inneh|ll blandat svenska och engelska, eller som delvis inneh|ll information i n}got artificuellt spr}k, slog programmet slint. Jag har antagligen programmet kvar p} n}got band n}gonstans om n}gon vill ha en kopia av det. From owner-nordpost@nada.kth.se Mon Dec 21 14:25:06 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04667; Mon, 21 Dec 92 14:25:10 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04651; Mon, 21 Dec 92 14:25:06 +0100 Received: by dkuug.dk id AA03794 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Mon, 21 Dec 1992 14:24:52 +0100 Message-Id: <199212211324.AA03794@dkuug.dk> From: keld@dkuug.dk (Keld J|rn Simonsen) Date: Mon, 21 Dec 1992 14:24:51 +0100 In-Reply-To: Jacob Palme SKHB on Dec 21, 14:21 MET <1242599*JPALME/O=SU/OU=DSV/@NONE.SE> <9212210032.AA24421@mercutio.admin.kth.se> X-Charset: ASCII X-Char-Esc: 29 Mime-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mnemonic-Intro: 29 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: nordpost@nada.kth.se Subject: Re: Att automatiskt ta reda pa i vilket sprak en text ar skri Cc: Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*182 Jacob Palme SKHB writes: > Jag testk|rde mitt program f|r att lista ut spr}ket p} en text > p} ett antal filer i den s.k. QINFO-databasen p} QZ, en databas > som jag hade lagt upp och som bestod av intressanta texter > ur e-mail m.m. Mitt program ber{knade en kvot f|r svenska och > en f|r engelska, om kvoten f|r det ena spr}ket var tillr{ckligt > mycket h|gre {n f|r det andra, ans}g programmet att det var > i det spr}ket. Det fungerade perfekt f|r alla texter som > verkligen inneh|ll vanligt spr}k. Men f|r n}gra texter som > inneh|ll blandat svenska och engelska, eller som delvis inneh|ll > information i n}got artificuellt spr}k, slog programmet slint. > > Jag har antagligen programmet kvar p} n}got band n}gonstans > om n}gon vill ha en kopia av det. ja, jeg vil gerne have en kopi af det. Hvordan gik det io/vrigt med mine konverteringsrutiner? Var de brugbare? -- Keld From owner-nordpost@nada.kth.se Mon Dec 21 15:38:03 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA05386; Mon, 21 Dec 92 15:38:11 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA05365; Mon, 21 Dec 92 15:38:03 +0100 Received: by dkuug.dk id AA06713 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Mon, 21 Dec 1992 15:37:47 +0100 Message-Id: <199212211437.AA06713@dkuug.dk> From: keld@dkuug.dk (Keld J|rn Simonsen) Date: Mon, 21 Dec 1992 15:37:47 +0100 In-Reply-To: keld@dkuug.dk (Keld J|rn Simonsen) on Dec 21, 14:41 MET <199212211324.AA03794@dkuug.dk> Jacob Palme SKHB on Dec 21, 14:21 MET <1242599*JPALME/O=SU/OU=DSV/@NONE.SE> <9212210032.AA24421@mercutio.admin.kth.se> X-Charset: ASCII X-Char-Esc: 29 Mime-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mnemonic-Intro: 29 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: nordpost@nada.kth.se Subject: Re: Att automatiskt ta reda pa i vilket sprak en text ar skri Cc: Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*183 Keld J|rn Simonsen writes: > Jacob Palme SKHB writes: > > > Jag har antagligen programmet kvar p} n}got band n}gonstans > > om n}gon vill ha en kopia av det. > > ja, jeg vil gerne have en kopi af det. Dette var ment som en besked kun til Jacob. Jeg brugte min almindelige reply til forfatter-funktion, men dette havde altsaa utilsigtet resultat. Peter, kunne du ikke go/re saa man nemt kan svare kun til forfatteren af artiklen? Dette er normal procedure for mailinglister mange andre steder. -- Keld From paf@nada.kth.se Mon Dec 21 17:01:59 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA06215; Mon, 21 Dec 92 17:02:09 +0100 Received: from sysman.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA06195; Mon, 21 Dec 92 17:01:59 +0100 Received: from localhost.nada.kth.se by sysman.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA22111; Mon, 21 Dec 92 17:01:57 +0100 Message-Id: <9212211601.AA22111@sysman.nada.kth.se> To: nordpost@nada.kth.se Cc: "Olle J{rnefors" Subject: Re: MIME i mail resp news In-Reply-To: Your message of 21 Dec 92 13:46:06 +0100. <1242598*JPALME/O=SU/OU=DSV/@NONE.SE> Date: Mon, 21 Dec 92 17:01:56 +0100 From: Patrik F{ltstr|m Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*184 Citat ur brev fr}n: Jacob Palme SKHB >Om man anv{nder MIME s} har man v{l inget st|rre behov av en >8 bitars transportmekanism, ty d} kodas ju allt {nd} i 7-bits-form? I och fðr sig, men om mottagaren INTE har MIME (vilket sÙkert kommer vara fallet ett lÚngt tag framÚt), sÚ ser det bÙttre ut med 8-bitars transport och ISO-8859-1. paf From owner-nordpost@nada.kth.se Tue Dec 22 00:05:17 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08927; Tue, 22 Dec 92 00:05:22 +0100 Received: from othello.admin.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08911; Tue, 22 Dec 92 00:05:17 +0100 Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b) id AA27638; Tue, 22 Dec 92 00:05:08 +0100 Received: by mercutio.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0) id AA27654; Tue, 22 Dec 92 00:05:35 +0100 Date: Tue, 22 Dec 92 00:05:35 +0100 Message-Id: <9212212305.AA27654@mercutio.admin.kth.se> From: Olle Jarnefors , Peter Svanberg Old-Sender: Olle Jarnefors To: Datorpostteknik i Norden Cc: keld@dkuug.dk (Keld J|rn Simonsen), Olle Jarnefors In-Reply-To: <199212211437.AA06713@dkuug.dk> "Mon, 21 Dec 1992 15:37:47 +0100" (From: Keld J|rn Simonsen ) Subject: Re: Att automatiskt ta reda pa i vilket sprak en text ar skri Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*185 > Peter, kunne du ikke go/re saa man nemt kan svare kun til > forfatteren af artiklen? Dette er normal procedure for mailinglister > mange andre steder. Vad vi har f|rst}tt finns det tv} sorters brevlistor. 1) P} de som har v{ldigt stor trafik eller d{r det mesta handlar om att b{ttre informerade personer svarar p} fr}gor fr}n mer okunniga personer {r det normala att kommentarer skickas till f|rfattaren av listinl{gget som vanliga brev. Han/hon sammanfattar sedan alla synpunkter och skickar en sammanst{llning till brevlistan. 2) P} brevlistor med mer moderat trafikvolym och p} brevlistor d{r en mer genuin diskussion mellan mer eller mindre j{mb|rdiga deltagare {ger rum {r det vanliga att svar och kommentarer skickas direkt till listan. En del har brevlistan som To:-mottagare, andra bara som Cc:-mottagare, men effekten {r den samma. Det {r ganska klart att nordpost-listan h|r till kategori 2 snarare {n 1. D{rf|r har vi valt att Reply-To:-f{ltet i inl{gg som skickas ut fr}n listan normalt ska peka p} listan sj{lv. Om man skickar ett inl{gg till listan med ett Reply-To:-f{lt med annat inneh}ll, till exempel ens egen datorpostadress, kommer det dock att respekteras av brevlistan och allts} inte {ndras. P} det s{ttet kan man sj{lv best{mma om kommentarer till ett inl{gg man g|r normalt kommer att skickas direkt till listan eller bara till en sj{lv. (Ett tag funderade vi p} denna l|sning: Utg}ende brev f}r tv} f{lt, Reply-To: med avs{ndarens adress och Followup-To: med brevlistans adress. Om Followup-To: har inneh}llet "poster" inneb{r detta att inga svar ska skickas direkt till listan. Ungef{r s} fungerar det i news enligt RFC 1036, avsnitt 2.2.1 och 2.2.3. Vi avskrev dock detta eftersom sannolikt inga datorbrevskickningsprogram tar h{nsyn till dessa tv} brevhuvudf{lt p} detta s{tt.) F|r |vrigt inneh|ll ditt inl{gg n}gra CTRL-], textfr{mmande styrtecken som inte b|r skickas till brevlistor. -- Olle J{rnefors, TS-Data, KTH 08-790 71 26 --- Peter Svanberg Datorpost psv@nada.kth.se Nada, KTH 100 44 STHLM From owner-nordpost@nada.kth.se Tue Dec 22 00:23:20 1992 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09613; Tue, 22 Dec 92 00:23:26 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09597; Tue, 22 Dec 92 00:23:20 +0100 Received: by dkuug.dk id AA22924 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Tue, 22 Dec 1992 00:23:12 +0100 Message-Id: <199212212323.AA22924@dkuug.dk> From: keld@dkuug.dk (Keld J|rn Simonsen) Date: Tue, 22 Dec 1992 00:23:11 +0100 In-Reply-To: Olle Jarnefors , Peter Svanberg on Dec 22, 0:06 MET <9212212305.AA27654@mercutio.admin.kth.se> <199212211437.AA06713@dkuug.dk> "Mon, 21 Dec 1992 15:37:47 +0100" (From: Keld J|rn Simonsen ) X-Charset: ASCII X-Char-Esc: 29 Mime-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mnemonic-Intro: 29 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: nordpost@nada.kth.se Subject: Re: Att automatiskt ta reda pa i vilket sprak en text ar skri Cc: Olle Jarnefors Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*186 De mailere jeg har set, har to slags svarmuligheder: en til afsenderen og en til afsender+cc . Dette g{lder bla for elm, mush, mh og mailx. Jeg kunne |nske mig at de to muligheder kunne udnyttes n}r man kommunikerede p} nordpost listen. Dette kunne g|res ved at fjerne den "Reply-To:" header, som I inds{tter, efter min mening helt un|digt. -- Keld From owner-nordpost@nada.kth.se Mon Jan 4 13:45:11 1993 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA06550; Mon, 4 Jan 93 13:45:17 +0100 Received: from malmo.trab.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA06534; Mon, 4 Jan 93 13:45:11 +0100 Received: by malmo.trab.se (5.65+bind 1.7+ida 1.4.2/TRM-1-NS); Mon, 4 Jan 93 13:45:09 +0100 (MET) Date: Mon, 4 Jan 93 13:45:09 +0100 From: Dan Oscarsson Message-Id: <9301041245.AA01729@malmo.trab.se> To: nordpost@nada.kth.se Subject: kodning av ISO 10646 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*187 Vi skall i och för sig prata om MIME, men då teckenkodning är relaterat till MIME så skulle jag vilja veta hur ni ser på detta: Det finns ett behov av att använda EN teckenkodning, både för utbyte av data och att använda lokalt på sitt system. Idag finns det en standard ISO 10646 som täcker de flesta tecken i världen och därför vore det lämpligt om den användes. Men för att enkelt införa den och för att inte behöva använda 4 oktetter per tecken i alla fall, behövs ett sätt att representera ISO 10646 i ett 1-oktettsformat. Speciellt på system som idag använder ASCII eller ISO 8859-1, som båda är äkta delmängder av ISO 10646, vore en 1-oktettskodning som är kompatibel med dessa lämplig. Jag känner till två föreslagna kodningar av ISO 10646 som använder 1-oktetts- kodning: UTF och UTF-2 (FSS-UTF). Den första är den gamla och den andra är en nyare som inte använder ASCII-tecken i kodningen för mer än ASCII-tecken, och därför kan användas i filnamn. MEN båda dessa är bara kompatibla med ASCII, INTE ISO 8859-1! De kan alltså inte användas på system som använder ISO 8859-1- kodning. En del anser att om man inför ISO 8859-1 kompatibilitet så måste alla andra ISO 8859-* kodningarna också klaras. Men jag kan inte se att detta har någon koppling. De andra ISO 8859-*-koderna är INTE delmängder av ISO 10646. Dessutom är det ISO 8859-1 som många leverantörer stödjer idag (bl.a. flera operativsystem, många applikation, t.o.m. MS Windows). Om kodningen inte är ISO 8859-1 kompatibel, betyder det att jag på mitt system kommer att behöva vänta MYCKET länge innan jag kan byta till ISO 10646. Eftersom jag då inte kan byta gradvis utan måste ändra allt på en gång inklusive koda om alla filer. Jag måste vänta tills både operativsystem och ALLA applikationer stödjer det nya kodningsformatet. Annars skulle t.ex. en del applikationer fortfarande skriva ISO 8859-1-filer. Om en 1-oktettskodning som var ISO 8859-1 kompatibel användes, kan en gradvis övergång ske eftersom ISO 8859-1 applikationer fortfarande använder en korrekt kodning. För er som tänker med fasa på övergången till Solaris 2.x på era Sunnar, det bytet är en barnlek jämfört med att byta till ISO 10646 utan ISO 8859-1 kompatibilitet. Jag tycker att vi skall ta fram en ny 1-oktettskodning av ISO 10646 och föreslå den för resten av världen och inte bara godta den engelsktalande delens behov. Det är inget svårt alls att ge ett förslag till en kodning som är kompatibel med både ASCII och ISO 8859-1, och dessutom fortfarande är ganska kompakt även för koder utöver dessa. Jag kan ge ett förslag. Vad tycker ni? Dan -- Dan Oscarsson Telia Research AB Email: Dan.Oscarsson@malmo.trab.se Box 85 201 20 Malmo, Sweden From owner-nordpost@nada.kth.se Mon Jan 4 14:00:39 1993 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA06663; Mon, 4 Jan 93 14:00:43 +0100 Received: from oddput.efd.lth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA06647; Mon, 4 Jan 93 14:00:39 +0100 Received: by efd.lth.se (Smail3.1.28.1 #1) id m0n8rQ6-0002VVC; Mon, 4 Jan 93 14:00 MET Message-Id: To: nordpost@nada.kth.se Subject: Re: kodning av ISO 10646 In-Reply-To: Your message of "Mon, 04 Jan 1993 13:45:09 +0100." <9301041245.AA01729@malmo.trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Mon, 04 Jan 1993 14:00:37 +0100 From: Joergen Haegg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*188 In message <9301041245.AA01729@malmo.trab.se>you write: > > >Men f|r att enkelt inf|ra den och f|r att inte beh|va anv{nda 4 oktetter >per tecken i alla fall, beh|vs ett s{tt att representera ISO 10646 Men är det 10646 som kommer att erövra världen? Jag vill minnas någon 16-bitskod (UNICODE eller nåt) som skulle klara allt som 10646 kan. -------- Jörgen Hägg jh@efd.lth.se postmaster@efd.lth.se Telnr: 046-107492, 104013(fax) Snigelpost: Hämtställe 7, BOX 118, 221 00 LUND Lunds Tekniska Högskola Paket: E-huset, Ole Römers väg 3, 221 00 LUND Bore, n.: A person who talks when you wish him to listen. -- Ambrose Bierce, "The Devil's Dictionary" From psv@nada.kth.se Mon Jan 4 18:21:56 1993 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09059; Mon, 4 Jan 93 18:22:04 +0100 Received: from cyklop.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09043; Mon, 4 Jan 93 18:21:56 +0100 Received: from localhost.nada.kth.se by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA02163; Mon, 4 Jan 93 18:21:53 +0100 Message-Id: <9301041721.AA02163@cyklop.nada.kth.se> To: nordpost@nada.kth.se Subject: Re: kodning av ISO 10646 In-Reply-To: <9301041245.AA01729@malmo.trab.se> from "Dan Oscarsson " "Mon, 4 Jan 93 13:45:09 +0100 " Date: Mon, 04 Jan 93 18:21:52 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*189 Citat ur brev från: Dan Oscarsson > > Jag känner till två föreslagna kodningar av ISO 10646 som använder 1-oktetts- > kodning: UTF och UTF-2 (FSS-UTF). (Det som tidigare hette UTF kallas numera UTF-1.) > En del anser att om man inför ISO 8859-1 kompatibilitet så måste alla > andra ISO 8859-* kodningarna också klaras. Men jag kan inte se att detta > har någon koppling. De andra ISO 8859-*-koderna är INTE delmängder av > ISO 10646. Koppligen heter rättvisa! Favorisering av Latin-1-kod skulle av vissa betraktas som "eurocentrism", dvs. att vi behandlar icke-Europa+USA styvmoderligt - en parallell till hur USA behandlat icke-USA tidigare. > Dessutom är det ISO 8859-1 som många leverantörer stödjer > idag (bl.a. flera operativsystem, många applikation, t.o.m. MS > Windows). Unixsystem levererade i västra Europa är "inställda" på Latin-1-kod men huvudparten av programvaran har väl inga förutfattade meningar om _vilken_ åttabitskod som används? Med "locale"-hanteringen ställer man ju lätt om till något annat. Någon som vet i vilken utsträckning andra 8859-delar används och understöds? Jag tror inte det är försumbart. > Om kodningen inte är ISO 8859-1 kompatibel, betyder det att jag på mitt > system kommer att behöva vänta MYCKET länge innan jag kan byta till > ISO 10646. > Eftersom jag då inte kan byta gradvis utan måste ändra allt på en gång > inklusive koda om alla filer. Jag måste vänta tills både operativsystem och > ALLA applikationer stödjer det nya kodningsformatet. Annars skulle t.ex. en > del applikationer fortfarande skriva ISO 8859-1-filer. Tja, förutsatt att den nya kodningen "gömmer" icke-Latin-1-tecken på ett sätt som alla Latin-1-kunniga program hanterar vettigt (vid läsning, alltså). Finns en sådan kodning? > För er som tänker med fasa på övergången till Solaris 2.x på era Sunnar, det > bytet är en barnlek jämfört med att byta till ISO 10646 utan ISO 8859-1 > kompatibilitet. Jag betvivlar ändå om det är vettigt att byta till UCS innan man har fullständigt understöd. > Jag tycker att vi skall ta fram en ny 1-oktettskodning av ISO 10646 och > föreslå den för resten av världen och inte bara godta den engelsktalande > delens behov. Precis detsamma kan alla 8859-x-användande länder hävda. > Det är inget svårt alls att ge ett förslag till en kodning som är > kompatibel med både ASCII och ISO 8859-1, och dessutom fortfarande är > ganska kompakt även för koder utöver dessa. Jag kan ge ett förslag. Kan du göra en kodning som är så elegant enkel som UTF-2 men där alla åttabitsoktetter är Latin-1-dito (utom möjligen några enstaka i C1) så vill jag gärna se den! --- Peter Svanberg, Nada, KTH From owner-nordpost@nada.kth.se Tue Jan 5 09:02:10 1993 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14535; Tue, 5 Jan 93 09:02:17 +0100 Received: from malmo.trab.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14514; Tue, 5 Jan 93 09:02:10 +0100 Received: by malmo.trab.se (5.65+bind 1.7+ida 1.4.2/TRM-1-NS); Tue, 5 Jan 93 09:02:09 +0100 (MET) Date: Tue, 5 Jan 93 09:02:09 +0100 From: Dan Oscarsson Message-Id: <9301050802.AA06636@malmo.trab.se> To: nordpost@nada.kth.se Subject: Re: kodning av ISO 10646 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*190 >> En del anser att om man inf|r ISO 8859-1 kompatibilitet s} m}ste alla >> andra ISO 8859-* kodningarna ocks} klaras. Men jag kan inte se att detta >> har n}gon koppling. De andra ISO 8859-*-koderna {r INTE delm{ngder av >> ISO 10646. > >Koppligen heter r{ttvisa! Favorisering av Latin-1-kod skulle av vissa >betraktas som "eurocentrism", dvs. att vi behandlar icke-Europa+USA >styvmoderligt - en parallell till hur USA behandlat icke-USA tidigare. > Frågan är vilken nivå man kan vara rättvis. Även icke 8859-* borde kanske stödjas. Och varför stödja ASCII? Anledningen jag tycker ISO 8859-1 kan stödjas är att den är en delmängd av ISO 10646. Det är ingen av de andra. >> Dessutom {r det ISO 8859-1 som m}nga leverant|rer st|djer >> idag (bl.a. flera operativsystem, m}nga applikation, t.o.m. MS >> Windows). > >Unixsystem levererade i v{stra Europa {r "inst{llda" p} Latin-1-kod >men huvudparten av programvaran har v{l inga f|rutfattade meningar om >_vilken_ }ttabitskod som anv{nds? Åtminstone FrameMaker och CAP har 8859-1 hantering och inget annat, tror jag. NIS+, IDL har bara 8859-1. Vet ej om MS Windows har annat än 8859-1. Finns säkert fler. > >> Om kodningen inte {r ISO 8859-1 kompatibel, betyder det att jag p} mitt >> system kommer att beh|va v{nta MYCKET l{nge innan jag kan byta till >> ISO 10646. >> Eftersom jag d} inte kan byta gradvis utan m}ste {ndra allt p} en g}ng >> inklusive koda om alla filer. Jag m}ste v{nta tills b}de operativsystem och >> ALLA applikationer st|djer det nya kodningsformatet. Annars skulle t.ex. en >> del applikationer fortfarande skriva ISO 8859-1-filer. > >Tja, f|rutsatt att den nya kodningen "g|mmer" icke-Latin-1-tecken p} >ett s{tt som alla Latin-1-kunniga program hanterar vettigt (vid >l{sning, allts}). Finns en s}dan kodning? Svårt att "gömma" tecken. UTF-2 gömmer inga. UTF-2 använder dessutom en del C1-kontrolltecken som kan störa. >> Det {r inget sv}rt alls att ge ett f|rslag till en kodning som {r >> kompatibel med b}de ASCII och ISO 8859-1, och dessutom fortfarande {r >> ganska kompakt {ven f|r koder ut|ver dessa. Jag kan ge ett f|rslag. > >Kan du g|ra en kodning som {r s} elegant enkel som UTF-2 men d{r alla >}ttabitsoktetter {r Latin-1-dito (utom m|jligen n}gra enstaka i C1) s} >vill jag g{rna se den! Visst. Dan From psv@nada.kth.se Tue Jan 5 09:51:47 1993 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14837; Tue, 5 Jan 93 09:51:57 +0100 Received: from cyklop.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14820; Tue, 5 Jan 93 09:51:47 +0100 Received: from localhost.nada.kth.se by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA27565; Tue, 5 Jan 93 09:51:45 +0100 Message-Id: <9301050851.AA27565@cyklop.nada.kth.se> To: nordpost@nada.kth.se Subject: Re: kodning av ISO 10646 In-Reply-To: <9301050802.AA06636@malmo.trab.se> from "Dan Oscarsson " "Tue, 5 Jan 93 09:02:09 +0100 " Date: Tue, 05 Jan 93 09:51:44 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*191 Citat ur brev från: Dan Oscarsson > > Frågan är vilken nivå man kan vara rättvis. Även icke 8859-* borde kanske > stödjas. Och varför stödja ASCII? Nä just det, rättvisast är att vara orättvis mot alla, liksom. Att man måste ha understöd för ASCII är väl ändå självklart? > Anledningen jag tycker ISO 8859-1 kan stödjas är att den är en delmängd > av ISO 10646. Det är ingen av de andra. Det tycker jag inte är ett tillräckligt skäl. > Åtminstone FrameMaker FrameMaker har en helt egen teckenkod (som dessutom saknar en del Latin-1-tecken) så konvertering till/från något annat än Latin-1 kan inte vara något problem. > och CAP har 8859-1 hantering och inget annat, tror jag. > NIS+, IDL har bara 8859-1. Vet ej om MS Windows har annat än 8859-1. > Finns säkert fler. Menar du att programleverantörer gör om misstaget och "hårdlöder" en ny teckenkod? Enastående! Men Unixsystemen i allmänhet är inte sådana iallafall, och det var väl det vi talade om? > >Tja, f|rutsatt att den nya kodningen "g|mmer" icke-Latin-1-tecken p} > >ett s{tt som alla Latin-1-kunniga program hanterar vettigt (vid > >l{sning, allts}). Finns en s}dan kodning? > Svårt att "gömma" tecken. UTF-2 gömmer inga. > UTF-2 använder dessutom en del C1-kontrolltecken som kan störa. Nej just det. Jag befarar att man får nya edv-aktiga problem med Latin-1-program när man utsätter dom för din nya UTF-Dan-kodning. From owner-nordpost@nada.kth.se Tue Jan 5 20:01:30 1993 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA18948; Tue, 5 Jan 93 20:01:37 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA18932; Tue, 5 Jan 93 20:01:30 +0100 Received: by dkuug.dk id AA02645 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Tue, 5 Jan 1993 20:01:15 +0100 Message-Id: <199301051901.AA02645@dkuug.dk> From: keld@dkuug.dk (Keld J|rn Simonsen) Date: Tue, 5 Jan 1993 20:01:14 +0100 In-Reply-To: Dan Oscarsson "Re: kodning av ISO 10646" (Jan 5, 9:02) X-Charset: ASCII X-Char-Esc: 29 Mime-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mnemonic-Intro: 29 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: nordpost@nada.kth.se Subject: Re: kodning av ISO 10646 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*192 Dan Oscarsson writes: > Fr}gan {r vilken niv} man kan vara r{ttvis. [ven icke 8859-* borde kanske > st|djas. Och varf|r st|dja ASCII? > Anledningen jag tycker ISO 8859-1 kan st|djas {r att den {r en delm{ngd > av ISO 10646. Det {r ingen av de andra. Alle de andre er da ogsaa en delmaengde af 10646. > >> Dessutom {r det ISO 8859-1 som m}nga leverant|rer st|djer > >> idag (bl.a. flera operativsystem, m}nga applikation, t.o.m. MS > >> Windows). > > > >Unixsystem levererade i v{stra Europa {r "inst{llda" p} Latin-1-kod > >men huvudparten av programvaran har v{l inga f|rutfattade meningar om > >_vilken_ }ttabitskod som anv{nds? > ]tminstone FrameMaker och CAP har 8859-1 hantering och inget annat, tror jag. > NIS+, IDL har bara 8859-1. Vet ej om MS Windows har annat {n 8859-1. > Finns s{kert fler. Saa vidt jeg ved findes der en del produkter der understo/tter graesk, kyrillisk og latin2. > > > >> Om kodningen inte {r ISO 8859-1 kompatibel, betyder det att jag p} mitt > >> system kommer att beh|va v{nta MYCKET l{nge innan jag kan byta till > >> ISO 10646. > >> Eftersom jag d} inte kan byta gradvis utan m}ste {ndra allt p} en g}ng > >> inklusive koda om alla filer. Jag m}ste v{nta tills b}de operativsystem och > >> ALLA applikationer st|djer det nya kodningsformatet. Annars skulle t.ex. en > >> del applikationer fortfarande skriva ISO 8859-1-filer. > > > >Tja, f|rutsatt att den nya kodningen "g|mmer" icke-Latin-1-tecken p} > >ett s{tt som alla Latin-1-kunniga program hanterar vettigt (vid > >l{sning, allts}). Finns en s}dan kodning? > Sv}rt att "g|mma" tecken. UTF-2 g|mmer inga. > UTF-2 anv{nder dessutom en del C1-kontrolltecken som kan st|ra. En metode var at ko/re mnemonics, dvs du bruger 8859-1 som basetegnsaet og saa via mnemonics har du adgang til resten af 10646. Mnemonics er rimeligt kompakt, og mere kompakt end UTF1 og UTF2. Keld From owner-nordpost@nada.kth.se Thu Jan 7 08:30:46 1993 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA03091; Thu, 7 Jan 93 08:30:51 +0100 Received: from malmo.trab.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA03075; Thu, 7 Jan 93 08:30:46 +0100 Received: by malmo.trab.se (5.65+bind 1.7+ida 1.4.2/TRM-1-NS); Thu, 7 Jan 93 08:30:44 +0100 (MET) Date: Thu, 7 Jan 93 08:30:44 +0100 From: Dan Oscarsson Message-Id: <9301070730.AA18477@malmo.trab.se> To: nordpost@nada.kth.se Subject: Re: kodning av ISO 10646 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*193 >> Fr}gan {r vilken niv} man kan vara r{ttvis. [ven icke 8859-* borde kanske >> st|djas. Och varf|r st|dja ASCII? >> Anledningen jag tycker ISO 8859-1 kan st|djas {r att den {r en delm{ngd >> av ISO 10646. Det {r ingen av de andra. > >Alle de andre er da ogsaa en delmaengde af 10646. Teckenmässigt ja, kodmässigt nej! Jag syftar till kodningen och då är ASCII, ISO 8859-1 och Unicode delmängd av ISO 10646. > >En metode var at ko/re mnemonics, dvs du bruger 8859-1 som basetegnsaet >og saa via mnemonics har du adgang til resten af 10646. > >Mnemonics er rimeligt kompakt, og mere kompakt end UTF1 og UTF2. > UTF2 tar två oktetter för många vanliga tecken. Mnemonics tar tre och är då inte mer kompakt. Dan From owner-nordpost@nada.kth.se Thu Jan 7 19:46:54 1993 Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09395; Thu, 7 Jan 93 19:47:04 +0100 Received: from dkuug.dk by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09379; Thu, 7 Jan 93 19:46:54 +0100 Received: by dkuug.dk id AA10719 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Thu, 7 Jan 1993 19:32:40 +0100 Message-Id: <199301071832.AA10719@dkuug.dk> From: keld@dkuug.dk (Keld J|rn Simonsen) Date: Thu, 7 Jan 1993 19:32:38 +0100 In-Reply-To: Dan Oscarsson "Re: kodning av ISO 10646" (Jan 7, 8:31) X-Charset: ASCII X-Char-Esc: 29 Mime-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mnemonic-Intro: 29 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: nordpost@nada.kth.se Subject: Re: kodning av ISO 10646 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*194 Dan Oscarsson writes: > >En metode var at k|re mnemonics, dvs du bruger 8859-1 som basetegns{t > >og s} via mnemonics har du adgang til resten af 10646. > > > >Mnemonics er rimeligt kompakt, og mere kompakt end UTF1 og UTF2. > > > UTF2 tar tv} oktetter f|r m}nga vanliga tecken. Mnemonics tar tre och {r > d} inte mer kompakt. Mnemonics tar en oktet for alle 8859-1 tegn, hvis vi taler om mnemonic 8859-1 (og det g|r vi!), det er mere kompakt end UTF2 - og vel is{r for svensk/nordisk brug. keld From owner-nordpost@nada.kth.se Mon Jun 7 10:27:46 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA11221; Mon, 7 Jun 93 10:27:51 +0200 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA11200; Mon, 7 Jun 93 10:27:46 +0200 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA19788 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Mon, 7 Jun 1993 10:27:41 +0200 Received: from alba.udac.uu.se by solix.udac.uu.se with SMTP id AA20184 (5.67a8/IDA-1.5 for ); Mon, 7 Jun 1993 10:27:40 +0200 Received: by alba.udac.uu.se (5.0/SMI-SVR4) id AA02363; Mon, 7 Jun 93 10:28:23 +0200 Date: Mon, 7 Jun 93 10:28:23 +0200 From: Martin.Wendel@udac.uu.se (Martin Wendel) Message-Id: <9306070828.AA02363@alba.udac.uu.se> To: nordpost@nada.kth.se Subject: MIME-gatewayprogramvara X-Sun-Charset: ISO-8859-1 Content-Length: 3558 X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*195 Eftersom det har varit v{ldigt tyst p} den h{r listan de senaste m}naderna tycker jag det nu kan vara dags att bryta tystnaden f|r lite information. Som vissa antagligen k{nner till, har SUNET beslutat att finansiera utveckling av en gatewayprogramvara f|r konvertering mellan MIME - ickeMIME. Utvecklingen skall sk|tas av UDAC och prim{rt av mig sj{lv. Avtal {r nyligen undertecknat och s{tter en dead-line i slutet av oktober. Kraven p} programvaran {r kortfattat som f|ljer: * Programvaran skall dels vara frist}ende (filter), dels vara inl{nkat i IDA-sendmail (gateway). * Text-konvertering skall kunna ske mellan ett stort antal teckenset samt med Quoted-Printable. * Bin{rfiler skall kunna konverteras mellan Base64, BinHex och uuencode. Headerhantering skall sj{lvklart f|lja MIME-standarden. Plattformar {r Sunos4.x , Solaris2.x, Ultrix>=4.2, AIX>=3.2-RS6000, HPUX>=9.0 Jag t{nkte h{r dryfta mina ideer vad g{ller en dylik programvara S} som jag ser det {r det vissa aspekter som m}ste beaktas speciellt: 1 Headrar Headerhanteringen {r ett st|rre problem {n vad som kan l|sas med ett statiskt system: Det {r sv}rt att f|ruts{ga hur alla UA-specifika headrar ser ut. Bla kr{ver exempelvis SUN's mailtool speciella headrar f|r att sk|ta medskick etc. MIME utvecklas och modifieringar av specifikationen i rfc1341 kommer. Det {r l{mpligt att anv{nda ett konfigureringsspr}k f|r att kunna enkelt modifera/addera headertyper. Detta spr}k b|r vara TCL. 2 Medskick En BinHexad eller uuencodad fil {r alltid representerad i US-ASCII, {ven om det {r en nationell variant av ASCII som normalt skickas i brev. Detta ger potentiella problem med generell teckenkonvertering, som jag har egen erfarenhet av. En BinHexat medskick med checksummefel m}ste exempelvis betraktas som text, men med teckenset US-ASCII. En mac-fil med b}de datafork och resourcefork har ingen naturlig representation i MIME (f|rr{n MacMIME blir standard), den har heller ingen naturlig representation i exempelvis en PC. I nul{get finns tv} alternativ: Kasta resourceforken eller utf|r ingen konvertering. Det f|rstn{mnda tycker jag vore of|rsk{mt, det sistn{mda {r inte heller riktigt bra. Sen } andra sidan, den som har gl{dje av en dylik mac-fil p} en PC klarar ocks} av att h{mta hem ett BinHexprogram f|r att packa upp filen. Samma sak g{ller f|r uuencodad apple-single. 3 Brevtyper Vissa Content-Types i MIME har ingen naturlig motsvarighet i icke-MIME brev. Tex Multipart/Parallel f}r betraktas som Multipart/Mixed och Message/External-Body f}r ers{ttas med informationstext. Medskick som skickas i flera delar som partiella brev kan inte naturligt konverteras. 4 Fl|desstruktur F|r att f} n}gorlunda prestanda b|r programmet implementeras som ett tv}stegs filter: Steg 1 strukturerar upp information om brevets egenskaper, steg 2 utf|r en eventuell konvertering. Detta g|r det enklare att l{nka ihop med sendmail, steg 1 sker i collect, steg 2 sker i deliver. K|hantering m}ste integreras med sendmails k|hantering. Kom g{rna med synpunkter p} dessa id`er. ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From owner-nordpost@nada.kth.se Mon Jun 7 10:49:18 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA11391; Mon, 7 Jun 93 10:49:21 +0200 Received: from baal.efd.lth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA11374; Mon, 7 Jun 93 10:49:18 +0200 Message-Id: <9306070849.AA11374@nada.kth.se> Received: from baal.efd.lth.se by baal.efd.lth.se with smtp (perl jhmail 0.10) (rfc1413: jh@baal.efd.lth.se) id 45dc0c_1f0_1 ; Mon, 7 Jun 1993 10:48:37 MET DST X-Conversion: converted to ISO 646SE by baal.efd.lth.se Date: Mon, 07 Jun 1993 10:48:31 +0200 From: Joergen Haegg To: nordpost@nada.kth.se In-Reply-To: Your message of "Mon, 07 Jun 1993 10:28:23 +0200." <9306070828.AA02363@alba.udac.uu.se> Subject: Re: MIME-gatewayprogramvara Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*196 In message <9306070828.AA02363@alba.udac.uu.se>you write: > >Som vissa antagligen k{nner till, har SUNET beslutat att finansiera utveckling >av en gatewayprogramvara f|r konvertering mellan MIME - ickeMIME. Utvecklingen >skall sk|tas av UDAC och prim{rt av mig sj{lv. Avtal {r nyligen undertecknat >och s{tter en dead-line i slutet av oktober. Varf|r blev det just UDAC fr}gar nyfiken? Den som {r intresserad att prova kan f} en kopia av jhmail (i perl och C) som klarar in och utg}ende konvertering beroende p} avs{ndare, inkanal, mottagare samt utkanal. Konfigurerbar p} alla h}ll och kanter :-). F|r n{rvarande i ett fungerande alfastadium. Jag har sj{lv k|rt den i en m}nad. >Kraven p} programvaran {r kortfattat som f|ljer: > >* Programvaran skall dels vara frist}ende (filter), dels vara inl{nkat i > IDA-sendmail (gateway). Det {r faktiskt dags att dumpa sendmail. Den {r ganska s|nderhackad. > specifikationen i rfc1341 kommer. > Det {r l{mpligt att anv{nda ett konfigureringsspr}k f|r att kunna > enkelt modifera/addera headertyper. Detta spr}k b|r vara TCL. Av vilken anledning just TCL? >2 Medskick > > En BinHexad eller uuencodad fil {r alltid representerad i US-ASCII, > {ven om det {r en nationell variant av ASCII som normalt skickas i > brev. Detta ger potentiella problem med generell teckenkonvertering, > som jag har egen erfarenhet av. En BinHexat medskick med checksummefel > m}ste exempelvis betraktas som text, men med teckenset US-ASCII. Det g}r inte att konvertera brev fr}n iso 646SE, risken f|r korrupt data {r f|r stor. > utf|r ingen konvertering. Egentligen det enda m|jliga tills Macen klarar att }tminstone l{gga p} lite MIME-rubriker. > >3 Brevtyper > > Vissa Content-Types i MIME har ingen naturlig motsvarighet i icke-MIME > brev. Tex Multipart/Parallel f}r betraktas som Multipart/Mixed och > Message/External-Body f}r ers{ttas med informationstext. Medskick som > skickas i flera delar som partiella brev kan inte naturligt konverteras. St|rre delen av brev kommer att vara text/plain, och d} {r det inga problem. Multipart kan bli ganska komplicerade, varf|r en konvertering kan bli sv}r. >4 Fl|desstruktur > > F|r att f} n}gorlunda prestanda b|r programmet implementeras som ett > tv}stegs filter: Steg 1 strukturerar upp information om brevets egenskaper, > steg 2 utf|r en eventuell konvertering. Detta g|r det enklare att l{nka > ihop med sendmail, steg 1 sker i collect, steg 2 sker i deliver. K|hantering > m}ste integreras med sendmails k|hantering. Man m}ste ocks} ta h{nsyn till vad mottagaren ber{ttar om sig via EHLO. -------- J|rgen H{gg jh@efd.lth.se postmaster@efd.lth.se Telnr: 046-107492, 104013(fax) Snigelpost: H{mtst{lle 7, BOX 118, 221 00 LUND Lunds Tekniska H|gskola Paket: E-huset, Ole R|mers v{g 3, 221 00 LUND Bride, n.: A woman with a fine prospect of happiness behind her. -- Ambrose Bierce, "The Devil's Dictionary" From paf@nada.kth.se Mon Jun 7 12:02:33 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12015; Mon, 7 Jun 93 12:02:36 +0200 Received: from mumrik.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA11998; Mon, 7 Jun 93 12:02:33 +0200 Message-Id: <9306071002.AA11998@nada.kth.se> To: nordpost@nada.kth.se Subject: Re: MIME-gatewayprogramvara In-Reply-To: Your message of "Mon, 07 Jun 1993 10:28:23 +0200." <9306070828.AA02363@alba.udac.uu.se> Date: Mon, 07 Jun 1993 12:02:33 +0200 From: Patrik Faltstrom Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*197 Martin Wendel writes: >Kraven p} programvaran {r kortfattat som f|ljer: > >* Programvaran skall dels vara frist}ende (filter), dels vara inl{nkat i > IDA-sendmail (gateway). > >* Text-konvertering skall kunna ske mellan ett stort antal teckenset samt > med Quoted-Printable. > >* Bin{rfiler skall kunna konverteras mellan Base64, BinHex och uuencode. > >Headerhantering skall sj{lvklart f|lja MIME-standarden. Plattformar {r >Sunos4.x , Solaris2.x, Ultrix>=4.2, AIX>=3.2-RS6000, HPUX>=9.0 Det absolut viktigaste för den svenska marknaden är konvertering av tecken. Det är också den som vi på NADA har märkt som kräver mest tankearbete beroende på att det är detta som vanliga dödliga blir mest irriterade över om det är fel. Jag tycker alltså vi här ska diskutera vad man ska göra åt tex svensk 7-bitskod när man konverterar till/från MIME/8-bit SMTP. Mappningen bör kunna ske per domänbasis, dvs man borde i sendmail.cf eller liknande tala om per mottagardomän (eller användare) om han vill ha/skickar svensk 7-bitskod eller MIME eller iso-8859-1. Dessa tre koder (åtminstone) måste vi kunna mappa mellan. MIME->iso-8859-1 är enkelt så länge brevet består av "charset=iso-8859-1", men vad ska man göra med andra teckenuppsättningar? MIME->svensk 7-bitskod. Enkelt på liknande sätt. iso-8859-1->MIME. Också enkelt. svensk 7-bitskod->MIME. Hur ska man göra här? Hur man ska mappa olika MIME content-types mot SMTP-brevkroppar med enbart text tror jag är enklare. uuencode är det konverteringssätt som alla PC-baserade system (typ CC:Mail och MS-Mail) använder, och BinHex är det som Eudora (och MacPost?) använder. Varken BinHex eller uuencode använder dock enbart de 65 "säkra" tecknen som Base64 använder och då är frågan vad man ska göra när man skapar MIME-brev av en sådat brev (alltså in i MIME). Från MIME borde man packa upp Base64 och koda i lämpligt annat format (vilket?). Mycket att prata om...tecknen är viktigast! paf From owner-nordpost@nada.kth.se Mon Jun 7 12:40:19 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12407; Mon, 7 Jun 93 12:40:22 +0200 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12389; Mon, 7 Jun 93 12:40:19 +0200 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA20359 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Mon, 7 Jun 1993 12:40:12 +0200 Received: from alba.udac.uu.se by solix.udac.uu.se with SMTP id AA21151 (5.67a8/IDA-1.5 for ); Mon, 7 Jun 1993 12:40:11 +0200 Received: by alba.udac.uu.se (5.0/SMI-SVR4) id AA02453; Mon, 7 Jun 93 12:40:53 +0200 Date: Mon, 7 Jun 93 12:40:53 +0200 From: Martin.Wendel@udac.uu.se (Martin Wendel) Message-Id: <9306071040.AA02453@alba.udac.uu.se> To: nordpost@nada.kth.se Subject: Re: MIME-gatewayprogramvara X-Sun-Charset: US-ASCII Content-Length: 3537 X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*198 > Den som {r intresserad att prova kan f} en kopia av jhmail (i perl och C) > som klarar in och utg}ende konvertering beroende p} avs{ndare, > inkanal, mottagare samt utkanal. Konfigurerbar p} alla h}ll och kanter :-). Verkar intressant, kan du skicka en kopia till mig? > > specifikationen i rfc1341 kommer. > > Det {r l{mpligt att anv{nda ett konfigureringsspr}k f|r att kunna > > enkelt modifera/addera headertyper. Detta spr}k b|r vara TCL. > Av vilken anledning just TCL? > TCL {r ett kraftfullt spr}k, det {r enkelt att koppla ihop med annan C-kod (f|r att g|ra TCL-evalueringar fr}n C eller f|r att peta i C-data-strukturer fr}n TCL) och det {r s}pass v{lspritt att det {r supporterat. > >2 Medskick > > > > En BinHexad eller uuencodad fil {r alltid representerad i US-ASCII, > > {ven om det {r en nationell variant av ASCII som normalt skickas i > > brev. Detta ger potentiella problem med generell teckenkonvertering, > > som jag har egen erfarenhet av. En BinHexat medskick med checksummefel > > m}ste exempelvis betraktas som text, men med teckenset US-ASCII. > > Det g}r inte att konvertera brev fr}n iso 646SE, risken f|r > korrupt data {r f|r stor. > > > utf|r ingen konvertering. > > Egentligen det enda m|jliga tills Macen klarar att }tminstone l{gga > p} lite MIME-rubriker. > Den konvertering som kan bli t{nkbar redan nu {r till/fr}n BinHex och uuencoded applesingle/appledouble. Jag planerar att kolla upp m|jligheten/ |nskv{rdheten av detta, och {ven att kolla p} macbinary-formatet. > > > >3 Brevtyper > > > > Vissa Content-Types i MIME har ingen naturlig motsvarighet i icke-MIME > > brev. Tex Multipart/Parallel f}r betraktas som Multipart/Mixed och > > Message/External-Body f}r ers{ttas med informationstext. Medskick som > > skickas i flera delar som partiella brev kan inte naturligt konverteras. > > St|rre delen av brev kommer att vara text/plain, och d} {r det inga problem. > Multipart kan bli ganska komplicerade, varf|r en konvertering kan > bli sv}r. Den n{st st|rsta delen kommer att bli multipart, s} jag antar att det m}ste supporteras i alla fall. > > > >4 Fl|desstruktur > > > > F|r att f} n}gorlunda prestanda b|r programmet implementeras som ett > > tv}stegs filter: Steg 1 strukturerar upp information om brevets egenskaper, > > steg 2 utf|r en eventuell konvertering. Detta g|r det enklare att l{nka > > ihop med sendmail, steg 1 sker i collect, steg 2 sker i deliver. K|hantering > > m}ste integreras med sendmails k|hantering. > > Man m}ste ocks} ta h{nsyn till vad mottagaren ber{ttar om sig > via EHLO. Ja, det {r n}gonting jag m}ste studera mer noga. En annan sak som jag gl|mde n{mna {r headerhantering enligt rfc1342. Vi har d}lig erfarenhet av bla en del bryggor till LAN-mail d{r 8bitarsheadrar skickas ut (eftersom vi k|r 8bitar lokalt p} brevkroppen) och st{ller till problem. Speciellt irriterande {r det med 8bitars text som kommentarf{lt i From-adresserna. Detta {r n}gonting som ocks} m}ste konverteras till rfc1342-format. M|jlighet att konvertera fr}n rfc1342 till 8 eller 7bitars text b|r ocks} finnas. ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From owner-nordpost@nada.kth.se Mon Jun 7 13:20:34 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12841; Mon, 7 Jun 93 13:20:38 +0200 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12824; Mon, 7 Jun 93 13:20:34 +0200 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA20566 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Mon, 7 Jun 1993 13:20:33 +0200 Received: from alba.udac.uu.se by solix.udac.uu.se with SMTP id AA21436 (5.67a8/IDA-1.5 for ); Mon, 7 Jun 1993 13:20:32 +0200 Received: by alba.udac.uu.se (5.0/SMI-SVR4) id AA02467; Mon, 7 Jun 93 13:21:14 +0200 Date: Mon, 7 Jun 93 13:21:14 +0200 From: Martin.Wendel@udac.uu.se (Martin Wendel) Message-Id: <9306071121.AA02467@alba.udac.uu.se> To: nordpost@nada.kth.se Subject: Re: MIME-gatewayprogramvara X-Sun-Charset: US-ASCII Content-Length: 3402 X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*199 > Det absolut viktigaste f|r den svenska marknaden {r konvertering av > tecken. Det {r ocks} den som vi p} NADA har m{rkt som kr{ver mest > tankearbete beroende p} att det {r detta som vanliga d|dliga blir > mest irriterade |ver om det {r fel. Inst{mmer, de som inte {r s} insatta i problemet har oftasts mycket liten f|rst}else f|r varf|r det |verhuvudtaget {r problem med svenska tecken. > Jag tycker allts} vi h{r ska diskutera vad man ska g|ra }t tex svensk > 7-bitskod n{r man konverterar till/fr}n MIME/8-bit SMTP. > > Mappningen b|r kunna ske per dom{nbasis, dvs man borde i sendmail.cf > eller liknande tala om per mottagardom{n (eller anv{ndare) om han > vill ha/skickar svensk 7-bitskod eller MIME eller iso-8859-1. Och p} samma s{tt med uuencode, MIME eller BinHex. > Dessa tre koder (}tminstone) m}ste vi kunna mappa mellan. > > MIME->iso-8859-1 {r enkelt s} l{nge brevet best}r av "charset=iso-8859-1", > men vad ska man g|ra med andra teckenupps{ttningar? Eftersom alla tecken i exempelvis iso-8859-2 rimligtvis inte finns i iso-8859-1, kan man h{r t{nka sig att anv{nda n}gon mnemonisk representation av dessa tecken? Jag tycker inte man skall anv{nda n}gon slags flera-till-en konvertering mellan 8bitars teckenset, det {r illa nog med den som kr{vs till iso-646-se. > svensk 7-bitskod->MIME. Hur ska man g|ra h{r? Kan man anse att text skriven i "svensk 7-bitskod" verkligen {r iso-646-se? Jag kan t{nka mig att somliga anv{nder exempelvis hakparenteser f|r att representera hakparentes men {ven svenska tecken i samma text. Detta {r verkligen ett stort problem. Sj{lvklart {r BinHex resp. uuencode alltid us-ascii och inte svensk, men detta klaras av gatewayprogramvaran. Jag tycker att n}gonstans m}ste gr{nserna dras. Antingen {r det iso-646-se eller {r det us-ascii man skickar. I annat fall f}r man specificera teckenset i headern (l{mpligen enligt MIME). Jag tror inte p} l|sningar med programvara som k{nner igen exempelvis C-kod. En l|sning {r naturligtvis att uuencoda partierna skrivna i us-ascii (kanske lite kn|ligt?). > > Hur man ska mappa olika MIME content-types mot SMTP-brevkroppar med > enbart text tror jag {r enklare. uuencode {r det konverteringss{tt > som alla PC-baserade system (typ CC:Mail och MS-Mail) anv{nder, och > BinHex {r det som Eudora (och MacPost?) anv{nder. Varken BinHex eller > uuencode anv{nder dock enbart de 65 "s{kra" tecknen som Base64 anv{nder > och d} {r fr}gan vad man ska g|ra n{r man skapar MIME-brev av > en s}dat brev (allts} in i MIME). Fr}n MIME borde man packa upp > Base64 och koda i l{mpligt annat format (vilket?). Jag anser att dessa skall kodas om (ex uudecode -> base64encode, Base64 -> BinHex etc) i alla fall d} formatet kunnat verifieras vara korrekt. I de fall med checksummefel eller andra fel b|r det betraktas som text i us-ascii (det blir upp till mottagaren att packa upp manuellt). Eudora fr}gar exempelvis, d} den hittar checksummefel, om den skall packa upp filen. ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From paf@nada.kth.se Mon Jun 7 14:41:53 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA13587; Mon, 7 Jun 93 14:41:56 +0200 Received: from mumrik.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA13570; Mon, 7 Jun 93 14:41:53 +0200 Message-Id: <9306071241.AA13570@nada.kth.se> To: nordpost@nada.kth.se Subject: Re: MIME-gatewayprogramvara In-Reply-To: Your message of "Mon, 07 Jun 1993 13:21:14 +0200." <9306071121.AA02467@alba.udac.uu.se> Date: Mon, 07 Jun 1993 14:41:52 +0200 From: Patrik Faltstrom Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*200 Martin Wendel writes: >Jag tycker att n}gonstans m}ste gr{nserna dras. Antingen {r det iso-646-se >eller {r det us-ascii man skickar. I annat fall f}r man specificera teckenset >i headern (l{mpligen enligt MIME). Jag tror inte p} l|sningar med programvara >som k{nner igen exempelvis C-kod. En l|sning {r naturligtvis att uuencoda >partierna skrivna i us-ascii (kanske lite kn|ligt?). Svensk 7-bitskod är inte registrerad som MIME-teckenkod och vi på NADA har haft en lång diskussion med Eudora-folket om man egentligen ska ha nån sån. Problemet är att vi på NADA tycker att antingen kör man 7-bitskod, eller så kör man MIME och iso-8859-1. OM man ska lägga in svensk 7-bitskod utan konvertering i MIME så kan man använda "x-SEN_850200_B" resp "x-SEN_850200_C" (som de två versionerna tyvärr heter). Just nu pågår det förresten en "religiös" debatt om det är meningen att man ska definiera hur många olika "content-type" och "charset" som helst, eller om man ska minimera antalet för att göra implementationer enklare. Vi på NADA argumenterar för det förra, dvs man ska minimera antalet. Annars tycker vi man riskerar interopabiliteten som MIME skulle lösa. >Jag anser att dessa skall kodas om (ex uudecode -> base64encode, Base64 -> >BinHex etc) i alla fall d} formatet kunnat verifieras vara korrekt. I de fall >med checksummefel eller andra fel b|r det betraktas som text i us-ascii >(det blir upp till mottagaren att packa upp manuellt). Eudora fr}gar >exempelvis, d} den hittar checksummefel, om den skall packa upp filen. Tyvärr innehåller inte AppleSingle/AppleDouble någon checksumma, utan "bara" binhex och uuencode. Men, detta kan man log lösa, det är värre vad man ska göra med 646-koder som ska in i MIME. paf From owner-nordpost@nada.kth.se Mon Jun 7 15:56:25 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14568; Mon, 7 Jun 93 15:56:30 +0200 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14549; Mon, 7 Jun 93 15:56:25 +0200 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA21327 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Mon, 7 Jun 1993 15:56:24 +0200 Received: from alba.udac.uu.se by solix.udac.uu.se with SMTP id AA23215 (5.67a8/IDA-1.5 for ); Mon, 7 Jun 1993 15:56:23 +0200 Received: by alba.udac.uu.se (5.0/SMI-SVR4) id AA02579; Mon, 7 Jun 93 15:57:05 +0200 Date: Mon, 7 Jun 93 15:57:05 +0200 From: Martin.Wendel@udac.uu.se (Martin Wendel) Message-Id: <9306071357.AA02579@alba.udac.uu.se> To: nordpost@nada.kth.se Subject: Re: MIME-gatewayprogramvara X-Sun-Charset: US-ASCII Content-Length: 2506 X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*201 L}t mig bara f} f|rtydliga. Nedanst}ende stycke syftar p} det som kommer ut ur icke-MIME 7bitars mailklienter. > > >Jag tycker att n}gonstans m}ste gr{nserna dras. Antingen {r det iso-646-se > >eller {r det us-ascii man skickar. I annat fall f}r man specificera teckenset > >i headern (l{mpligen enligt MIME). Jag tror inte p} l|sningar med programvara > >som k{nner igen exempelvis C-kod. En l|sning {r naturligtvis att uuencoda > >partierna skrivna i us-ascii (kanske lite kn|ligt?). > Svensk 7-bitskod {r inte registrerad som MIME-teckenkod och vi > p} NADA har haft en l}ng diskussion med Eudora-folket om man > egentligen ska ha n}n s}n. Problemet {r att vi p} NADA tycker > att antingen k|r man 7-bitskod, eller s} k|r man MIME och > iso-8859-1. OM man ska l{gga in svensk 7-bitskod utan > konvertering i MIME s} kan man anv{nda "x-SEN_850200_B" resp > "x-SEN_850200_C" (som de tv} versionerna tyv{rr heter). Jag tycker svensk 7-bitskod skall konverteras till iso-8859-1 innan man l{gger in det i MIME. Personligen tycker jag att svensk 7-bitskod borde avvecklas (vilket antagligen {r om|jligt p} kort sikt) till f|rm}n f|r 8bitars teckenset, samt att MIME och Quoted-Printable anv{nds d} 8bitars transparens inte kan uppn}s eller garanteras. Jag tycker allts} inte att vi skall registrera nya teckenkoder i MIME f|r att vidmakth}lla nationell 7bits kod, utan att vi ist{llet arbetar f|r att 8bitarskod anv{nds i s} stor utstr{ckning som m|jligt. I de fall man bara har tillg}ng till 7bitarskod b|r detta i avsaknad av MIME tolkas som svensk 7bitskod (som saknar bla hakparenteser). > Just nu p}g}r det f|rresten en "religi|s" debatt om det > {r meningen att man ska definiera hur m}nga olika "content-type" > och "charset" som helst, eller om man ska minimera antalet > f|r att g|ra implementationer enklare. Vi p} NADA argumenterar > f|r det f|rra, dvs man ska minimera antalet. Annars tycker vi > man riskerar interopabiliteten som MIME skulle l|sa. Inst{mmer helt och h}llet, nya typer borde verkligen vara nya typer och inte nya varianter av gamla typer. ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From owner-nordpost@nada.kth.se Mon Jun 7 16:05:13 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14684; Mon, 7 Jun 93 16:05:16 +0200 Received: from baal.efd.lth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14667; Mon, 7 Jun 93 16:05:13 +0200 Message-Id: <9306071405.AA14667@nada.kth.se> Received: from baal.efd.lth.se by baal.efd.lth.se with smtp (perl jhmail 0.10) (rfc1413: jh@baal.efd.lth.se) id 462619_71f_1 ; Mon, 7 Jun 1993 16:04:33 MET DST X-Conversion: converted to ISO 646SE by baal.efd.lth.se Date: Mon, 07 Jun 1993 16:04:30 +0200 From: Joergen Haegg To: nordpost@nada.kth.se In-Reply-To: Your message of "Mon, 07 Jun 1993 14:41:52 +0200." <9306071241.AA13570@nada.kth.se> Subject: Re: MIME-gatewayprogramvara Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*202 In message <9306071241.AA13570@nada.kth.se>you write: > > Martin Wendel writes: > >>Jag tycker att n}gonstans m}ste gr{nserna dras. Antingen {r det iso-646-se >>eller {r det us-ascii man skickar. I annat fall f}r man specificera teckenset >>i headern (l{mpligen enligt MIME). Jag tror inte p} l|sningar med programvara >>som k{nner igen exempelvis C-kod. En l|sning {r naturligtvis att uuencoda >>partierna skrivna i us-ascii (kanske lite kn|ligt?). Nej, det kommer att bli en viss procent fel, och d} undrar anv{ndaren om dennes brev verkligen kommer fram. Man m}ste kunna lita p} att inneh}llet inte blir f|rvanskat. >iso-8859-1. OM man ska l{gga in svensk 7-bitskod utan >konvertering i MIME s} kan man anv{nda "x-SEN_850200_B" resp >"x-SEN_850200_C" (som de tv} versionerna tyv{rr heter). Var hittar man info om dessa tv}? >Just nu p}g}r det f|rresten en "religi|s" debatt om det >{r meningen att man ska definiera hur m}nga olika "content-type" >och "charset" som helst, eller om man ska minimera antalet >f|r att g|ra implementationer enklare. Vi p} NADA argumenterar >f|r det f|rra, dvs man ska minimera antalet. Annars tycker vi >man riskerar interopabiliteten som MIME skulle l|sa. H}ller helt med. Det {r tillr{ckligt m}nga redan nu. >Tyv{rr inneh}ller inte AppleSingle/AppleDouble n}gon checksumma, utan >"bara" binhex och uuencode. Men, detta kan man log l|sa, det {r v{rre >vad man ska g|ra med 646-koder som ska in i MIME. Mmm, man m}ste nog skicka in dessa brev som de {r, eventuellt med n}gon l{mplig MIME-rubrik. -------- J|rgen H{gg jh@efd.lth.se postmaster@efd.lth.se Telnr: 046-107492, 104013(fax) Snigelpost: H{mtst{lle 7, BOX 118, 221 00 LUND Lunds Tekniska H|gskola Paket: E-huset, Ole R|mers v{g 3, 221 00 LUND When you are about to do an objective and scientific piece of investigation of a topic, it is well to gave the answer firmly in hand, so that you can proceed forthrightly, without being deflected or swayed, directly to the goal. -- Amrom Katz From paf@nada.kth.se Mon Jun 7 16:10:21 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14778; Mon, 7 Jun 93 16:10:25 +0200 Received: from mumrik.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14760; Mon, 7 Jun 93 16:10:21 +0200 Message-Id: <9306071410.AA14760@nada.kth.se> To: nordpost@nada.kth.se Cc: psv@nada.kth.se, ojarnef@admin.kth.se Subject: Re: MIME-gatewayprogramvara In-Reply-To: Your message of "Mon, 07 Jun 1993 16:04:30 +0200." <9306071405.AA14667@nada.kth.se> Date: Mon, 07 Jun 1993 16:10:21 +0200 From: Patrik Faltstrom Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*203 Joergen Haegg writes: >>iso-8859-1. OM man ska l{gga in svensk 7-bitskod utan >>konvertering i MIME s} kan man anv{nda "x-SEN_850200_B" resp >>"x-SEN_850200_C" (som de tv} versionerna tyv{rr heter). > >Var hittar man info om dessa tv}? Jag har inte information om dem, men Peter eller Olle kanske vet mer. Olle har en bra beskrivning om svensk 7-bitskod och 646 i allmännhet som han kanske kan skicka ut (snälla olle...). >>Tyv{rr inneh}ller inte AppleSingle/AppleDouble n}gon checksumma, utan >>"bara" binhex och uuencode. Men, detta kan man log l|sa, det {r v{rre >>vad man ska g|ra med 646-koder som ska in i MIME. > >Mmm, man m}ste nog skicka in dessa brev som de {r, eventuellt >med n}gon l{mplig MIME-rubrik. Se min fina ;-) MacMIME definition som verkar accepterad av "massorna" och är anmäld hos IANA som nya content-types. Den finns att få för anonym ftp från paf-mac.nada.kth.se i katalogen pub. MacMIME finns dessutom redan för AppleSingle <-> CAP i senaste metamail-distributionen (version 2.5) från Nathaniel Borenstein. Allmänn checksumma kommer i MIME förhoppningsvis i samband med PEM (Private Enhanced Mail). paf From owner-nordpost@nada.kth.se Tue Jun 8 02:50:21 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA20511; Tue, 8 Jun 93 02:50:25 +0200 Received: from othello.admin.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA20494; Tue, 8 Jun 93 02:50:21 +0200 Received: by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b) id AA14660; Tue, 8 Jun 93 02:50:46 +0200 Date: Tue, 8 Jun 93 02:50:46 +0200 Message-Id: <9306080050.AA14660@othello.admin.kth.se> From: Olle Jarnefors To: Datorpostteknik i Norden Cc: Olle Jarnefors In-Reply-To: <9306071410.AA14760@nada.kth.se> (Mon, 07 Jun 1993 16:10:21 +0200, Patrik Faltstrom ) Subject: Re: MIME-gatewayprogramvara Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*204 > >>iso-8859-1. OM man ska l{gga in svensk 7-bitskod utan > >>konvertering i MIME s} kan man anv{nda "x-SEN_850200_B" resp > >>"x-SEN_850200_C" (som de tv} versionerna tyv{rr heter). > > > >Var hittar man info om dessa tv}? > > Jag har inte information om dem, men Peter eller Olle kanske > vet mer. Olle har en bra beskrivning om svensk 7-bitskod och > 646 i allm{nnhet som han kanske kan skicka ut (sn{lla olle...). Namnen "SEN_850200_B och "SEN_850200_C" inf|rdes i den beryktade RFC 1345 (Keld Simonsen: Character Mnemonics & Character Sets. June 1992). De betyder helt enkelt den standardiserade svenska 7-bitskoden i grundversion respektive egennamnsversion. Skillnaderna mellan grundversionen och egennamnsversionen {r att den f|rstn{mnda bara har satt in sex svenska nationella bokst{ver (][\}{|) i st{llet f|r vissa ASCII-tecken, medan den sistn{mnda ocks} har bytt till sig litet och stort e med akut accent och litet och stort tyskt y. (En skillnad f|religger ocks} mellan grundversionen och ASCII s}tillvida att grundversionen har ett rakt |verstreck d{r ASCII har tilde.) Den officiella standarden SS 63 61 27 anger att dollar i ASCII ska bytas ut mot valutatecken (den d{r lilla solen som fanns p} ABC80:s tangentbord). I verkligheten {r dock dollar nog minst lika vanligt som valutatecken. Om n}gon {r intresserad kan jag l{mna mer detaljerad information om de trista tr{sk som 7-bitskoderna och olika idag f|rekommande s{tt att representera ][\ utg|r. -- Olle J{rnefors, TS-Data, KTH 08-790 71 26 From owner-nordpost@nada.kth.se Tue Jun 8 12:45:50 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24116; Tue, 8 Jun 93 12:45:53 +0200 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24099; Tue, 8 Jun 93 12:45:50 +0200 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA26888 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Tue, 8 Jun 1993 12:45:48 +0200 Received: from alba.udac.uu.se by solix.udac.uu.se with SMTP id AA27376 (5.67a8/IDA-1.5 for ); Tue, 8 Jun 1993 12:45:47 +0200 Received: by alba.udac.uu.se (5.0/SMI-SVR4) id AA03149; Tue, 8 Jun 93 12:46:28 +0200 Date: Tue, 8 Jun 93 12:46:28 +0200 From: Martin.Wendel@udac.uu.se (Martin Wendel) Message-Id: <9306081046.AA03149@alba.udac.uu.se> To: nordpost@nada.kth.se Subject: MIME-gateway (Texthantering) X-Sun-Charset: US-ASCII Content-Length: 2532 X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*205 (Jag byter tr}d f|r textdiskussionen) Jag g|r ett f|rs|k att skapa handtag att h{nga upp diskussionen p} (f}r se om det blir tydligare;-). S} som jag ser det finns det huvudsakligen tv} motiv till varf|r svensk 7bitskod fortfarande anv{nds i mail: 1/ F|r att garantera att texten {r intakt vid routing via k{nda eller ok{nda 7bitsservrar (svensk 7bitskod som transportformat). 2/ F|r att st|dja de som fortfarande anv{nder sig av 7bitsterminaler (svensk 7bitskod som visningsformat). I fallet 2 finns inte mycket att {ndra p}, men man kan ju hoppas att 7bits- terminalerna {r p} v{g ut s} sm}ningom (vad jag f|rst}r {r det billigare att k|pa en ny PC {n en ny terminal). I fallet 1 {r det ju t{nkt att MIME skall l|sa problemen (mha MIME-Gateway), dvs svensk 7bitskod eller 8bitskod endast som lokalt transportformat i de fall d} detta kr{vs. G}r det att komma |verens om att dessa f|ruts{ttnignar skall ligga till grund f|r en MIME-gateway (b|r n}got {ndras eller l{ggas till?): * Svensk 7bitskod inte skall anv{ndas i MIME? F|rdelar: Vi kan i s} fall anv{nda RFC:n rakt av utan lokala till{gg. Det blir inga komplikationer vid internationella kontakter. * Brev som kommer in med svensk 7bitskod till MIME-gatewayen representeras (konverteras) som iso-8859-1? (Eventuellt ocks} med quoted-printable) * Brev som kommer in med svensk 7bitskod anses vara representerade i svensk 7bitskod och inte blandat med us-ascii? (G{ller inte BinHex eller uuencode) Nackdelar: Detta ger potentiella problem med skickning av ex. C-program fr}n vissa klienter. Hur enklast l|sa detta? * Ett lokalt teckenset best{ms, giltigt f|r dom{ner, maskiner eller anv{ndare, och konfigureras in i n}gon lokal MIME-gateway. Konvertering av teckenset sker med avseende p} detta. Ett problem {r hur man konverterar fr}n ex. iso8859-2 -> iso8859-1. Jag tycker att tv}-till-en konvertering {r ett specialfall som bara b|r till{mpas p} iso-8859-1 -> iso-646-se. I andra fall b|r n}got mnemoniskt format anv{ndas f|r tecken som inte finns representerade i m}l-teckensetet. ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From owner-nordpost@nada.kth.se Tue Jun 8 14:33:13 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA25127; Tue, 8 Jun 93 14:33:16 +0200 Received: from baal.efd.lth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA25110; Tue, 8 Jun 93 14:33:13 +0200 Message-Id: <9306081233.AA25110@nada.kth.se> Received: from baal.efd.lth.se by baal.efd.lth.se with smtp (perl jhmail 0.10) (rfc1413: jh@baal.efd.lth.se) id 476209_eb5_1 ; Tue, 8 Jun 1993 14:32:33 MET DST X-Conversion: converted to ISO 646SE by baal.efd.lth.se Date: Tue, 08 Jun 1993 14:32:30 +0200 From: Joergen Haegg To: nordpost@nada.kth.se In-Reply-To: Your message of "Tue, 08 Jun 1993 12:46:28 +0200." <9306081046.AA03149@alba.udac.uu.se> Subject: Re: MIME-gateway (Texthantering) Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*206 In message <9306081046.AA03149@alba.udac.uu.se>you write: > >1/ F|r att garantera att texten {r intakt vid routing via k{nda eller ok{nda >7bitsservrar (svensk 7bitskod som transportformat). B|r g} att ers{tta med 7BITMIME direkt. >2/ F|r att st|dja de som fortfarande anv{nder sig av 7bitsterminaler >(svensk 7bitskod som visningsformat). \vers{tt brev till anv{ndaren, men ej anv{ndarens egna. >I fallet 2 finns inte mycket att {ndra p}, men man kan ju hoppas att 7bits- >terminalerna {r p} v{g ut s} sm}ningom (vad jag f|rst}r {r det billigare att >k|pa en ny PC {n en ny terminal). Skulle tro det. Om anv{ndaren beh|ver mer funktionalitet {n vad iso 646se ger s} f}r denne |verv{ga MIME. >* Svensk 7bitskod inte skall anv{ndas i MIME? Kanske enklast att packa samman all 7bitskod som us-ascii? N}gra rubriker extra (f|r MIME) kan ju inte skada. >* Brev som kommer in med svensk 7bitskod till MIME-gatewayen representeras > (konverteras) som iso-8859-1? (Eventuellt ocks} med quoted-printable) Jag tycker att detta {r farligt. Man kommer inte ifr}n ett antal f|rbannade anv{ndare. (Som inte lyckades skicka senaste GIF-bilden till sin kompis :-) >* Brev som kommer in med svensk 7bitskod anses vara representerade i svensk > 7bitskod och inte blandat med us-ascii? (G{ller inte BinHex eller uuencode) Hur vet vi det? Dvs, att det inte {r us-ascii. >* Ett lokalt teckenset best{ms, giltigt f|r dom{ner, maskiner eller > anv{ndare, och konfigureras in i n}gon lokal MIME-gateway. Konvertering av > teckenset sker med avseende p} detta. Ett problem {r hur man konverterar fr} Det {r nog det b{sta s{ttet. (S} har jag sj{lv gjort. :-) > ex. iso8859-2 -> iso8859-1. Jag tycker att tv}-till-en konvertering {r ett > specialfall som bara b|r till{mpas p} iso-8859-1 -> iso-646-se. I andra fall > b|r n}got mnemoniskt format anv{ndas f|r tecken som inte finns representerad > i m}l-teckensetet. Nej, det r{cker med iso-8859-1 -> iso-646-se. Det l{r t{cka 99.9% av behovet. Man kan ocks} fr}ga sig om det beh|vs fler konverteringar till 646se just nu. -------- J|rgen H{gg jh@efd.lth.se postmaster@efd.lth.se Telnr: 046-107492, 104013(fax) Snigelpost: H{mtst{lle 7, BOX 118, 221 00 LUND Lunds Tekniska H|gskola Paket: E-huset, Ole R|mers v{g 3, 221 00 LUND A neighbor came to Nasrudin, asking to borrow his donkey. "It is out on loan," the teacher replied. At that moment, the donkey brayed loudly inside the stable. "But I can hear it bray, over there." "Whom do you believe," asked Nasrudin, "me or a donkey?" From psv@nada.kth.se Tue Jun 8 15:25:08 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA25829; Tue, 8 Jun 93 15:25:11 +0200 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA25812; Tue, 8 Jun 93 15:25:08 +0200 Message-Id: <9306081325.AA25812@nada.kth.se> To: nordpost@nada.kth.se Subject: Re: MIME-gateway (Texthantering) In-Reply-To: Your message of "Tue, 08 Jun 1993 12:46:28 +0200." <9306081046.AA03149@alba.udac.uu.se> Date: Tue, 08 Jun 1993 15:25:07 +0200 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*207 Citat ur brev från: Martin.Wendel@udac.uu.se (Martin Wendel) > * Svensk 7bitskod inte skall anv{ndas i MIME? Ja! > * Brev som kommer in med svensk 7bitskod till MIME-gatewayen representeras > (konverteras) som iso-8859-1? (Eventuellt ocks} med quoted-printable) Ja. > * Brev som kommer in med svensk 7bitskod anses vara representerade i svensk > 7bitskod och inte blandat med us-ascii? (G{ller inte BinHex eller uuencode) > > Nackdelar: Detta ger potentiella problem med skickning av ex. C-program > fr}n vissa klienter. Hur enklast l|sa detta? Olle J och jag har gjort ett jätteenkelt program som söker efter vanligt förkommande (korta) ord innehållande åäö, kodat med några olika teckenkoder. Jag tror man med lite tillägg till denna algoritm skulle kunna få ett ganska säkert sätt att avgöra om ett meddelande innehåller svenska med svensk sjubitskod. Dock kvarstår då hur man gör med meddelanden som innehåller C-program *och* svensk text (utanför eller inuti programmet). > * Ett lokalt teckenset best{ms, giltigt f|r dom{ner, maskiner eller > anv{ndare, och konfigureras in i n}gon lokal MIME-gateway. Konvertering av > teckenset sker med avseende p} detta. Ett problem {r hur man > konverterar fr}n ex. iso8859-2 -> iso8859-1. Jag tycker att tv}-till-en > konvertering {r ett specialfall som bara b|r till{mpas p} > iso-8859-1 -> iso-646-se. I andra fall b|r n}got mnemoniskt > format anv{ndas f|r tecken som inte finns representerade > i m}l-teckensetet. ("Två-till-en konvertering" kan misstolkas, använd hellre t.ex. "icke-reversibel konvertering". När jag ändå är i terminologi- tagen: "teckenkod" kan vi väl använda för "coded character set"?) Svaret på hur detta bör göras tycker jag beror på ifall resultatet av MIME-slussens konverteringar är tänkta att ytterligare behandlas innan dom hamnar på användarnas skärmar. Eftersom det väl *inte* är fallet, tycker jag läsvettigheten väger tyngre än frågan om huruvida man kan återskapa Latin-2-tecknen. Alltså, hellre en icke-reversibel en-till-en eller en-till-flera- konvertering (t.ex. --> "r" eller "r'") än en reversibel (t.ex. --> "&r'" eller "ŕ") --- Peter Svanberg, Nada, KTH From owner-nordpost@nada.kth.se Tue Jun 8 16:38:12 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA26599; Tue, 8 Jun 93 16:38:17 +0200 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA26582; Tue, 8 Jun 93 16:38:12 +0200 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA28137 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Tue, 8 Jun 1993 16:38:10 +0200 Received: from alba.udac.uu.se by solix.udac.uu.se with SMTP id AA28975 (5.67a8/IDA-1.5 for ); Tue, 8 Jun 1993 16:38:09 +0200 Received: by alba.udac.uu.se (5.0/SMI-SVR4) id AA03355; Tue, 8 Jun 93 16:38:49 +0200 Date: Tue, 8 Jun 93 16:38:49 +0200 From: Martin.Wendel@udac.uu.se (Martin Wendel) Message-Id: <9306081438.AA03355@alba.udac.uu.se> To: nordpost@nada.kth.se Subject: Re: MIME-gateway (Texthantering) X-Sun-Charset: US-ASCII Content-Length: 3964 X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*208 Peter Svanberg skriver: > ("Tv}-till-en konvertering" kan misstolkas, anv{nd hellre t.ex. > "icke-reversibel konvertering". N{r jag {nd} {r i terminologi- > tagen: "teckenkod" kan vi v{l anv{nda f|r "coded character > set"?) > OK, (jag anv{nde "tv}-till-en konvertering" f|r att inte misstolkas, i och med ditt f|rtydligande borde jag kunna anv{nda icke-reversibel konvertering utan att misstolkas. Teckenkod var ett b{ttre ord {n teckenset, skall f|rs|ka komma ih}g att anv{nda det;-). J|rgen H{gg skriver: >>* Svensk 7bitskod inte skall anv{ndas i MIME? >Kanske enklast att packa samman all 7bitskod som us-ascii? >N}gra rubriker extra (f|r MIME) kan ju inte skada. > >>* Brev som kommer in med svensk 7bitskod till MIME-gatewayen representeras >> (konverteras) som iso-8859-1? (Eventuellt ocks} med quoted-printable) > >Jag tycker att detta {r farligt. Man kommer inte ifr}n ett antal >f|rbannade anv{ndare. (Som inte lyckades skicka senaste GIF-bilden till >sin kompis :-) Jag h}ller inte med dig. (F|r tydlighetens skull: Det {r katastrofalt att g|ra teckenkonvertering p} BinHex eller uuencode. Detta kommer inte att f} ske i gatewayprogramvaran, partier med BinHex eller uuencode kommer att skiljas av (logiskt) fr}n texten och teckenkonvertering kommer bara att utf|ras p} den del av brevet som {r text.) Jag anser att vi {r h{n- visade att anv{nda iso-8859-1 f|r svensk text i MIME, }tminstone om man skall f|lja rfc:n strikt utan till{gg av nya teckenkoder. Jag vill g|ra n}gra f|rtydliganden till: Kan vi komma |verens om f|ljande: * Avs{ndaren av ett brev specificerar direkt (tex genom MIME) eller indirekt (tex genom konfiguration av lokal mail-gateway) vilken teckenkod som anv{nds i en text i ett datorbrev. Detta {r enda s{ttet att veta vad avs{ndaren egentligen har skrivit. Att skicka vidare data p} det s{tt som g|rs nu (utan n}gon info i headern om teckenkod) {r enligt min mening grunden till de problem som finns d} datorbrev f}r galen teckenrepresentation och anv{ndaren blir frustrerad. Att exempelvis skicka svensk 7bits teckenkod som us-ascii i MIME ger ju inga f|rb{ttringar j{mf|rt med idag. Den ovane gillar inte att l{sa hakparenteser ist{llet f|r svenska tecken. (Mitt syfte {r att g|ra gatewayprogramvaran enkelt konfigurerbar f|r att kunna anpassas till lokala preferenser. I princip vill jag att den skall kunna konfigureras till vilka konverteringar som helst (inom rimliga gr{nser). Men inte desto mindre {r det ju viktigt att f} samf|rst}nd om vad som skall skickas mellan dessa |ar av lokala preferenser.) Tillbaka till Peter Svanberg: > Svaret p} hur detta b|r g|ras tycker jag beror p} ifall > resultatet av MIME-slussens konverteringar {r t{nkta att > ytterligare behandlas innan dom hamnar p} anv{ndarnas sk{rmar. Detta {r en intressant synvinkel. Min utg}ngspunkt {r att ingen s{rskild konvertering skall utf|ras fr}n det att brevet l{mnar gatewayen till dess att det dyker upp p} sk{rmen. > Eftersom det v{l *inte* {r fallet, tycker jag l{svettigheten > v{ger tyngre {n fr}gan om huruvida man kan }terskapa > Latin-2-tecknen. Allts}, hellre en icke-reversibel en-till-en > eller en-till-flera- konvertering (t.ex. > --> "r" eller "r'") {n en reversibel (t.ex. > --> "&r'" eller "ŕ") OK, jag kan k|pa detta argument (}tminstone som lokal preferens som b|r tillgodoses). Finns kodningstabeller f{rdiga f|r s}dant. (Vad blev det egentligen av det teckenkonverteringsprogram som sunet l{t f} utvecklat?). ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From paf@nada.kth.se Tue Jun 8 17:25:04 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA27170; Tue, 8 Jun 93 17:25:07 +0200 Received: from mumrik.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA27153; Tue, 8 Jun 93 17:25:04 +0200 Message-Id: <9306081525.AA27153@nada.kth.se> To: nordpost@nada.kth.se Subject: Re: MIME-gateway (Texthantering) In-Reply-To: Your message of "Tue, 08 Jun 1993 14:32:30 +0200." <9306081233.AA25110@nada.kth.se> Date: Tue, 08 Jun 1993 17:25:04 +0200 From: Patrik Faltstrom Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*209 Joergen Haegg writes: >Nej, det r{cker med iso-8859-1 -> iso-646-se. Det l{r t{cka 99.9% >av behovet. > >Man kan ocks} fr}ga sig om det beh|vs fler konverteringar till 646se just >nu. Det viktigaste i detta stadium är att funktionaliteten finns i översättningsprogramvaran, dvs att man i efterhand per avsändare/ mottagare/brevinnehåll (vad vet jag?) kan haka in egna konverteringsfunktioner (alltså inte bara konvertering genom tabelluppslagning) för text i brevkroppen (eller per "part" i ett multipart message från MIME). I en (nära) framtid är det intressant med konvertering till/från UNICODE/ISO-2022-jp och annat som inte kan konverteras med enbart tabelluppslagningar. Om man ser på just konvertering måst jag säga att UNICODE är synnerligen korkat specificerat (nu fick jag det sagt), men det är inget att göra nåt åt. paf From owner-nordpost@nada.kth.se Wed Jun 9 09:42:55 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA03994; Wed, 9 Jun 93 09:43:00 +0200 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA03976; Wed, 9 Jun 93 09:42:55 +0200 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA02278 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Wed, 9 Jun 1993 09:42:53 +0200 Received: from alba.udac.uu.se by solix.udac.uu.se with SMTP id AA01543 (5.67a8/IDA-1.5 for ); Wed, 9 Jun 1993 09:42:52 +0200 Received: by alba.udac.uu.se (5.0/SMI-SVR4) id AA03671; Wed, 9 Jun 93 09:43:30 +0200 Date: Wed, 9 Jun 93 09:43:30 +0200 From: Martin.Wendel@udac.uu.se (Martin Wendel) Message-Id: <9306090743.AA03671@alba.udac.uu.se> To: nordpost@nada.kth.se Subject: Re: MIME-gateway (Texthantering) X-Sun-Charset: US-ASCII Content-Length: 1972 X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*210 Patrik F{ltstr|m skriver: > Det viktigaste i detta stadium {r att funktionaliteten finns i > |vers{ttningsprogramvaran, dvs att man i efterhand per avs{ndare/ > mottagare/brevinneh}ll (vad vet jag?) kan haka in egna > konverteringsfunktioner (allts} inte bara konvertering genom > tabelluppslagning) f|r text i brevkroppen (eller per "part" i ett > multipart message fr}n MIME). > Keld Simonsen har ju gjort ett konverteringskit med ganska omfattande funktionalitet, (jag antar att ni har tittat p} det). Att anv{nda det skulle ge funktionalitet till konvertering mellan n}got hundratal teckenkoder. Kitet st|der inte icke-reversibel konvertering, s} en s}dan m}ste skapas om man vill ha det (tabell fr}n iso8859-1 till iso646-se borde r{cka). I de fall tecken inte finns i m}lteckenkoden (tex fr}n iso8859-2 till iso8859-1) l{mnas ett MNEM-tecken ist{llet, dvs med r{tt programvara kan man efterkonvertera till annan teckenkod. Jag f|rutser ett problem som kan intr{ffa vid konvertering av text till MIME. Enligt MIME skall en text som inneh}ller flera teckenkoder (l{s teckenkod X inneh{ller tecken fr}n b}de iso8859-1 och iso8859-2 och kan inte representeras i bara ett av dem) ha typen multipart/mixed d{r de olika delarna av multiparten kan inneh}lla enstaka tecken eller ord. Det kommer att bli mycket sv}rt att f} denna typ av funktionalitet i en MIME-gateway. Jag f|resl}r d{rf|r att konvertering av teckenkod sker en-teckenkod-till-EN-annan-teckenkod. D{r den andra teckenkoden kan t{nkas inneh}lla enstaka MNEM-tecken. ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From psv@nada.kth.se Wed Jun 9 17:01:05 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08078; Wed, 9 Jun 93 17:01:09 +0200 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08061; Wed, 9 Jun 93 17:01:05 +0200 Message-Id: <9306091501.AA08061@nada.kth.se> To: nordpost@nada.kth.se Subject: Re: MIME-gateway (Texthantering) In-Reply-To: Your message of "Tue, 08 Jun 1993 16:38:49 +0200." <9306081438.AA03355@alba.udac.uu.se> Date: Wed, 09 Jun 1993 17:01:03 +0200 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*211 Citat ur brev från: Martin.Wendel@udac.uu.se (Martin Wendel) > > Eftersom det v{l *inte* {r fallet, tycker jag l{svettigheten > > v{ger tyngre {n fr}gan om huruvida man kan }terskapa > > Latin-2-tecknen. Allts}, hellre en icke-reversibel en-till-en > > eller en-till-flera- konvertering (t.ex. > > --> "r" eller "r'") {n en reversibel (t.ex. > > --> "&r'" eller "ŕ") > > OK, jag kan k|pa detta argument (}tminstone som lokal preferens som b|r > tillgodoses). Finns kodningstabeller f{rdiga f|r s}dant. (Vad blev det > egentligen av det teckenkonverteringsprogram som sunet l{t f} utvecklat?). Du syftar förmodligen på UHÄ-Tekniklådans projekt "ÅÄÖ-gruppen". Tekniklådan avsomnade med UHÄ men ÅÄÖ-gruppen har uppgått i ett RARE-projekt som ska leverera tabeller, program och rapport till årsskiftet. Ett samarbete med MIME-slussprojektet vore mycket intressant. > Kitet st|der inte icke-reversibel konvertering, s} en s}dan > m}ste skapas om man vill ha det (tabell fr}n iso8859-1 till > iso646-se borde r{cka). Vårt gör alltså det - man kan välja mellan en-till-en, en-till-flera respektive reversibel (= Kelds) konvertering. > I de fall tecken inte finns i m}lteckenkoden (tex fr}n iso8859-2 till > iso8859-1) l{mnas ett MNEM-tecken ist{llet, dvs med r{tt programvara > kan man efterkonvertera till annan teckenkod. ... eller konfigurera så att man får någon annan sorts konvertering (enligt ovan)? --- Peter Svanberg, Nada, KTH From owner-nordpost@nada.kth.se Wed Jun 9 20:38:06 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09609; Wed, 9 Jun 93 20:38:09 +0200 Received: from othello.admin.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09592; Wed, 9 Jun 93 20:38:06 +0200 Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b) id AA18703; Wed, 9 Jun 93 20:38:31 +0200 Received: by mercutio.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0) id AA17175; Wed, 9 Jun 93 20:37:02 +0200 Date: Wed, 9 Jun 93 20:37:02 +0200 Message-Id: <9306091837.AA17175@mercutio.admin.kth.se> From: Olle Jarnefors To: Datorpostteknik i Norden Cc: Olle Jarnefors References: <9306081046.AA03149@alba.udac.uu.se> (Tue, 8 Jun 93 12:46:28 +0200, Martin.Wendel@udac.uu.se) <9306081438.AA03355@alba.udac.uu.se> (Tue, 8 Jun 93 16:38:49 +0200, Martin.Wendel@udac.uu.se) Subject: Re: MIME-gateway (Texthantering) &s Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*212 Martin.Wendel@udac.uu.se (Martin Wendel) skriver i brevet <9306081046.AA03149@alba.udac.uu.se>: > * Brev som kommer in med svensk 7bitskod anses vara representerade i svensk > 7bitskod och inte blandat med us-ascii? (G{ller inte BinHex eller uuencode) > > Nackdelar: Detta ger potentiella problem med skickning av ex. C-program > fr}n vissa klienter. Hur enklast l|sa detta? Och i brevet <9306081438.AA03355@alba.udac.uu.se>: > J|rgen H{gg skriver: > >>* Brev som kommer in med svensk 7bitskod till MIME-gatewayen representeras > >> (konverteras) som iso-8859-1? (Eventuellt ocks} med quoted-printable) > > > >Jag tycker att detta {r farligt. Man kommer inte ifr}n ett antal > >f|rbannade anv{ndare. (Som inte lyckades skicka senaste GIF-bilden till > >sin kompis :-) > > Jag h}ller inte med dig. (F|r tydlighetens skull: Det {r katastrofalt att > g|ra teckenkonvertering p} BinHex eller uuencode. Detta kommer inte att > f} ske i gatewayprogramvaran, partier med BinHex eller uuencode kommer > att skiljas av (logiskt) fr}n texten och teckenkonvertering kommer bara > att utf|ras p} den del av brevet som {r text.) Jag anser att vi {r h{n- > visade att anv{nda iso-8859-1 f|r svensk text i MIME, }tminstone om man > skall f|lja rfc:n strikt utan till{gg av nya teckenkoder. > * Avs{ndaren av ett brev specificerar direkt (tex genom MIME) eller indirekt > (tex genom konfiguration av lokal mail-gateway) vilken teckenkod som anv{nds > i en text i ett datorbrev. Detta {r enda s{ttet att veta vad avs{ndaren > egentligen har skrivit. Att skicka vidare data p} det s{tt som g|rs nu > (utan n}gon info i headern om teckenkod) {r enligt min mening grunden > till de problem som finns d} datorbrev f}r galen teckenrepresentation > och anv{ndaren blir frustrerad. De praktiska problemen med att m}nga MIME-of|rm|gna anv{ndare kommer att f} _all_ sin utg}ende post konverterad av MIME-slussen borde kunna mildras genom f|ljande Hemska Hack: >> MIME-slussen tittar p} slutet av Subject:-raden p} icke-MIME-brev. Om det st}r ett "&"-tecken d{r s} g|rs ingen konvertering. Brevet antas i s} fall vara skrivet med ASCII och det enda som g|rs {r att ett MIME-Version:-f{lt adderas. F|rdelar: Den C-programmerare som vill skicka ett program kan se till att det i alla fall g}r att kompilera hos mottagaren ({ven om []\ i kommentarer och str{ngar inte blir riktigt r{tt). Till den teckenkodsnaiva anv{ndare som har blivit br{nd kan man i alla fall s{ga: N{sta g}ng du ska skicka en TeX-fil/sh-skript/... i ett datorbrev, skriv ett "&" sist p} Subject:-raden! Alla brevhanteringsprogram ger anv{ndaren m|jlighet att best{mma vad som ska st} p} SUbject:-raden s} den h{r l|sningen kommer att fungera i praktiken f|r alla. Det torde ocks} vara mycket s{llsynt att n}gon av andra sk{l vill ha tecknet "&" sist i Subject:-f{ltet. Den h{r ide'n kan f|rst}s "f|rfinas" ytterligare, fast jag {r os{ker p} om man skulle vinna tillr{ckligt mycket p} det. Beroende p} vilken kod som st}r sist p} Subject: kan olika tolkningar av brevet g|ras: &a Brevet skrivet med ASCII (ingen konvertering) &sg Brevet skrivet med svensk 7-bitskod (bara "][\}{|" konverteras) &sn Brevet skrivet med svensk 7-bitskod ("][\}{|@^`~" konverteras) &sG Brevet skrivet med svensk 7-bitskod ("$][\}{|" konverteras) &sN Brevet skrivet med svensk 7-bitskod ("$][\}{|@^`~" konverteras) &b Brevet skrivet med brittisk 7-bitskod ("#" blir pundtecken) &n Brevet skrivet med dansk/norsk 7-bitskod (&s* skulle vara anv{ndbara f|r s}dana anv{ndare som normalt har konvertering i MIME-slussen avst{ngd.) From owner-nordpost@nada.kth.se Thu Jun 10 10:58:59 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14869; Thu, 10 Jun 93 10:59:04 +0200 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14852; Thu, 10 Jun 93 10:58:59 +0200 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA08613 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Thu, 10 Jun 1993 10:58:57 +0200 Received: from alba.udac.uu.se by solix.udac.uu.se with SMTP id AA21004 (5.67a8/IDA-1.5 for ); Thu, 10 Jun 1993 10:58:55 +0200 Received: by alba.udac.uu.se (5.0/SMI-SVR4) id AA04743; Thu, 10 Jun 93 10:59:33 +0200 Date: Thu, 10 Jun 93 10:59:33 +0200 From: Martin.Wendel@udac.uu.se (Martin Wendel) Message-Id: <9306100859.AA04743@alba.udac.uu.se> To: nordpost@nada.kth.se Subject: Re: MIME-gateway (Texthantering) &s X-Sun-Charset: US-ASCII Content-Length: 3535 X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*213 > De praktiska problemen med att m}nga MIME-of|rm|gna anv{ndare > kommer att f} _all_ sin utg}ende post konverterad av > MIME-slussen borde kunna mildras genom f|ljande Hemska Hack: > > >> MIME-slussen tittar p} slutet av Subject:-raden p} > icke-MIME-brev. Om det st}r ett "&"-tecken d{r s} g|rs ingen > konvertering. Brevet antas i s} fall vara skrivet med ASCII > och det enda som g|rs {r att ett MIME-Version:-f{lt adderas. > > F|rdelar: Den C-programmerare som vill skicka ett program kan se > till att det i alla fall g}r att kompilera hos mottagaren ({ven > om []\ i kommentarer och str{ngar inte blir riktigt r{tt). Till > den teckenkodsnaiva anv{ndare som har blivit br{nd kan man i > alla fall s{ga: N{sta g}ng du ska skicka en TeX-fil/sh-skript/... > i ett datorbrev, skriv ett "&" sist p} Subject:-raden! Dvs samma funktionalitet som f|rordas av rfc1344 med header-raden "Content-Conversion: Prohibited". Det finns en risk med att ge anv{ndarna m|jlighet att helt st{nga av all konvertering: att alltf|r m}nga anv{nder denna m|jlighet slentrianm{ssigt f|r att kunna kommunicera precis som tidigare och att |verl}ta till mot- tagaren att sk|ta all n|dv{ndig konvertering. Jag medger att funktionaliteten dock {r tilltalande, kanske f}r problemet betraktas som ett pedagogiskt problem. > Den h{r ide'n kan f|rst}s "f|rfinas" ytterligare, fast jag {r > os{ker p} om man skulle vinna tillr{ckligt mycket p} det. > Beroende p} vilken kod som st}r sist p} Subject: kan olika > tolkningar av brevet g|ras: > > &a Brevet skrivet med ASCII (ingen konvertering) > &sg Brevet skrivet med svensk 7-bitskod (bara "][\}{|" konverteras) > &sn Brevet skrivet med svensk 7-bitskod ("][\}{|@^`~" konverteras) > &sG Brevet skrivet med svensk 7-bitskod ("$][\}{|" konverteras) > &sN Brevet skrivet med svensk 7-bitskod ("$][\}{|@^`~" konverteras) > &b Brevet skrivet med brittisk 7-bitskod ("#" blir pundtecken) > &n Brevet skrivet med dansk/norsk 7-bitskod > > (&s* skulle vara anv{ndbara f|r s}dana anv{ndare som normalt > har konvertering i MIME-slussen avst{ngd.) Jag vet inte om man kan garantera att &a, dvs us-ascci, inte skall uts{ttas f|r n}gon konvertering. Kan man inte ist{llet t{nka sig att &a st}r f|r us-ascii och t.ex. && st}r f|r ingen konvertering. Kanske m}ste teckenkodnamnen ges i tydligare form, f|r att ge mer flexibel funktionalitet f|r diverse teckenkoder vi inte t{nker p}, Kanske skall man travestera rfc1342 och ha t.ex. &?iso-646?& som identifierare ist{llet. [r det meningsfullt att utvidga till att g{lla mer {n det som n{mns ovan? Man kan t{nka sig ytterligare funktionalitet, tex godtycklig teckenkod, kommando till gatewayen: g|r denna typ av konvertering etc. En annan sak {r att gatewayen, om den lyckas utf|ra en konvertering, m}ste f|r{ndra/ta bort &* f{ltet. Dessutom m}ste man t{nka p} vilken teckenkodsspecifikation som har h|gst prioritet (ett MIME-brev med charset samt &* i subject). Min personliga }sikt {r att MIME-specifika headrar alltid skall ha h|gst prioritet och g{lla oavsett mots{gande icke-MIME specifikationer. ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From owner-nordpost@nada.kth.se Sat Jun 12 17:33:26 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA07335; Sat, 12 Jun 93 17:33:29 +0200 Received: from kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA07318; Sat, 12 Jun 93 17:33:26 +0200 Received: from HERON.DAFA.SE by kth.se (5.65+bind 1.7+ida 1.4.2/6.0) id AA16932; Sat, 12 Jun 93 17:33:24 +0200 X400-Received: by /PRMD=QZ/ADMD=TEDE/C=SE/; Relayed; 12 Jun 93 17:30:46+0200 Date: 12 Jun 93 17:30:46+0200 From: Jacob Palme SKHB Message-Id: <1338861*JPALME_(reply-to_jpalme@dsv.su.se)@KOM.DAFA.SE> In-Reply-To: <9306091837.AA17175@mercutio.admin.kth.se> To: Mailchar nordiskt mote om teckenstandarder i elektronisk post , Datorpostteknik i Norden , "Olle J{rnefors" Subject: Re: MIME-gateway (Texthantering) &s Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*214 [r det helt orimligt att t{nka sig att gatewayen blir s} intelligent att den tittar p} meddelandet och r{knar ut ur dess inneh}ll vilket spr}k det {r skrivet p} och vilken teckenkod det anv{nder. Svenska kan man l{tt k{nna igen p} frekvensen av f|rekomst av de 10 vanligaste orden i texten. Det r{cker med att titta p} de f|rsta raderna i texten. Sedan man konstaterat att det {r svenska kan man l{tt se vilken sorts }{| som anv{nds i texten. Och sedan konverterar man bara n{r det verkligen {r svensk text. Allt detta borde datorn kunna klara helt automatiskt. I os{kra fall {r det givetvis b{st att inte konvertera. Enda nackdel jag kan se med detta {r ett meddelande som f|rst {r ren svenska i t.ex. 20 rader och d{refter g}r |ver till uuencode eller binhex eller n}got s}dant, som absolut inte f}r konverteras. (Jag skrev ett program f|r n}gra }r sedan, som testade om en text var p} svenska, engelska eller annat spr}k genom att titta p} f|rekomsten av de vanligaste orden. Det visade sig vara mycket enkelt och n{stan 100 % tr{ffs{kert. Missarna var att programmet f|r n}gra enstaka texter som var en blandning av text i olika spr}k, eller som inneh|ll kod i n}got programspr}k, svarade att den inte kunde reda ut vilket spr}k det var skrivet p}.) From psv@nada.kth.se Sun Jun 13 15:59:27 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14364; Sun, 13 Jun 93 15:59:30 +0200 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14347; Sun, 13 Jun 93 15:59:27 +0200 Message-Id: <9306131359.AA14347@nada.kth.se> To: nordpost@nada.kth.se Subject: Re: MIME-gateway (Texthantering) &s In-Reply-To: Your message of "12 Jun 1993 17:30:46 +0200." <1338861*JPALME_(reply-to_jpalme@dsv.su.se)@KOM.DAFA.SE> Date: Sun, 13 Jun 1993 15:59:26 +0200 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*215 Jacob Palme skrev: > [r det helt orimligt att t{nka sig att gatewayen blir s} > intelligent att den tittar p} meddelandet och r{knar ut > ur dess inneh}ll vilket spr}k det {r skrivet p} och vilken > teckenkod det anv{nder. : : > Allt detta borde datorn kunna klara helt automatiskt. > I os{kra fall {r det givetvis b{st att inte konvertera. > > Enda nackdel jag kan se med detta {r ett meddelande som > f|rst {r ren svenska i t.ex. 20 rader och d{refter g}r > |ver till uuencode eller binhex eller n}got s}dant, som > absolut inte f}r konverteras. Uuencode och binhex kan ju upptäckas, men däremot kan källkod bli lite knivigare, om det föregås av text som du påpekade, eller innehåller textsträngar på svenska. Andra kniviga fall är brev som är väldigt korta. Jag har en känsla av att källkodsskick är rätt ovanligt och föreslår att *om* man ska ha automatik så ska det normalt vara förvalt så att om osäkerhet råder så uförs konvertering. Det ger nog högst sannolikhet för rätt resultat. Dessutom kan Olles "&"-metod användas för att gå förbi automatiken. From owner-nordpost@nada.kth.se Mon Jun 14 09:22:25 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA19841; Mon, 14 Jun 93 09:22:28 +0200 Received: from malmo.trab.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA19824; Mon, 14 Jun 93 09:22:25 +0200 Received: by malmo.trab.se (5.65+bind 1.7+ida 1.4.2/TRM-1-NS); Mon, 14 Jun 93 09:22:22 +0200 (MET) Date: Mon, 14 Jun 93 09:22:22 +0200 From: Dan Oscarsson Message-Id: <9306140722.AA02978@malmo.trab.se> To: nordpost@nada.kth.se Subject: Re: MIME-gateway (Texthantering) - standardkodning Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*216 Vore det inte lämpligt att vi använde EN teckenkodning för MTA till MTA överföring? Däremot mellan UA och MTA, dvs. lokalt på ett ställe, kan man använda vad som helst. Det bästa hade varit att använda ISO 10646 för MTA till MTA överföring. Då täcks praktigt taget alla tecken i världen. I och för sig räcker ISO 8859-1 för oss, men varför inte klara av alla tecken? Och man kan göra det kompatibelt med ISO 8859-1. Vi skulle kunna använda något jag kunde kalla: UCS-VLOSE (UCS Variable Length Octet Stream Encoding). ISO 8859-1 kompatibel. Kan koda många vanliga UCS-koder i 2 oktetter (inkl. grekiska, ryska och arabiska). Använder en del kontrollkoder i C1-delen som prefix. Borde hanteras vettigt även av program som bara klarar 8-bits-tecken. Filer kan flyttas mellan olika datorer utan "byte-swap", fast tyvärr måste "ny rad" omkodas. Vi borde använt NEL ("next line") koden, men tyvärr går det nog inte. Är en kodad version som UTF, men kompatibel med ISO 8859-1. När MIME med 8-bits överföring används kan UCS-VLOSE användas direkt i de flesta fall. Vid 7-bits överföring får vi ta fram en UCS-Quoted-Printable (finns redan ett förslag på detta från ietf-822 listan). Dan -- Dan Oscarsson Telia Research AB Email: Dan.Oscarsson@malmo.trab.se Box 85 201 20 Malmo, Sweden From owner-nordpost@nada.kth.se Mon Jun 14 15:47:06 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA22730; Mon, 14 Jun 93 15:47:09 +0200 Received: from baal.efd.lth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA22713; Mon, 14 Jun 93 15:47:06 +0200 Message-Id: <9306141347.AA22713@nada.kth.se> Received: from baal.efd.lth.se by baal.efd.lth.se with smtp (perl jhmail 0.10) (rfc1413: jh@baal.efd.lth.se) id 4e0b67_6db5_1 ; Sun, 13 Jun 1993 15:48:47 MET DST X-Conversion: converted to ISO 646SE by baal.efd.lth.se Date: Sun, 13 Jun 1993 15:48:44 +0200 From: Joergen Haegg To: nordpost@nada.kth.se In-Reply-To: Your message of "12 Jun 1993 17:30:46 +0200." <1338861*JPALME_(reply-to_jpalme@dsv.su.se)@KOM.DAFA.SE> Subject: Re: MIME-gateway (Texthantering) &s Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*217 In message <1338861*JPALME_(reply-to_jpalme@dsv.su.se)@KOM.DAFA.SE>you write: > >[r det helt orimligt att t{nka sig att gatewayen blir s} >intelligent att den tittar p} meddelandet och r{knar ut >ur dess inneh}ll vilket spr}k det {r skrivet p} och vilken >teckenkod det anv{nder. > >Svenska kan man l{tt k{nna igen p} frekvensen av f|rekomst >av de 10 vanligaste orden i texten. Det r{cker med att titta >p} de f|rsta raderna i texten. Och om brevet inneh}ller en beskrivning av det program eller den data som f|ljer? Framf|rallt g}r det inte att avg|ra vilket spr}k det {r utan att anv{nda en rej{l ordlista. >Allt detta borde datorn kunna klara helt automatiskt. >I os{kra fall {r det givetvis b{st att inte konvertera. Vad definierar du som os{kert i det h{r fallet? >Enda nackdel jag kan se med detta {r ett meddelande som >f|rst {r ren svenska i t.ex. 20 rader och d{refter g}r >|ver till uuencode eller binhex eller n}got s}dant, som >absolut inte f}r konverteras. Som sagt var, det {r ganska vanligt med dylika brev. M|jligen skulle konstruktionen med ett '&' i Subject: fungera, men det kr{ver lite disciplin av anv{ndarna. En annan m|jlighet {r att l}ta anv{ndarna registrera sig (automatiskt) via ett brev till en demon. Det r{cker med att man s{ger 'Jag vill ha omvandlat till ISO 8859-1', eller n}got liknande. D} kan man p} anv{ndarniv} avg|ra vad sjubitarsbrevet ska omvandlas till. Konvertera inte de icke-registrerade anv{ndarnas brev. D} kan man ocks} fixa eventuella PC- eller Mac-teckenkoder p} samma s{tt. Tja, bara lite funderingar. B{st {r nog {nd} att l}ta bli att konvertera sjubitarsbrev. -------- J|rgen H{gg jh@efd.lth.se postmaster@efd.lth.se Telnr: 046-107492, 104013(fax) Snigelpost: H{mtst{lle 7, BOX 118, 221 00 LUND Lunds Tekniska H|gskola Paket: E-huset, Ole R|mers v{g 3, 221 00 LUND Mother told me to be good, but she's been wrong before. From owner-nordpost@nada.kth.se Mon Jun 14 15:48:59 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA22757; Mon, 14 Jun 93 15:49:02 +0200 Received: from baal.efd.lth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA22740; Mon, 14 Jun 93 15:48:59 +0200 Message-Id: <9306141348.AA22740@nada.kth.se> Received: from baal.efd.lth.se by baal.efd.lth.se with smtp (perl jhmail 0.10) (rfc1413: jh@baal.efd.lth.se) id 4f09e0_734_1 ; Mon, 14 Jun 1993 09:54:32 MET DST X-Conversion: converted to ISO 646SE by baal.efd.lth.se Date: Mon, 14 Jun 1993 09:54:28 +0200 From: Joergen Haegg To: nordpost@nada.kth.se In-Reply-To: Your message of "Mon, 14 Jun 1993 09:22:22 +0200." <9306140722.AA02978@malmo.trab.se> Subject: Re: MIME-gateway (Texthantering) - standardkodning Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*218 In message <9306140722.AA02978@malmo.trab.se>you write: > >Vore det inte l{mpligt att vi anv{nde EN teckenkodning f|r MTA till MTA >|verf|ring? D{remot mellan UA och MTA, dvs. lokalt p} ett st{lle, kan man >anv{nda vad som helst. Jod}, men hur g|r man med de som inte vill byta sin MTA. >Det b{sta hade varit att anv{nda ISO 10646 f|r MTA till MTA |verf|ring. >D} t{cks praktigt taget alla tecken i v{rlden. Om nu 10646 verkligen sl}r igenom. Eller Unicode. Eller... Vi kanske ska b|rja med det som anv{nds. MIME ber{ttar ju faktiskt allt om inneh}llet, s} vad man vill uppn} {r MIME mellan MTA:er. -------- J|rgen H{gg jh@efd.lth.se postmaster@efd.lth.se Telnr: 046-107492, 104013(fax) Snigelpost: H{mtst{lle 7, BOX 118, 221 00 LUND Lunds Tekniska H|gskola Paket: E-huset, Ole R|mers v{g 3, 221 00 LUND Come, every frustum longs to be a cone, And every vector dreams of matrices. Hark to the gentle gradient of the breeze: It whispers of a more ergodic zone. -- Stanislaw Lem, "Cyberiad" From owner-nordpost@nada.kth.se Mon Jun 14 20:19:10 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA25056; Mon, 14 Jun 93 20:19:16 +0200 Received: from othello.admin.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA25039; Mon, 14 Jun 93 20:19:10 +0200 Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b) id AA00885; Mon, 14 Jun 93 20:19:37 +0200 Received: by mercutio.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0) id AA06119; Mon, 14 Jun 93 20:17:55 +0200 Date: Mon, 14 Jun 93 20:17:55 +0200 Message-Id: <9306141817.AA06119@mercutio.admin.kth.se> From: Olle Jarnefors To: Datorpostteknik i Norden Cc: Olle Jarnefors In-Reply-To: <9306100859.AA04743@alba.udac.uu.se> (Thu, 10 Jun 93 10:59:33 +0200, Martin.Wendel@udac.uu.se (Martin Wendel)) Subject: Re: MIME-gateway (Texthantering) Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*219 Varning: Detta brev {r l}ngt och l}ngrandigt. Det diskuterar ett antal tekniska aspekter p} MIME-slussens |nskv{rda funktionss{tt p} en s{rdeles detaljerad niv}. Endast f|r experter, direkt inblandade och mycket motiverade l{sare. Martin Wendel skrev (10 Jun 93 10:59:33 +0200) i inl{gget <9306100859.AA04743@alba.udac.uu.se>: > > >> MIME-slussen tittar p} slutet av Subject:-raden p} > > > icke-MIME-brev. Om det st}r ett "&"-tecken d{r s} g|rs ingen > > > konvertering. Brevet antas i s} fall vara skrivet med ASCII > > > och det enda som g|rs {r att ett MIME-Version:-f{lt adderas. > > Dvs samma funktionalitet som f|rordas av rfc1344 med header-raden > "Content-Conversion: Prohibited". M}nga som skulle ha nytta av funktionen att f|r ett visst brev hindra den normala konverteringen i MIME-slussen har dock ingen reell m|jlighet att f} ett visst brevhuvudf{lt infogat i de brev de skickar. D{rf|r {r specialtolkning av de sista tecknen i Subject:-f{ltet en b{ttre praktisk l|sning. Dock vore det nog bra om slussen beaktade ett eventuellt "Content-Conversion: Prohibited", eftersom detta {r ett f{lt som {r definierat i en (oomstridd) RFC. Det skulle ocks} inneb{ra en m|jlighet att helt st{nga av MIME-slussens konverteringsfunktion, som {r helt oberoende av brevets inneh}ll (= de brevhuvudf{lt som {r avsedda f|r m{nskliga l{sare, framf|r allt Subject:, plus brevkroppen). > ... Det finns en risk med att ge > anv{ndarna m|jlighet att helt st{nga av all konvertering: att > alltf|r m}nga anv{nder denna m|jlighet slentrianm{ssigt f|r att > kunna kommunicera precis som tidigare och att |verl}ta till mot- > tagaren att sk|ta all n|dv{ndig konvertering. Jag medger att > funktionaliteten dock {r tilltalande, kanske f}r problemet > betraktas som ett pedagogiskt problem. Dessutom {r ju MIME-slussen i f|rsta hand t{nkt att hj{lpa "vanliga" datorpostanv{ndare under en |verg}ngstid tills de har kunnat byta till MIME-kunnig programvara. S}dana anv{ndare anv{nder mest datorpost f|r att skicka enkel text, f|r det mesta p} svenska, och de kommer att ha enbart f|rdelar av att vara anslutna till en MIME-sluss. Bland annat f}r de ju inkommande brev konverterade till svensk 7-bitskod som de annars skulle f} se med ][\ som "=" plus en hexkod eller EDV. Att mer datorteknikinsatta anv{ndare kan slippa f} sina brev konverterade om de vill det tycker jag {r bra. Men det har v{l hela tiden varit t{nkt att MIME-slussen skulle kunna konfigureras s} att konvertering inte g|rs f|r brev till eller fr}n s{rskilt utvalda adresser {ven om |vriga adresser p} en viss v{rddator har konvertering? > Jag vet inte om man kan garantera att &a, dvs us-ascci, inte skall > uts{ttas f|r n}gon konvertering. Kan man inte ist{llet t{nka sig > att &a st}r f|r us-ascii och t.ex. && st}r f|r ingen konvertering. Man kan naturligtvis best{mma en syntax f|r konverteringskoden p} slutet av Subject:-raden (eller i ett Content-Conversion:- f{lt) som ger avs{ndaren av ett brev maximal kontroll |ver vilken konvertering som ska g|ras. I det system f|r teckenkodskonvertering som vi h}ller p} att utforma i RARE- projektet C3-TF (forts{ttning p} arbetet i Teknikl}dans ][\- grupp) t{nker vi oss att konverteringen ska best{mmas fullst{ndigt med hj{lp av fem parametrar, av vilka de tre viktigaste {r: 1) Vilken teckenkod man konverterar fr}n. 2) Vilken teckenkod man konverterar till. 3) Om man vill att konverteringen ska 3.1) bevara str{ngl{ngden (1-1-konvertering), 3.2) ge b{sta l{sbarhet eller 3.3) kunna }terkonverteras till ursprunglig teckenkod utan informationsf|rlust (reversibel konvertering). F|r att g|ra det hela l{tt att f|rst} och utnyttja f|r vanliga anv{ndare tror jag dock att det {r viktigast att de praktiskt betydelsefulla konverteringarna {r enkla att ange. F|renklingar i den generella modellen som b|r g|ras {r d}: -- L}t MIME-slussen sj{lv avg|ra m}lteckenkoden f|r konverteringen bland de f|r MIME-brev rekommenderade teckenkoderna. -- Anv{nd alltid konverteringstyp 3.2, som ger b{sta l{sbarhet. Detta leder till att man bara beh|ver specificera parameter 1, vilken teckenkod MIME-slussen ska konvertera fr}n, det vill s{ga vilken teckenkod man har skrivit det egna brevet med. Att veta det kan vara sv}rt nog f|r en datortekniskt ointresserad anv{ndare, men han {r hj{lpt av att MIME-slussen b|r veta hans normala teckenkod (som kan vara svensk 7-bitskod i n}gon av de fyra varianter jag n{mnde i f|reg}ende inl{gg p} den h{r brevlistan eller, kanske, n}gon av kodsidorna 437 och 859 f|r IBM PC eller Mac-kod eller NeXT-kod). N{r det blir fel f|r en s}dan anv{ndare l{r det i de allra flesta fall bero p} att ingen konvertering skulle ha gjorts alls, det vill s{ga att brevet borde ha behandlats som om det var skrivet i ASCII fr}n b|rjan. Detta "konverterings"alternativ b|r d{rf|r ha en s} enkel kod som m|jligt att placera sist p} Subject:-raden och jag f|resl}r tecknet "&", som det knappast kan finnas n}gon anledning att ha d{r annars. Behovet av koder f|r att ange en annan teckenkod i ett brev {r i praktiken betydligt mindre, skulle jag tro. Om vi vill ha en s}dan funktionalitet i MIME-slussen, kan vi gott f|lja Martins f|rslag: > Kanske m}ste teckenkodnamnen ges i tydligare form, f|r att ge mer > flexibel funktionalitet f|r diverse teckenkoder vi inte t{nker p}, > Kanske skall man travestera rfc1342 och ha t.ex. &?iso-646?& som > identifierare ist{llet. Det {r nog bara anv{ndare som {r vana vid "konstiga datakoder" som skulle utnyttja detta, s} koderna beh|ver inte g|ras s} korta som i mitt tidigare f|rslag. Det verkar vettigt att anknyta till RFC 1342, allts} del 2 av MIME-specifikationen som handlar om hur man ska kunna anv{nda andra teckenkoder {n ASCII i brevhuvudf{lten. RFC 1342 s{ger att allt som st}r i brevhuvudf{lt ska tolkas som vanligt (allts} som skrivet i ASCII), utom encoded-tokens som har strukturen "=?"teckenkodsnamn"?"|verf|ringskodningsnamn"?"kodad_text"?=" Teckenkodsnamnen {r samma som anv{nds i charset-parametern i MIME-brev. \verf|ringskodningen anges med "Q" eller "B" som {r n{stan likadana som Quoted-Printable och Base64. En m|jlighet vore att anv{nda grunkor som "=?us-ascii?x-charset??=" f|r att ange med vilken teckenkod brevet {r skrivet. Med "=?x-uuencode?x-binform??=" skulle man kunna anges att brevet i sin helhet {r binhexat (och b|r konverteras till "Content-Type: Application/Octet-Stream" med "Content-Transfer-Encoding: Base64"). F|r eventuella andra tj{nster som MIME-slussen skulle kunna utf|ra f|r ett visst brev kan andra pseudo-v{rden p} |verf|ringskodning anv{ndas. > En annan sak {r att gatewayen, om den lyckas utf|ra en konvertering, > m}ste f|r{ndra/ta bort &* f{ltet. Verkar bra. > ... Dessutom m}ste man t{nka p} vilken > teckenkodsspecifikation som har h|gst prioritet (ett MIME-brev med > charset samt &* i subject). Min personliga }sikt {r att MIME-specifika > headrar alltid skall ha h|gst prioritet och g{lla oavsett mots{gande > icke-MIME specifikationer. F|rst n}gra definitioner: En MIME-sluss har som _abonnenter_ anv{ndarna/brevl}dorna ett antal dom{ner. _F|rvald teckenkod_ och _f|rvald bin{rfilrepresentation_ {r definierade f|r abonnenterna p} dom{n-, maskin/v{rddator- eller anv{nadar/ brevl}deniv}. Med ett _inkommande_ brev menar jag h{r ett brev till en abonnent, med _utg}ende_ brev ett brev fr}n en abonnent. ]tminstone dessa teckenkoder b|r supporteras: # 7-bitskoder: + svensk 7-bitskod i grundversion (med dollar) + svensk 7-bitskod i egennamnsversion (med dollar) + US-ASCII # 8-bitskoder: + ISO 8859-1 + IBM PC-kod CP437 + IBM PC-kod CP850 + Mac-kod + NeXT-kod # MIME (det vill s{ga ingen konvertering alls) ]tminstone dessa bin{rfilrepresentationer b|r supporteras: - uuencode - binhex - MIME (det vill s{ga Base64 beh}lls) S} h{r tror jag att konvertering b|r utf|ras i MIME-slussen: 0) Allm{nt: Ingen konvertering b|r utf|ras om ett inkommande eller utg}ende brev inneh}ller "Content-Conversion: Prohibited". I |vrigt g{ller f|ljande: N{r konvertering av ett brev (eller en brevkroppsdel) har gjorts, adderas ett s{rskilt Received:-f{lt till brevets (eller brevkroppsdelens) huvud som redovisar vad som har gjorts. S}dana kan kanske se ut s} h{r: Received: from mime.sunet.se by mime.sunet.se conv-type charset source x-iso-646-se-b target iso-8859-1 conv-type add-mime-headers id AA14979; Tue, 1 Jun 93 05:49:20 +0200 Received: from mime.sunet.se by mime.sunet.se conv-type binform source x-uuencode target base64 conv-type add-mime-headers id AA16412; Wed, 2 Jun 93 21:26:40 +0200 1) Brev och brevkroppsdelar av Text-typ: Om ett inkommande eller utg}ende brev (eller en kroppsdel i det) har ett Content-Type:-f{lt med en typ Text/ s} b|r MIME-slussen anta att brevet (kroppsdelen) {r skrivet med den teckenkod som anges av eventuell charset-parameter. Om ingen s}dan finns b|r MIME-slussen anta att den {r US-ASCII (i enlighet med specifikationen av MIME i RFC 1341). Det ska inte spela n}gon roll om Subject:-f{ltet slutar med n}got som ser ut som en konverteringskod. Konvertering g|rs bara p} inkommande brev vars teckenkod skiljer sig fr}n mottagarens f|rvalda teckenkod. Ingen speciell behandling av delar som ser ut att vara uuencodade eller binhexade utf|rs. (Det {r inte meningen att s}dana ska finnas i MIME-brev.) I inkommande brev som konverterats beh}lls MIME-f{lten, och den teckenkod till vilken konvertering har gjorts anges som charset-parameter. (H{r f}r vi inf|ra en rad X-namn f|r teckenkoder.) Ett Content-Transfer-Encoding:-f{lt f}r ocks} s{ttas in med v}rdet 7BIT eller 8BIT beroende p} vilken sorts teckenkod konverteringen gjorts till (eller befintligt f{lt f}r {ndras). 2) Brev och brevkroppsdelar av annan typ {n Text: Inkommande brev och brevkroppsdelar som har Content-Type:- f{lt med v{rden av typ Image, Audio, Video eller Application b|r konverteras till f|rvalt bin{rfilformat, om Content- Transfer-Encoding: {r Quoted-Printable, Base64 eller 8bit. Utg}ende s}dana brev konverteras inte. F|r Message- och Multipart-brev f}r eventuell konvertering avg|ras f|r varje kroppsdel separat. I inkommande brev som konverterats beh}lls MIME-f{lten, och det bin{rfilsformat till vilket konvertering har gjorts anges med ett X-namn i Content-Transfer-Encoding:-f{ltet -- X-Uuencode vid uuencodning och X-Binhex vid binhexning. 3) Brev utan Content-Type:-f{lt: I utg}ende brev som inte inneh}ller n}got Content-Type:-f{lt best{mmer eventuellt konverteringsdirektiv i slutet av Subject:-f{ltet vilken konvertering som ska g|ras. Om inget konverteringsdirektiv finns i ett utg}ende brev, utf|rs konvertering fr}n den f|rvalda teckenkoden till l{mplig MIME-teckenkod. Dock b|r delar av brevkroppen som ser ut att vara uuencodade eller binhexade inte konverteras. Om en ordanalys av det slag som Jacob Palme f|reslagit ger till resultat att filen inte inneh}ller n}gra av orden i listan |ver de vanligaste svenska orden, b|r dock ingen konvertering g|ras utan brevet antas ha teckenkoden US-ASCII. Om analysen ger till resultat att svenska ord f|rekommer men {r kodade med en viss annan kod {n den f|rvalda, g|rs konverteringen i st{llet fr}n den teckenkoden. (Denna analysmetod kan dock inte skilja p} olika varianter av svensk 7-bitskod eller av IBM PC-kod.) Om analysen ger till resultat att svenska ord f|rekommer men synes vara kodade med flera olika teckenkoder, g|rs ingen konvertering. Som v{rde p} charset-parametern anv{nds d} "unknown-8bit". Samma sak g|rs om den f|rvalda teckenkoden {r en 7-bitskod men brevet inneh}ller h|ga tecken. I utg}ende brev s{tts passande MIME-f{lt in, allts} dels "MIME-Version: 1.0", dels "Content-Type: Text/Plain; charset=" eller "Content-Type: Application/Octet-Stream", dels "Content-Transfer-Encoding:" med l{mpligt v{rde (Quoted-Printable f|r text med annan teckenkod {n US-ASCII). Inkommande brev utan Content-Type:-f{lt uts{tts inte f|r n}gon konvertering. 4) Brevhuvudf{lt: I inkommande MIME-brevs (eller brevkroppsdelars) huvudf{lt kan icke-ASCII-tecken vara kodade med encoded-words enligt MIME del 2 (RFC 1342). Dessa b|r konverteras till f|rvald teckenkod ({ven om den {r en 8-bitskod). I utg}ende brev utan Content-Type:-f{lt b|r brevhuvudf{lten genomg} samma konvertering som brevkroppen. N}gra specialfall att se upp med: -- Den teckenkod som konverteringen g|rs ifr}n {r en 7-bitskod, men n}got f{lt inneh}ller h|ga tecken: Brevet b|r returneras med felmeddelande. -- Den teckenkod som konverteringen g|rs ifr}n {r en 7-bitskod och i n}got f{lt anv{nds ett l}gt tecken p} ett s{tt som inte {r till}tet enligt RFC 822 men som vore till}tet om detta tecken representerades i en 8-bitskod och kodades i ett encoded-word. Till exempel {r From: ]ke [nglund illegalt enligt RFC 822 men det motsvarande From: =?ISO-8859-1?Q?=C5ke_=C4nglund?= till}tet. I dessa fall b|r en v{lsinnad konvertering g|ras. -- Den teckenkod som konverteringen g|rs ifr}n {r en 8-bitskod och 8-bitstecken f|rekommer i n}got f{lt p} ett st{lle d{r icke-ASCII-tecken inte kan anges enligt MIME ens med hj{lp av encoded-words, till exempel i f{ltnamnet eller i en quoted-string: Brevet b|r returneras med felmeddelande. F|rm}ga att avkoda f{lt med encoded-words enligt RFC 1342 saknas tyv{rr i en del datorpostprogram som p}st}s vara MIME-anpassade. D{rf|r b|r nog f|rutom konvertering till ISO-8859-1 med Q-konvertering ocks} en konvertering g|ras till US-ASCII vars resultat placeras sist i f{ltet inom parentes. I ovanst}ende exempel skulle det bli: From: =?ISO-8859-1?Q?=C5ke_=C4nglund?= (Ake Anglund) From owner-nordpost@nada.kth.se Tue Jun 15 10:51:52 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA00388; Tue, 15 Jun 93 10:51:55 +0200 Received: from baal.efd.lth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA00371; Tue, 15 Jun 93 10:51:52 +0200 Message-Id: <9306150851.AA00371@nada.kth.se> Received: from baal.efd.lth.se by baal.efd.lth.se with smtp (perl jhmail 0.10) (rfc1413: jh@baal.efd.lth.se) id 50688a_1522_1 ; Tue, 15 Jun 1993 10:50:43 MET DST X-Conversion: converted to ISO 646SE by baal.efd.lth.se Date: Tue, 15 Jun 1993 10:50:35 +0200 From: Joergen Haegg To: nordpost@nada.kth.se Cc: Olle Jarnefors In-Reply-To: Your message of "Mon, 14 Jun 1993 20:17:55 +0200." <9306141817.AA06119@mercutio.admin.kth.se> Subject: Re: MIME-gateway (Texthantering) Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*220 In message <9306141817.AA06119@mercutio.admin.kth.se>you write: > >> betraktas som ett pedagogiskt problem. > >Att mer datorteknikinsatta anv{ndare kan slippa f} sina brev >konverterade om de vill det tycker jag {r bra. Men det har v{l >hela tiden varit t{nkt att MIME-slussen skulle kunna Kan man lite mer om datorer s} {r det inte sv}rt att l{gga in 'Prohibited' som RFC:n f|reskriver. Det {r nog den snyggaste l|sningen. De flesta {r nog, som du s{ger, n|jda med omvandling. >1) Vilken teckenkod man konverterar fr}n. > >2) Vilken teckenkod man konverterar till. > >3) Om man vill att konverteringen ska > 3.1) bevara str{ngl{ngden (1-1-konvertering), > 3.2) ge b{sta l{sbarhet eller > 3.3) kunna }terkonverteras till ursprunglig teckenkod utan > informationsf|rlust (reversibel konvertering). > >-- L}t MIME-slussen sj{lv avg|ra m}lteckenkoden f|r > konverteringen bland de f|r MIME-brev rekommenderade > teckenkoderna. Det h}ller jag med om. >-- Anv{nd alltid konverteringstyp 3.2, som ger b{sta l{sbarhet. Inneb{r detta {ven MNEMONICS? (Hu :-) >Detta "konverterings"alternativ b|r d{rf|r ha en s} >enkel kod som m|jligt att placera sist p} Subject:-raden och jag >f|resl}r tecknet "&", som det knappast kan finnas n}gon >anledning att ha d{r annars. Ok, det {r rimligt. Det b|r knappast st{lla till n}got problem. >Det {r nog bara anv{ndare som {r vana vid "konstiga datakoder" >som skulle utnyttja detta, s} koderna beh|ver inte g|ras s} korta Helt riktigt. >som i mitt tidigare f|rslag. Det verkar vettigt att anknyta till >RFC 1342, allts} del 2 av MIME-specifikationen som handlar om >hur man ska kunna anv{nda andra teckenkoder {n ASCII i >brevhuvudf{lten. > >RFC 1342 s{ger att allt som st}r i brevhuvudf{lt ska tolkas som >vanligt (allts} som skrivet i ASCII), utom encoded-tokens som >har strukturen > >"=?"teckenkodsnamn"?"|verf|ringskodningsnamn"?"kodad_text"?=" >Teckenkodsnamnen {r samma som anv{nds i charset-parametern i >MIME-brev. \verf|ringskodningen anges med "Q" eller "B" som {r >n{stan likadana som Quoted-Printable och Base64. En m|jlighet >vore att anv{nda grunkor som "=?us-ascii?x-charset??=" f|r att >ange med vilken teckenkod brevet {r skrivet. D} bryter man rfc1342 genom att ange annat {n Q eller B. >Med "=?x-uuencode?x-binform??=" skulle man kunna anges att >brevet i sin helhet {r binhexat (och b|r konverteras till >"Content-Type: Application/Octet-Stream" med >"Content-Transfer-Encoding: Base64"). [r det inte enklare att h}lla sig till en typ av kodning, dvs '&*'? Men det {r riktigt att man ska h}lla sig till base64 eller quoted-printable. >]tminstone dessa teckenkoder b|r supporteras: (\hh, 'st|djas' heter det v{l :-) >S} h{r tror jag att konvertering b|r utf|ras i MIME-slussen: > >0) Allm{nt: > > Ingen konvertering b|r utf|ras om ett inkommande eller > utg}ende brev inneh}ller "Content-Conversion: Prohibited". I > |vrigt g{ller f|ljande: > > N{r konvertering av ett brev (eller en brevkroppsdel) har > gjorts, adderas ett s{rskilt Received:-f{lt till brevets > (eller brevkroppsdelens) huvud som redovisar vad som har > gjorts. S}dana kan kanske se ut s} h{r: > > Received: from mime.sunet.se by mime.sunet.se > conv-type charset source x-iso-646-se-b target iso-8859-1 > conv-type add-mime-headers id AA14979; Tue, 1 Jun 93 05:49:20 +0200 Received: kan inte se ut hur som helst. Man m}ste }tminstone l{gga egna saker mellan parenteser vilket betyder kommentarer. >2) Brev och brevkroppsdelar av annan typ {n Text: > > F|r Message- och Multipart-brev f}r eventuell konvertering > avg|ras f|r varje kroppsdel separat. [r det inte lite mycket att beg{ra att programmet ska klara multipart? Det blir ganska komplicerat i s} fall! > -- Den teckenkod som konverteringen g|rs ifr}n {r en > 7-bitskod och i n}got f{lt anv{nds ett l}gt tecken p} ett > s{tt som inte {r till}tet enligt RFC 822 men som vore > till}tet om detta tecken representerades i en 8-bitskod > och kodades i ett encoded-word. Till exempel {r > > From: ]ke [nglund > > illegalt enligt RFC 822 men det motsvarande > > From: =?ISO-8859-1?Q?=C5ke_=C4nglund?= > > till}tet. I dessa fall b|r en v{lsinnad konvertering > g|ras. Det kan finnas MTA:er och klienter som inte klarar detta. B{ttre att konvertera till 'aa', 'oe' osv. -------- J|rgen H{gg jh@efd.lth.se postmaster@efd.lth.se Telnr: 046-107492, 104013(fax) Snigelpost: H{mtst{lle 7, BOX 118, 221 00 LUND Lunds Tekniska H|gskola Paket: E-huset, Ole R|mers v{g 3, 221 00 LUND Subtlety is the art of saying what you think and getting out of the way before it is understood. From owner-nordpost@nada.kth.se Tue Jun 15 18:00:27 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA03692; Tue, 15 Jun 93 18:00:32 +0200 Received: from othello.admin.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA03675; Tue, 15 Jun 93 18:00:27 +0200 Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b) id AA26579; Tue, 15 Jun 93 18:00:55 +0200 Received: by mercutio.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0) id AA10398; Tue, 15 Jun 93 17:59:11 +0200 Date: Tue, 15 Jun 93 17:59:11 +0200 Message-Id: <9306151559.AA10398@mercutio.admin.kth.se> From: Olle Jarnefors To: Datorpostteknik i Norden Cc: Olle Jarnefors In-Reply-To: <9306141348.AA22740@nada.kth.se> (Mon, 14 Jun 1993 09:54:28 +0200, Joergen Haegg ) Subject: Re: MIME-gateway (Texthantering) - standardkodning Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*221 Joergen Haegg skrev (Mon, 14 Jun 1993 09:54:28 +0200) i <9306141348.AA22740@nada.kth.se>: > In message <9306141817.AA06119@mercutio.admin.kth.se>you write: > > >> betraktas som ett pedagogiskt problem. > > > >Att mer datorteknikinsatta anv{ndare kan slippa f} sina brev > >konverterade om de vill det tycker jag {r bra. Men det har v{l > >hela tiden varit t{nkt att MIME-slussen skulle kunna > > Kan man lite mer om datorer s} {r det inte sv}rt att l{gga > in 'Prohibited' som RFC:n f|reskriver. Det {r nog den snyggaste l|sningen. > De flesta {r nog, som du s{ger, n|jda med omvandling. Men det finns ju r{tt m}nga anv{ndare som k|r helt annorlunda postsystem. De {r ofta sammankopplade med Internet via slussar som helt best{mmer vilka f{lt som ska tas med i brevhuvudet i utg}ende brev. Jag t{nker p} s}dant som Quickmail, MS Mail, ccMail, VMS-MAIL. EARN/BITNET. > >1) Vilken teckenkod man konverterar fr}n. > > > >2) Vilken teckenkod man konverterar till. > > > >3) Om man vill att konverteringen ska > > 3.1) bevara str{ngl{ngden (1-1-konvertering), > > 3.2) ge b{sta l{sbarhet eller > > 3.3) kunna }terkonverteras till ursprunglig teckenkod utan > > informationsf|rlust (reversibel konvertering). > > > >-- L}t MIME-slussen sj{lv avg|ra m}lteckenkoden f|r > > konverteringen bland de f|r MIME-brev rekommenderade > > teckenkoderna. > > Det h}ller jag med om. > > >-- Anv{nd alltid konverteringstyp 3.2, som ger b{sta l{sbarhet. > > Inneb{r detta {ven MNEMONICS? > (Hu :-) Nej! MNEMONICS {r alternativ 3.3. > >... En m|jlighet > >vore att anv{nda grunkor som "=?us-ascii?x-charset??=" f|r att > >ange med vilken teckenkod brevet {r skrivet. > > D} bryter man rfc1342 genom att ange annat {n Q eller B. Kommunikationen mellan MIME-slussen och dess abonnenter bryter ju mot Internet-standarderna p} olika s{tt. SMTP-RFC822-MIME till}ter till exempel inte att annan teckenkod {n US-ASCII anv{nds om det inte anges brevhuvudet enligt MIME. Den kanal f|r styrning av slussen genom inneh}llet i Subject:-f{ltet som vi eventuellt inf|r beh|ver inte heller uppfylla Internet- standarderna till punkt och pricka, {ven om alla avvikelser b|r vara noga genomt{nkta. Att anv{nda "encoded-word"s i Subject:-f{ltet med ett X-v{rde p} "encoding" {r en acceptabel avvikelse enligt min mening, eftersom ett s}dant "encoded-word" saknar mening enligt RFC 1342 och X-v{rden p} "encoding" inte kommer att tas i anspr}k i n}gon framtida utvidgning av MIME. > >Med "=?x-uuencode?x-binform??=" skulle man kunna anges att > >brevet i sin helhet {r binhexat (och b|r konverteras till > >"Content-Type: Application/Octet-Stream" med > >"Content-Transfer-Encoding: Base64"). > > [r det inte enklare att h}lla sig till en typ av kodning, dvs '&*'? Det kan bli enklare koder, men &*-uttryck {r, i motsats till den sorts "encoded-word"s som jag f|resl}r, fullt legala inslag i Subject:-f{ltet enligt Internet- standarderna. > > N{r konvertering av ett brev (eller en brevkroppsdel) har > > gjorts, adderas ett s{rskilt Received:-f{lt till brevets > > (eller brevkroppsdelens) huvud som redovisar vad som har > > gjorts. S}dana kan kanske se ut s} h{r: > > > > Received: from mime.sunet.se by mime.sunet.se > > conv-type charset source x-iso-646-se-b target iso-8859-1 > > conv-type add-mime-headers id AA14979; Tue, 1 Jun 93 05:49:20 +0200 > > Received: kan inte se ut hur som helst. Man m}ste }tminstone > l{gga egna saker mellan parenteser vilket betyder kommentarer. Mitt exempel var inspirerat av det exempel p} Received:-f{lt vid konvertering som ing}r i RFC 1428, "Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME": : Received: from dbc.mtview.ca.us by dbc.mtview.ca.us : convert rfc822-to-8bit; Tue, 01 Sep 1992 01:18:00 -0700 I RFC 821 kallas Received:-f{lt f|r "time stamp line" och ser ut s} h{r: : Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST I RFC 822 d{remot definieras syntaxen med : received = "Received" ":" ; one per relay : ["from" domain] ; sending host : ["by" domain] ; receiving host : ["via" atom] ; physical path : *("with" atom) ; link/mail protocol : ["id" msg-id] ; receiver msg id : ["for" addr-spec] ; initial form : ";" date-time ; time received Kommentarer enligt RFC 822 {r inte avsedda f|r data som ska vara maskintolkbara: : The comment construct permits message originators to add text : which will be useful for human readers, but which will be : ignored by the formal semantics. I RFC 1123, "Requirements for Internet Hosts, Part 2", finns ytterligare n}gra regler f|r f{ltets utseende: -- Efter "from" kan komma b}de en dom{nadress och en IP-adress. -- Identifieringsstr{ngen som st}r efter "id" beh|ver inte inneh}lla "@". (I verkligheten struntar m}nga program ocks} i att s{tta "<" och ">" runt identifieringen.) -- Efter "for" kan f|lja en lista av "addr-spec", n{r brevet har flera mottagare. En detaljerad diskussion av olika diskrepanser mellan RFC 821 och RFC 822 (i belysning av RFC 1123) {gde rum p} comp.mail.headers i januari i }r. Med ledning av den kan en aktualiserad syntax f|r Received:-f{ltet, som ocks} uttrycker "current practice", anges s} h{r: received = "Received" ":" ; one per relay ["from" domain ["(" domain-litteral ")"]] ; sending host ["by" domain] ; receiving host ["via" atom] ; physical path *("with" atom) ; link/mail protocol ["id" (local-part/msg-id)] ; receiver id ["for" 1#addr-spec] ; initial form ";" date-time ; time received Om man ska bygga vidare p} denna syntax f|r att m|jligg|ra ordnad angivelse av konverteringar ut|ver datatransporter verkar det rimligt att l{gga till nya nyckelord till den nu godk{nda listan (from, by, via, with, id, for) och begr{nsa syntaxen f|r det f|ljande dataelementet till enklaste form, "atom". Det vore f|rst}s b{st om en ny RFC utarbetades som beskriver de nya anv{ndningarna f|r Received:-f{ltet, inklusive nya nyckelord och de v{rden dessa kan f|ljas av. Kanske beh|vs ocks} utbyggbarhet genom att IANA f}r registrera nya s}dana i framtiden. > >2) Brev och brevkroppsdelar av annan typ {n Text: > > > > F|r Message- och Multipart-brev f}r eventuell konvertering > > avg|ras f|r varje kroppsdel separat. > > [r det inte lite mycket att beg{ra att programmet ska klara v> multipart? > Det blir ganska komplicerat i s} fall! Borde kunna klaras med rekursion. > > -- Den teckenkod som konverteringen g|rs ifr}n {r en > > 7-bitskod och i n}got f{lt anv{nds ett l}gt tecken p} ett > > s{tt som inte {r till}tet enligt RFC 822 men som vore > > till}tet om detta tecken representerades i en 8-bitskod > > och kodades i ett encoded-word. Till exempel {r > > > > From: ]ke [nglund > > > > illegalt enligt RFC 822 men det motsvarande > > > > From: =?ISO-8859-1?Q?=C5ke_=C4nglund?= > > > > till}tet. I dessa fall b|r en v{lsinnad konvertering > > g|ras. > > Det kan finnas MTA:er och klienter som inte klarar detta. > B{ttre att konvertera till 'aa', 'oe' osv. Som framg}r p} ett annat st{lle i mitt tidigare inl{gg f|redrar jag att MIME-slussen g|r b{gge typerna av konvertering. Resultatet av den informationsbevarande konverteringen till RFC 1342-format ers{tter det ursprungliga inneh}llet i f{ltet, resultatet av konverteringen till US-ASCII placeras sist i f{ltet i en kommentar. (Om konvertering till ASCII av ]. [ och \ ska ge Aa, Ae och Oe eller A, A och O kan alltid diskuteras.) From owner-nordpost@nada.kth.se Tue Jun 15 21:57:55 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA05577; Tue, 15 Jun 93 21:58:00 +0200 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA05560; Tue, 15 Jun 93 21:57:55 +0200 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA05299 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Tue, 15 Jun 1993 21:57:54 +0200 Received: from alba.udac.uu.se by solix.udac.uu.se with SMTP id AA11145 (5.67a8/IDA-1.5 for ); Tue, 15 Jun 1993 21:57:52 +0200 Received: by alba.udac.uu.se (5.0/SMI-SVR4) id AA07278; Tue, 15 Jun 93 21:58:18 +0200 From: Martin.Wendel@udac.uu.se (Martin Wendel) Message-Id: <9306151958.AA07278@alba.udac.uu.se> Subject: Re: MIME-gateway (Texthantering) To: nordpost@nada.kth.se Date: Tue, 15 Jun 1993 21:58:16 +0200 (MET DST) In-Reply-To: <9306141817.AA06119@mercutio.admin.kth.se> from "Olle Jarnefors" at Jun 14, 93 08:17:55 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 9764 X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*222 Olle Jarnefors writes: > Martin Wendel skrev (10 Jun 93 10:59:33 +0200) > i inl{gget <9306100859.AA04743@alba.udac.uu.se>: > > Dvs samma funktionalitet som f|rordas av rfc1344 med header-raden > > "Content-Conversion: Prohibited". > > M}nga som skulle ha nytta av funktionen att f|r ett visst brev > hindra den normala konverteringen i MIME-slussen har dock ingen > reell m|jlighet att f} ett visst brevhuvudf{lt infogat i de brev > de skickar. D{rf|r {r specialtolkning av de sista tecknen i > Subject:-f{ltet en b{ttre praktisk l|sning. Jag h}ller med. > Dock vore det nog > bra om slussen beaktade ett eventuellt "Content-Conversion: > Prohibited", eftersom detta {r ett f{lt som {r definierat i en > (oomstridd) RFC. Jag h}ller med. > > Att mer datorteknikinsatta anv{ndare kan slippa f} sina brev > konverterade om de vill det tycker jag {r bra. Men det har v{l > hela tiden varit t{nkt att MIME-slussen skulle kunna > konfigureras s} att konvertering inte g|rs f|r brev till eller > fr}n s{rskilt utvalda adresser {ven om |vriga adresser p} en > viss v{rddator har konvertering? Konverteringen skall kunna vara fritt konfigurerbar, dvs {ven ingen konvertering skall kunna konfigureras. > > Jag vet inte om man kan garantera att &a, dvs us-ascci, inte skall > > uts{ttas f|r n}gon konvertering. Kan man inte ist{llet t{nka sig > > att &a st}r f|r us-ascii och t.ex. && st}r f|r ingen konvertering. > > Man kan naturligtvis best{mma en syntax f|r konverteringskoden > p} slutet av Subject:-raden OK, vi kan l{mna detta till senare. Det {r viktigare att bli |verens om grunderna. > I det system f|r > teckenkodskonvertering som vi h}ller p} att utforma i RARE- > projektet C3-TF (forts{ttning p} arbetet i Teknikl}dans ][\- > grupp) t{nker vi oss att konverteringen ska best{mmas > fullst{ndigt med hj{lp av fem parametrar, Det vore intressant att ta del av gruppens arbete, och eventuellt inkorporera programmet i MIME-gatewayprogramvaran. Det som ligger n{rmast till hands f|r tillf{llet {r dock att anv{nda Kelds konver- teringsrutiner som ju ocks} f|rst}r MNEM, inte minst viktigt om det blir dknets beslut att anv{nda MNEM i MIME. (OBS, denna diskussions- tr}d g{ller inte f|r eller mot MNEM). > > F|r att g|ra det hela l{tt att f|rst} och utnyttja f|r vanliga > anv{ndare tror jag dock att det {r viktigast att de praktiskt > betydelsefulla konverteringarna {r enkla att ange. OK, vi pratar allts} h{r om ett antal kortkommandon f|r mer utf|rliga teckenkodsspecifikationer. Jag h}ller med, det borde finnas. > > -- L}t MIME-slussen sj{lv avg|ra m}lteckenkoden f|r > konverteringen bland de f|r MIME-brev rekommenderade > teckenkoderna. > Javisst, eftersom vad detta {r {r att ge icke-MIME anv{ndarna tillg}ng till liknande hj{lpmedel som MIME-anv{ndarna har vad g{ller att specificera brevets teckenkod i brevhuvudet, inte att l}ta dem styra konverteringen. > > Teckenkodsnamnen {r samma som anv{nds i charset-parametern i > MIME-brev. \verf|ringskodningen anges med "Q" eller "B" som {r > n{stan likadana som Quoted-Printable och Base64. En m|jlighet > vore att anv{nda grunkor som "=?us-ascii?x-charset??=" f|r att > ange med vilken teckenkod brevet {r skrivet. > > Med "=?x-uuencode?x-binform??=" skulle man kunna anges att > brevet i sin helhet {r binhexat (och b|r konverteras till > "Content-Type: Application/Octet-Stream" med > "Content-Transfer-Encoding: Base64"). Jag gillar inte syntaxen, den {r alltf|r lik rfc1342 f|r att vara enkel att skilja fr|n felaktiga rfc1342 headrar. Dessutom ser jag ingen anledning att specificera varken uuencode eller binhex eftersom dessa kan uppt{ckas som de {r i breven. Det som beh|ver specificeras {r teckenkod och detta b|r g|ras p} ett s{tt som {r v{sentligt skiljt fr}n rfc1342 (exempelvis, men inte n|dv{ndigtvis, som &?us-ascii?&). > S} h{r tror jag att konvertering b|r utf|ras i MIME-slussen: > > 0) Allm{nt: > > Ingen konvertering b|r utf|ras om ett inkommande eller > utg}ende brev inneh}ller "Content-Conversion: Prohibited". I > |vrigt g{ller f|ljande: > Jag h}ller med. > N{r konvertering av ett brev (eller en brevkroppsdel) har > gjorts, adderas ett s{rskilt Received:-f{lt till brevets > (eller brevkroppsdelens) huvud som redovisar vad som har > gjorts. Jag h}ller med (syntaxen kan diskuteras senare). > > 1) Brev och brevkroppsdelar av Text-typ: > > Om ett inkommande eller utg}ende brev (eller en kroppsdel i > det) har ett Content-Type:-f{lt med en typ Text/ > s} b|r MIME-slussen anta att brevet (kroppsdelen) {r skrivet > med den teckenkod som anges av eventuell charset-parameter. (F|rtydligande: MIME-Version skall sj{lvklart ocks} vara specificerat i brevhuvudet f|r att det skall betraktas som MIME. Jag f|ruts{tter att detta {r underf|rst}tt) > Om ingen s}dan finns b|r MIME-slussen anta att den {r > US-ASCII (i enlighet med specifikationen av MIME i RFC 1341). > Det ska inte spela n}gon roll om Subject:-f{ltet slutar med > n}got som ser ut som en konverteringskod. > Jag h}ller med. > Konvertering g|rs bara p} inkommande brev vars teckenkod > skiljer sig fr}n mottagarens f|rvalda teckenkod. Ingen > speciell behandling av delar som ser ut att vara uuencodade > eller binhexade utf|rs. (Det {r inte meningen att s}dana ska > finnas i MIME-brev.) Gatewayen kommer inte att leta efter uuencode eller binhex s} fort MIME konstaterats i ett inkommande brev. > I inkommande brev som konverterats beh}lls MIME-f{lten, och > den teckenkod till vilken konvertering har gjorts anges som > charset-parameter. (H{r f}r vi inf|ra en rad X-namn f|r > teckenkoder.) Ett Content-Transfer-Encoding:-f{lt f}r ocks} > s{ttas in med v}rdet 7BIT eller 8BIT beroende p} vilken sorts > teckenkod konverteringen gjorts till (eller befintligt f{lt > f}r {ndras). Hm. Du menar MIME-in/MIME-ut? I s} fall b|r MIME-ut vara konfigurerad, (om inte, tycker inte jag det finns n}gon anledning att beh}lla MIME- f{lten). Jag tror inte jag h}ller med. Jag skulle vilja betrakta det hela s} h{r: 1/ MIME -> MIME 2/ MIME -> ickeMIME 3/ ickeMIME -> MIME 4/ ickeMIME -> ickeMIME MIME f|ruts{tter rfc1341, dvs us-ascii, iso8859-[1-9] samt Quoted- Printable och Base64. ickeMIME f|ruts{tter bara uuencode och binhex, dvs teckenkod {r inte begr{nsad som i rfc1341. 1/ Ingen konvertering. 2/ Konvertering av teckenkod och bin{rkodningsformat till konfigurerat teckenkod samt binhex eller uuencode. Eftersom MIME inte {r menings- fullt f|r mottagaren tas dessa headrar bort och ers{tts av konfigurerade dito. 3/ Konvertering av teckenkod och bin{rkodningsformat till MIME dito. MIME-headrar s{tts in. 4/ Eventuell konvertering av teckenkod och bin{rkodningsformat. > > 2) Brev och brevkroppsdelar av annan typ {n Text: > > Inkommande brev och brevkroppsdelar som har Content-Type:- > f{lt med v{rden av typ Image, Audio, Video eller Application > b|r konverteras till f|rvalt bin{rfilformat, om Content- > Transfer-Encoding: {r Quoted-Printable, Base64 eller 8bit. > Utg}ende s}dana brev konverteras inte. > > F|r Message- och Multipart-brev f}r eventuell konvertering > avg|ras f|r varje kroppsdel separat. > > I inkommande brev som konverterats beh}lls MIME-f{lten, och > det bin{rfilsformat till vilket konvertering har gjorts anges > med ett X-namn i Content-Transfer-Encoding:-f{ltet -- > X-Uuencode vid uuencodning och X-Binhex vid binhexning. > Lika h{r: jag ser ingen anledning att beh}lla MIME-f{lten d} konvertering gjorts till ickeMIME. M{rk att vissa UA:s har egen headerhantering och kr{ver viss syntax f|r att k{nna igen medskick (jfr OpenWindows3.[0,1] mailtool. MIME-headrar skickade till den skulle ta bort m|jligheten att enkelt ta emot medskick). > 3) Brev utan Content-Type:-f{lt: > > I utg}ende brev som inte inneh}ller n}got Content-Type:-f{lt > best{mmer eventuellt konverteringsdirektiv i slutet av > Subject:-f{ltet vilken konvertering som ska g|ras. > > Om inget konverteringsdirektiv finns i ett utg}ende brev, > utf|rs konvertering fr}n den f|rvalda teckenkoden till > l{mplig MIME-teckenkod. Dock b|r delar av brevkroppen som ser > ut att vara uuencodade eller binhexade inte konverteras. > Binhex och uuencode b|r ist{llet konverteras till Base64. > Om en ordanalys av det slag som Jacob Palme f|reslagit ger > till resultat att filen inte inneh}ller n}gra av orden i > listan |ver de vanligaste svenska orden, b|r dock ingen > konvertering g|ras utan brevet antas ha teckenkoden US-ASCII. > Jag ser mer problem {n f|rdelar med detta. Kommer metoden att ha r{tt fler g}nger {n om man f|ruts{tter att brevet {r kodat i den f|rvalda teckenkoden? F|r anv{ndaren tror jag att problemen med den senare metoden {r mer konsekventa {n med den f|rra. I de fallen beh|vs ist{llet teckenkodsspecifikation enligt &*. Dvs jag litar inte p} maskinbaserade gissningar av en anv{ndares intentioner. > > I utg}ende brev s{tts passande MIME-f{lt in, allts} dels > "MIME-Version: 1.0", dels "Content-Type: Text/Plain; > charset=" eller > "Content-Type: Application/Octet-Stream", dels > "Content-Transfer-Encoding:" med l{mpligt v{rde > (Quoted-Printable f|r text med annan teckenkod {n US-ASCII). OK. > Inkommande brev utan Content-Type:-f{lt uts{tts inte f|r > n}gon konvertering. Inkommande brev av ok{nd typ uts{tts inte f|r konvertering i andra fall {n d} de f|ruts{tts vara i svensk-ascii och mottagaren inte har detta som f|rval. Eventuell konvertering mellan binhex och uuencode kan ocks} f|rekomma. > 4) Brevhuvudf{lt: (utklippt) Jag h}ller med. From paf@nada.kth.se Wed Jun 16 07:02:03 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08613; Wed, 16 Jun 93 07:02:07 +0200 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08596; Wed, 16 Jun 93 07:02:03 +0200 Message-Id: <9306160502.AA08596@nada.kth.se> To: nordpost@nada.kth.se Subject: Re: MIME-gateway (Texthantering) In-Reply-To: Your message of "Tue, 15 Jun 1993 21:58:16 +0200." <9306151958.AA07278@alba.udac.uu.se> Date: Wed, 16 Jun 1993 07:02:03 +0200 From: Patrik Faltstrom Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*223 Martin Wendel writes: >blir dknets beslut att anv{nda MNEM i MIME. (OBS, denna diskussions- >tr}d g{ller inte f|r eller mot MNEM). Konverteringen fr}n MNEM {r intressant f|r dem som inte vill ha MNEM. (Vi p} NADA vill INTE ha MNEM) >Jag gillar inte syntaxen, den {r alltf|r lik rfc1342 f|r att vara >enkel att skilja fr|n felaktiga rfc1342 headrar. Dessutom ser >jag ingen anledning att specificera varken uuencode eller binhex >eftersom dessa kan uppt{ckas som de {r i breven. Det som beh|ver >specificeras {r teckenkod och detta b|r g|ras p} ett s{tt som >{r v{sentligt skiljt fr}n rfc1342 (exempelvis, men inte >n|dv{ndigtvis, som &?us-ascii?&). B}de uuencode och BinHex {r mycket enkla att uppt{cka i brev beroende p} att b{gge har v{l definierade str{ngar vid start och slut p} kodade avsnitt. Man beh|ver allt}s} inte hantera detta mer speciellt {n att man kollar efter dessa n{r man f}r ett icke-mime-brev. >Gatewayen kommer inte att leta efter uuencode eller binhex s} fort >MIME konstaterats i ett inkommande brev. Detta f|rst}r jag inte. Du borde mena att man letar om man sett att inkommande brev INTE {r MIME? >Binhex och uuencode b|r ist{llet konverteras till Base64. Det g}r inte att konvertera BinHex till Base64 beroende p} BinHex utformning! (hur vore det med testimplementationer innan diskussionen forts{tter) paf From owner-nordpost@nada.kth.se Wed Jun 16 09:33:28 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09386; Wed, 16 Jun 93 09:33:31 +0200 Received: from mars.dsv.su.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09369; Wed, 16 Jun 93 09:33:28 +0200 Received: from dsvmc119.dsv.su.se by mars.dsv.su.se (5.61-bind 1.4+ida/4.0) id AA07694; Wed, 16 Jun 93 09:33:20 +0200 Date: Wed, 16 Jun 93 09:33:20 +0200 Message-Id: <9306160733.AA07694@mars.dsv.su.se> To: nordpost@nada.kth.se From: tor@dsv.su.se Subject: MIME-gateway (Texthantering) Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*224 Jag tycker att Martin Wendels f|rslag (det som jag kopierat in nedan) {r helt i sin ordning. Finns det n}gra tankar p} att kunna komma |verens om n}got. Det hela verkar mycket hit och dit. Kan man inte samla en grupp och diskutera detta. Vid ett s}dant m|te b|r man ha m}ls{ttningen att komma |verens. Det vore fint att f} f|rslag p} en funktionell och enkel l|sning t s} anart som m|jligt. Kopieratr i de t jag tyckte var bra med Martin Ws l|sningsf|rslag. ------------------------------Martins f|rslag b|rjan ------------------------------------------ S} som jag ser det finns det huvudsakligen tv} motiv till varf|r svensk 7bitskod fortfarande anv{nds i mail: 1/ F|r att garantera att texten {r intakt vid routing via k{nda eller ok{nda 7bitsservrar (svensk 7bitskod som transportformat). 2/ F|r att st|dja de som fortfarande anv{nder sig av 7bitsterminaler (svensk 7bitskod som visningsformat). I fallet 2 finns inte mycket att {ndra p}, men man kan ju hoppas att 7bits- terminalerna {r p} v{g ut s} sm}ningom (vad jag f|rst}r {r det billigare att k|pa en ny PC {n en ny terminal). I fallet 1 {r det ju t{nkt att MIME skall l|sa problemen (mha MIME-Gateway), dvs svensk 7bitskod eller 8bitskod endast som lokalt transportformat i de fall d} detta kr{vs. G}r det att komma |verens om att dessa f|ruts{ttnignar skall ligga till grund f|r en MIME-gateway (b|r n}got {ndras eller l{ggas till?): * Svensk 7bitskod inte skall anv{ndas i MIME? F|rdelar: Vi kan i s} fall anv{nda RFC:n rakt av utan lokala till{gg. Det blir inga komplikationer vid internationella kontakter. * Brev som kommer in med svensk 7bitskod till MIME-gatewayen representeras (konverteras) som iso-8859-1? (Eventuellt ocks} med quoted-printable) * Brev som kommer in med svensk 7bitskod anses vara representerade i svensk 7bitskod och inte blandat med us-ascii? (G{ller inte BinHex eller uuencode) Nackdelar: Detta ger potentiella problem med skickning av ex. C-program fr}n vissa klienter. Hur enklast l|sa detta? * Ett lokalt teckenset best{ms, giltigt f|r dom{ner, maskiner eller anv{ndare, och konfigureras in i n}gon lokal MIME-gateway. Konvertering av teckenset sker med avseende p} detta. Ett problem {r hur man konverterar fr}n ex. iso8859-2 -> iso8859-1. Jag tycker att tv}-till-en konvertering {r ett specialfall som bara b|r till{mpas p} iso-8859-1 -> iso-646-se. I andra fall b|r n}got mnemoniskt format anv{ndas f|r tecken som inte finns representerade i m}l-teckensetet. ------------------------------Martins f|rslag--- slut ------------------------------------------ Ett beslut {r efterl{ngtat. From owner-nordpost@nada.kth.se Wed Jun 16 10:23:17 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09702; Wed, 16 Jun 93 10:23:20 +0200 Received: from baal.efd.lth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09685; Wed, 16 Jun 93 10:23:17 +0200 Message-Id: <9306160823.AA09685@nada.kth.se> Received: from baal.efd.lth.se by baal.efd.lth.se with smtp (perl jhmail 0.10) (rfc1413: jh@baal.efd.lth.se) id 51b361_2793_1 ; Wed, 16 Jun 1993 10:22:18 MET DST X-Conversion: converted to ISO 646SE by baal.efd.lth.se Date: Wed, 16 Jun 1993 10:22:16 +0200 From: Joergen Haegg To: nordpost@nada.kth.se In-Reply-To: Your message of "Wed, 16 Jun 1993 09:33:20 +0200." <9306160733.AA07694@mars.dsv.su.se> Subject: Re: MIME-gateway (Texthantering) Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*225 In message <9306160733.AA07694@mars.dsv.su.se>you write: > >Jag tycker att Martin Wendels f|rslag (det som jag kopierat in nedan) {r >helt i sin ordning. > >Finns det n}gra tankar p} att kunna komma |verens om n}got. Det hela verkar >mycket hit och dit. Kan man inte samla en grupp och diskutera detta. Vid >ett s}dant m|te b|r man ha m}ls{ttningen att komma |verens. Jag f|ruts{tter att denna grupp samlas elektroniskt. Annars vore det inte i linje med m}let (datorpost allts} ;-) Gruppen finns v{l redan, dvs denna lista? -------- J|rgen H{gg jh@efd.lth.se postmaster@efd.lth.se Telnr: 046-107492, 104013(fax) Snigelpost: H{mtst{lle 7, BOX 118, 221 00 LUND Lunds Tekniska H|gskola Paket: E-huset, Ole R|mers v{g 3, 221 00 LUND A "No" uttered from deepest conviction is better and greater than a "Yes" merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi From owner-nordpost@nada.kth.se Wed Jun 16 10:51:25 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09949; Wed, 16 Jun 93 10:51:28 +0200 Received: from malmo.trab.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09932; Wed, 16 Jun 93 10:51:25 +0200 Received: by malmo.trab.se (5.65+bind 1.7+ida 1.4.2/TRM-1-NS); Wed, 16 Jun 93 10:51:23 +0200 (MET) Date: Wed, 16 Jun 93 10:51:23 +0200 From: Dan Oscarsson Message-Id: <9306160851.AA12312@malmo.trab.se> To: nordpost@nada.kth.se Subject: Re: MIME-gateway (Texthantering) - standardkodning Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*226 > >In message <9306140722.AA02978@malmo.trab.se>you write: >> >>Vore det inte l{mpligt att vi anv{nde EN teckenkodning f|r MTA till MTA >>|verf|ring? D{remot mellan UA och MTA, dvs. lokalt p} ett st{lle, kan man >>anv{nda vad som helst. > >Jod}, men hur g|r man med de som inte vill byta sin MTA. Det jag pratade om var kod för sändning med MIME och nya MTA:er, gamla får klaras med MIME-slussen, > >>Det b{sta hade varit att anv{nda ISO 10646 f|r MTA till MTA |verf|ring. >>D} t{cks praktigt taget alla tecken i v{rlden. > >Om nu 10646 verkligen sl}r igenom. Eller Unicode. Eller... Om man hela tiden är pessimistisk så blir det inget. 10646 är mycket bättre än att folk sänder 8859-2 eller andra koder som man bara får en massa besvär lokalt att konvertera. >Vi kanske ska b|rja med det som anv{nds. Ja, men inte föreslå att alla sänder Mackodning, IBM PC eller annat konstigt. >MIME ber{ttar ju faktiskt allt om inneh}llet, s} vad man vill uppn} >{r MIME mellan MTA:er. Naturligtvis, men även om man använder MIME skall man inte rekommendera att text sänds i annat än ISO 8859-1 eller UCS. Annars blir inte världen mycket bättre. Dan From owner-nordpost@nada.kth.se Wed Jun 16 10:55:56 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA10010; Wed, 16 Jun 93 10:55:58 +0200 Received: from mars.dsv.su.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09993; Wed, 16 Jun 93 10:55:56 +0200 Received: from dsvmc119.dsv.su.se by mars.dsv.su.se (5.61-bind 1.4+ida/4.0) id AA08720; Wed, 16 Jun 93 10:55:51 +0200 Date: Wed, 16 Jun 93 10:55:51 +0200 Message-Id: <9306160855.AA08720@mars.dsv.su.se> To: nordpost@nada.kth.se From: tor@dsv.su.se Subject: Re: MIME-gateway (Texthantering) Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*227 >In message <9306160733.AA07694@mars.dsv.su.se>you write: > >-------- >J|rgen H{gg jh@efd.lth.se postmaster@efd.lth.se >Telnr: 046-107492, 104013(fax) Snigelpost: H{mtst{lle 7, BOX 118, 221 00 LUND >Lunds Tekniska H|gskola Paket: E-huset, Ole R|mers v{g 3, 221 00 LUND > >A "No" uttered from deepest conviction is better and greater than a >"Yes" merely uttered to please, or what is worse, to avoid trouble. > -- Mahatma Ghandi Gandis yttrande {r filosofiskt intressant. Problemet {r m}nga g}nger att vi alla upplever "verkligheten" s} olika. Vi ser var och en v}r lilla bit och vi har ibland sv}rt att f|rest{lla oss att det finns n}got utanf|r denna v}r personliga verklighet. Det {r trevligt med diskission och det {r ocks} trevligt att f} en praktisk l|sning p} ett problem medan det {r aktuellt. N{r alla har inf|rt ISO 10??? beh|ver vi inte diskutera denna fr}ga l{ngre. From owner-nordpost@nada.kth.se Wed Jun 16 12:50:59 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA10772; Wed, 16 Jun 93 12:51:04 +0200 Received: from othello.admin.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA10755; Wed, 16 Jun 93 12:50:59 +0200 Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b) id AA09156; Wed, 16 Jun 93 12:51:27 +0200 Received: by mercutio.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0) id AA13321; Wed, 16 Jun 93 12:49:41 +0200 Date: Wed, 16 Jun 93 12:49:41 +0200 Message-Id: <9306161049.AA13321@mercutio.admin.kth.se> From: Olle Jarnefors , Peter Svanberg Old-Sender: Olle Jarnefors To: Datorpostteknik i Norden Cc: Olle Jarnefors , Peter Svanberg In-Reply-To: <9306141817.AA06119@mercutio.admin.kth.se> (Mon, 14 Jun 1993 20:17:55 +0200, Olle Jarnefors ) Subject: Re: MIME-gateway (Texthantering) Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*228 Vi har i dialogform redigerat samman (s} gott det gick) en privat diskussion vi hade med utg}ngspunkt fr}n inl{gg *219 p} nordpost-listan fr}n Olle <9306141817.AA06119@mercutio.admin.kth.se> (Mon, 14 Jun 1993 20:17:55 +0200). Teckenf|rklaringar: O> skrivet av Olle Jarnefors P> skrivet av Peter Svanberg X> blablabla X> X> Y> Y faller X i talet under en l{ngre X-replik X> X> X> X svarar genast p} detta inpass ... X> X> och forts{tter sedan sin tidigare p}b|rjade tankeg}ng ----- O> conv-type charset source x-iso-646-se-b target iso-8859-1 O> conv-type add-mime-headers id AA14979; Tue, 1 Jun 93 05:49:20 +0200 P> Formatet p} detta {r v{l f|reslaget n}gonstans? [r det det du P> g}tt efter? O> Nej! Det finns allts} tv} n{r det g{ller Received:-f{ltet delvis O> of|renliga Internet-standarder, RFC 821 och RFC 822. Dessutom O> anges lite l|st i Greg Vaudreuills RFC 1428 om slussning av O> illegala 8-bitsbrev till MIME-v{rlden att sp}rinformation b|r O> adderas, inklusive ett exempel p} hur det b|r se ut: O> O> : Received: from dbc.mtview.ca.us by dbc.mtview.ca.us O> : convert rfc822-to-8bit; Tue, 01 Sep 1992 01:18:00 -0700 O> O> Detta inneb{r en utvidgning av Internet-standarderna, som inte O> definierar n}got nyckelord "convert". Jag tycker att det h{r O> f|rslaget {r mindre lyckat, d{rf|r att det f|rs|ker pressa in O> f|r mycket information, b}de k{llformat och m}lformat, i en O> enda "atom". Det {r ocks} sv}rt att generalisera till andra O> typer av konvertering {n den som behandlas i RFC 1428. (I O> RFC 1344 av Nat Borenstein, om anv{ndning av MIME f|r att O> f|rb{ttra Internet-Mail-slussar, framf|rs till och med en stark O> rekommendation att sp}rinformation, g{rna i form av ett O> Received:-f{lt, ska adderas till ett konverterat brev. Ingen O> vink ges dock om hur ett s}dant f{lt b|r se ut.) O> O> I mitt exempel har jag i st{llet anv{nt ett nytt nyckelord f|r O> varje dataelement, en utvidgning som "skalar" b{ttre. Det {r O> ocks} en enkel utvidgning av den inre struktur f|r Received:- O> f{lt som RFC 821 och RFC 822 anv{nder: En f|ljd av par av O> nyckelord f|ljt av en "atom" eller liknande som anger v{rdet. O> O> Jag tror nog att en ny RFC borde skrivas som l|ser O> mots{ttningarna mellan RFC 821 och RFC 822 n{r det g{ller O> Received:-f{ltets inneh}ll, specificerar en generell syntasx f|r O> f{ltet, anger hur ny nyckelord och v{rden kan registreras hos O> IANA och ocks} inf|r ett mindre antal s}dana f|r konvertering i O> samband med MIME. ----- O> I inkommande brev som konverterats beh}lls MIME-f{lten, och O> den teckenkod till vilken konvertering har gjorts anges som O> charset-parameter. (H{r f}r vi inf|ra en rad X-namn f|r O> teckenkoder.) P> Se d{r, h{r kommer dom iallafall, MIME-namnen p} svenska P> teckenkoder... Har du {ndrat dig eller {r detta ett specialfall som P> bekr{ftar regeln/du inte t{nkt p}? En annan metod vore ju att P> ta bort MIME-f{lten. O> Observera att dessa teckenkodsnamn inte ska sl{ppas ut p} O> Internet utan {r en "privat" utvidgning avtalad mellan O> MIME-slussen och de RFC 822-liknande datorpostsystem som {r O> anslutna till den. Alternativet att ta bort MIME-f{lten O> f|rkastade jag eftersom det i vissa fall kommer att leda till O> on|dig informationsf|rlust. S{rskilt g{ller det om ocks} det O> inre MIME-skelettet i Multipart- och Message-brev ska opereras O> bort. (Vissa mottagande brevsystem l{r filtrera bort dem i alla O> fall.) ----- O> 3) Brev utan Content-Type:-f{lt: O> Om en ordanalys av det slag som Jacob Palme f|reslagit ger O> till resultat att filen inte inneh}ller n}gra av orden i O> listan |ver de vanligaste svenska orden, b|r dock ingen O> konvertering g|ras utan brevet antas ha teckenkoden US-ASCII. P> [ven om brevet bara inneh}ller n}gra f} ord? "N{hedu!", t.ex.... P> Allt det ovan och nedan sagda om ordanalys faller v{l d}? Dvs. P> ordanalys som ger miss s{ger inget om antalet ord < viss gr{ns. O> Jag ser ordanalysen mest som en kontroll av att den f|rvalda O> teckenkoden f|r utg}ende brev (i vilka teckenkoden inte O> indikeras p} n}got s{tt) inte {r uppenbart orimlig. Bara om O> ordanalysen ger ett resultat som markant avviker fr}n f|rvald O> teckenkod b|r den tillm{tas betydelse. Ett s}dant fall {r om O> inga svenska ord alls hittas. O> O> P> Jomen, som jag sa, svenskar skriver inte alltid ordbokssvenska! O> P> "Om inga svenska ord hittas d} antalet ord > X" g}r jag med O> P> p}, med X = 100 eller n}t. O> O> O> Du har nog r{tt. O> O> ... Om man hittar ett enda svenskt ord O> b|r den f|rvalda teckenkoden accepteras. O> O> P> OK. O> O> ... (Ordlistan f}r f|rst}s inte inneh}lla s}dana ord som till O> exempel "{r" i svensk 7-bitskod. Det kan ju utan vidare O> f|rekomma i annat {n svensk text, till exempel C-program!) ----- O> 3) Brev utan Content-Type:-f{lt: O> Om en ordanalys av det slag som Jacob Palme f|reslagit ger O> till resultat att filen inte inneh}ller n}gra av orden i O> listan |ver de vanligaste svenska orden, b|r dock ingen O> konvertering g|ras utan brevet antas ha teckenkoden US-ASCII. P> Annat kriterium: Texten inneh}ller bara kodelement i den invarianta P> delen av 646. Fast det kanske {r r{tt ovanligt? Men *om* det intr{ffar P> {r ju saken klar. O> I s} fall ger alla teckenkodskonverteringar samma resultat som O> ingen konvertering alls! P> Jag menade att som en effektiviserande del i textunders|kningen P> kan man kolla om detta kriterium r}kar vara sant, varvid P> unders|kningen kan avbrytas (med resultatet "konvertera ej"). O> Det {r riktigt. Men mitt tidigare inl{gg var inte inriktat p} O> att ange hur en _effektiv_ implementation b|r g|ras utan p} att O> st{lla upp de yttre krav som varje _korrekt_ implementation ska O> uppfylla. ----- O> Inkommande brev utan Content-Type:-f{lt uts{tts inte f|r O> n}gon konvertering. P> Jas}? Inget |verg}ngsunderst|d f|r Sun-illegal-brev? O> Jag t{nkte nog p} den idealiserade situationen att MIME-slussen O> var en sluss till den rena v{rlden av RFC822-konforma brev. Men O> brev inneh}llande h|ga tecken eller skrivna med svensk 7-bitskod O> kan f|rst}s ha "l{ckt ut" och finnas {ven p} den sidan av O> slussen. Jag har inte t{nkt igenom riktigt vilken serviceniv} O> n{r det g{ller konvertering av inkommande brev fr}n den sidan O> som kan vara rimlig. Ska MIME-slussen kanske rent av fungera som O> ett *reningsverk*, som tar hand om alla passerande brev i diverse O> otill}tna brevformat och "renar" dem till korrekt MIME-post? P> Intressant! I s} fall m}ste man vara *mycket* s{ker p} P> slussprogramvarans tillf|rlitlighet... From owner-nordpost@nada.kth.se Wed Jun 16 20:36:45 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA15053; Wed, 16 Jun 93 20:36:50 +0200 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA15036; Wed, 16 Jun 93 20:36:45 +0200 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA10481 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Wed, 16 Jun 1993 20:36:43 +0200 Received: from alba.udac.uu.se by solix.udac.uu.se with SMTP id AA16604 (5.67a8/IDA-1.5 for ); Wed, 16 Jun 1993 20:36:42 +0200 Received: by alba.udac.uu.se (5.0/SMI-SVR4) id AA07848; Wed, 16 Jun 93 20:37:07 +0200 From: Martin.Wendel@udac.uu.se (Martin Wendel) Message-Id: <9306161837.AA07848@alba.udac.uu.se> Subject: Re: MIME-gateway (Texthantering) To: nordpost@nada.kth.se Date: Wed, 16 Jun 1993 20:37:05 +0200 (MET DST) In-Reply-To: <9306160502.AA08596@nada.kth.se> from "Patrik Faltstrom" at Jun 16, 93 07:02:03 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 4920 X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*229 Patrik Faltstrom writes: > > Martin Wendel writes: > > >blir dknets beslut att anv{nda MNEM i MIME. (OBS, denna diskussions- > >tr}d g{ller inte f|r eller mot MNEM). > > Konverteringen fr}n MNEM {r intressant f|r dem som inte vill ha MNEM. > (Vi p} NADA vill INTE ha MNEM) Precis det jag ville f|rmedla. > > >Gatewayen kommer inte att leta efter uuencode eller binhex s} fort > >MIME konstaterats i ett inkommande brev. > > Detta f|rst}r jag inte. Du borde mena att man letar om man sett att > inkommande brev INTE {r MIME? Ja, det {r det jag menar. > >Binhex och uuencode b|r ist{llet konverteras till Base64. > > Det g}r inte att konvertera BinHex till Base64 beroende p} > BinHex utformning! Kan man hoppas p} att din macMIME g|r detta m|jligt? Jag medger, med nuvarande MIME format (endast rfc1341) g}r det inte OM inte resource forken har l{ngden 0, dvs med tex word-dokument (som borde best} av endast datafork och binhex header) {r det m|jligt. > (hur vore det med testimplementationer innan diskussionen forts{tter) Helt riktigt. Jag har faktiskt en prototyp n{stan f{rdig som f|r n{rvarande fungerar med f|ljande kriterier (fungerar som stand-alone eller inl{nkad i IDA-sendmail): Den fungerar i tv}-pass: Under "collect" samlas data om det inkommande brevet. Dessa data samlas i objekt som beskriver varje del av brevet. F|r text {r exempelvis teckenkod viktigt att veta (kan finnas genom MIME-headrar eller genom best{mt f|rval, jfr mailertable IDA-sendmail). F|r bin{rfiler {r filnamn och typ viktiga data. Prototypen har den begr{nsningen att data om brevet representeras som en l{nkad lista av s}dana objekt. Detta g|r det kn|ligt med binhex, d{rf|r har jag den begr{sningen att binhex som har resourcefork med l{ngd annan {n 0 inte konverteras alls. En annan design med objekt i tr{dstruktur skulle f|renkla implementationen av konvertering fr}n binhex till macMIME. (Detta ger en f|renklad bild av data strukturerna) Exempelvis kan ett inkommande brev representeras i objekt enligt: 1/ Header Typ: Multipart och MIME 2/ Header Typ: text, teckenkod = iso8859-1; kodning quoted-printable 3/ Header Typ: octet-stream; namn = testfil kodning = base64 Samt med referenser till l{ngd etc, f|r att enkelt kunna operera p} det befintliga brevet. Anrop till TCL-rutiner g|rs fortl|pande f|r att evaluera headrar f|r varje object. N{r "collect" fasen {r |ver, g|rs anrop till TCL-rutiner f|r att best{mma vilken typ av konvertering som skall g|ras f|r varje objekt. Dessa konverteringar l{ggs p} i datastrukturen f|r att anv{ndas senare av C-konverteringsrutinerna. Dessutom {ndras headrarna s} att vissa tas bort och vissa l{ggs till f|r varje objekt, allt enligt specifikation i TCL. Slutligen g|rs sista passet, "deliver", d} sj{lva konverertingen g|rs. Konvertering p} ett objekt kan tex vara: 1/packa upp base64, packa uuencode 2/konvertera fr}n macteckenkod till iso8859-1, g|r 8till7bits konvertering till svensk ascii. dvs f|r varje objekt kan en eller flera konverteringsfunktioner anv{ndas. Konverteringsrutinerna {r skrivna i C och g|r f|ljande: packa upp base64, quoted-printable, uuencode eller binhex(datafork) resp packa ihop dito. De fungerar med radvis indata, dvs de kan kopplas efter varandra i samma process. Teckenkonvertering g|rs med Kelds strconv-rutiner. Prototypen {r helt konfigurerbar i TCL vad g{ller byte av headrar, utf|rande av konvertering etc. Detta g|r det m|jligt att tex ta in ett MIME-brev och konvertera till SUN-mailtool format och f} ikoner i mailtool att fungera som de skall (testat och funkar OK). Eftersom i princip hela utf|randet styrs med det on-the-fly konfigurerbara spr}ket TCL, kan i princip vilket utf|rande som helst f}s. Om en syntaktisk felkonfigureraring g|rs, dvs n}got error fr}n TCL, nollst{lls all info och brevet skickas igenom utan konvertering. Det finns en hel del f|r{ndringar som beh|ver g|ras f|r att ut|ka flexibiliteten till att klara ocks} full binhex/macMIME konvertering. Jag funderar ocks} p} att l{gga till hantering av uuencoded apple- single/apple-double, dessa rutiner borde kunna samordnas med macMIMEs. Dessutom beh|ver tabeller uppr{ttas f|r att hantera tolkning av exmepelvis Type/Creator till motsvarande filnamnsextension. F|r n{rvarande klarar gatewayen av MS/Word5.0 och Excel4.0, vad skall h{nda med typer som inte k{nns igen? Dessutom har prototypen fn inget st|d f|r rfc1342, detta m}ste ocks} l{ggas in. Diskussionen i nordpost-listan {r viktig f|r att komma |verens om hur brev mellan olika lokala |ar av preferenser skall se ut. Vad g{ller att uppfylla vissa lokala |nskem}l om hur vissa headrar skall se ut, teckenkod, relay utan konvertering etc b|r detta kunna konfigureras ganska fritt. Fr}gan om att l}ta gatewayen fungera som ett reningsverk mot internet {r intressant och borde inte vara om|jlig att genomf|ra. D{remot vet jag inte om det vore |nskv{rt att genomf|ra. From paf@nada.kth.se Wed Jun 16 20:59:55 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA15310; Wed, 16 Jun 93 20:59:59 +0200 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA15291; Wed, 16 Jun 93 20:59:55 +0200 Message-Id: <9306161859.AA15291@nada.kth.se> To: nordpost@nada.kth.se Subject: Re: MIME-gateway (Texthantering) In-Reply-To: Your message of "Wed, 16 Jun 1993 20:37:05 +0200." <9306161837.AA07848@alba.udac.uu.se> Date: Wed, 16 Jun 1993 20:59:55 +0200 From: Patrik Faltstrom Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*230 Mest diskussion om Macintosh och BinHex i detta brev. Kasta bort det snarast om du inte {r intresserad av detta. Martin Wendel writes: >> >Binhex och uuencode b|r ist{llet konverteras till Base64. >> >> Det g}r inte att konvertera BinHex till Base64 beroende p} >> BinHex utformning! > >Kan man hoppas p} att din macMIME g|r detta m|jligt? Jag medger, >med nuvarande MIME format (endast rfc1341) g}r det inte OM inte >resource forken har l{ngden 0, dvs med tex word-dokument (som >borde best} av endast datafork och binhex header) {r det m|jligt. Nja, enligt mitt MacMIME-f|rslag s} ska man antingen (helst) konvertera BinHex till AppleSingle (eller AppleDouble) + Base64. Annars ska man skicka BinHex som det {r utan vare sig Base64 eller Quoted-Printable. Men naturligtvis tagga det korrekt med MIME-header enligt MacMIME. Jag tror det {r f|r "jobbigt" att g|ra som du t{nkte, f|r d} m}ste man avkoda BinHex och kolla storlekarna p} de olika delarna av filen innan man eventuellt forts{tter. >> (hur vore det med testimplementationer innan diskussionen forts{tter) > >Helt riktigt. Jag tyckte bara det b|rjade bli lite f|r mycket prat om "vad som g}r att g|ra och inte" n{r vi egentligen var |verens om det mesta f|rutom just algoritmerna f|r n{r och hur man ska konvertera. >Prototypen har den begr{nsningen att data om brevet representeras som >en l{nkad lista av s}dana objekt. Detta g|r det kn|ligt med binhex, >d{rf|r har jag den begr{sningen att binhex som har resourcefork med >l{ngd annan {n 0 inte konverteras alls. En annan design med objekt i >tr{dstruktur skulle f|renkla implementationen av konvertering fr}n >binhex till macMIME. Jag tycker detta r{cker. Eventuellt {r det snyggast om du g|r om BinHex till (enligt MacMIME): Multipart/Applefile application/applefile content-type-som-passar-enligt-typen-p}-Macdokumentet Jag kan skicka lite kodexempel om du beh|ver. >2/konvertera fr}n macteckenkod till iso8859-1, g|r 8till7bits konvertering >till svensk ascii. >dvs f|r varje objekt kan en eller flera konverteringsfunktioner anv{ndas. Ok, nu kommer detaljerna... OM man skickar ett Macdokument som BinHex och detta har typen TEXT till n}gon. D} vill man vanligtvis inte(?) att detta ska konverteras, utan l}t det vara kodat. D{remot text i en brevkropp som kommer in i Macintoshens tecken- upps{ttning {r }t helt annat. Denna kan konverteras. >Jag funderar ocks} p} att l{gga till hantering av uuencoded apple- >single/apple-double, dessa rutiner borde kunna samordnas med macMIMEs. Du menar om man skickar till/fr}n AppleLink? Jag har f|rs|kt skicka s}nt, (dvs x-uuencoded-applesingle) men det funkar b{ttre med BinHex in i AppleLink. D{remot ta emot uuencoded AppleSingle funkar bra med mina rutiner som jag testat MacMime med. Dock baserar min Mac-kod sig helt och h}llet p} de som f|ljer med CAP-paketet, och dessa i sin tur klarar bara av (korkade program) som distribuerade AppleSingle/AppleDouble version 1 och inte version 2, som {r den som man b|r anv{nda. Det {r inget viktigt som skiljer. Strunta i att kolla version, och strunta i att kolla "typ" i headern s} funkar det. Fr}n AppleLink kommer uuencoded AppleSingle version 2. Fr}n det som f|ljer med CAP-paketet kommer version 1. Fetch klarar bara av att ta emot version 1. Eudora klarar (i n|sta version) b}de version 1 och 2. paf From owner-nordpost@nada.kth.se Sat Jun 19 21:35:43 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA10401; Sat, 19 Jun 93 21:35:50 +0200 Received: from dkuug.dk by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA10382; Sat, 19 Jun 93 21:35:43 +0200 Received: by dkuug.dk id AA08989 (5.65c8/IDA-1.4.4j); Sat, 19 Jun 1993 21:35:21 +0200 Message-Id: <199306191935.AA08989@dkuug.dk> From: keld@dkuug.dk (Keld J|rn Simonsen) Date: Sat, 19 Jun 1993 21:35:21 +0200 In-Reply-To: Patrik Faltstrom "Re: MIME-gatewayprogramvara" (Jun 7, 15:48) X-Charset: ASCII X-Char-Esc: 29 Mime-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mnemonic-Intro: 29 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: nordpost@nada.kth.se Subject: Re: MIME-gatewayprogramvara Cc: psv@nada.kth.se, ojarnef@admin.kth.se Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*231 Patrik Faltstrom writes: > Joergen Haegg writes: > > >>iso-8859-1. OM man ska l{gga in svensk 7-bitskod utan > >>konvertering i MIME s} kan man anv{nda "x-SEN_850200_B" resp > >>"x-SEN_850200_C" (som de tv} versionerna tyv{rr heter). > > > >Var hittar man info om dessa tv}? > > Jag har inte information om dem, men Peter eller Olle kanske > vet mer. Olle har en bra beskrivning om svensk 7-bitskod och > 646 i allm{nnhet som han kanske kan skicka ut (sn{lla olle...). De to tegnsaet hedder "SEN_850200_B" resp "SEN_850200_C" uden "x-" foran og de er beskervet i RFC1345 og registreret for MIME brug. Hilsen keld From owner-nordpost@nada.kth.se Sat Jun 19 21:39:53 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA10435; Sat, 19 Jun 93 21:39:56 +0200 Received: from dkuug.dk by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA10418; Sat, 19 Jun 93 21:39:53 +0200 Received: by dkuug.dk id AA09078 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Sat, 19 Jun 1993 21:39:33 +0200 Message-Id: <199306191939.AA09078@dkuug.dk> From: keld@dkuug.dk (Keld J|rn Simonsen) Date: Sat, 19 Jun 1993 21:39:32 +0200 In-Reply-To: Martin.Wendel@udac.uu.se (Martin Wendel) "Re: MIME-gatewayprogramvara" (Jun 7, 15:58) X-Charset: ASCII X-Char-Esc: 29 Mime-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mnemonic-Intro: 29 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: nordpost@nada.kth.se Subject: Re: MIME-gatewayprogramvara Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*232 > > Svensk 7-bitskod {r inte registrerad som MIME-teckenkod och vi > > p} NADA har haft en l}ng diskussion med Eudora-folket om man > > egentligen ska ha n}n s}n. Svensk 7-bit er registretet for MIME af IANA, se RFC1340, RFC1345 og Jon Postels skrivelser for nylig. Keld From owner-nordpost@nada.kth.se Mon Jun 21 18:19:41 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24056; Mon, 21 Jun 93 18:19:44 +0200 Received: from kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24039; Mon, 21 Jun 93 18:19:41 +0200 Received: from HERON.DAFA.SE by kth.se (5.65+bind 1.7+ida 1.4.2/6.0) id AA26178; Mon, 21 Jun 93 18:19:39 +0200 Received: by heron.dafa.se (16.6/SiteCap-3.0) id AA18726; Mon, 21 Jun 93 18:19:37 +0200 Date: Mon, 21 Jun 93 18:19:37 +0200 From: Jacob Palme SKHB Message-Id: <9306211619.AA18726@heron.dafa.se> To: nordpost@nada.kth.se Subject: Vad {r enklast f|r icke hackers? Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*233 N{r det g{ller val av olika tekniska l|sningar, s} f|resl}r jag att man, innan man v{ljer l|sning, g|r en konsekvensanalys av vad de olika m|jliga valen betyder f|r s}dana anv{ndare av e-mail som inte {r datorspecialister och som inte kan l{ra sig f|rst} s}dant d{r som att man m}ste skriva "&" sist i {rendet och annat hackigt. T{nk er en lektor i grekiska, som vill anv{nda e-mail f|r att utbyta grekiska texter med forskare i andra europeiska l{nder. Hur g|r man det minst komplicerat f|r honom? (Jag skrev "grekiska" och inte "latin" f|r att inte g|ra det alltf|r enkelt!) From owner-nordpost@nada.kth.se Wed Jun 23 20:59:13 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA17607; Wed, 23 Jun 93 20:59:18 +0200 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA17590; Wed, 23 Jun 93 20:59:13 +0200 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA16874 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Wed, 23 Jun 1993 20:59:12 +0200 Received: from alba.udac.uu.se by solix.udac.uu.se with SMTP id AA12532 (5.67a8/IDA-1.5 for ); Wed, 23 Jun 1993 20:59:10 +0200 Received: by alba.udac.uu.se (5.0/SMI-SVR4) id AA11201; Wed, 23 Jun 93 20:59:22 +0200 From: Martin.Wendel@udac.uu.se (Martin Wendel) Message-Id: <9306231859.AA11201@alba.udac.uu.se> Subject: MIME-gateway Text (f|rslag) To: nordpost@nada.kth.se Date: Wed, 23 Jun 1993 20:59:20 +0200 (MET DST) In-Reply-To: <9306140722.AA02978@malmo.trab.se> from "Dan Oscarsson" at Jun 14, 93 09:22:22 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 5383 X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*234 Det verkar som om }sikterna om texthanteringen vad g{ller MIME-gatewayen {r n}gorlunda likartade. Jag skall h{r f|rs|ka mig p} att komma med ett f|rslag som det f|rhoppningsvis g}r att komma |verens om. F|rst n}gra definitioner: MIME-klient - En anv{ndarprogramvara som f|ruts{tts skicka MIME-brev enligt MIME-standarden, samt som f|ruts{tts kunna ta emot och visa endast de brev som uppfyller MIME-standarden. (Detta {r strikt och beh|ver inte betyda att det inte finns MIME-klienter som {r mer flexibla). IckeMIME-klient - En anv{ndarprogramvara som inte anses kunna tolka hela inneb|rden av ett brev som {r skapat enligt MIME-standarden. Denna skickar heller inga brev som uppfyller MIME-standarden utan skickar ickeMIME-brev. Denna programvara skickar text i n}gon teckenkod, 7 eller 8-bitars okodat. F|rvald teckenkod - Konfigurering av en lokal mailserver som inneb{r att text i brev fr}n en viss klient anses ha denna teckenkod d} annat inte specificerats i sj{lva brevet (tex enligt MIME-standarden). Det {r troligt att mailservern har flera olika f\rvalda teckenkoder konfigurerade f|r olika lokala klienter. Default teckenkod - \verenskommelse om att d} ingen f|rvald teckenkod existerar, och heller ingen teckenkod specificerats i brevet, f|r ett visst brev, skall detta brev betraktas som om det {r skrivet i denna default teckenkod. Rimligen finns en 7 och en 8-bitars default teckenkod. Motivering till f|rslaget: F|r att kunna uppn} smidig kommunikation mellan MIME-klienter och ickeMIME-klienter {r det av st|rsta vikt att det finns ett entydigt s{tt att tolka text i brev, dvs med vilken tecken- kod ett visst brev {r skrivet. F|rslag: 1/ Default sjubitars teckenkod f|r SUNET skall vara svensk sjubits teckenkod. (Diskussion om vilken av de m|jligen tre som finns kan ske senare. Jag kommer dock nedan att anv{nda iso646-se som namn p} denna, vilket m|jligen d} inte blir helt korrekt). 2/ Default }ttabitars teckenkod f|r SUNET skall vara iso8859-1. Denna skickas bara okodad enligt |verenskommelse eller enligt ESMTP standard. 3/ F|rvald teckenkod {r fri att s{ttas till vad som helst f|r lokalt bruk eller enligt |verenskommelse. F|r att underl{tta b|r dock f|rvalda teckenkod anv{ndas i princip bara f|r lokalt bruk. Denna teckekod s{tts antagligen olika f|r olika lokala ickeMIME-klienter. 4/ Teckenkod enligt specifikation i sj{lva brevet f}r ske enligt f|ljande: a/ I MIME-brev enligt MIME-standarden. b/ I ickeMIME-brev sist p} subject-raden, enligt Olle J{rnefors ide, &?teckenkod-namn?& d{r teckenkod-namn {r specificerat i rfc1345. 5/ En "pass-thru" specifikation, dvs d} brevet skall passera okonverterat genom MIME-gatewayen, kan g|ras p} f|ljande s{tt: a/ I MIME-brev enligt rfc1344 med header-raden Content-conversion: Prohibitet b/ I ickeMIME-brev genom en enskiljd ampersand "&" sist p} subject-raden (Olle J{rnefors ide). 6/ Teckenkodnamn enligt 4b b|r i vissa fall kunna specificeras med en kortnotering. Syntax och omfattning kan diskuteras senare. 7/ Omfattningen av teckenkoder i MIME {ndras inte f|r svenskt bruk, dvs giltiga teckenkoder i MIME-brev {r us-ascii samt iso8859-[1-9]. Gatewayen kommer dock att ha m|jlighet att tolka och konvertera (fr}n) {ven andra teckenkoder. 8/ MIME-gatewayen kommer att tills vidare kunna genomf|ra tv} typer av konverteringar: a/ Reversibel konvertering. b/ Ickereversibel konvertering. 8a kommer att ske enligt Keld Simonsens strcnv-paket dvs i om|jliga fall kommer enskilda konverterade tecken att bli representerade enligt MNEM (detta torde dock bli mycket s{llsynt). 8b kommer att ske enligt iso-8859-1 -> iso646-se medelst tabell. I fall d} konvertering skall ske fr}n annan teckenkod {n iso8859-1 kommer f|rst konvertering enligt 8a att genomf|ras till just iso8859-1. (jag {r dock |ppen f|r f|rslag med tabeller fr}n iso8859-[2-9] till iso-646-se). 9/ Default eller f|rvald teckenkod har ingen inneb|rd d} det g{ller att tolka MIME-brev fr}n MIME-klienter utan anv{nds endast f|r ickeMIME-brev. Tolkning av teckenkod sker enligt f|ljande: a/ MIME-brev - us-ascii, iso8859-[1-9] enligt rfc1341. b/ ickeMIME-brev - Den f|rsta uppfylld av (och endast den): * Subject-raden enligt (4b) och (6). * F|rvald teckenkod enligt (3). * Default teckenkod, sjubitars text enligt (1) och 8bitars text enligt (2). 10/ Konvertering av teckenkod kommer att ske i alla fall utom de som: a/ Inte beh|vs, dvs m{lteckenkod och ursprungsteckenkod {r samma. b/ D} "pass-thru" specificerats enligt (5) d} ingen konvertering sker |verhuvudtaget. 11/ Str{van b|r vara att ickeMIME-klienter ers{tts med MIME-klienter i s} stor utstr{ckning som {r m|jligt, i |vrigt b|r en ickeMIME-klient skickar sina brev via en lokal MIME-gateway f|r alla brev som inte {r lokala. Detta f|r att kunna dra nytta av den konverteringskapacitet som byggs upp med anv{ndandet av MIME-gatewayer inom SUNET. Str{van b|r ocks} vara att MIME anv{nds f|r brevkommunikation mellan olika |ar av lokala preferenser inom SUNET och att ickeMIME endast anv{nds f|r lokalt bruk. (Hur detta kan genomf|ras smidigast kan diskuteras senare.) Det {r i samband med ovanst}ende |nskv{rt att MIME-gatewayen till}ts str{va efter att konvertera brev till MIME-format (}tminstone inom SUNET) i alla fall d} inte n}got annat specificerats (tex genom konfigurering). From owner-nordpost@nada.kth.se Thu Jun 24 11:08:36 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA23125; Thu, 24 Jun 93 11:08:40 +0200 Received: from oddput.efd.lth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA23108; Thu, 24 Jun 93 11:08:36 +0200 Received: from efd.lth.se by efd.lth.se with smtp (Smail3.1.28.1 #1) id m0o8nIH-0002UtC; Thu, 24 Jun 93 11:08 MET DST Message-Id: To: nordpost@nada.kth.se Subject: Re: MIME-gateway Text (f|rslag) In-Reply-To: Your message of "Wed, 23 Jun 1993 20:59:20 MET DST." <9306231859.AA11201@alba.udac.uu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Thu, 24 Jun 1993 11:09:07 MET DST From: Joergen Haegg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*235 In message <9306231859.AA11201@alba.udac.uu.se>you write: > >F|rslag: > > >1/ Default sjubitars teckenkod f|r SUNET skall vara svensk sjubits >teckenkod. (Diskussion om vilken av de m|jligen tre som finns kan >ske senare. Jag kommer dock nedan att anv{nda iso646-se som namn >p} denna, vilket m|jligen d} inte blir helt korrekt). > >2/ Default }ttabitars teckenkod f|r SUNET skall vara iso8859-1. >Denna skickas bara okodad enligt |verenskommelse eller enligt >ESMTP standard. Om man inte vet vilken teckenkod som anv{nds s} {r det 'charset=unknown-8bit' som g{ller enligt RFC 1428. A special purpose character set called "unknown-8bit" is defined to be an unknown 8bit character set, encoded into a sequence of octets. It can be used as a label for any character set from any language, using any encoding. It must not be further defined. The use of this token in a "charset=" field of a message indicates that nothing is known about the character set used. This marker is intended for use by non-MIME to MIME gateways; specifically in those which translate from SMTP to 8bit ESMTP/MIME. This character set is not intended to be used by mail composers. It is assumed that the mail composer knows the character set in use and will mark it with a character set value as specified in [1], as amended by current Assigned Numbers documents [6]. The use of the "unknown-8bit" label is intended only by mail gateway agents which cannot determine via out-of-band information the intended character set. The interpretation of the "unknown-8bit" is up to the mail reader. It is assumed that in many cases the human user will be able to interpret the information and choose an appropriate character set or pre-processor. Det {r |nskv{rt att de filter som skrivs eller används är separata program, l{tta att anv{nda f|r andra {ndam}l ocks}. t.ex. 'mittfilter -i 7bitmime -o iso646se utfil' D} kan dessa {ven anv{ndas i eventuella klientprogram om s} skulle beh|vas. Analysprogrammen b|r fungera likadant, 'anaylsera To: nordpost@nada.kth.se Subject: Re: MIME-gateway Text (f|rslag) In-Reply-To: Your message of "Wed, 23 Jun 1993 20:59:20 +0200." <9306231859.AA11201@alba.udac.uu.se> Date: Thu, 24 Jun 1993 14:47:38 +0200 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*236 Citat ur brev från: Martin.Wendel@udac.uu.se (Martin Wendel) > > Först några definitioner: > > MIME-klient - En användarprogramvara som förutsätts skicka > MIME-brev enligt MIME-standarden ... > IckeMIME-klient - En användarprogramvara som inte anses > kunna tolka ... > Förvald teckenkod - Konfigurering av en lokal mailserver som > innebär att text i brev från en viss klient anses ha denna > teckenkod då annat inte specificerats i själva brevet (tex > enligt MIME-standarden). Det är troligt att mailservern har > flera olika fÖrvalda teckenkoder konfigurerade för olika > lokala klienter. Vad är "lokal mailserver" här? Programvara av Sendmail-typ? Vad menas med "konfigurering av ..."? Menar du att SUNET-MIME-sluss-programvaran ska/kan användas på lokal nivå i en dator, och inte - som jag trott - mellan lokala oändrade "Sendmail-ar" och omvärlden? Hur får "mailservern" reda på vilken "klient" användaren använder? > Förvald teckenkod - Konfigurering av en lokal mailserver som > Default teckenkod - Överenskommelse om att då ingen förvald > teckenkod existerar ... Då "förval" är ett (av många) försök att översätta "default" är det olyckligt om vi använder dessa med *olika* betydelser. (Och tänk om vi ska översätta till engelska... ;-)) Vi talar väl här f.ö. om förval på olika nivåer: användar-, domän-, och landsnivå? Dvs. då inget sägs om teckenkod styrs valet av förval (om det finns) på dessa olika nivåer, i nämnd ordning. Eller är det någon väsensskilnad mellan dina två termer jag missat? > 3/ Förvald teckenkod är fri att sättas till vad som helst för > lokalt bruk eller enligt överenskommelse. För att underlätta > bör dock förvalda teckenkod användas i princip bara för lokalt > bruk. Denna teckekod sätts antagligen olika för olika lokala > ickeMIME-klienter. Som sagt, hur man i slussprogramvaran kan skilja mellan "klienter" (brevhanteringsprogram) förstår jag inte. Är det f.ö. så olika? Är det inte användaren/domänen som väljer att använda en viss teckenkod, i alla "klienter"? > 8/ MIME-gatewayen kommer att tills vidare kunna genomföra två > typer av konverteringar: > a/ Reversibel konvertering. > b/ Ickereversibel konvertering. > > 8a kommer att ske enligt Keld Simonsens strcnv-paket > dvs i omöjliga fall kommer enskilda konverterade tecken > att bli representerade enligt MNEM (detta torde dock bli > mycket sällsynt). Menar du att det är (och kommer att fortsätta att vara) sällsynt att andra icke-ASCII-tecken än ÅÄÖ används? För alla sådana krävs ju MNEM vid konvertering till svensk sjubitskod. > 8b kommer att ske enligt iso-8859-1 -> iso646-se > medelst tabell. I fall då konvertering skall ske > från annan teckenkod än iso8859-1 kommer först > konvertering enligt 8a att genomföras till just > iso8859-1. (jag är dock öppen för förslag med > tabeller från iso8859-Ä2-9Å till iso-646-se). (Jag hoppas som sagt C3-projektets programvara kan provas för detta ändamål, när den finns.) --- Peter Svanberg, Nada, KTH From owner-nordpost@nada.kth.se Sat Jun 26 14:16:55 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12381; Sat, 26 Jun 93 14:16:59 +0200 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12364; Sat, 26 Jun 93 14:16:55 +0200 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA00968 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Sat, 26 Jun 1993 14:16:53 +0200 Received: from alba.udac.uu.se by solix.udac.uu.se with SMTP id AA22382 (5.67a8/IDA-1.5 for ); Sat, 26 Jun 1993 14:16:52 +0200 Received: by alba.udac.uu.se (5.0/SMI-SVR4) id AA12665; Sat, 26 Jun 93 14:16:58 +0200 From: Martin.Wendel@udac.uu.se (Martin Wendel) Message-Id: <9306261216.AA12665@alba.udac.uu.se> Subject: Re: MIME-gateway Text (f|rslag) To: nordpost@nada.kth.se Date: Sat, 26 Jun 1993 14:16:57 +0200 (MET DST) In-Reply-To: from "Joergen Haegg" at Jun 24, 93 11:09:07 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1690 X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*237 Joergen Haegg writes: > > Om man inte vet vilken teckenkod som anv{nds s} {r det 'charset=unknown-8bit' > som g{ller enligt RFC 1428. > Specifikationen i rfc1428 {r ett f|rslag f|r konvertering fr}n 8bit till MIME. I det sammanhanget kan det vara l{mpligt med ett charset=unknown-8bit, men det vi m}ste ta h{nsyn till {r inte bara 8bit till MIME utan ocks} 7bit till MIME samt MIME till 8bit eller 7bit. D} kr{vs ocks} ett charset=unknown-7bit !? samt en tolkning av inneb|rden av dessa tv} (hur skall man annars kunna konvertera 8bitMIME till 7bit?). Ist{llet f|respr}kar jag en entydig metod att h{rleda teckenkod i ett brev, eller om du s} vill bla att charset=unknown-8bit f}r ett nationellt v{rde (iso8859-1). Naturligtvis m}ste anv{ndarna bli medvetna om detta p} samma s{tt som de m}ste vara medvetna om vad som h{nder idag n{r de l}ter sin mac med eudora konvertera till svensk 7bitskod. > > Det {r |nskv{rt att de filter som skrivs eller anv{nds {r separata > program, l{tta att anv{nda f|r andra {ndam}l ocks}. > > t.ex. 'mittfilter -i 7bitmime -o iso646se utfil' > Ja, det st}r skrivet i avtalet att det skall finnas patchar till IDAsendmail och dessutom ett frist}ende filter (som skall fungera p} liknande s{tt du skriver ovan). > > PS. > Kommer k{llkoden till brevslussen att vara fri att sprida? > Eftersom n}gon f}r betalt s} vore det bra att veta ;-) > Programvaran skall g|ras fritt tillg{nglig. SUNET {ger alla r{ttigheter s} det {r upp till dem att best{mma hur fritt det f}r anv{ndas. Jag k{nner inte till n}gra detaljer om detta {nnu, men jag antar att det finns, eller borde finnas, n}t som liknar gnus generella licensiering {ven f|r SUNET. From owner-nordpost@nada.kth.se Sat Jun 26 14:55:49 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12511; Sat, 26 Jun 93 14:55:52 +0200 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12494; Sat, 26 Jun 93 14:55:49 +0200 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA01070 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Sat, 26 Jun 1993 14:55:47 +0200 Received: from alba.udac.uu.se by solix.udac.uu.se with SMTP id AA22408 (5.67a8/IDA-1.5 for ); Sat, 26 Jun 1993 14:55:45 +0200 Received: by alba.udac.uu.se (5.0/SMI-SVR4) id AA12679; Sat, 26 Jun 93 14:55:52 +0200 From: Martin.Wendel@udac.uu.se (Martin Wendel) Message-Id: <9306261255.AA12679@alba.udac.uu.se> Subject: Re: MIME-gateway Text (f|rslag) To: nordpost@nada.kth.se Date: Sat, 26 Jun 1993 14:55:50 +0200 (MET DST) In-Reply-To: <9306241247.AA24841@nada.kth.se> from "Peter Svanberg" at Jun 24, 93 02:47:38 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 5233 X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*238 Peter Svanberg writes: > > Citat ur brev fr}n: Martin.Wendel@udac.uu.se (Martin Wendel) > > > F|rvald teckenkod - Konfigurering av en lokal mailserver som > > inneb{r att text i brev fr}n en viss klient anses ha denna > > teckenkod d} annat inte specificerats i sj{lva brevet (tex > > enligt MIME-standarden). Det {r troligt att mailservern har > > flera olika f\rvalda teckenkoder konfigurerade f|r olika > > lokala klienter. > > Vad {r "lokal mailserver" h{r? Programvara av Sendmail-typ? Mitt syfte med f|rslaget var att vara mer generell {n s}, dvs ett postkontor eller MTA (om nu det {r en l{mpligt term), d{remot kommer MIME-gatewayen att kunna l{nkas ihop med IDA-sendmail. > Vad menas med "konfigurering av ..."? Menar du att > SUNET-MIME-sluss-programvaran ska/kan anv{ndas p} lokal niv} i > en dator, och inte - som jag trott - mellan lokala o{ndrade > "Sendmail-ar" och omv{rlden? "Kan" inte "ska", men {ven som du trott. Jag tycker man skall l{mna stor frihet till den lokala organisationen, men jag tycker ocks} att det som inte tolkas lokalt (och konverteras tex till MIME) m}ste tolkas n}gon annanstans och d} {r det viktigt att ha klara premisser f|r tolkningen (bla d{rav f|rslaget). > Hur f}r "mailservern" reda p} vilken "klient" anv{ndaren > anv{nder? Genom tabeller, jfr mailertable i IDAsendmail. Om det finns m}nga olikartade klienter blir det l}nga tabeller annars blir det korta (med kanske bara ett alternativ). F|rdelen med gatewayprogramvaran {r ju ocks} att dessa tabeller kan distribueras genom att anv{nda mer lokala MIME-gateways (kanske institutions- niv}). Eftersom vi p} UDAC internt k|r med 8bit har vi erfarenhet av att s{tta upp liknande tabeller (ca 200 anv{ndare med egna burkar), det {r ett initialt arbete att s{tta upp dem men det blir inte mycket extra arbete sedan vid den l|pande driften. > > F|rvald teckenkod - Konfigurering av en lokal mailserver som > > > Default teckenkod - \verenskommelse om att d} ingen f|rvald > > teckenkod existerar ... > > D} "f|rval" {r ett (av m}nga) f|rs|k att |vers{tta "default" {r > det olyckligt om vi anv{nder dessa med *olika* betydelser. > (Och t{nk om vi ska |vers{tta till engelska... ;-)) Vi talar > v{l h{r f.|. om f|rval p} olika niv}er: anv{ndar-, dom{n-, och > landsniv}? Dvs. d} inget s{gs om teckenkod styrs valet av > f|rval (om det finns) p} dessa olika niv}er, i n{mnd ordning. > Eller {r det n}gon v{sensskilnad mellan dina tv} termer jag > missat? Du har f|rst}tt mig r{tt. Ber om urs{kt f|r att jag blandar ihop termerna. Jag trodde sj{lv det fanns en nyansskillnad mellan f|rvald och default, men jag kan acceptera att den inte finns. Det jag t{nkte med default var EN nationell 7bits och EN 8bitskod. Det jag t{nkte med f|rvald var mera fritt; en eller flera lokala teckenkoder (helt best{mda p} lokal niv}). > > > 3/ F|rvald teckenkod {r fri att s{ttas till vad som helst f|r > > lokalt bruk eller enligt |verenskommelse. F|r att underl{tta > > b|r dock f|rvalda teckenkod anv{ndas i princip bara f|r lokalt > > bruk. Denna teckekod s{tts antagligen olika f|r olika lokala > > ickeMIME-klienter. > > Som sagt, hur man i slussprogramvaran kan skilja mellan > "klienter" (brevhanteringsprogram) f|rst}r jag inte. [r det > f.|. s} olika? [r det inte anv{ndaren/dom{nen som v{ljer att > anv{nda en viss teckenkod, i alla "klienter"? Som jag skrev ovan; Anv{ndaren/dom{nen kan v{lja en viss teckenkod som g{ller f|r alla lokala klienter. Det kan ocks} finnas flera teckenkoder. Som jag f|rst}tt det anv{nder NADA en teckenkod. UDAC anv{nder 5 stycken. Det {r upp till lokala arrangemang att v{lja hur det skall fungera lokalt. > > 8/ MIME-gatewayen kommer att tills vidare kunna genomf|ra tv} > > typer av konverteringar: > > a/ Reversibel konvertering. > > b/ Ickereversibel konvertering. > > > > 8a kommer att ske enligt Keld Simonsens strcnv-paket > > dvs i om|jliga fall kommer enskilda konverterade tecken > > att bli representerade enligt MNEM (detta torde dock bli > > mycket s{llsynt). > > Menar du att det {r (och kommer att forts{tta att vara) > s{llsynt att andra icke-ASCII-tecken {n ][\ anv{nds? F|r alla > s}dana kr{vs ju MNEM vid konvertering till svensk sjubitskod. F|r reversibel konvertering ja. Dan Oscarsson implementerade ju ISOC kommandot i en sendmail. Den typen av konvertering som g|rs av denna sendmail vid nekande svar {r ickereversibel och t{cker iso8859-1 till svensk sjubitskod. Samma konvertering genomf|rs av MIME-gatewayen (8b). Anv{ndandet av diverse andra icke-ASCII-tecken tror jag kommer att |ka i takt med anv{ndandet av 8bitars teckenkoder, men jag tror fortfarande det kommer att vara begr{nsat (vad g{ller inom Sverige). > > 8b kommer att ske enligt iso-8859-1 -> iso646-se > > medelst tabell. I fall d} konvertering skall ske > > fr}n annan teckenkod {n iso8859-1 kommer f|rst > > konvertering enligt 8a att genomf|ras till just > > iso8859-1. (jag {r dock |ppen f|r f|rslag med > > tabeller fr}n iso8859-[2-9] till iso-646-se). > > (Jag hoppas som sagt C3-projektets programvara kan provas f|r > detta {ndam}l, n{r den finns.) Hoppas jag med, jag {r nyfiken p} hur de fungerar och det borde inte vara n}gra problem att l{nka in den i MIME-gatewayen. From owner-nordpost@nada.kth.se Tue Jun 29 18:25:28 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA07921; Tue, 29 Jun 93 18:25:31 +0200 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA07904; Tue, 29 Jun 93 18:25:28 +0200 Received: from HERON.DAFA.SE by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA05064; Tue, 29 Jun 93 18:25:26 +0200 X400-Received: by /PRMD=QZ/ADMD=TEDE/C=SE/; Relayed; 29 Jun 93 18:16:08+0200 Date: 29 Jun 93 18:16:08+0200 From: Lennart Borgman AB_Draco Message-Id: <1268002*Lennart.Borgman@AB_Draco.dafa.se> In-Reply-To: <9306261255.AA12679@alba.udac.uu.se> To: Datorpostteknik i Norden , Mailchar nordiskt mote om teckenstandarder i elektronisk post Subject: igen Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*239 Har skummat igenom era inl{gg. Min mening {r att konverteringar i m|jligaste m}n b|r undvikas. Vi anv{nder sedan l{nga 8-bits tecken (ISO8859-1) lokalt. Vi har en hel del anv{ndare som ringer upp svenska databaser, som anv{nder 7-bits-tecken. Det {r faktiskt inga st|rre problem f|r de flesta anv{ndare att lsa alla konstiga parenteser som svenaska tecken. Visst blir de glada om de f}r svenska tecken ist{llet, men under en |verg}ngsperiod mycket v{l klara sig. Vad skulle t ex h{nda om man g|r mail-ftp via en vms-mail- loppling till internet? From owner-nordpost@nada.kth.se Tue Jun 29 20:13:01 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09072; Tue, 29 Jun 93 20:13:04 +0200 Received: from eru.mt.luth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09055; Tue, 29 Jun 93 20:13:01 +0200 Received: by eru.mt.luth.se with SMTP (5.65+bind 1.7+ida 1.4.2/IDA-1.2.8-NS) id AA24679; Tue, 29 Jun 1993 20:12:59 +0200 Message-Id: <199306291812.AA24679@eru.mt.luth.se> To: nordpost@nada.kth.se Subject: Re: MIME-gateway Text (f|rslag) In-Reply-To: Your message of Wed, 23 Jun 93 20:59:20 +0200. <9306231859.AA11201@alba.udac.uu.se> Date: Tue, 29 Jun 93 20:12:57 +0200 From: Sven-Ove Westberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*240 > Det verkar som om }sikterna om texthanteringen vad g{ller > MIME-gatewayen {r n}gorlunda likartade. Jag skall h{r f|rs|ka > mig p} att komma med ett f|rslag som det f|rhoppningsvis g}r > att komma |verens om. > F|rst n}gra definitioner: > F|rvald teckenkod - Konfigurering av en lokal mailserver som > inneb{r att text i brev fr}n en viss klient anses ha denna > teckenkod d} annat inte specificerats i sj{lva brevet (tex > enligt MIME-standarden). Det {r troligt att mailservern har > flera olika f\rvalda teckenkoder konfigurerade f|r olika > lokala klienter. > Default teckenkod - \verenskommelse om att d} ingen f|rvald > teckenkod existerar, och heller ingen teckenkod specificerats > i brevet, f|r ett visst brev, skall detta brev betraktas som > om det {r skrivet i denna default teckenkod. Rimligen finns > en 7 och en 8-bitars default teckenkod. > F|rslag: > 1/ Default sjubitars teckenkod f|r SUNET skall vara svensk sjubits > teckenkod. (Diskussion om vilken av de m|jligen tre som finns kan > ske senare. Jag kommer dock nedan att anv{nda iso646-se som namn > p} denna, vilket m|jligen d} inte blir helt korrekt). > 5/ En "pass-thru" specifikation, dvs d} brevet skall passera > okonverterat genom MIME-gatewayen, kan g|ras p} f|ljande s{tt: > a/ I MIME-brev enligt rfc1344 med header-raden > Content-conversion: Prohibitet > b/ I ickeMIME-brev genom en enskiljd ampersand "&" > sist p} subject-raden (Olle J{rnefors ide). > 8/ MIME-gatewayen kommer att tills vidare kunna genomf|ra tv} > typer av konverteringar: > a/ Reversibel konvertering. > b/ Ickereversibel konvertering. > 8a kommer att ske enligt Keld Simonsens strcnv-paket > dvs i om|jliga fall kommer enskilda konverterade tecken > att bli representerade enligt MNEM (detta torde dock bli > mycket s{llsynt). > 8b kommer att ske enligt iso-8859-1 -> iso646-se > medelst tabell. I fall d} konvertering skall ske > fr}n annan teckenkod {n iso8859-1 kommer f|rst > konvertering enligt 8a att genomf|ras till just > iso8859-1. (jag {r dock |ppen f|r f|rslag med > tabeller fr}n iso8859-[2-9] till iso-646-se). > 9/ Default eller f|rvald teckenkod har ingen inneb|rd d} det g{ller > att tolka MIME-brev fr}n MIME-klienter utan anv{nds endast f|r > ickeMIME-brev. Tolkning av teckenkod sker enligt f|ljande: > a/ MIME-brev - us-ascii, iso8859-[1-9] enligt rfc1341. > b/ ickeMIME-brev - Den f|rsta uppfylld av (och endast den): > * Subject-raden enligt (4b) och (6). > * F|rvald teckenkod enligt (3). > * Default teckenkod, sjubitars text enligt (1) > och 8bitars text enligt (2). Vad h{der om ett brev med c-kod, TEX dokument etc som inte har en & i slutet av Subject raden r}kar pasera en gateway!! Vi kan INTE f|ruts}tta att v{rlden utanf|r sverige anpassar sig till konstiga lokala regler. Default (fl}t svengelskan) 7-bitars kod m}ste vara US-ascii. Vi kan g|ra vad vi vill med hj{lp av f|rvald teckenkod. OBS f|r lokalt producerade brev kan man v{lja "f|rvald teckenkod" lika med iso646-se f|r den lokala maskinen. > Det {r i samband med ovanst}ende |nskv{rt att MIME-gatewayen till}ts > str{va efter att konvertera brev till MIME-format (}tminstone inom > SUNET) i alla fall d} inte n}got annat specificerats (tex genom > konfigurering). Detta stycke understryker vikten av att inte anse att default teckenkod {r annat {n US-ascii. Brev som uppfylle RFC-822 m}ste komma igenom of|rvanskade. Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden. From owner-nordpost@nada.kth.se Tue Jun 29 21:11:21 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09684; Tue, 29 Jun 93 21:11:24 +0200 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09667; Tue, 29 Jun 93 21:11:21 +0200 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA15316 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Tue, 29 Jun 1993 21:11:20 +0200 Received: from alba.udac.uu.se by solix.udac.uu.se with SMTP id AA19038 (5.67a8/IDA-1.5 for ); Tue, 29 Jun 1993 21:11:18 +0200 Received: by alba.udac.uu.se (5.0/SMI-SVR4) id AA13885; Tue, 29 Jun 93 21:11:19 +0200 From: Martin.Wendel@udac.uu.se (Martin Wendel) Message-Id: <9306291911.AA13885@alba.udac.uu.se> Subject: Re: MIME-gateway Text (f|rslag) To: nordpost@nada.kth.se Date: Tue, 29 Jun 1993 21:11:17 +0200 (MET DST) In-Reply-To: <199306291812.AA24679@eru.mt.luth.se> from "Sven-Ove Westberg" at Jun 29, 93 08:12:57 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1741 X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*241 > > Vad h{der om ett brev med c-kod, TEX dokument etc som inte har en & i slutet av > Subject raden r}kar pasera en gateway!! Vi kan INTE f|ruts}tta > att v{rlden utanf|r sverige anpassar sig till konstiga lokala regler. > > Default (fl}t svengelskan) 7-bitars kod m}ste vara US-ascii. Vi kan > g|ra vad vi vill med hj{lp av f|rvald teckenkod. OBS f|r lokalt > producerade brev kan man v{lja "f|rvald teckenkod" lika med iso646-se > f|r den lokala maskinen. Det jag hade i }tanke med hela f|rslaget var att det skulle g{lla f|r SUNET. Dvs min 7bitars default var en nationell teckenkod som g{ller f|r 7bitars brev skickade fr}n SUNET till SUNET. Jag inst{mmer i din tolkning att utl{nningar inte skall beh|va utst} svensk ascii (det {r illa nog att svenskar skall beh|va utst} den;). Problemet {r att om man vill ha konvertering |verhuvudtaget (vilket man vill, speciellt om det kommer in 8bitars brev) m}ste man ha n}gonting att utg} ifr}n. Fr}gan {r mao: skall man anse att inrikes s{nda och mottagna brev {r skrivna i svensk 7bitskod eller i us-ascii? (En kort blick p} breven till denna lista ger ett entydigt svar;) Utrikeskorrespondensen torde det nog mycket riktigt vara l{mpligt att v{lja us-ascii f|r, jag h}ller med dig d{r. > > Det {r i samband med ovanst}ende |nskv{rt att MIME-gatewayen till}ts > > str{va efter att konvertera brev till MIME-format (}tminstone inom > > SUNET) i alla fall d} inte n}got annat specificerats (tex genom > > konfigurering). > > Detta stycke understryker vikten av att inte anse att default teckenkod > {r annat {n US-ascii. Brev som uppfylle RFC-822 m}ste komma igenom > of|rvanskade. > I s} fall vore MIME-gatewayen ganska ointressant, dvs aldrig konvertering till/fr}n MIME. From owner-nordpost@nada.kth.se Mon Jul 12 08:47:22 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA27847; Mon, 12 Jul 93 08:47:25 +0200 Received: from oddput.efd.lth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA27830; Mon, 12 Jul 93 08:47:22 +0200 Received: from efd.lth.se by efd.lth.se with smtp (Smail3.1.28.1 #1) id m0oFHfU-0002WBC; Mon, 12 Jul 93 08:47 MET DST Message-Id: To: nordpost@nada.kth.se Subject: Re: MIME-gateway Text (f|rslag) In-Reply-To: Your message of "Sat, 26 Jun 1993 14:16:57 MET DST." <9306261216.AA12665@alba.udac.uu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Mon, 12 Jul 1993 08:48:06 MET DST From: Joergen Haegg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*242 In message <9306261216.AA12665@alba.udac.uu.se>you write: >Joergen Haegg writes: >> >> Om man inte vet vilken teckenkod som anv{nds s} {r det 'charset=unknown-8bit >' >> som g{ller enligt RFC 1428. >> > >Specifikationen i rfc1428 {r ett f|rslag f|r konvertering fr}n >8bit till MIME. I det sammanhanget kan det vara l{mpligt med ett >charset=unknown-8bit, men det vi m}ste ta h{nsyn till {r inte >bara 8bit till MIME utan ocks} 7bit till MIME samt MIME till >8bit eller 7bit. D} kr{vs ocks} ett charset=unknown-7bit !? >samt en tolkning av inneb|rden av dessa tv} (hur skall man >annars kunna konvertera 8bitMIME till 7bit?). Nej, unknown-8bit anv{nds f|r ospecificerade teckenkoder, {ven sjubitars. Men ben{mns 8bit d} man inte vet n}got om teckenkoden. (Eller bryr sig om att kontrollera.) >Ist{llet f|respr}kar jag en entydig metod att h{rleda teckenkod >i ett brev, eller om du s} vill bla att charset=unknown-8bit f}r >ett nationellt v{rde (iso8859-1). Naturligtvis m}ste anv{ndarna Fortfarande {r unknown-8bit verkligen 'unknown'. Det st}r speciellt 'It must not be further defined'. -------- Jörgen Hägg jh@efd.lth.se postmaster@efd.lth.se Telnr: 046-107492, 104013(fax) Snigelpost: Hämtställe 7, BOX 118, 221 00 LUND Lunds Tekniska Högskola Paket: E-huset, Ole Römers väg 3, 221 00 LUND From owner-nordpost@nada.kth.se Tue Aug 31 16:02:18 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA18952; Tue, 31 Aug 93 16:02:22 +0200 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA18935; Tue, 31 Aug 93 16:02:18 +0200 Received: from ester.dsv.su.se by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA02540; Tue, 31 Aug 93 16:02:07 +0200 X400-Received: by /PRMD=SUNET/ADMD=_/C=SE/; Relayed; 31 Aug 93 15:51:06+0200 Date: 31 Aug 93 15:51:06+0200 From: Jacob Palme DSV Message-Id: <385119*jpalme@su-kom.dsv.su.se> To: Swedish Initiative for a Research and Education Network , nordpost@nada.kth.se, DSV Personalmote Cc: ext-swnet.sunet-info@dsv.su.se Subject: Seminarier om filter i meddelandesystem m.m. Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*243 DSV har f}tt ett anslag fr}n NUTEK f|r forskning om intelligenta filter i gruppkommunikationssystem. Inom ramen f|r detta anslag ordnar vi nu n}gra seminarier. Seminarierna {r i f|rsta hand avsedda f|r att utbilda oss som jobbar i projektet, men andra intresserade {r v{lkomna att delta. Datum Tid Lokal [mne M}ndag 10.00-Sal 7C Daniel Pargman ger en |versikt |ver n}gra 93-09-06 10.45 (1) k{nda system f|r att filtrera (v{lja ut vad en viss person {r intresserad av) meddelanden i elektronisk post och gruppkommunikation. Bl.a. kommer Oval, Infoscope och Information Lens att presenteras. (1) Electrum, Hiss A, Plan 7, g} till v{nster n{r du l{mnar hissen (inte till h|ger som till DSV-s tidigare lokaler) 11.00-Sal 7C Diskussion med anledning av Daniels 11.45 presentation Ann Lantz ber{ttar om att diskutera ett 13.00-Sal 7C datorsystem man aldrig anv{nt: ett 13.45 underlag till f|rb{ttring av befintligt informationssystem? Med syfte att studera effekter av externt minnesst|d under gruppdiskussioner utf|rdes en studie under v}ren. Underlaget f|r sj{lva gruppdiskussionen var en kort beskrivning av systemet USENET NEWS. Resultatet av dessa gruppdiskussioner kommer att beskrivas utifr}n vad som {r gemensamt f|r grupperna samt de eventuella "unika" ideer som kommit fram i n}gra av grupperna. 14.00-Sal 7C Diskussion med anledning av Anns 14.45 presentation. M}ndag 10.00-605 Jacob Palme ber{ttar om program- och 93-09-27 11.45 datastrukturer hos olika meddelande- system, f|ljt av en diskussion om hur kopplingen kan g|ras mellan intelligenta filter och existerande system. 13.00-605 Daniel Pargman eller Olle Palmgren 14.45 ber{ttar och demonstrerar det filtersystem, kopplat till newsreadern nn, som de har utvecklat som exjobb vid SICS, f|ljt av diskussion kring det de presenterat. M}ndag 10.00-605 Jacob Palme demonstrerar en prototyp f|r 93-10-25 11.45 ett fullgrafiskt gr{nssnitt till SuperKOM under MS Windows, f|ljt av diskussion kring gr{nssnittsfr}gor. From owner-nordpost@nada.kth.se Tue Sep 28 08:58:17 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA26853; Tue, 28 Sep 93 08:58:19 +0100 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA26836; Tue, 28 Sep 93 08:58:17 +0100 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA05469 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Tue, 28 Sep 1993 08:58:15 +0100 Received: from aquila.UDAC.UU.SE by solix.udac.uu.se with SMTP id AA13602 (5.67a8/IDA-1.5 for ); Tue, 28 Sep 1993 08:58:14 +0100 Received: from alba.udac.uu.se by aquila.udac.uu.se with SMTP id AA02308 (5.67a8/IDA-1.5/Mk-0.9 for ); Tue, 28 Sep 1993 08:59:57 +0100 Received: by alba.udac.uu.se (5.0/SMI-SVR4) id AA03979; Tue, 28 Sep 93 08:55:22 +0100 Date: Tue, 28 Sep 93 08:55:22 +0100 From: Martin.Wendel@udac.uu.se (Martin Wendel) Message-Id: <9309280755.AA03979@alba.udac.uu.se> To: nordpost@nada.kth.se Subject: MIME-gateway X-Sun-Charset: US-ASCII Content-Length: 1965 X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*244 Nu {r sommaren slut, MIME-gatewayen b|rjar bli f{rdig och {r uppe och snurrar f|r testning och det b|rjar bli dags att ta fram en konfiguration f|r teckenkods- specfikation/pass-thru f|r icke-MIME klienter. Nu f|ljer forts{ttningen p} den stora teckniska diskussionen som upph|rde under sommaren: Olle J{rnefors kom med ett f|rslag i b|rjan p} sommaren som byggde p} manuell specifikation i header-raden. En ampersand i slutet betydde pass-thru, n}gon form av konstruktion med teckenkodsnamn i slutet specificerade teckenkod. Jag tyckte f|rslaget var utm{rkt men har nu, d} jag b|rjat fundera p} det igen, blivit |vertygad om att det m}ste modifieras. Iden att exploatera header-raden f|r specifikation och styrning av konvertering {r fortfarande utm{rkt. Att d{remot anv{nda de sista tecknen p} raden {r inte s} lyckat. Det borde inneb{ra problem med tanke p} att m}nga anv{ndare g|r reply p} brev utan att ta notis om de headrar som importeras fr}n originalbrevet (som Postmaster ser man det mesta, bla anv{ndare som g|r reply p} felmeddelanden fr}n Mailer-Daemon etc). Det betyder att hela konversationen kommer att styras av ursprungsavs{ndaren, vilket inte {r det som {r t{nkt. Jag f|resl}r ist{llet att man l{gger in styrtecknen i b|rjan p} subject-raden ist{llet och att man l{gger in kolon ist{llet f|r ampersand. Exempel: pass-thru b|r specificeras som f|ljer: Subject: :=:Hej svejs. teckenkodsspecifikation enligt: Subject: :us-ascii: Howdy dowdy Tacksam f|r diskussion om detta med de som k{nner sig manade. ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From owner-nordpost@nada.kth.se Tue Sep 28 09:20:46 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA27355; Tue, 28 Sep 93 09:20:55 +0100 Received: from umdix.umdc.umu.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA27336; Tue, 28 Sep 93 09:20:46 +0100 Received: from puh.umdc.umu.se by umdix.umdc.umu.se with SMTP id AA21102 (5.65c/IDA-1.4.4 for ); Tue, 28 Sep 1993 09:22:41 +0100 Received: by puh.umdc.umu.se (/\==/\ Smail3.1.25.1 #25.7) id ; Tue, 28 Sep 93 09:20 MET Message-Id: From: Christer.Welam@umdac.umu.se (Christer Welam) Subject: Re: MIME-gateway To: nordpost@nada.kth.se Date: Tue, 28 Sep 1993 09:20:46 +0100 (MET) In-Reply-To: <9309280755.AA03979@alba.udac.uu.se> from "Martin Wendel" at Sep 28, 93 08:55:22 am X-Mailer: ELM [version 2.4 PL13] Content-Type: text Content-Length: 2627 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*245 > > Nu {r sommaren slut, MIME-gatewayen b|rjar bli f{rdig och {r uppe och snurrar f|r > testning och det b|rjar bli dags att ta fram en konfiguration f|r teckenkods- > specfikation/pass-thru f|r icke-MIME klienter. > > Nu f|ljer forts{ttningen p} den stora teckniska diskussionen som upph|rde under > sommaren: > > Olle J{rnefors kom med ett f|rslag i b|rjan p} sommaren som byggde p} manuell > specifikation i header-raden. En ampersand i slutet betydde pass-thru, n}gon > form av konstruktion med teckenkodsnamn i slutet specificerade teckenkod. > Jag tyckte f|rslaget var utm{rkt men har nu, d} jag b|rjat fundera p} det igen, > blivit |vertygad om att det m}ste modifieras. > > Iden att exploatera header-raden f|r specifikation och styrning av konvertering > {r fortfarande utm{rkt. Att d{remot anv{nda de sista tecknen p} raden {r inte s} > lyckat. > > Det borde inneb{ra problem med tanke p} att m}nga anv{ndare g|r reply p} brev > utan att ta notis om de headrar som importeras fr}n originalbrevet (som Postmaster > ser man det mesta, bla anv{ndare som g|r reply p} felmeddelanden fr}n Mailer-Daemon > etc). Det betyder att hela konversationen kommer att styras av ursprungsavs{ndaren, > vilket inte {r det som {r t{nkt. > > Jag f|resl}r ist{llet att man l{gger in styrtecknen i b|rjan p} subject-raden ist{llet > och att man l{gger in kolon ist{llet f|r ampersand. > Jag tycker inte att subject-raden {r lyckad alls f|r detta {ndam}l! Eftersom den kan editeras av den som svarar kan den mycket v{l bli modifierad p} ett s{tt som g|r att omkodning/icke-omkodning blir helt fel! (Du skriver f|rresten omv{xlande "header" och "subject" - {r det samma rad du menar?) Jag tycker mycket illa om system som "meranv{nder" f{lt f|r helt andra saker {n de {r avsedda f|r fr}n b|rjan. Framf|r allt f|r icke-datorvana (l{s: icke- freaks!) {r s}dant h{r ytterst f|rvirrande. Jag h}ller kontakt via datorpost med ett stort antal datoranv{ndare vid universitet och h|gskolor, den absoluta lejonparten av dem icke det minsta programmeringskunniga (eller ens intresse- rade). F|r dem {r rubriken "Subject" helt begriplig och logisk som ett f{lt som motsvarar {rendemeningen i ett vanligt dokument. Du kan ALDRIG f} dem att begripa eller {n mindre acceptera att b|rjan av {rendemeningen {r n}got tekniskt hokuspokus, som dessutom g|r att det praktiskt tillg{ngliga utrymmet f|r egen {rendemening (som {r det som syns i startbilden p} Elm, Eudora etc) krymper till n}got oanv{ndbart. Jag kan m|jligen acceptera det om datorpostsystemet utnyttjar utrymmet utan att anv{ndaren ser det eller kan p}verka det. Christer Welam From owner-nordpost@nada.kth.se Tue Sep 28 12:47:14 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA01171; Tue, 28 Sep 93 12:47:17 +0100 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA01154; Tue, 28 Sep 93 12:47:14 +0100 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA07181 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Tue, 28 Sep 1993 12:47:12 +0100 Received: from aquila.UDAC.UU.SE by solix.udac.uu.se with SMTP id AA15615 (5.67a8/IDA-1.5 for ); Tue, 28 Sep 1993 12:47:11 +0100 Received: from alba.udac.uu.se by aquila.udac.uu.se with SMTP id AA02523 (5.67a8/IDA-1.5/Mk-0.9 for ); Tue, 28 Sep 1993 12:48:55 +0100 Received: by alba.udac.uu.se (5.0/SMI-SVR4) id AA04143; Tue, 28 Sep 93 12:44:19 +0100 Date: Tue, 28 Sep 93 12:44:19 +0100 From: Martin.Wendel@udac.uu.se (Martin Wendel) Message-Id: <9309281144.AA04143@alba.udac.uu.se> To: nordpost@nada.kth.se Subject: Re: MIME-gateway X-Sun-Charset: US-ASCII Content-Length: 2630 X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*246 > Jag tycker inte att subject-raden {r lyckad alls f|r detta {ndam}l! Eftersom > den kan editeras av den som svarar kan den mycket v{l bli modifierad p} ett > s{tt som g|r att omkodning/icke-omkodning blir helt fel! (Du skriver f|rresten > omv{xlande "header" och "subject" - {r det samma rad du menar?) Urs{kta, det blev fel. Subject skall det vara. (Jag fick rusa till ett m|te och hann inte korrekturl{sa). Syftet med att ha kontrolltecknen f|rst {r just att svar p} utskick ofta prefixar subject med ett "Re:". Detta deaktiverar kontrolltecknen, vilket ocks} {r meningen. Att |verhuvudtaget anv{nda n}gon form av kontrolltecken i subject-raden {r ju att ge anv{ndare som anv{nder icke-MIME klienter m|jlighet att fr}ng} den f|rvalda teckenkoden. Hela diskussionen handlar om vad som skall g{lla f|r icke-MIME anv{ndare n{r man anv{nder andra teckenkoderna {n de f|rvalda. > Jag tycker mycket illa om system som "meranv{nder" f{lt f|r helt andra saker > {n de {r avsedda f|r fr}n b|rjan. Framf|r allt f|r icke-datorvana (l{s: icke- > freaks!) {r s}dant h{r ytterst f|rvirrande. Jag h}ller kontakt via datorpost > med ett stort antal datoranv{ndare vid universitet och h|gskolor, den absoluta > lejonparten av dem icke det minsta programmeringskunniga (eller ens intresse- > rade). F|r dem {r rubriken "Subject" helt begriplig och logisk som ett f{lt > som motsvarar {rendemeningen i ett vanligt dokument. Jag vet inte om du har l{st Olles inl{gg fr}n den 9/14 juni. Anledningen till att anv{nda just subjectraden {r att denna {r den enda rad m}nga klienter till}ter anv{ndaren att skriva den h{r typen av information p}. Har du n}got b{ttre f|rslag {r jag intresserad. > Du kan ALDRIG f} dem att > begripa eller {n mindre acceptera att b|rjan av {rendemeningen {r n}got > tekniskt hokuspokus, som dessutom g|r att det praktiskt tillg{ngliga utrymmet > f|r egen {rendemening (som {r det som syns i startbilden p} Elm, Eudora etc) > krymper till n}got oanv{ndbart. Alternativen {r att l}ta anv{ndaren l{gga till ytterligare en header-rad, vilket torde vara om|jligt i de flesta fall, eller naturligtvis det |nskv{rda att uppdatera deras elm med MIME-patcharna och eudora till 1.4 (2.0). ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From owner-nordpost@nada.kth.se Sat Oct 2 12:58:15 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA05688; Sat, 2 Oct 93 12:58:18 +0100 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA05671; Sat, 2 Oct 93 12:58:15 +0100 Received: from ester.dsv.su.se by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA28240; Sat, 2 Oct 93 12:58:14 +0100 X400-Received: by /PRMD=SUNET/ADMD=_/C=SE/; Relayed; 02 Oct 93 12:51:04+0100 Date: 02 Oct 93 12:51:04+0100 From: Jacob Palme DSV Message-Id: <419738*jpalme@su-kom.dsv.su.se> In-Reply-To: To: Christer Welam , nordpost@nada.kth.se, Nordpost - diskussion om elektronisk post i Nordunett Subject: Re: MIME-gateway Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*247 Varf|r skall _avs{ndaren_ av ett meddelande beh|va specificera n}gon konvertering av det? Det r{cker v{l med att avs{ndaren anger vilken teckenstandard meddelandet {r skrivet av, och f|r det finns det ju MIME- standard. Sedan {r det mottagaren som beh|ver styra konvertering, i de fall d} mottagaren inte kan ta emot den teckenstandard som meddelandet {r skrivet i. Om avs{ndaren inte har MIME-kompatibel mailer, s} f}r man anta att det avs{ndaren skriver {r i IA5 (=7-bits ASCII) eller i n}gon nationell variant av detta. Det finns d} ett behov f|r en s}dan anv{ndare att ange vilken nationell variant av IA5 som hans meddelande {r skrivet i. Och om hans mailer inte {r MIME-kompatibel, vill eller kan han troligen inte editera meddelandets huvud. [r det det som denna diskussion handlar om? Hur en avs{ndare som inte har MIME-kompatibel mailer skall ange vilken tecken- standard hans meddelande {r skrivet i. Kan inte detta anges i f|rsta raden p} texten av meddelandet, genom n}gon av texterna: Character set: IA5 Swedish general Character set: IA5 Swith name Character set: IA5 international Character set: ISO 8859-1 Man skulle kunna till}ta {ven svenska varianter av ovanst}ende satser: Teckenstandard: Svensk allm{n Teckenstandard: Svenska namn Teckenstandard: Internationell IA5 Teckenstandard: Internationell ASCII Teckenstandard: ISO 8859-1 From owner-nordpost@nada.kth.se Sun Oct 3 11:21:22 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12179; Sun, 3 Oct 93 11:21:26 +0100 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12153; Sun, 3 Oct 93 11:21:22 +0100 Received: from ester.dsv.su.se by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09028; Sun, 3 Oct 93 11:21:12 +0100 X400-Received: by /PRMD=SUNET/ADMD=_/C=SE/; Relayed; 03 Oct 93 11:21:02+0100 Date: 03 Oct 93 11:21:02+0100 From: Jacob Palme DSV Message-Id: <419774*jpalme@su-kom.dsv.su.se> In-Reply-To: <419773*jpalme@su-kom.dsv.su.se> To: Martin Wendel , nordpost@nada.kth.se, Nordpost - diskussion om elektronisk post i Nordunett Subject: Re: MIME-gateway Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*248 En alternativ m|jlighet vore att l{gga denna rad sist i texten. F|rdel med detta {r att de som anv{nder mailsystem med signature- funktion kan l{gga in detta i signaturen, och slipper t{nka p} att skriva denna rad varje g}ng de s{nder ett brev. From owner-nordpost@nada.kth.se Sun Oct 3 11:21:22 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12216; Sun, 3 Oct 93 11:21:34 +0100 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12155; Sun, 3 Oct 93 11:21:22 +0100 Received: from ester.dsv.su.se by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09048; Sun, 3 Oct 93 11:21:21 +0100 X400-Received: by /PRMD=SUNET/ADMD=_/C=SE/; Relayed; 03 Oct 93 11:21:02+0100 Date: 03 Oct 93 11:21:02+0100 From: Jacob Palme DSV Message-Id: <419773*jpalme@su-kom.dsv.su.se> In-Reply-To: <9309281144.AA04143@alba.udac.uu.se> To: Martin Wendel , nordpost@nada.kth.se, Nordpost - diskussion om elektronisk post i Nordunett Subject: Re: MIME-gateway Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*249 Jag f|redrar att anv{ndaren l{gger till en rad f|rst i texten av sitt inl{gg, med n}got i stil med Teckenstandard: Svensk normal 7-bits Det {r mera klartext, mindre hokus-pokus. Och f|rsta raden i texten upprepas inte i kommentarer, vilket {r det r{tta, avsikten {r ju att tala om vilken teckenstandard som anv{nds i ett enda visst meddelande. Kommentaren skrivs kanske i ett annat system med annan teckenstandard. From owner-nordpost@nada.kth.se Sun Oct 3 11:41:51 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12336; Sun, 3 Oct 93 11:41:55 +0100 Received: from dkuug.dk by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12319; Sun, 3 Oct 93 11:41:51 +0100 Received: by dkuug.dk id AA15172 (5.65c8/IDA-1.4.4j for nordpost@nada.kth.se); Sun, 3 Oct 1993 11:40:37 +0100 Message-Id: <199310031040.AA15172@dkuug.dk> From: keld@dkuug.dk (Keld J|rn Simonsen) Date: Sun, 3 Oct 1993 11:40:37 +0100 In-Reply-To: Jacob Palme DSV "Re: MIME-gateway" (Oct 2, 12:58) X-Charset: ASCII X-Char-Esc: 29 Mime-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mnemonic-Intro: 29 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: nordpost@nada.kth.se, Christer Welam , Nordpost - diskussion om elektronisk post i Nordunett Subject: Re: MIME-gateway Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*250 Jacob Palme DSV writes: > Det finns d} ett behov f|r en s}dan anv{ndare att ange vilken > nationell variant av IA5 som hans meddelande {r skrivet i. Och > om hans mailer inte {r MIME-kompatibel, vill eller kan han troligen > inte editera meddelandets huvud. De fleste mailere kan automatisk generere bruger-specificerede headers, fx mime-headers. Det er saadan jeg laver MIME-headers nu. > [r det det som denna diskussion handlar om? Hur en avs{ndare > som inte har MIME-kompatibel mailer skall ange vilken tecken- > standard hans meddelande {r skrivet i. > > Kan inte detta anges i f|rsta raden p} texten av meddelandet, > genom n}gon av texterna: > > Character set: IA5 Swedish general > Character set: IA5 Swith name > Character set: IA5 international > Character set: ISO 8859-1 > > Man skulle kunna till}ta {ven svenska varianter av ovanst}ende > satser: > > Teckenstandard: Svensk allm{n > Teckenstandard: Svenska namn > Teckenstandard: Internationell IA5 > Teckenstandard: Internationell ASCII > Teckenstandard: ISO 8859-1 Der er allerede navne for dette registrerede til MIME brug, se RFC 1340 og RFC1345. Var det ikke bedre at bruge hvad der allerede er lavet fremfor at opfinde noget nyt? Keld From owner-nordpost@nada.kth.se Mon Oct 4 09:58:05 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA20475; Mon, 4 Oct 93 09:58:09 +0100 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA20456; Mon, 4 Oct 93 09:58:05 +0100 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA00404 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Mon, 4 Oct 1993 09:58:02 +0100 Received: from aquila.UDAC.UU.SE by solix.udac.uu.se with SMTP id AA23988 (5.67a8/IDA-1.5 for ); Mon, 4 Oct 1993 09:58:01 +0100 Received: from alba.udac.uu.se by aquila.udac.uu.se with SMTP id AA02760 (5.67a-Emil1.0/IDA-1.5 for ); Mon, 4 Oct 1993 09:59:50 +0100 Received: by alba.udac.uu.se (5.0/SMI-SVR4) id AA07044; Mon, 4 Oct 93 09:54:58 +0100 Date: Mon, 4 Oct 93 09:54:58 +0100 From: Martin.Wendel@udac.uu.se (Martin Wendel) Message-Id: <9310040854.AA07044@alba.udac.uu.se> To: nordpost@nada.kth.se Subject: Re: MIME-gateway X-Sun-Charset: US-ASCII Content-Length: 2722 X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*251 > [r det det som denna diskussion handlar om? Hur en avs{ndare > som inte har MIME-kompatibel mailer skall ange vilken tecken- > standard hans meddelande {r skrivet i. Exakt, jag ber om urs{kt om detta inte framgick klart. > Kan inte detta anges i f|rsta raden p} texten av meddelandet, > genom n}gon av texterna: > Om du vill att mottagaren sj{lv skall hantera avs{ndarens teckenkod {r det en l{mplig metod att just skriva in den teckenkod som anv{nds i sj{lva brevet. Detta likav{l som det {r trevligt att specificera vad f|r slags medskick man skickar med. D{remot kommer inte MIME-gatewayen att hantera denna information automatiskt eftersom den inte processar text p} annat s{tt {n genom teckenkonvertering. Om det {r s} att avs{ndarens mail-server {r konfigurerad att utf|ra viss konvertering kan det ocks} visa sig att informationen i b|rjan p} brevet inte st{mmer |verens med inneh}llet. Fr}gan g{ller allts} hur skall undantagen hanteras, dvs hur man skall ge de anv{ndare som anv{nder MIME-gatewayen frihet att styra hanteringen till n}got annat {n det f|rvalda, samt hur man skall ge de anv{ndare som inte anv{nder MIME-gatewayen m|jlighet att specificera vilken teckenkod de skriver sina brev i (om inte nationellt- eller site-f|rval g{ller). Det {r i detta perspektivet Olles f|rslag passar in. Headrar {r enkla att s|ka upp, och enkla att finna kommandostr{ngar i. I princip kan man t{nka sig att endast definiera ett kommando, s.k. pass-thru eller ingen konvertering, och i |vrigt |verl{mna }t anv{ndarna sj{lva att anv{nda ditt f|rslag, och att l}ta dem sj{lva utf|ra n|dv{ndig teckenkonvertering. Jag tror dock detta {r sv}rt, de som kan utf|ra egen teckenkonvertering {r inte i behov av g|ra den typ av undantag som diskussionen g{ller. De kan sj{lva konvertera r{tt fr}n b|rjan. Min sista inv{ndning mot Olles f|rslag g{llde om kommandostr{ngen skulle finnas i b|rja eller i slutet p} subject-raden. Eftersom jag f|rst nu ins}g att en direkt-reply skulle f} samma kommando sist p} subject-raden tycker jag det {r b{ttre att anv{nda b|rjan p} raden, och d{rigenom tvinga alla avs{ndare att specificera undantag om s}dana skall ske (ist{llet f|r att undantag specificeras omedvetet). Sen h}ller jag med Keld om att registrerade teckenkodsnamn skall anv{ndas. ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From owner-nordpost@nada.kth.se Mon Oct 4 11:20:55 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA21634; Mon, 4 Oct 93 11:20:59 +0100 Received: from baal.efd.lth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA21617; Mon, 4 Oct 93 11:20:55 +0100 Received: from baal by baal.efd.lth.se with smtp (perl jhmail 0.20) id 2caff7d5_1cb9_1 ; Mon, 4 Oct 1993 11:15:49 MET Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Date: Mon, 04 Oct 1993 11:15:46 MET From: =?iso-8859-1?Q?J=f6rgen_H=e4gg?= To: nordpost@nada.kth.se Cc: Martin Wendel , Nordpost - diskussion om elektronisk post i Nordunett In-Reply-To: Your message of "03 Oct 1993 11:21:02 MET." <419773*jpalme@su-kom.dsv.su.se> Subject: Re: MIME-gateway Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*252 In message <419773*jpalme@su-kom.dsv.su.se>you write: > >Jag f|redrar att anv{ndaren l{gger till en rad f|rst i texten >av sitt inl{gg, med n}got i stil med > >Teckenstandard: Svensk normal 7-bits Det vore nog, som du påpekade i ett tidigare brev, enklare för användaren att lägga det sist i brevet. Då kan man, som sagt, lägga in detta i sin signatur. Annars glömmer man nog :-). Å andra sidan är det enklare för konverteringsprogram att upptäcka det. Knepigt. Men det är bra mycket bättre än att lägga koder i Subject. -------- ---- Detta brev kan vara omvandlat till ISO 646SE. Berätta för mig om din brevläsare klarar MIME så slipper du denna omvandling. - Jörgen Hägg jh@efd.lth.se postmaster@efd.lth.se Telnr: 046-107492, 104013(fax) Snigelpost: Hämtställe 7, BOX 118, 221 00 LUND Lunds Tekniska Högskola Paket: E-huset, Ole Römers väg 3, 221 00 LUND Never eat more than you can lift. -- Miss Piggy From owner-nordpost@nada.kth.se Mon Oct 4 11:29:02 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA21875; Mon, 4 Oct 93 11:29:05 +0100 Received: from umdix.umdc.umu.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA21857; Mon, 4 Oct 93 11:29:02 +0100 Received: from puh.umdc.umu.se by umdix.umdc.umu.se with SMTP id AA15722 (5.65c/IDA-1.4.4 for ); Mon, 4 Oct 1993 11:31:05 +0100 Received: by puh.umdc.umu.se (/\==/\ Smail3.1.25.1 #25.7) id ; Mon, 4 Oct 93 11:28 MET Message-Id: From: Christer.Welam@umdac.umu.se (Christer Welam) Subject: Re: MIME-gateway To: nordpost@nada.kth.se Date: Mon, 4 Oct 1993 11:28:59 +0100 (MET) In-Reply-To: from "=?iso-8859-1?Q?J=f6rgen_H=e4gg?=" at Oct 4, 93 11:15:46 am X-Mailer: ELM [version 2.4 PL13] Content-Type: text Content-Length: 206 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*253 > > > Du har n}got annat knas (eller ocks} jag), f|r din From-rad ser ut s} h{r n{r den kommer till mig: =?iso-8859-1?Q?J=f6rgen_H=e4gg?= [r det n}got som har relevans f|r denna diskussion? Christer From owner-nordpost@nada.kth.se Mon Oct 4 12:48:10 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA23208; Mon, 4 Oct 93 12:48:15 +0100 Received: from baal.efd.lth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA23187; Mon, 4 Oct 93 12:48:10 +0100 Received: from baal by baal.efd.lth.se with smtp (perl jhmail 0.20) id 2cb00d61_1e27_1 ; Mon, 4 Oct 1993 12:47:46 MET Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Date: Mon, 04 Oct 1993 12:47:43 MET From: =?iso-8859-1?Q?J=f6rgen_H=e4gg?= To: nordpost@nada.kth.se In-Reply-To: Your message of "Mon, 04 Oct 1993 11:28:59 MET." Subject: Re: MIME-gateway Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*254 In message you write: > >Du har n}got annat knas (eller ocks} jag), f|r din From-rad ser ut s} >h{r n{r den kommer till mig: > >=?iso-8859-1?Q?J=f6rgen_H=e4gg?= Jag provar hur Sunos och ultrix klarar åttabitsgecos. Då man inte får skicka åttabitar i rubriker omvandlar min MTA alla rubriker enligt RFC 1342. Eftersom listan går via mail.nada.kth.se upptäckte min MTA detta och skickade åttabitsbrev i stället för att omvandla till ISO 646SE. (Mail.nada.kth.se klarar kommandot "ISOC 8859-1".) Dock skickas alla rubriker utan åttabitstecken. Uppenbarligen saknas konvertering av 1342 till svensk ascii på mail.nada.kth.se. >[r det n}got som har relevans f|r denna diskussion? Ja, det har det säkert. RFC 1342 måste ingå i en brevkonverterare. -------- ---- Detta brev kan vara omvandlat till ISO 646SE. Berätta för mig om din brevläsare klarar MIME så slipper du denna omvandling. - Jörgen Hägg jh@efd.lth.se postmaster@efd.lth.se Telnr: 046-107492, 104013(fax) Snigelpost: Hämtställe 7, BOX 118, 221 00 LUND Lunds Tekniska Högskola Paket: E-huset, Ole Römers väg 3, 221 00 LUND This limerick is **SO**FILTHY** that it would offend you. So I'll put "di-dah" for the filthy words: Di-dah, di-dah, di-dah di-dah, Di-dah di-dah di-dah, di-dah; di-dah di-dah di-dah? Di-dah di-dah di-dah. Di-dah di-dah, di-dah di-fuck. From psv@nada.kth.se Mon Oct 4 13:02:54 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA23499; Mon, 4 Oct 93 13:02:59 +0100 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA23479; Mon, 4 Oct 93 13:02:54 +0100 Message-Id: <9310041202.AA23479@nada.kth.se> To: nordpost@nada.kth.se Subject: Re: MIME-gateway In-Reply-To: Your message of "Mon, 04 Oct 1993 12:47:43 +0700." Date: Mon, 04 Oct 1993 13:02:53 +0100 From: Peter Svanberg Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*255 Citat ur brev från: Jörgen Hägg > Jag provar hur Sunos och ultrix klarar åttabitsgecos. > Då man inte får skicka åttabitar i rubriker omvandlar min MTA > alla rubriker enligt RFC 1342. Tips: Standarder kan byta RFC-nummer under utvecklingen. Bättre att använda namnet, "MIME del 2" i detta fall. (Den finns numera som RFC 1522!) > Eftersom listan går via mail.nada.kth.se upptäckte min MTA detta > och skickade åttabitsbrev i stället för att omvandla till ISO 646SE. > (Mail.nada.kth.se klarar kommandot "ISOC 8859-1".) > Dock skickas alla rubriker utan åttabitstecken. > > Uppenbarligen saknas konvertering av 1342 till > svensk ascii på mail.nada.kth.se. Visst! Varken Sendmail eller brevlistehanteringsprogrammet (Procmail) på mail.nada.kth.se har någon MIME-kunskap f.n. Ja-svar på ISOC-frågan implicerar inget om MIME-kunnighet! (Detalj: Du har fel tidszon på dina brev: Mon, 04 Oct 1993 12:47:43 +0700.) --- Peter Svanberg, Nada, KTH From owner-nordpost@nada.kth.se Mon Oct 4 13:22:56 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24034; Mon, 4 Oct 93 13:22:59 +0100 Received: from baal.efd.lth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24017; Mon, 4 Oct 93 13:22:56 +0100 Received: from baal by baal.efd.lth.se with smtp (perl jhmail 0.20) id 2cb01591_1f11_1 ; Mon, 4 Oct 1993 13:22:41 MET Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Date: Mon, 04 Oct 1993 13:22:38 MET From: =?iso-8859-1?Q?J=f6rgen_H=e4gg?= To: nordpost@nada.kth.se In-Reply-To: Your message of "Mon, 04 Oct 1993 13:02:53 MET." <9310041202.AA23479@nada.kth.se> Subject: Re: MIME-gateway Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*256 In message <9310041202.AA23479@nada.kth.se>you write: > >Citat ur brev fr}n: J|rgen H{gg > >Tips: Standarder kan byta RFC-nummer under utvecklingen. B{ttre >att anv{nda namnet, "MIME del 2" i detta fall. (Den finns >numera som RFC 1522!) Ser man på. Men 1342 är egentligen inte del av MIME. Tydligen dags att uppdatera :-). >> Uppenbarligen saknas konvertering av 1342 till >> svensk ascii p} mail.nada.kth.se. > >Visst! Varken Sendmail eller brevlistehanteringsprogrammet >(Procmail) p} mail.nada.kth.se har n}gon MIME-kunskap f.n. Visst, inga klagomål. Problemet är egentligen att det finns brevklienter som maskar åttonde biten. Därför omvandlar jag alla brev enligt 1342. >Ja-svar p} ISOC-fr}gan implicerar inget om MIME-kunnighet! Helt riktigt. Dessutom skickas brevet som åttabitsbrev utan MIME-tillägg. (Förutom 1342-omvandlingen.) Det här ger ju anledning att fråga hur man ska hantera Dan-hackade sendmailprogram. Ska ISOC-frågan också medföra åttabitsrubriker? >(Detalj: Du har fel tidszon p} dina brev: >Mon, 04 Oct 1993 12:47:43 +0700.) Hoppsan. Så kan det gå med ny programvara :-) -------- ---- Detta brev kan vara omvandlat till ISO 646SE. Berätta för mig om din brevläsare klarar MIME så slipper du denna omvandling. - Jörgen Hägg jh@efd.lth.se postmaster@efd.lth.se Telnr: 046-107492, 104013(fax) Snigelpost: Hämtställe 7, BOX 118, 221 00 LUND Lunds Tekniska Högskola Paket: E-huset, Ole Römers väg 3, 221 00 LUND Anxiety, n.: The first time you can't do it a second time. Panic, n.: The second time you can't do it the first time. From owner-nordpost@nada.kth.se Sat Oct 23 13:48:51 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA05803; Sat, 23 Oct 93 13:48:55 +0100 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA05784; Sat, 23 Oct 93 13:48:51 +0100 Received: from ester.dsv.su.se by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12399; Sat, 23 Oct 93 13:48:42 +0100 X400-Received: by /PRMD=SUNET/ADMD=_/C=SE/; Relayed; 23 Oct 93 13:41:04+0100 Date: 23 Oct 93 13:41:04+0100 From: Jacob Palme DSV Message-Id: <445279*jpalme@su-kom.dsv.su.se> To: nordpost@nada.kth.se Subject: Svensk terminologi inom omr}det "elektronisk post" Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*257 Jag var f|r ett par dagar sedan p} ett m|te vid ITS (Informationstekniska Standardiseringen i Sverige) f|r att utarbeta ordbok inom omr}det elektronisk post. Nedan citerar jag bara n}gra ord, som {r speciellt kontroversiella, f|r att h|ra om n}gon annan har n}gon annan }sikt. Likas} {r det givetvis intressant vad man anv{nder f|r ord p} danska och norska. Engelsk term: administration management domain Svensk term: allm{n dom{n Engelsk term: non-repudiation of origin Svensk term: oavvislighet av ursprung Engelsk term: bulletin board system, BBS Engelsk definition: Computer conference system and database of stored information Svensk term: BBS Engelsk term: distribution list Engelsk synonym: mailing list Svensk term: distributionslista Engelsk term: domain defined attribute Svensk term: distriktsattribut Sv synonym: DDA Engelsk term: electronic mail Svensk term: elektronisk post Anm{rkning: Vi hade en l}ng diskussion om ordet "datorpost" men detta ans}gs ej acceptabelt d} postverket s{ljer en tj{nst med namnet "datorpost" som {r n}got annat {n det vi menar med elektronisk post Engelsk term: message Svensk term: f|rs{ndelse Anm{rkning: Vi hade l}ng diskussion mellan orden "meddelande" och "f|rs{ndelse". "F|rs{ndelse" {r ett adekvatare ord, men "meddelande" {r kanske redan s} inarbetat att det {r l|nl|st att bek{mpa det. Engelsk term: proof of delivery Svensk term: leveransbevis Engelsk term: non-repudiation of delivery Svensk term: Oavvisligt leveransbevis Engelsk term: blind copy recipient Svensk term: hemlig k{nnedomsmottagare Engelsk term: interpersonal message Svensk term: person-till-person-meddelande Varf|r inte "person-till-person-f|rs{ndelse"? From owner-nordpost@nada.kth.se Sat Oct 23 17:53:03 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA07467; Sat, 23 Oct 93 17:53:07 +0100 Received: from Nomina.lu.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA07450; Sat, 23 Oct 93 17:53:03 +0100 Received: from Gemini.ldc.lu.se by nomina.lu.se with SMTP (5.65/IDA-1.2.8) id AA19874; Sat, 23 Oct 93 17:54:05 +0100 Date: Sat, 23 Oct 93 17:54 +0100 From: Jan Engvald LDC Subject: Re: Svensk terminologi inom omr}det "elektronisk post" To: nordpost@nada.kth.se Message-Id: X-Envelope-To: nordpost@nada.kth.se X-Vms-To: IN%"nordpost@nada.kth.se" X-Vms-Cc: XJELDC Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*258 >Engelsk term: electronic mail >Svensk term: elektronisk post >Anm{rkning: Vi hade en l}ng diskussion om ordet "datorpost" men >detta ans}gs ej acceptabelt d} postverket s{ljer en tj{nst med >namnet "datorpost" som {r n}got annat {n det vi menar med >elektronisk post Jag ser absolut inget sk{l att inte anv{nda ordet datorpost i alla fall. Inte skall v{l alla andra lida bara f|r att n}gon anv{nder det i annan betydelse. Ordet datorpost {r logiskt bildat, f|rst}s direkt av de flesta personer, och {r l{tt att s{ga. Elektronisk post {r b{ttre {n elpost, som jag ocks} sett anv{ndas, men datorpost {r det b{sta ordet. >Engelsk term: blind copy recipient >Svensk term: hemlig k{nnedomsmottagare Jag tycker det {r b{ttre med: dold mottagare (ev. dold k{nnedomsmottagare). Jan E LDC From owner-nordpost@nada.kth.se Mon Oct 25 08:21:28 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA23685; Mon, 25 Oct 93 08:21:31 +0100 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA23668; Mon, 25 Oct 93 08:21:28 +0100 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA29161 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Mon, 25 Oct 1993 08:21:26 +0100 Received: from alba.udac.uu.se by solix.udac.uu.se with SMTP id AA23468 (5.67a8/IDA-1.5 for ); Mon, 25 Oct 1993 08:21:25 +0100 Received: by alba.udac.uu.se (5.0/SMI-SVR4) id AA18576; Mon, 25 Oct 93 08:21:21 +0100 Date: Mon, 25 Oct 93 08:21:21 +0100 From: Martin.Wendel@udac.uu.se (Martin Wendel) Message-Id: <9310250721.AA18576@alba.udac.uu.se> To: nordpost@nada.kth.se Subject: Re: Svensk terminologi inom omr}det "elektronisk post" X-Sun-Charset: US-ASCII Content-Length: 1212 X-Charset: LATIN1 X-Char-Esc: 29 Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*259 > Engelsk term: bulletin board system, BBS > Engelsk definition: Computer conference system and database > of stored information > Svensk term: BBS > Jag har inget annat f|rslag utan bara en fr}ga: [r det klokt att v{lja en engelsk f|rkortning som svensk term? > Engelsk term: electronic mail > Svensk term: elektronisk post > Anm{rkning: Vi hade en l}ng diskussion om ordet "datorpost" men > detta ans}gs ej acceptabelt d} postverket s{ljer en tj{nst med > namnet "datorpost" som {r n}got annat {n det vi menar med > elektronisk post > Datorpost {r det inarbetade namnet, enligt min }sikt, och d{rf|r det mest l{mpade. Ett l{ngre alternativ kan vara datorf|rmedlad post. Elektronisk post {r f|r generellt f|r att vara en bra term (tex visst {r fax ocks} elektronisk post). ______________________________________________________________ E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC Domainmaster@UU.SE Martin Wendel Postmaster@UU.SE Box 174 Tel: 018 - 18 77 80 S-751 04 Uppsala Int: +46 18 18 77 80 SWEDEN Fax: +46 18 51 66 00 ______________________________________________________________ From owner-nordpost@nada.kth.se Mon Oct 25 09:16:17 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24329; Mon, 25 Oct 93 09:16:21 +0100 Received: from troll.efd.lth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24312; Mon, 25 Oct 93 09:16:17 +0100 Received: from efd.lth.se [130.235.51.10] (baal.efd.lth.se) by kobra.efd.lth.se with smtp (perl jhmail 0.20) id 2ccb8b45_6f22_1 ; Mon, 25 Oct 1993 09:16:05 MET Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Date: Mon, 25 Oct 1993 09:18:32 MET From: =?iso-8859-1?Q?J=f6rgen_H=e4gg?= To: nordpost@nada.kth.se In-Reply-To: Your message of "23 Oct 1993 13:41:04 MET." <445279*jpalme@su-kom.dsv.su.se> Subject: Re: Svensk terminologi inom omr}det "elektronisk post" Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*260 In message <445279*jpalme@su-kom.dsv.su.se>you write: > Misstänker att detta ord kommer att väcka debatt. :-) >Engelsk term: electronic mail >Svensk term: elektronisk post >Anm{rkning: Vi hade en l}ng diskussion om ordet "datorpost" men >detta ans}gs ej acceptabelt d} postverket s{ljer en tj{nst med >namnet "datorpost" som {r n}got annat {n det vi menar med >elektronisk post Visst är eletronisk post något bättre än datorpost, men datorpost är betydligt enklare och kortare. Har postverket kontaktats för en kommentar? Elektronisk post kan egentligen vara beteckning på allt mellan fax och datorpost. -------- ---- Detta brev kan vara omvandlat till ISO 646SE. Berätta för mig om din brevläsare klarar MIME så slipper du denna omvandling. - Jörgen Hägg jh@efd.lth.se postmaster@efd.lth.se Telnr: 046-107492, 104013(fax) Snigelpost: Hämtställe 7, BOX 118, 221 00 LUND Lunds Tekniska Högskola Paket: E-huset, Ole Römers väg 3, 221 00 LUND Q: How many IBM types does it take to change a light bulb? A: 100. Ten to do it, and 90 to write document number GC7500439-0001, Multitasking Incandescent Source System Facility, of which 10% of the pages state only "This page intentionally left blank", and 20% of the definitions are of the form "A ...... consists of sequences of non-blank characters separated by blanks". From owner-nordpost@nada.kth.se Mon Oct 25 09:20:55 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24407; Mon, 25 Oct 93 09:20:58 +0100 Received: from troll.efd.lth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24390; Mon, 25 Oct 93 09:20:55 +0100 Received: from efd.lth.se [130.235.51.10] (baal.efd.lth.se) by kobra.efd.lth.se with smtp (perl jhmail 0.20) id 2ccb8c54_6f42_1 ; Mon, 25 Oct 1993 09:20:36 MET Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Date: Mon, 25 Oct 1993 09:23:04 MET From: =?iso-8859-1?Q?J=f6rgen_H=e4gg?= To: ulf@efd.lth.se (Ulf Andersson) Cc: perf@nada.kth.se, ch@nada.kth.se In-Reply-To: Your message of "Sat, 23 Oct 1993 13:58:00 MET." Subject: Re: Keyclick, Ahrgghghgghl glubb... Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*261 In message you write: > > >Hejsan. > >Hur blir jag av med keyclick-oljudet? xset c off i .xinitrc. Men jag ska nog lägga in det generellt. Lustigt, den ska starta utan klick. Har du någon xset i dina filer? -------- Jörgen Hägg jh@efd.lth.se Systemansvarig för Linjenämnd EFD Telnr: 7492 Fax: 4013 Snigelpost: Hämtställe 7 Paket: E-huset, Ole Römers väg 3 Bureaucrat, n.: A politician who has tenure. From owner-nordpost@nada.kth.se Mon Oct 25 09:24:22 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24476; Mon, 25 Oct 93 09:24:25 +0100 Received: from troll.efd.lth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24459; Mon, 25 Oct 93 09:24:22 +0100 Received: from efd.lth.se [130.235.51.10] (baal.efd.lth.se) by kobra.efd.lth.se with smtp (perl jhmail 0.20) id 2ccb8d22_6f56_1 ; Mon, 25 Oct 1993 09:24:02 MET Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Date: Mon, 25 Oct 1993 09:26:30 MET From: =?iso-8859-1?Q?J=f6rgen_H=e4gg?= To: Magnus Zall Cc: perf@nada.kth.se, ch@nada.kth.se In-Reply-To: Your message of "Sat, 23 Oct 1993 18:40:34 MET." Subject: Re: Voice mail Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*262 In message you write: > >Jag har fått email från en kompis. Det är en ljudfil med ett program som heter >"Audio Tool V3", som lär ingå i paketet Xwindows. Finns detta på skolan? Om >inte, finns det något sätt jag kan spela upp filen? Allt med 'Tool' låter som om det har med Open Windows att göra. (Open Windows finns dessutom inte installerat.) Paketet 'Xwindows' känner jag inte till, vad är det? Om du menar 'X Window System' så finns det inget som har med ljud att göra i fönstersystemet. -------- Jörgen Hägg jh@efd.lth.se Systemansvarig för Linjenämnd EFD Telnr: 7492 Fax: 4013 Snigelpost: Hämtställe 7 Paket: E-huset, Ole Römers väg 3 There was an old man of the port Whose prick was remarkably short. When he got into bed, The old woman said, "This isn't a prick; it's a wart!" From owner-nordpost@nada.kth.se Mon Oct 25 09:26:24 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24550; Mon, 25 Oct 93 09:26:27 +0100 Received: from troll.efd.lth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24533; Mon, 25 Oct 93 09:26:24 +0100 Received: from efd.lth.se [130.235.51.10] (baal.efd.lth.se) by kobra.efd.lth.se with smtp (perl jhmail 0.20) id 2ccb8d87_6f64_1 ; Mon, 25 Oct 1993 09:25:43 MET Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 25 Oct 1993 09:28:10 MET From: =?iso-8859-1?Q?J=f6rgen_H=e4gg?= To: knsri@iitk.ernet.in In-Reply-To: Your message of "Sat, 23 Oct 1993 23:30:17 MET." <9310231802.AA08117@iitk.ernet.in> Subject: Re: Request for E-mail of Professors in Power System Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*263 In message <9310231802.AA08117@iitk.ernet.in>you write: > >I have not yet heard anything in this connection. Please help. > Sorry, I don't remember what you requested. (My mailflow is about a hundred letter a day. :-) -------- Joergen Haegg jh@efd.lth.se System manager @ efd Phone: international +46 46 107492 Lund Institute of Technology Snailmail: DDG, Maildelivery 7, BOX 118 Fax: +46 46 104013 S-221 00 LUND, Sweden For every credibility gap, there is a gullibility fill. -- R. Clopton From owner-nordpost@nada.kth.se Mon Oct 25 09:27:32 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24634; Mon, 25 Oct 93 09:27:35 +0100 Received: from troll.efd.lth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24616; Mon, 25 Oct 93 09:27:32 +0100 Received: from efd.lth.se [130.235.51.10] (baal.efd.lth.se) by kobra.efd.lth.se with smtp (perl jhmail 0.20) id 2ccb8dd4_6f7d_1 ; Mon, 25 Oct 1993 09:27:00 MET Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Date: Mon, 25 Oct 1993 09:29:28 MET From: =?iso-8859-1?Q?J=f6rgen_H=e4gg?= To: e87gs@efd.lth.se (Goeran Svensson) In-Reply-To: Your message of "Sun, 24 Oct 1993 12:40:00 MET." Subject: Re: Mac-arkivet forsvunnet? Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*264 In message you write: > >Hej! > >Forr i varlden kunde man na mac-arkivet genom lampligt directorybyte >fran sin hemkatalog. Gor man pa samma satt nu hittar man bara ett tomt >bibliotek. Vad ar hemligheten? Kor man ftp till lth.se funkar det bra. Visst, har du provat /n/mac_arch? -------- Jörgen Hägg jh@efd.lth.se Systemansvarig för Linjenämnd EFD Telnr: 7492 Fax: 4013 Snigelpost: Hämtställe 7 Paket: E-huset, Ole Römers väg 3 Signs of crime: screaming or cries for help. -- from the Brown Security Crime Prevention Pamphlet From owner-nordpost@nada.kth.se Mon Oct 25 09:44:56 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24981; Mon, 25 Oct 93 09:44:58 +0100 Received: from troll.efd.lth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24964; Mon, 25 Oct 93 09:44:56 +0100 Received: from efd.lth.se [130.235.51.10] (baal.efd.lth.se) by kobra.efd.lth.se with smtp (perl jhmail 0.20) id 2ccb91fc_6fee_1 ; Mon, 25 Oct 1993 09:44:44 MET Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Date: Mon, 25 Oct 1993 09:47:10 MET From: =?iso-8859-1?Q?J=f6rgen_H=e4gg?= To: nordpost@nada.kth.se Subject: Hoppsan! Errors-To: owner-nordpost@nada.kth.se Reply-To: nordpost@nada.kth.se Sender: owner-nordpost@nada.kth.se X-Mailing-List: Datorpostteknik i Norden*265 Ber om ursäkt för allt skräp. Pinsamt programfel. Min MTA ackumulerade utgående adresser. Numera fixat. -------- ---- Detta brev kan vara omvandlat till ISO 646SE. Berätta för mig om din brevläsare klarar MIME så slipper du denna omvandling. - Jörgen Hägg jh@efd.lth.se postmaster@efd.lth.se Telnr: 046-107492, 104013(fax) Snigelpost: Hämtställe 7, BOX 118, 221 00 LUND Lunds Tekniska Högskola Paket: E-huset, Ole Römers väg 3, 221 00 LUND Serving coffee on aircraft causes turbulence. From owner-nordpost@nada.kth.se Mon Oct 25 11:32:41 1993 Received: by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA26445; Mon, 25 Oct 93 11:32:45 +0100 Received: from columba.UDAC.UU.SE by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA26425; Mon, 25 Oct 93 11:32:41 +0100 Received: from solix.udac.uu.se by columba.udac.uu.se with SMTP id AA00980 (5.65c8/IDA-1.4.4 for nordpost@nada.kth.se); Mon, 25 Oct 1993 11:32:39 +0100 Received: from [130.238.129.140] (macs105c.udac.uu.se) by solix.udac.uu.se with SMTP id AA25346 (5.67a8/IDA-1.5 for ); Mon, 25 Oct 1993 11:32:35 +0100 Message-Id: