[Olug-list] Medlemsskap

[Frode Gill]

(Ja, denne meldingen er sendt med utf-8. Beklager, men det er for =C3=A5 =
vise et=20
par av p=C3=A5standene mine. Hvis klienten din ikke st=C3=B8tter utf-8, o=
verse denne=20
meldingen, du vil neppe v=C3=A6re interessert i den uansett)

On Sat, 10 May 2003 15:00:03 +0200, Kjartan Kvassnes <kvassnes@netcom.no>=
=20
wrote:

> Hvis vi skal holde oss til s=C3=A5kalte "etablerte standarder", s=C3=A5=
 m=C3=A5 jeg nok=20
> innr=C3=B8mme at den mest sannsynlig er Amerikansk og ikke innehar st=C3=
=B8tte for=20
> =C3=A6, =C3=B8 og =C3=A5.

Eldre standarder forutsatte us-ascii, s=C3=A5 kom en periode der iso-8859=
-1=20
skulle gjelde hvis ikke noe annet var satt, og n=C3=A5 m=C3=A5 enhver ny =
standard=20
st=C3=B8tte utf-8. Problemet vi ser med mail (og usenet for den saks skyl=
d) er=20
at det bygges opp=C3=A5, og kreves kompatibilitet med, standarder som er =
over 20=20
=C3=A5r gamle (Den opprinnelige mailstandarden, RFC822, kom i 1982).


> Og n=C3=A5r det gjelder denne standarden alle snakker om, vil jeg gjern=
e se=20
> den. Det finnes fors=C3=A5vidt for news, men mail og news er ikke det s=
amme.=20
> Og jeg snakker om at jeg gjerne vil se en standard, ikke en RFC. RFCer =
er=20
> ikke standarder, selv om mange virker =C3=A5 tro det.

Siden jobben min er =C3=A5 lage en mailklient, blir jeg nok mer enn=20
gjennomsnittlig provosert av slike uttalelser. N=C3=A5r vi snakker om new=
s og=20
mail, er standardene absolutt definert i RFCer. Ikke alle RFCene blir=20
standarder, og ikke alt som brukes er definert i standard RFC (mye av=20
usenet bruker son-of-RFC1036 som de-facto standard. Denne har aldri tatt=20
steget opp til en egen standard RFC), men alt er absolutt bakoverkompatib=
el=20
til en standard definert i en RFC. Hvordan en mail skal se ut er definert=
 i=20
RFCer, og KUN RFCer. Opprinnelig RFC822, fornyet i RFC2822. RFC822=20
spesifiserte at alle header M=C3=85 v=C3=A6re 7-bit us-ascii. For =C3=A5 =
komme rundt=20
problemene med tegnsett brukes Mime-standarden (som ogs=C3=A5 innbefatter=
=20
Quoted-Printable og Base64), RFC2045-2049. Dette er standardene, og enhve=
r=20
mailklient som pr=C3=B8ver =C3=A5 sende noe som strider mot dette, vil si=
mpelthen=20
ikke fungere, mailserverene vil forkaste meldingene.
Problemet i nyere tid er at mange klienter forholder seg til alle disse=20
standardene, men likevel skaper mye kluss. HTML-mail startet vel hele den=
ne=20
tr=C3=A5den, og manglende st=C3=B8tte for tegnsett er ogs=C3=A5 nevnt. Me=
d HTML har man et=20
reelt valg. Enten sender man text/plain, text/html, eller begge deler.=20
Problemstillingen g=C3=A5r her p=C3=A5 hvem det er som skal velge present=
asjonen og=20
formateringen av informasjonen som sendes - senderen eller mottakeren (og=
 i=20
de fleste IT-milj=C3=B8er er det vedtatt at dette er mottakerens privileg=
ie).=20
N=C3=A5r det gjelder tegnsett er problemstillingen v=C3=A6rre. Stort sett=
 bruker jeg=20
