LISTSERV mailing list manager LISTSERV 15.5

Help for MHTML Archives


MHTML Archives

MHTML Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave MHTML
Reply | Post New Message
Search Archives


Subject: Re: Summary of decisions at the Montreal MHTML IETF meeting
From: Larry Masinter <[log in to unmask]>
Reply-To:IETF working group on HTML in e-mail <[log in to unmask]>
Date:Wed, 10 Jul 1996 20:48:08 PDT
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (376 lines)


>What we need is for someone to propose specific new text to replace
>the two sections on charsets and newlines.

I did, although it's not great... maybe I should make another pass at
it. I'm not sure what Jacob intends to do with my proposed edits.

================================================================
Date: 8 Jul 1996 23:42:24 -0700
To: [log in to unmask]
CC: [log in to unmask]
In-reply-to: <[log in to unmask]>
        (message from Jacob Palme on Mon, 8 Jul 1996 10:05:25 PDT)
Subject: Re: MHTML WG Minutes for WG review before IETF publication...
From: Larry Masinter <[log in to unmask]>

I found myself tempted to make much more wide-ranging edits to the
draft. I'm not clear that this is welcome, though.
Also Steve Zilles showed me a marked-up copy where lots of the
'HTML-centrism' part of the draft was fixed, so that it was clear that
the same mechanism would work for mailing PDF with embedded resources
too. However, the thing you mailed me doesn't seem to have those edits
applied. So, though I tried to do some of this (below), I think my
effort might be counter-productive.

I will volunteer to repropose edits whatever it is Jacob produces,
either using the enclosed edits or not.

================================================================
*** draft-ietf-mhtml-spec-01.txt        Mon Jul  8 15:28:22 1996
--- draft-ietf-mhtml-spec-01-lmm.txt    Mon Jul  8 23:37:09 1996
***************
*** 34,52 ****

  Abstract

! Although HTML was designed within the context of MIME, more than the
! specification of HTML as defined in RFC 1866 is needed for two electronic
  mail user agents to be able to interoperate using HTML as a document
! format. These issues include the naming of objects that are normally
! referred to by URIs, and the means of aggregating objects that go
! together. This memo describes a set of guidelines that will allow
  conforming mail user agents to be able to send, deliver and display these
! HTML objects. In addition it is hoped that these techniques will also
! apply to the wider category of URI-enabled objects. In order to do this,
! the memo introduces two new MIME content-headers with the names "Content-
! Location" and "Content-Base".

-
  Table of Contents

  1. Introduction       4
--- 34,48 ----

  Abstract

! Although HTML [RFC 1866] was designed within the context of MIME,
! in some cases, more is needed for two electronic
  mail user agents to be able to interoperate using HTML as a document
! format. Issues include the naming of objects that are normally
! referred to by URIs and the means of aggregating objects that go
! together. This document describes a set of guidelines that will allow
  conforming mail user agents to be able to send, deliver and display these
! HTML objects, as well as other objects that contain URIs.

  Table of Contents

  1. Introduction       4
***************
*** 107,125 ****
  1. Introduction

  The HTML format is a very common format for documents in the Internet, and
! there is an obvious need to be able to send documents in this format in e-
! mail [RFC821=SMTP, RFC822]. The "text/html; version=2.0" media type is
! defined in RFC 1866 [HTML2]. This memo gives additional specifications on
  how to use the text/html media type as a Content-Type in MIME [RFC
! 1521=MIME1] e-mail messages. In particular, the document discusses sending
! of HTML objects with embedded links to images and other data in separate
! objects which are to be displayed inline to the recipient.

- An alternative way for sending HTML documents in e-mail is to only send
- the URL, and let the recipient look up the document using HTTP. That
- method is described in [URLBODY] and is not described in this memo.
-
-
  2. Terminology

  2.1 Conformance requirement terminology
--- 103,118 ----
  1. Introduction

  The HTML format is a very common format for documents in the Internet, and
! there is an obvious need to be able to send documents in this format in
! e-mail [RFC821=SMTP, RFC822]. The "text/html" media type is
! defined in RFC 1866 [HTML2]. This document gives additional specifications on
  how to use the text/html media type as a Content-Type in MIME [RFC
! 1521=MIME1] e-mail messages. HTML documents commonly include links
! to other objects and resources, either embedded or directly accessible through hypertext links.
! When mailing a HTML document, it is often desirable to also mail all
! of the additional resources that are referenced in it; those elements
! are necessary for the complete interpretation of the HTML.

  2. Terminology

  2.1 Conformance requirement terminology
***************
*** 263,287 ****



! 3. Purpose

