home *** CD-ROM | disk | FTP | other *** search
/ Magazyn WWW 1998 October / www_10_1998.iso / info / ogonki / myszka.txt < prev    next >
Internet Message Format  |  1998-09-09  |  9KB
  1. Date: Mon, 19 Aug 1996 21:06:34 +0200
  2. From: Wojciech Myszka <myszka@norka.immt.pwr.wroc.pl>
  3.  
  4. 1.   Jest bardzo wiele standard≤w kodowania znak≤w w komputerach pracu-
  5.    j▒cych  w Internecie (inaczej ma DOS,  inaczej Windows,  MAC,  Amiga
  6.    i Unix).
  7.  
  8. 2.   Zasad▒ u┐ywan▒  podczas przesy│ania  poczty elektronicznej powinno
  9.    byµ, ┐e pisana jest przy u┐yciu narzΩdzi i zestawu font≤w dostΩpnych
  10.    lokalnie.
  11.  
  12. 3.  Aby taka przesy│ka mog│a byµ odebrana poprawnie u odbiorcy,  trzeba
  13.    zapewniµ dwie rzeczy:
  14.  
  15.    + wszystkie znaki przejd▒ niezniekszta│cone przez system poczty,
  16.    + odbiorca znajdzie w nag│≤wkach przesy│ki informacjΩ o sposobie
  17.      jej zakodowania (┐eby wiedzia│ jakich przestawie± ma dokonywaµ).
  18.  
  19. 4. Do osi▒gniΩcia tego celu w Internecie obmy╢lono standard MIME. Po-
  20.    zwala on:
  21.  
  22.    + na przesy│anie znak≤w narodowych (czytaj o "niezerowym ≤smym
  23.      bicie") kana│ami poczty elektronicznej zgodnymi z SMTP;
  24.    + na przesy│anie dowolnej przesy│ki zawieraj▒cej dane "nietekstowe";
  25.    + zdefiniowanie typu przesy│anej wiadomo╢ci (zawarto╢ci przesy│ki)
  26.      - daje to mo┐liwo╢µ automatycznego uruchamiania odpowiedniej
  27.      aplikacji u odbiorcy w celu jej odczytania".
  28.  
  29. 5.   Zasady u┐ycia MIME  w poczcie okre╢laj▒  RFC 1521 "MIME (Multipur-
  30.    pose  Internet Mail Extensions) Part One:  Mechanisms for Specifying
  31.    and Describing the Format of Internet Message Bodies".
  32.  
  33.    RFC  1521 definiuje format  wiadomo╢ci (zasadniczo zgodny  z RFC 822
  34.    czy  precyzyjniej m≤wi▒c nie naruszaj▒cy RFC 822,  ale rozszerzony o
  35.    nowe  nag│≤wki),   sposoby  kodowania informacji  (BASE64  i Quoted-
  36.    Printable)  oraz spos≤b okre╢lania zawarto╢ci przesy│ki.  Definiuje
  37.    r≤wnie┐ zestaw   podstawowych typ≤w (Image, Audio, Video).
  38.  
  39.    W rozdziale 7.1.1 definiuje zestawy znak≤w, kt≤re mog▒ byµ u┐ywane
  40.    w przesy│kach MIME. S▒ to: us-ascii i iso-8859-x (0 < x < 10).
  41.  
  42.    Mo┐na powiedzieµ, ┐e ten dokument jest ju┐ stary, ale najnowsza jego
  43.    "wersja"   (czy  og≤lniej   draft  rfc,    kt≤ry  opisuje   pocztΩ
  44.    elektroniczna)  -  stanowisko  to podtrzymuje.   Mo┐na  znale╝µ  go
  45.    szukaj▒c pliku o nazwie draft-ietf-822ext-mime-hdrs-00.txt
  46.  
  47.    Oba  powy┐ej cytowane  dokumenty w identyczny  spos≤b formu│uj▒ kwe-
  48.    stiΩ u┐ywanych zestaw≤w znak≤w (cytuj▒ za draftem"):
  49.  
  50.         Beyond US-ASCII, an enormous proliferation of character
  51.         sets is possible. It is the opinion of the IETF working group
  52.         that a large number of character sets is NOT a good thing.
  53.         We would prefer to specify a SINGLE character set that can
  54.         be used universally for representing all of the world's
  55.         languages in Internet mail. Unfortunately, existing practice in
  56.         several communities seems to point to the continued use of
  57.         multiple character sets in the near future. For this reason, we
  58.         define names for a small number of character sets for which
  59.         a strong constituent base exists.
  60.  
  61.         The defined charset values are:
  62.             (1) US-ASCII - as defined in ANSI X3.4-1986 [US-ASCII].
  63.             (2) ISO-8859-X - where "X" is to be replaced, as necessary,
  64.                 for the parts of ISO-8859 [ISO-8859]. Note that the
  65.                 ISO 646 character sets have deliberately been omitted
  66.                 in favor of their 8859 replacements, which are the
  67.                 designated character sets for Internet mail. As of
  68.                 the publication of this document, the legitimate values
  69.                 for "X" are the digits 1 through 9.
  70.  
  71.         All of these character sets are used as pure 7bit or 8bit sets
  72.         without any shift or escape functions. The meaning of shift
  73.         and escape sequences in these character sets is not defined.
  74.         The character sets specified above are the ones that were
  75.         relatively uncontroversial during the drafting of MIME. This
  76.         document does not endorse the use of any particular cha-
  77.         racter set other than US-ASCII, and recognizes that the fu-
  78.         ture evolution of world character sets remains unclear. It is
  79.         expected that in the future, additional character sets will be
  80.         registered for use in MIME.
  81.  
  82.         Note that the character set used, if anything other than US-
  83.         ASCII, must always be explicitly specified in the Content-Type
  84.         field.
  85.  
  86.         No other character set name may be used in Internet mail
  87.         without the publication of a formal specification and its
  88.         registration with IANA, or by private agreement, in which case
  89.         the character set name must begin with "X-".
  90.  
  91.         Implementors are discouraged from defining new character
  92.         sets unless absolutely necessary.
  93.  
  94.    (Zwracam uwagΩ na pierwszy i ostatni ustΩp cytatu: autorzy normy
  95.    sugeruj▒ ┐ebu nie mno┐yµ byt≤w nad miarΩ :-))
  96.  
  97. 6.   W przypadku WWW  sprawa jest nieco  bardziej skomplikowana.  Chyba
  98.    ┐aden  z obowi▒zuj▒cych  dokument≤w nie  pisze nic  na temat zestawu
  99.    znak≤w  u┐ywanych przez protok≤│ http  (poza iso-8859-1 i us-ascii).
  100.  
  101.    W  bardzo wielu  miejscach znajduj▒  siΩ tam  natomiast odwo│ania do
  102.    standardu  MIME (przy  okre╢laniu typu  przesy│anego pliku  na przy-
  103.    k│ad).  St▒d,  wydaje siΩ,  ┐e mo┐na ekstrapolowaµ wszystkie zasady
  104.    MIME.
  105.  
  106.    I  rzeczywi╢cie w tym kierunku idzie draft opisuj▒cy wersje HTTP/1.1
  107.    (Dokument   zatytu│owany  Hypertext  Transfer  Protocol  -  HTTP/1.1
  108.    mo┐na   znale╝µ  w  wielu  archiwach  poszukuj▒c  pliku  o  nazwie
  109.    draft-ietf-http-v11-spec-05).
  110.  
  111.    Wsp≤│zale┐no╢ci  i  r≤┐nice  pomiΩdzy  RFC  1521  a  standardem HTTP
  112.    opisane s▒ w rozdziale 19.4 cytowanego dokumentu.
  113.    Dokument  bardzo wyra╝nie  wypowiada siΩ na  temat kwestii u┐ywanych
  114.    zestaw≤w znak≤w (rozdzia│ 3.4):
  115.  
  116.         Although HTTP allows an arbitrary token to be used as a
  117.         charset value, any token that has a predefined value within
  118.         the IANA Character Set registry MUST represent the
  119.         character set defined by that registry. Applications SHOULD
  120.         limit their use of character sets to those defined by the IANA
  121.         registry.
  122.  
  123.    Czy (rozdzia│ 3.7.1):
  124.  
  125.         The "charset" parameter is used with some media types to
  126.         define the character set (section 3.4) of the data. When no
  127.         explicit charset parameter is provided by the sender, media
  128.         subtypes of the "text" type are defined to have a default
  129.         charset value of "ISO-8859-1" when received via HTTP. Data in
  130.         character sets other than "ISO-8859-1" or its subsets MUST
  131.         be labeled with an appropriate charset value.
  132.  
  133.    I wreszcie w rozdziale 19.8.1:
  134.  
  135.         The following names should be added to the IANA character
  136.         set registry under the category "Preferred MIME name" and
  137.         this section deleted.
  138.  
  139.         "US-ASCII"
  140.         | "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
  141.         | "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
  142.         | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
  143.         | "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"
  144.         | "SHIFT_JIS" | "EUC-KR" | "GB2312" | "BIG5" | "KOI8-R"
  145.  
  146.     Definiuje on zestawy "preferowanych znak≤w MIME" przy czym ta
  147.     informacja ma byµ wpisana do "IANA character set registry", a wiΩc
  148.     jej znaczenie bΩdzie szersze ni┐ tylko dla HTTP.
  149.  
  150. 7.  Najgorzej jest chyba w przypadku NNTP (news≤w).  RFC opisuj▒cy jest
  151.    tak  stary, ┐e nawi▒zuje jedynie do RFC 822, z tym tylko, ┐e dopusz-
  152.    cza przesy│anie informacji "binarnych"... Ekstrapoluj▒c jednak dalsz▒
  153.    ewolucjΩ  rfc822,  sprawa wydaje  siΩ oczywista -  nale┐y u┐yµ MIME.
  154.  
  155. Na  koniec wreszcie  (poza sprawami  formalo-prawnymi je┐eli  tylko do-
  156. kumenty RFC - lub ich projekty - mo┐na nazwaµ prawem) pozostaj▒ kwestie
  157. czysto techniczne.
  158.  
  159. Ot≤┐  wydaje mi siΩ, ┐e z technicznego punktu widzenia, spraw▒ zasadni-
  160. cz▒  jest umieszczanie w standardowy spos≤b w "nag│≤wkach" przesy│anych
  161. dokument≤w informacji o u┐ytym zestawie znak≤w i typie przesy│ki. Tylko
  162. bowiem takie postΩpowanie daje odbiorcy sznsΩ na automatyczne przekodo-
  163. wanie otrzymanago dokumentu do lokalnego standardu wy╢wietlania i wyb≤r
  164. najlepszej aplikacji do jej obejrzenia.
  165.  
  166. Na koniec wreszcie pragnΩ wyraziµ przekonanie, ┐e firma Microsoft buduje
  167. oprogramowanie, kt≤re stara siΩ byµ zgodne z obowi▒zuj▒cymi standardami
  168. (w tym i MIME). A jedno co jej w tym przeszkadza to brak czasu i ograni-
  169. czone zasoby (┐e zacytujΩ wypowied╝ z FAQ grupy comp.mail.mime - pytanie
  170. 1.3.11 "Does Microsoft Mail support MIME?"):
  171.  
  172.         All current Microsoft Internet connectivity products are MIME
  173.         compliant, although somewhat eccentric in their behavior. Oddly
  174.         enough, the eccentric behavior is not because of Microsoft's
  175.         alleged goal to dominate the Internet with quasi-
  176.         proprietary protocols, nor is it out of ignorance. It's just a
  177.         matter of finite resources and tight delivery
  178.         schedules. Surprise.
  179.  
  180. (Carl S. Gutekunst <csg@clavinova.eng.sun.com> 20-Feb-1996)
  181.  
  182.