Minimalne kodowanie w mailu - które RFC?

[Rafal Jankowski]

Hej, czy ktoś może kojarzy gdzie jest dokładnie napisane (co w sumie
powinno być logiczne), że powinno się stosować minimalne możliwe
kodowanie, które obejmuje wszystkie znaki w wiadomości czyli np. nie
stosujemy UTF-8, tam gdzie ISO-8859-2 wystarcza?

[MF]

RFC 2046 p. 4.1.2. Charset Parameter
___
/
In general, composition software should always use the "lowest common
denominator" character set possible. For example, if a body contains
only US-ASCII characters, it SHOULD be marked as being in the US-
ASCII character set, not ISO-8859-1, which, like all the ISO-8859
family of character sets, is a superset of US-ASCII. More generally,
if a widely-used character set is a subset of another character set,
and a body contains only characters in the widely-used subset, it
should be labelled as being in that subset. This will increase the
chances that the recipient will be able to view the resulting entity
correctly.
\___

Zwracam uwagę na użycie „should” – czyli nie jest to nakaz, a zalecenie.

--
MF

[Rafal Jankowski]

On Fri, 19 Mar 2021, MF wrote:

> RFC 2046 p. 4.1.2. Charset Parameter
> ___
> /
> In general, composition software should always use the "lowest common
> denominator" character set possible. For example, if a body contains
> only US-ASCII characters, it SHOULD be marked as being in the US-
> ASCII character set, not ISO-8859-1, which, like all the ISO-8859
> family of character sets, is a superset of US-ASCII. More generally,
> if a widely-used character set is a subset of another character set,
> and a body contains only characters in the widely-used subset, it
> should be labelled as being in that subset. This will increase the
> chances that the recipient will be able to view the resulting entity
> correctly.
> \___

Wielkie dzięki!

> Zwracam uwagę na użycie „should” – czyli nie jest to nakaz, a zalecenie.

Prawda, wiadomo jednak, że should w RFC mimo wszystko jest dość mocnym
słowem, zgodnie z rfc2119:

[...]
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
[...]

Tak czy inaczej dzięki!

[Andrzej P. Wozniak]

Osoba podpisana jako MF <noe...@nospam.noproblem.invalid>
w artykule <news:9a59debd-2900-db6d...@komp.wujka.marcina>
pisze:

> On 19/03/2021 10:30, Rafal Jankowski wrote:
>> Hej, czy ktoś może kojarzy gdzie jest dokładnie napisane (co w sumie
>> powinno być logiczne), że powinno się stosować minimalne możliwe
>> kodowanie, które obejmuje wszystkie znaki w wiadomości czyli np. nie
>> stosujemy UTF-8, tam gdzie ISO-8859-2 wystarcza?

Nie ma dokładnie takiego zalecenia.

> RFC 2046 p. 4.1.2. Charset Parameter
> ___
> /
> In general, composition software should always use the "lowest common
> denominator" character set possible. For example, if a body contains
> only US-ASCII characters, it SHOULD be marked as being in the US-
> ASCII character set, not ISO-8859-1, which, like all the ISO-8859
> family of character sets, is a superset of US-ASCII. More generally,
> if a widely-used character set is a subset of another character set,
> and a body contains only characters in the widely-used subset, it
> should be labelled as being in that subset. This will increase the
> chances that the recipient will be able to view the resulting entity
> correctly.
> \___
>
> Zwracam uwagę na użycie „should” – czyli nie jest to nakaz, a zalecenie.

RFC 2046 pochodzi z czasów, kiedy UTF-8 nie był kodowaniem zalecanym.
W XXI wieku wszystkie standardy zostały dostosowane do UTF-8 i obecnie
zalecenia są takie:
Deklarowany i kodowany 8-bitowo UTF-8 albo nic (czyli niedeklarowany
7-bitowy US-ASCII).
Pozostałe zestawy znaków, w tym cała seria iso-8859-x, poszły w odstawkę.

O ile mi wiadomo, nie przyjęło się deklarowanie języka (typowe dla
przeglądarek), które ułatwiałoby sprawę czytnikom ekranowym.

RFC mam szukać na gwałt czy może poczekać?