! Although HTML [RFC 1866=HTML2] is a valid MIME [RFC1521=MIME1, MIME2]
! type, RFC 1866 [HTML2] does not provide enough specification in order for
! two electronic mail user agents to be able to interoperate using HTML as a
! document format. This draft describes a set of guidelines that will allow
! conforming mail user agents to be able to send, deliver and display HTML
! objects. This standard only covers HTML objects containing URIs [RFC
! 1738=URL], but it is hoped that these techniques can also be used for
! other object formats containing URIs.
!
! An HTML aggregate object is a MIME-encoded message that contains an HTML
  document as well as other data that is required in order to represent that
! object (inline pictures, style sheets, applets, etc.). HTML aggregate
! objects can also include additional HTML documents that are linked to the
! first object, as well as other arbitrary MIME content.

! In designing HTML capabilities for electronic mail user agents (UAs), it
! is important to keep in mind the differing needs of several audiences.
  Mail sending agents might send aggregate HTML objects as an encoding of
  normal day-to-day electronic mail. Mail sending agents might also send
  aggregate HTML objects when a user wishes to mail a particular document
--- 256,270 ----



! 3. Overview

! An aggregate HTML object is a MIME-encoded message that contains a root
  document as well as other data that is required in order to represent that
! document (inline pictures, style sheets, applets, etc.). Aggregate HTML
! objects can also include additional elements that are linked to the
! first object.

! It is important to keep in mind the differing needs of several audiences.
  Mail sending agents might send aggregate HTML objects as an encoding of
  normal day-to-day electronic mail. Mail sending agents might also send
  aggregate HTML objects when a user wishes to mail a particular document
***************
*** 301,308 ****
  breaking the message integrity (MIC) check that is part of the signature.


! 4. The Content-Location and Content-Base MIME Content
! Headers

  4.1 MIME content headers

--- 284,290 ----
  breaking the message integrity (MIC) check that is part of the signature.


! 4. The Content-Location and Content-Base MIME Content Headers

  4.1 MIME content headers

***************
*** 321,329 ****

      content-base ::= "Content-Base:" absoluteURI

! where URI is at present (June 1996) restricted to the syntax for URLs as
! defined in RFC 1738 [URL]. This syntax may be widened when the definition
! of the URI syntax becomes more stable.

  These two headers are valid only for exactly the content heading or
  message heading where they occurs and its text. They are thus not valid
--- 303,310 ----

      content-base ::= "Content-Base:" absoluteURI

! where URI is currently restricted to the syntax for URLs as
! defined in RFC 1738 [URL].

  These two headers are valid only for exactly the content heading or
  message heading where they occurs and its text. They are thus not valid
***************
*** 336,342 ****
  4.2 The Content-Base header

  The Content-Base gives a base for relative URIs occurring in other heading
! fields and in HTML contents which do not have any BASE element in their
  HTML code. Its value MUST be an absolute URI.

  Example showing which Content-Base is valid where:
--- 317,323 ----
  4.2 The Content-Base header

  The Content-Base gives a base for relative URIs occurring in other heading
! fields and in content which does not have any BASE element in its
  HTML code. Its value MUST be an absolute URI.

  Example showing which Content-Base is valid where:
***************
*** 351,357 ****
     Part 1:
     Content-Type: Text/HTML
     Content-ID: foo2*[log in to unmask]
!    Content-Location: "HTTP/www.ietf.cnir.reston.va.us/images/foo1.bar1" ;
     ;  This Content-Location must contain an absolute URI, since no base
     ;  is valid here.

--- 332,338 ----
     Part 1:
     Content-Type: Text/HTML
     Content-ID: foo2*[log in to unmask]
!    Content-Location: "http://www.ietf.cnir.reston.va.us/images/foo1.bar1" ;
     ;  This Content-Location must contain an absolute URI, since no base
     ;  is valid here.

***************
*** 362,368 ****
     Content-ID: foo4*[log in to unmask]
     Content-Location: "foo1.bar1" ; The Content-Base below applies to
                                   ; this relative URI
!    Content-Base: "http:/www.ietf.cnri.reston.va.us/images/"

     --boundary-example-1--

--- 343,349 ----
     Content-ID: foo4*[log in to unmask]
     Content-Location: "foo1.bar1" ; The Content-Base below applies to
                                   ; this relative URI
!    Content-Base: "http://www.ietf.cnri.reston.va.us/images/"

     --boundary-example-1--

***************
*** 531,537 ****
  In order to send such messages, there is a need to indicate which other
  body parts are referred to by the links in the Text/HTML body parts. This
  is done in the following way: For each distinct URI in the Text/HTML
