Vlákno názorů k článku Umnějí portáli česki? od Trader - Lupo, to vam tak často vypadávají autoři, že...

Metodou nepříliš populární, a to četbou příslušných specifikací. W3C ve specifikaci HTML 4.01 nijak nepreferuje standardní kódování a jako seznam kódování (a jejich jmen) zmiňuje registraturu IANA - a tam windows-1250 bohužel je. Takže windows-1250 je samozřejmě horší volba než ISO 8859-2, ale jeho použití na webu ničemu neodporuje.

Situace u e-mailu je zcela odlišná. RFC 2045 a 2049 zmiňují mezi povolenými kódováními pouze us-ascii a iso-8859-*. Takže v e-mailu opravdu nemá windows-1250 co dělat.

> RFC 2045 a 2049 zmiňují mezi povolenými kódováními pouze us-ascii a iso-8859-*.

promiňte, ale zdá se mi, že jste si to vyložil poněkud "k obrazu svému" ...

RFC 2045 jsem nečetl celé, ale nezdá se mi, že by problém konkrétních kódování řešilo - tím se zabývá až RFC 2046, které v sekci 4.1.2 jasně říká, že smí být použita pouze kódování
1. vyjmenovaná: us-ascii a iso-8859-1 až iso-8859-10 (mimochodem, pokud se nemýlím, teď máme už i iso-8859-11 až 15)
2. kódování registrovaná u IANA
3. stanovená soukromou dohodou a prefixovaná "X-"

RFC 2049 o žádných "povolených" kódováních nemluví - o zmíněných říká pouze to, že MIME-conformant mail user agent musí rozeznat us-ascii a iso-8859-* a že musí být schopen zobrazit znaky, které mají ascii a iso společné, tedy jmenovitě 1-127 ... z čehož nijak nevyplývá, že "conformant agent" nemůže ("nemá povoleno") používat něco jiného

výše uvedené podmínky se imho docela slušně shodují s požadavky html, nevidím nejmenší důvod, proč by iso-8859-2 měla mít v e-mailu větší přednost, než na webu ...

Takhle to tam ale také není, ta zmínka o kódováních registrovaných u IANA je docela dobře ukrytá a je formulována negativně, ne pozitivně. Rozhodně nejsou tyto tři varianty prezentovány jako rovnocenné, jak jste to pojal vy. U ISO kódování je pouze uvedeno, že je to ISO-8859-X, kde X reprezentuje jednotlivé části ISO-8859 s poznámkou, že v době vydání RFC je to 1-10. Jinak 2045 byl překlep, mělo to být 2046.

To, co musí umět convormant agent, je velmi podstatné. Když použiju ISO 8859-2, vím, že ho příjemce bude schopen zpracovat. Když použiju Windows 1250, je to ve hvězdách. To je pro mne dost podstatný rozdíl.

zmínka o IANA v RFC 2046 nijak ukryta není, dokonce je několikrát opakována ...
co se týče rovnocennosti variant (či "negativní formulace" kolem IANA), máte zčásti pravdu, první bod je nutno rozdělit na us-ascii, což je preferovaná znaková sada, a na iso8859-* - ty jsou pak opravdu na stejné úrovni, jako cokoliv u IANA nebo "X-"; mezi těmito zbývajícími případy není žádný upřednostněn - pokud se domníváte, že ano, prosím odcitujte mi pasáž, ze které tak usuzujete ...
poznámkou o ISO 8859-11 až 15 jsem chtěl naznačit právě ten fakt, že případný vznik dalších sad v této rodině je postaven na stejnou úroveň, jako registrace u IANA - prostě conforming agents nejsou tímto RFC nuceni s ISO 8859-x počítat nějak více než s čímkoliv jiným

ad RFC-2049
> Když použiju ISO 8859-2, vím, že ho příjemce bude schopen zpracovat.

to, že příjemce musí toto kódování znát a že musí být schopen zobrazit znaky shodné s us-ascii, nemá v praxi valného významu - chybějící písmena (nesjpíše ta s diakritikou) a znaky mohou obsah zcela znehodnotit - z tohoto hlediska mi přijde lepší, když v případě windows-1250 se k tomu klient bude chovat jako k binárním datům, nežli aby to v případě iso8859-x zmršil k nepoznání ... ale asi mi nepřísluší kritisovat jedno nepříliš šťastné ustanovení tohoto rfcčka; už dost odbíhám od tématu

spor vznikl okolo Vašeho tvrzení vyjádřeného ve dvou příspěvcích, pokusím se jej sesumírovat do věty "kódování windows-1250 není v emailu povoleno" - toto prostě pravda není

Jak to vidím já: jsou tam vyjmenovány definované znakové sady: v bodu 1 US-ASCII, v bodu 2 ISO-8859-*. Žádné další. Pak je tam jakési pojednání o tom, co to přesně znamená, a nakonec drobná zmínka, že se nesmí použít název znakové sady, který nebyl registrována u IANA, leda by to bylo na základě dvoustranné dohody (a pak musí začínat 'x-'). Jestli tohle klade ISO a windows-1250 na stejnou úroveň, pak asi neumím vůbec anglicky nebo každý čteme jiný dokument.

