🚀 go-pugleaf

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?

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

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!

Osoba podpisana jako MF <noemail@nospam.noproblem.invalid>
w artykule <news:9a59debd-2900-db6d-bce5-ef4183d7edb9@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  uszer@pochta.onet.pl  (zamień miejscami z⇔h w adresie) 

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

> On Fri, 19 Mar 2021, MF wrote:
>
>> 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.
> [...]

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.

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

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..."

Osoba podpisana jako Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl>
w artykule <news:684067f8-86cf-2834-ba74-ac1ed9cab3ff@wsisiz.edu.pl> 
pisze:

> 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..."

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.

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

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 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.

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.

Osoba podpisana jako Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl>
w artykule <news:4be2b023-2118-399-825-d3e6bf6c8a1e@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.

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

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ę.