iso-8859-15, men hvis jeg bruker tegn utenfor dette tegnsettet, f.eks hvi=
s=20
jeg siterer en overskrift fra www.sina.com.tw, "=E6=8A=97sars =E9=9A=94=E9=
=9B=A2=E9=81=8E=E9=A0=AD", er det ikke=20
fryktelig mange m=C3=A5tene =C3=A5 sette tegnsett til denne mailen p=C3=A5=
. En mulighet=20
hadde v=C3=A6rt =C3=A5 sende f=C3=B8rste delen av mailen i en multipart m=
ed tegnsettet=20
iso-8859-15, en multipart med den Taiwanske overskriften med tegnsett big=
5,=20
or resten av meldingen i nok en multipart med tegnsett iso-8859-15. Dette=
=20
kunne fort blitt *mange* parter, men mailklienter som kun st=C3=B8tter us=
-=20
ascii/iso-8859-1/iso-8859-15 ville kunne lese mesteparten av meldingen he=
lt=20
fint. Det andre alternativet er =C3=A5 sende meldingen med Content-Type:=20
charset=3D"utf-8". Enkelt, greit, helt standard, men eldre mail-klienter =
vil=20
ha problemer med tegn utenfor us-ascii - i Norge vil spesielt =C3=A6, =C3=
=B8 og =C3=A5 bli=20
vist som 3 rare tegn hver. Som du ser er mail med Content-Type: text/html=
=20
og underlige tegnsett helt greit if=C3=B8lge gjeldende standarder, men=20
problemene eksisterer like fullt. Derfor er det opp til mottakerene =C3=A5=
=20
bestemme seg for hva som gjelder. I privat korrespondanse er det lett =C3=
=A5 f=C3=A5=20
avsenderen til =C3=A5 endre oppsett (som regel er det Outlook Express-bru=
kere,=20
og de aner ikke at oppsettet deres skaper problemer), p=C3=A5 maillister =
f=C3=A5r det=20
defineres klare regler. P=C3=A5 denne listen ser jeg ingen grunn for text=
/html=20
og utf-8, og har derfor ingen motforestillinger mot =C3=A5 bannlyse begge=
 deler.


> S=C3=A5vidt meg bekjent, finnes mailstandarden bare spesifisert for hea=
dere i=20
> den grad det er s=C3=A5pass spesifisert, og en body der teksten g=C3=A5=
r.

En mail trenger ikke engang =C3=A5 ha en body. Les RFC822/RFC2822. (Ja, d=
et er=20
en standard)


> Hvis du i dag sitter p=C3=A5 en mailklient som ikke er i stand til =C3=A5=
 h=C3=A5ndtere=20
> de tekstformatene som brukes p=C3=A5 internett i dag, har du faktisk et=
=20
> problem. Det kan fungere godt p=C3=A5 et intranett, der alle sitter p=C3=
=A5 samme=20
> utstyr, men som alle vet er interopabilitet et het potet p=C3=A5 intern=
ett.

=C3=85 si at alle p=C3=A5 et intranett bruker samme utstyr er vel en kraf=
tig=20
overdrivelse. P=C3=A5 jobben min brukes en mengde forskjellige OS, og man=
ge=20
ulike mailklienter. Hva mailklienten din trenger av st=C3=B8tte er ogs=C3=
=A5 helt opp=20
til deg selv. St=C3=B8tter den ikke utf-8/big5/iso-2022-jp? Helt greit fo=
r=20
vanlige nordmenn. Har du derimot asiatiske venner eller kunder, er det=20
kritisk funksjonalitet. HTML-mail? Irrelevant, s=C3=A5 lenge det ikke er =
snakk=20
om at presentasjonen av meldingen er viktigere enn selve innholdet.=20
Personlig hater jeg det, men personer som sender meldinger der fontvalg,=20
farger, understrekning o.l er viktig, vil garantert foretrekke slikt.

--=20
Frode Gill