abychom si rozuměli, já čtu tohle: http://www.faqs.org/rfcs/rfc2046.html

pokud čtu dobře, nikde tam není zmínka, že definovaná znaková sada má přednost před sadou registrovanou nebo oboustranně smluvenou ...

naopak, je tam věta:
"This document does not endorse the use of any particular character set other than US-ASCII,"
kterou bych přeložil jako:
"Tento dokument nepropaguje použití jakékoliv konkrétní znakové sady jiné, nežli US-ASCII"
a ze které podle mě jasně vyplývá, že ISO-8859-*, jakožto sady jiné nežli US-ASCII, nejsou o nic více doporučeny (nebo schváleny či jak chcete "endorse" přeložit) nežli třeba právě windows-1250

Já ho čtu z IETF, ale verze je to nejspíš stejná. Jenže si všímám trochu jiných věcí. Takže vidím, že se tam také píše: A small number of standard character sets are, therefore, defined for Internet use in this document. The defined charset values are: (1) US-ASCII (zkráceno) (2) ISO-8859-X (zkráceno). Teprve o pár odstavců dál jsou zmíněny další dvě varianty, ale ne že by se měly nebo mohly používat, pouze že nic jiného se používat nesmí. Ale vzhledem ke specifickému pojetí slov must a should v RFC to nelze automaticky pokládat za schválení, že tyto znakové sady jsou v pořádku nebo dokonce na stejné úrovni jako US-ASCII nebo ISO-8859-X.

"další dvě varianty, ale ne že by se měly nebo mohly používat, pouze že nic jiného se používat nesmí." - pardon, ale neprotiřečíte si trochu? jestliže vybereme nějakou skupinu znakových sad a prohlásíme, že "nic jiného se používat nesmí", tak potom ta vybraná skupina nejspíše "by se mohla používat" (pokud ne, tak jsme zřejmě vybrali skupinu, ke které děláme opak, příliš široce, což je silně nelogické, ovšem nikoliv nemožné - ale v takovém případě by ještě v textu muselo být explicitně určeno, co z té vybrané skupiny se použít nesmí, což nikde řečeno není)
(ehm, jak si to po sobě čtu, mám pocit, že nejjednodušší by bylo nakreslit si množiny a ne plácat o "skupinách" :-)

dále mi není jasné, jakým způsobem mohla být slova "must" a "should" předefinována (imho i v RFC 2046 si zachovávají význam stejný, jako v jiných normativních textech), aby jejich NEpoužití dovolovalo Váš výklad textu (podotýkám, že tato slova v pasážích o výběru charsetu až na jednu vyjímku vůbec nejsou, a tou vyjímkou je "should" v odstavci o výběru "lowest common denominator", který se vůbec nezabývá tím, jestli je kódování definované, registrované nebo dohodnuté)

Vy opravdu nevidíte vůbec žádný rozdíl mezi tím, že jsou specifikovány definované znakové sady a způsobem, jakým jsou vymezeny ty ostatní? Proč tedy potom, podle vás, vůbec tu první skupinu výslovně jmenují? Vždyť tyto znakové sady byly registrovány u IANA už v době vydání dokumentu. Takže kdyby to bylo podle vás (tedy že by mezi US-ASCII/ISO-8859-* a ostatními registrovanými nebyl naprosto žádný rozdíl), vůbec by nebylo třeba je výslovně zmiňovat, protože spadají i do těch registrovaných.

Zmínku o významu slov must a should jsem uvedl proto, že pokud je něco striktně zakázáno, neznamená to automaticky, že cokoli jiného je povoleno nebo dokonce vhodné. To, že definice SMTP striktně zakazuje řádky delší než 998 znaků, také ještě neznamená, že řádek o délce 600 znaků je stejně v pořádku jako řádek o délce 60 znaků.

Chcete tedy říci, že záměrem autorů RFC 2046 bylo diskriminovat všechny jazyky, jejichž zápis si nevystačí se znaky pokrytými US-ASCII a rodinou ISO-8859, jenom proto, že pro účely textu zmínili existenci pouze těchto znakových sad? To snad ne ...

Šestisetznakový řádek je z technického hlediska naprosto stejně v pořádku, jako řádek šedesátiznakový. Není ale v pořádku z hlediska netikety. RFC 2822 jasně říká, že klient si musí poradit i s řádky delšími, než 78 znaků. Vaše pojetí významu slov by vedlo na rovnost "should" = "must", což je nesmysl.
Obdobně windows-1250 je v emailu z technického hlediska stejně v pořádku jako ISO-8859-2, rozdíl je opět v netiketě. Jak jsem již napsal, RFC 2046 kromě US-ASCII a výběru "lowest common denominator" nic explicitně neupřednostňuje ani slovy "must", ani "should"; pokud chcete namítnout, že to upřednostnění je implicitní, pak by z toho vyplývala výše zmíněná diskriminace "neISO" písem, což považuji za nepřípustné.

