PROXY  WHOIS  RQUOTE  TEXTS  SOFT  FOREX  BBOARD
 Music  Philosophy  Code  Literature  Russian

= ROOT|Technical|RFC|rfc2049.txt =

page 2 of 14



   available media types, nor that they will all share the same
   extensions.  In order to promote interoperability, however, it is
   useful to define the concept of "MIME-conformance" to define a
   certain level of implementation that allows the useful interworking
   of messages with content that differs from US-ASCII text.  In this
   section, we specify the requirements for such conformance.








 
RFC 2049                    MIME Conformance               November 1996


   A mail user agent that is MIME-conformant MUST:

    (1)   Always generate a "MIME-Version: 1.0" header field in
          any message it creates.

    (2)   Recognize the Content-Transfer-Encoding header field
          and decode all received data encoded by either quoted-
          printable or base64 implementations.  The identity
          transformations 7bit, 8bit, and binary must also be
          recognized.

          Any non-7bit data that is sent without encoding must be
          properly labelled with a content-transfer-encoding of
          8bit or binary, as appropriate.  If the underlying
          transport does not support 8bit or binary (as SMTP
          [RFC-821] does not), the sender is required to both
          encode and label data using an appropriate Content-
          Transfer-Encoding such as quoted-printable or base64.

    (3)   Must treat any unrecognized Content-Transfer-Encoding
          as if it had a Content-Type of "application/octet-
          stream", regardless of whether or not the actual
          Content-Type is recognized.

    (4)   Recognize and interpret the Content-Type header field,
          and avoid showing users raw data with a Content-Type
          field other than text.  Implementations  must be able
          to send at least text/plain messages, with the
          character set specified with the charset parameter if
          it is not US-ASCII.

    (5)   Ignore any content type parameters whose names they do
          not recognize.

    (6)   Explicitly handle the following media type values, to
          at least the following extents:

          Text:

            -- Recognize and display "text" mail with the
            character set "US-ASCII."

            -- Recognize other character sets at least to the
            extent of being able to inform the user about what
            character set the message uses.







 
RFC 2049                    MIME Conformance               November 1996


            -- Recognize the "ISO-8859-*" character sets to the
            extent of being able to display those characters that
            are common to ISO-8859-* and US-ASCII, namely all
            characters represented by octet values 1-127.

            -- For unrecognized subtypes in a known character
            set, show or offer to show the user the "raw" version
            of the data after conversion of the content from
            canonical form to local form.

            -- Treat material in an unknown character set as if
            it were "application/octet-stream".

          Image, audio, and video:

            -- At a minumum provide facilities to treat any
            unrecognized subtypes as if they were
            "application/octet-stream".

          Application:

            -- Offer the ability to remove either of the quoted-
            printable or base64 encodings defined in this
            document if they were used and put the resulting
            information in a user file.

=2=

1| < PREV = PAGE 2 = NEXT > |3|4|5|6|7|8|9|10|11.14

UP TO ROOT | UP TO DIR | TO FIRST PAGE

Google
 


E-mail Facebook Google Digg del.icio.us BlinkList Fark Furl Ma.gnolia Netscape NewsVine Reddit Slashdot Spurl StumbleUpon Technorati YahooMyWeb LiveJournal Blogmarks TwitThis Live News2.ru BobrDobr.ru Memori.ru MoeMesto.ru

0.0220561 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)