LISTSERV mailing list manager LISTSERV 15.5

Help for MHTML Archives

MHTML Archives

MHTML Archives


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


Join or Leave MHTML
Reply | Post New Message
Search Archives


New IETF draft for MHTML now ready!


Jacob Palme <[log in to unmask]>


IETF working group on HTML in e-mail <[log in to unmask]>


Sun, 14 Jul 1996 12:30:03 +0200





TEXT/PLAIN (1 lines)

I am now ready with the new IETF drafts from the MHTML group:

Title: MIME E-mail Encapsulation of Aggregate HTML Documents (MHTML)
Text file name: draft-ietf-mhtml-spec-01.txt
Postscript file name:

Title: Sending HTML in E-mail, an informational supplement to RFC ???:
MIME E-mail Encapsulation of Aggregate HTML Documents (MHTML)
Text file name: draft-ietf-mhthml-info-01.txt
Postscript file name:

The Postscript versions of the files shows the difference between
version 00 and version 01.

It was not possible for me to include all suggestions for changes
from all readers, since some suggestions from different readers
were contradictory. For example, at the Montreal meeting, I was
strictly instructed *not* to use the word "encoding" for the
HTML method of representing special characters with &-elements.
But several of the suggested new texts after the meeting use
exactly this word.

The two most controversial issues in the new draft is
(a) Mapping of relative to absolute URIs
(b) Non-US-ASCII-character rewriting

I include below in this e-mail message in full the new text
on these issues.

! (a) Mappping of relative to absolute URI-s
! ------------------------------------------
! 8.2 Use of the Content-Location header
! If there is a Content-Base header, then the recipient MUST employ relative
! to absolute resolution as defined in RFC 1808 [RELURL] of URIs in both the
! HTML markup and the Content-Location header before matching a hyperlink in
! the HTML markup to a Content-Location header. The same applies if the
! Content-Location contains an absolute URL, and the HTML markup contains a
! BASE element so that relative URL-s in the HTML markup can be resolved.

! If there is NO Content-Base header, and the Content-Location header
! contains a relative URL, then NO relative to absolute resolution SHOULD be
! performed (even if there is a BASE element in the HTML markup), and exact
! textual match of the relative URL-s in the Content-Location and the HTML
! markup is performed instead (after removal of LWSP introduced as described
! in section 4.4 above).
! The URI in the Content-Location header need not refer to an object which
! is actually available globally for retrieval using this URI (after
! resolution of relative URIs).

This is not exactly what was said at the Montreal meeting on Monday,
but is what was said during the editing meeting in Montreal on Wednesday.
That editing meeting said that non-resolvable relative URI-s should
be allowed as long as the URI in the Content-Location is the same
as the URI in the HTML text, so that is what I have written above.

(b) Non-US-ASCII-character rewriting

This item has been discussed in the list a lot, in spite of the
fact that we all agree fully on the functionality. All the disagreement
has been on which words are best used to express this functionality
clearly and correctly.

Here is the new text I have produced, it is a composite of portions
of suggested new wording from Larry Masinter and Martin J. Duerst:

! 11. Encoding Considerations for HTML bodies
! 11.1 Character set issues
! 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.
! However, there are some differences as to the default character
! encoding, specified by the MIME "charset" parameter. If this parameter
! is omitted: When transferred through HTTP, the default is [HTTP]:
! content-type: Text/HTML; charset=ISO-8859-1
! When transferred via e-mail, the default is [MIME1]:
! content-type: Text/HTML; charset=US-ASCII
! To avoid confusion, the MIME Content-Type parameter for Text/HTML
! SHOULD always include a charset value, and not rely on the MIME e-mail
! default of US-ASCII if no charset value is specified.
! When sending HTML via MIME e-mail, three layers of encoding are
! relevant as shown in Figure 1:
! Displayed text Displayed text
! | ^
! V |
! +-------------+ +----------------+
! | HTML editor | | HTML viewer |
! | | | or Web browser |
! +-------------+ +----------------+
! | ^
! V |
! HTML markup HTML markup
! | ^
! V |
! +------------------+ +-------------------+
! | MIME content- | | MIME content- |
! | transfer-encoder | | transfer-encoder |
! +------------------+ +-------------------+
! | ^
! V +-----------+ |
! transfer-encoding--->| Transport |-->transfer encoding
! +-----------+
! Figure 1
! Definitions (see Figure 1):
! Displayed text A visual representation of the intended text.
! HTML markup A sequence of characters formatted according to the
! HTML specification [HTML2].
! MIME encoding A sequence of octets physically forwarded via e-mail,
! may include MIME content-transfer-encoding as
! specified
! in [MIME1].
! HTML editor Software used to produce HTML markup.
! MIME content- Software used to encode and decode non-US-ASCII
! transfer-encoder characters according to the MIME standard.
! HTML viewer Software used to display HTML documents to
! recipients.
! Note: Real implementations need not split functions into different
! modules as described above. The figure above is a logical model in
! order to explain how rewriting and transport is done.
! If the displayed text contains non-US-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.
! 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 is
! encoded using a Content-Transfer-Encoding (as defined in [MIME1]
! section 5).
! In sending a message containing non US-ASCII characters, both these
! rewriting methods MAY be used, and any mixture of them MAY occur when
! sending the document via e-mail. Receiving mailers (together with the
! Web browser they may use to display the document) MUST be capable of
! handling any combinations of these rewriting methods.
! The value of the charset attribute of the Content-Type header field
! should be US-ASCII if and only if the HTML markup contains only US-
! ASCII characters (even if the displayed text contains non-US-ASCII
! characters).
! Example of non-US-ASCII characters in HTML: See section 9.3 above.
! 11.2 Line break characters
! The MIME standard [MIME1] specifies that line breaks in the MIME
! encoding (see figure 1) MUST be CRLF. The HTTP standard [HTTP]
! specifies that line breaks in transported 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.
! Note that since the mail content-MD5 is defined to a canonical form
! with all line breaks converted to CRLF, while the HTTP content-MD5 is
! defined to apply to the transmitted form. This means that the Content-
! MD5 HTTP header may not be correct for Text/HTML that is retrieved
! from a HTTP server and then sent via mail.

Jacob Palme <[log in to unmask]> (Stockholm University and KTH)
for more info see URL:

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



CataList Email List Search Powered by the LISTSERV Email List Manager