Ne. Jejich záměrem IMHO bylo, aby se používala US-ASCII tam, kde stačí. Kde nestačí, tam ISO 8859-X, a teprve když ani to není možné, sáhnout po jiné znakové sadě, a to pokud možno takové, která je registrovaná u IANA. Teprve kdyby ani to nebylo možné, použít (po předchozí dohodě) něco úplně jiného. To je postup, který považuji za naprosto logický a přirozený.

Mé pojetí neříká, že must = should. Mé pojetí říká, že should není jen nějaký nezávazný hint, který by byl na úrovni pouhé slušnosti. V úvodu je totiž jasně řečeno, že požadavky formulované jako should by měly být porušeny pouze v situacích, kdy k tomu máte hodně vážný důvod. Takže proto odmítám souhlasit s vaším názorem, že 600 znaků dlouhý řádek je úplně stejně v pořádku jako 60 znaků dlouhý řádek. Zrovna tak odmítám připustit, že cokoli není striktně zakázáno (must not), je automaticky v pořádku.

Souhlasím s Vámi v tom, že postup, který popisujete v prvním odstavci, je přirozený a logický. Není ovšem v onom RFCčku nijak vyžadován. Stejně tak, jako může být vážným důvodem porušení maximální délky řádku například citace dlouhé URL, tak mohou být pro někoho vážným důvodem k použití windows-1250 třeba české uvozovky, které v ISO-8859-2 chybí. Ale nepřu se o přirozenost a logiku, přu se o technickou stránku věci: Vy jste na začátku této diskuse tvrdil, že windows-1250 se použít nesmí, což není pravda. Konkrétně napsal jste "RFC 2045 a 2049 zmiňují mezi povolenými kódováními pouze us-ascii a iso-8859-*. Takže v e-mailu opravdu nemá windows-1250 co dělat." Nemluvíme přeci o schrödingerově kočce, ale o jasně rozhodnutelné věci se dvěma stavy, takže obrat Vašeho výroku "není povoleno" na "je zakázáno" nebo "nesmí se použít" si snad dovolit mohu.
Co se týče toho "should", teď říkáte, že takto dané požadavky porušeny být mohou, zatímco předtím jste k tématu tvrdil "pokud je něco striktně zakázáno, neznamená to automaticky, že cokoli jiného je povoleno". Tak tedy nově tvrdíte, že "nestriktní" (should místo must) zákaz porušen být může, zatímco předtím jste to popíral. (Jestli "automaticky" nebo "neautomaticky" je snad jedno, viz poznámka o determinističnosti výše.) Tak se rozhodněte ...
(Vaši poslední větu, která opět podporuje to starší citované stanovisko, úmyslně pomíjím, neboť pojem "v pořádku" je poněkud vágní a zahrneme-li do něj netiketu, lze s tou větou souhlasit.)

Pokud dlouhé URL považujete za vážný důvod, ospravedlňující překročení limitu 78 znaků na řádek, pak se velmi výrazně lišíme v pohledu na to, co je to vážný důvod. Jednak proto, že to lze velmi snadno vyřešit bez překročení 78 znaků, jednak proto, že si stejně nepomůžete, kdysi jsem někde viděl ukázku URL (ze stránek Microsoftu), které mělo kolem 11000 znaků - takže tam už byste to chtě nechtě řešit musel. Pod označením vážný důvod si představuji daleko významnější technické obtíže.

Dobrá, místo definovanými jsem napsal povolenými. Za tuto chybu se stydím, ale přesto trvám na tom, že v e-mailu nemá windows-1250 co dělat. Protože windows-1250 nepřináší nic, na co by nestačilo iso-8859-2 a jiná než definovaná kódování by měla být použita až tam, kde to bez nich nejde.

V dalším odstavci pak mícháte dvě naprosto nesouvisející věci. Za prvé: požadavky specifikované jako should mohou být porušeny - ovšem jen z vážných důvodů. V prvním odstavci jste ovšem názorně předvedl, že si frázi z vážných důvodů vykládáte jako kdykoli se mi to hodí, takže odtud asi bude pramenit ono nedorozumění. A pokud tento postoj nepřehodnotíte, asi se těžko dohodneme.

Druhá věc, a to mé tvrzení, že je-li něco zakázáno, není cokoli jiného automaticky povoleno, je naprosto přirozené a nijak nesouvisí s významem slova should. Hlavně mne vůbec nenapadlo, že tak prostá a přirozená myšlenka může být nepochopena a odmítnuta. Zkusím to demonstrovat na příkladu z reálného života: v silničním zákoně se píše, že je zakázáno vjet do ulice, kde je značka zákaz vjezdu. Má poznámka pak upozorňuje, že to automaticky neznamená, že mohu vjet do jakékoli ulice, kde ta značka není - jednoduše proto, že to může být zakázáno z mnoha jiných příčin. Pokud máte základní matematické vzdělání, shrnul bych to tak, že prostě obracíte implikaci. Vy si přečtete, větu, že (zjednodušeno) není-li název registrován u IANA, nesmí se použít (aniž by ... atd.) a vyložíte si ji tak, že je-li název registrován, může být použit bez jakýchkoli dalších omezení. Ale to ta věta přeci vůbec neříká.