--
Andrzej P. Woźniak us...@pochta.onet.pl (zamień miejscami z⇔h w adresie)

[Andrzej P. Wozniak]

Osoba podpisana jako Rafal Jankowski <jank...@oceanic.wsisiz.edu.pl>
w artykule <news:24183fb5-5c9b-191b...@wsisiz.edu.pl>
pisze:

Przypominam, że w tym samym RFC2119 napisano też, że "MUST" należy używać
w ograniczonym zakresie, głównie wtedy, kiedy dotyczy to technicznej
strony zapewnienia komunikacji w ogóle. Stąd "SHOULD" jest traktowane jako
definicja standardu.
Poza tym w tekstach może się pojawiać "should" pisane normalnie, które
jest zwykłym sformułowaniem informacyjnym.

[Rafal Jankowski]

On Sat, 20 Mar 2021, Andrzej P. Wozniak wrote:

> RFC 2046 pochodzi z czasów, kiedy UTF-8 nie był kodowaniem zalecanym.
> W XXI wieku wszystkie standardy zostały dostosowane do UTF-8 i obecnie
> zalecenia są takie:
> Deklarowany i kodowany 8-bitowo UTF-8 albo nic (czyli niedeklarowany 7-bitowy
> US-ASCII).
> Pozostałe zestawy znaków, w tym cała seria iso-8859-x, poszły w odstawkę.

Ale skoro zmieniło się zalecenie i przestało to być obowiązujące to w
nagłówku tego RFC nie powinna się znaleźć informacja: "obsoleted by..."

[Andrzej P. Wozniak]

Osoba podpisana jako Rafal Jankowski <jank...@oceanic.wsisiz.edu.pl>

w artykule <news:684067f8-86cf-2834...@wsisiz.edu.pl>
pisze:

Jest przecież rfc-index, a w nim masz wszystko opisane (według bieżących
danych):

2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of
Internet Message Bodies. N. Freed, N. Borenstein. November 1996.
(Format: TXT, HTML) (Obsoletes RFC1521, RFC1522, RFC1590) (Updated
by RFC2184, RFC2231, RFC5335, RFC6532) (Status: DRAFT STANDARD)
(DOI: 10.17487/RFC2045)

2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.
N. Freed, N. Borenstein. November 1996. (Format: TXT, HTML)
(Obsoletes RFC1521, RFC1522, RFC1590) (Updated by RFC2646, RFC3798,
RFC5147, RFC6657, RFC8098) (Status: DRAFT STANDARD) (DOI:
10.17487/RFC2046)

2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message
Header Extensions for Non-ASCII Text. K. Moore. November 1996.
(Format: TXT, HTML) (Obsoletes RFC1521, RFC1522, RFC1590) (Updated
by RFC2184, RFC2231) (Status: DRAFT STANDARD) (DOI:
10.17487/RFC2047)

2048 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration
Procedures. N. Freed, J. Klensin, J. Postel. November 1996. (Format:
TXT, HTML) (Obsoletes RFC1521, RFC1522, RFC1590) (Obsoleted by
RFC4288, RFC4289) (Updated by RFC3023) (Status: BEST CURRENT
PRACTICE) (DOI: 10.17487/RFC2048)

2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance
Criteria and Examples. N. Freed, N. Borenstein. November 1996.
(Format: TXT, HTML) (Obsoletes RFC1521, RFC1522, RFC1590) (Status:
DRAFT STANDARD) (DOI: 10.17487/RFC2049)


Jest też plik RFCs_for_errata.txt, gdzie jest lista dokumentów z
poprawkami. Są w nim RFC2045, 2046, 2047 i 2049. Poprawki z wyjaśnieniem
są w podkatalogu inline-errata.

[Rafal Jankowski]

No dobrze, ale ja w dalszym ciągu nie rozumiem, który z ww dokumentów i w
którym miejscu unieważnia RFC 2046 w całości lub choćby w części p. 4.1.2.

[Andrzej P. Wozniak]

Osoba podpisana jako Rafal Jankowski <jank...@oceanic.wsisiz.edu.pl>