! document, which refers to data which is sent in the same MIME message,
  there SHOULD be a separate body part within the multipart/related part of
  the message containing this data. Each such body part SHOULD contain a
  Content-Location header (see section 8.2) or a Content-ID header (see
--- 512,518 ----
  In order to send such messages, there is a need to indicate which other
  body parts are referred to by the links in the Text/HTML body parts. This
  is done in the following way: For each distinct URI in the Text/HTML
! document which refers to data which is sent in the same MIME message,
  there SHOULD be a separate body part within the multipart/related part of
  the message containing this data. Each such body part SHOULD contain a
  Content-Location header (see section 8.2) or a Content-ID header (see
***************
*** 685,745 ****
  Note the specification in [REL] on the relations between Content-
  Disposition and Multipart/Related.

-
  11. Encoding Considerations for HTML bodies

! 11.1 Character set issues

! A mail user agent that wishes to send a content-type of HTML can just do
! so, so long as the normal data encoding issues are taken care of as
! specified in RFC 1521 [MIME1]. However at a basic level there are some
! differences between HTML being transferred by HTTP and HTML being
! transferred through Internet email. When transferred through HTTP, HTML by
! default uses the document character set ISO-8859-1 [HTML2]. Within
! electronic mail, the default character set is US-ASCII [MIME1].

! The sending of HTML messages via MIME e-mail can be seen as two layers of
! encoding:

  Displayed text            Displayed text
  (e.g. with a              (e.g. with a HTML viewer
  HTML editor)              or Web browser)
!      |                         |
  HTML markup               HTML markup
!      |                         |
! MIME encoding--transport--MIME encoding

                  Figure 1


! If the displayed text contains non-ascii characters, these characters
! might have to be rewritten if the transport (as is common in e-mail) is
! set to handle only 7-bit characters.

! This rewriting can be done either at the HTML layer (using "&" entity
! references or numeric character references as defined in [HTML2] section
! 3.2.1) or at the MIME layer (using Content-Transfer-Encoding as defined in
! [MIME1] section 5).
!
! In sending a message containing non-ascii characters, both these rewriting
! methods for non-ascii characters MAY be used, and any mixture of them MAY
  occur when sending the document via e-mail. Receiving mailers MUST be
  capable of both decoding at the MIME layer and mapping at the HTML layer.
  MIME decoding MUST take place before mapping at the HTML layer.

- The charset attribute of the Content-Type attribute should be us-ascii if
- and only if the html markup contains only us-ascii characters (even if the
- displayed text contains non-ascii characters).
-
  11.2 Line break characters

! The MIME standard [MIME1] specifies that line breaks in the MIME encoding
! (see figure 1) MUST be CRLF. The HTML standard [HTML2] specifies that line
! breaks in HTML markup (see figure 2) may be either bare CRs, bare LFs or
! CRLFs. To allow data integrity checks through checksums, MIME encoding of
! line breaks SHOULD be such that after decoding, the line break
! representation of the original HTML markup is returned.
!

  12. Security Considerations

--- 666,724 ----
  Note the specification in [REL] on the relations between Content-
  Disposition and Multipart/Related.

  11. Encoding Considerations for HTML bodies

! 11.1 Character representations

! A mail user agent that is composing a message using HTML has a choice
! in how to represent and subsequently encode characters for the
! transmission of the mail message.

! The sending of messages using HTML and MIME e-mail can be seen as
! employing two layers of representation:

  Displayed text             Displayed text
  (e.g. with a               (e.g. with a HTML viewer
  HTML editor)               or Web browser)
!      |                          ^
!      v                        |
  HTML markup                HTML markup
!      |                          ^
!      v                          |
! MIME encoding-->transport-->MIME encoding

                  Figure 1

+ Informally, the displayed text consists of a visual representation of
+ the intended text; the HTML markup consists of a sequence of text
+ characters, and the MIME encoding consists of a sequence of octets.

! HTML markup allows some characters at the displayed text level to be
! represented using either entity references or numeric character
! references (as defined in [HTML2] section 3.2.1).  For example, a
! "small a, acute accent" may be represented by the entity reference
! "&aacute;" or the numeric character reference "&#255;". Alternatively,
! the same character might appear directly in the HTML document, but for
! transmission through MIME 7-bit-systems, the entire HTML document
! encoded using a Content-Transfer-Encoding (as defined in [MIME1]
! section 5).

! Either or both methods for representing non-ASCII characters MAY be
! used, and and any mixture of them MAY
  occur when sending the document via e-mail. Receiving mailers MUST be
  capable of both decoding at the MIME layer and mapping at the HTML layer.
  MIME decoding MUST take place before mapping at the HTML layer.

  11.2 Line break characters

! The MIME standard [MIME1] specifies that line breaks in the MIME
! encoding of text, when transmitted through conventional SMTP, (see
! figure 1) MUST be CRLF.  The HTML standard [HTML2] section 4.2.2
! allows more leeway in the representation of line breaks, as does the
! HTTP standard [HTTP]. Thus, it is possible that some transformation
! will be necessary, and data integrity checks which operate on the
! non-canonical form of HTML (e.g., HTTP Content-MD5 headers) may
! not be valid for retransmission through mail.

  12. Security Considerations

Back to: Top of Message | Previous Page | Main MHTML Page

Permalink



LISTSRV.NORDU.NET

CataList Email List Search Powered by the LISTSERV Email List Manager