w artykule <news:4be2b023-2118-399...@wsisiz.edu.pl> pisze:

> On Sun, 21 Mar 2021, Andrzej P. Wozniak wrote:
>
>>> Ale skoro zmieniło się zalecenie i przestało to być obowiązujące to w
>>> nagłówku tego RFC nie powinna się znaleźć informacja: "obsoleted
>>> by..."

>> Jest też plik RFCs_for_errata.txt, gdzie jest lista dokumentów z
>> poprawkami. Są w nim RFC2045, 2046, 2047 i 2049. Poprawki z
>> wyjaśnieniem są w podkatalogu inline-errata.
>
> No dobrze, ale ja w dalszym ciągu nie rozumiem, który z ww dokumentów
> i w którym miejscu unieważnia RFC 2046 w całości lub choćby w części
> p. 4.1.2.

Nie rozumiesz słów "updates" i "errata", prawda? Nie "zastąpiony,
unieważniony", tylko "zaktualizowany, uzupełniony, poprawiony".
Przejrzałeś chociaż wszystkie wskazane RFC z tego wieku?

Nie mam teraz czasu, żeby odrabiać za kogoś lekcje, więc jakieś cytaty
mogę wrzucić najwcześniej po świętach.

Wyjaśniam sens ogólny:
1. Każdy zestaw znaków zawiera zestaw US-ASCII jako podzbiór. Dotyczy to
m.in. zestawów iso-8859-x i zestawu utf-8 (zawsze z kreską).
2. Oprócz tego cały zestaw iso-8859-1 (ale tylko ten z iso-8859-x) jest
zgodny pod względem numeracji znaków z zestawem utf-8, co daje możliwość
3. Zalecenie należy rozumieć jako zalecenie maksymalnej kompatybilności
wstecznej z pocztą sprzed MIME, a nie zalecenie minimalnego kodowania. To
samo zalecenie dotyczy też kodowania transportowego (ale to inna para
kaloszy).

Automatycznie i zawsze poprawnie można osiągnąć tylko przypadki opisane w
następnym zdaniu. Jeśli nie ma znaków 8-bitowych, tylko 7-bitowe us-ascii,
można tekst w dowolnym języku (bazującym na łacinie) wysłać bez
jakiejkolwiek deklaracji MIME. W szczególności dotyczy to przypadku
opisanego w cytowanym punkcie.

Ze względu na historię rozwoju Unikodu brak pełnej jednoznaczności
kodowania i dalej automagicznie nie da się zrobić już nic. Jeśli tekst w
UTF-8 zawiera tylko znaki z iso-8859-1, w większości przypadków można go
wysłać jako iso-8859-1 (mają zgodny początek tablicy znaków), ale nie
zawsze. W praktyce jedynym znakiem 8-bitowym może być znak "ó", który
występuje również w iso-8859-2, a wtedy automat nawala.

Oznacza to w najprostszym ujęciu, że w cytowanym punkcie zamiast
iso-8859-1 trzeba po prostu wstawić utf-8.

[Rafal Jankowski]

On Thu, 25 Mar 2021, Andrzej P. Wozniak wrote:

> Nie rozumiesz słów "updates" i "errata", prawda? Nie "zastąpiony,
> unieważniony", tylko "zaktualizowany, uzupełniony, poprawiony". Przejrzałeś
> chociaż wszystkie wskazane RFC z tego wieku?

> Nie mam teraz czasu, żeby odrabiać za kogoś lekcje, więc jakieś cytaty mogę wrzucić najwcześniej po świętach.

A "zaktualizowany, [...], poprawiony" objawia się czym? Chyba tym,
że stary fragment jest zastąpiony nowym. Zgadza się czy może się mylę?

Nie, nie przeglądałem wszystkich RFC z tego wieku dlatego zapytałem się
który rfc lub która errata lub cokolwiek innego zastępuje, uzupełnia lub
poprawia zacytowany fragment RFC 2046. Można odpowiedzieć, można nie
odpowiadać, a można się ciskać jak wesz w ukropie. Wybrałeś trzecią opcję,
Twoja sprawa.
Co do reszty zaleceń na temat kodowania nie polemizuję, pewnie masz rację.