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

Subject: Re: Summary of decisions at the Montreal MHTML IETF meeting
From: Einar Stefferud <[log in to unmask]>
Reply-To:[log in to unmask]
Date:Thu, 4 Jul 1996 11:58:25 -0700

text/plain (45 lines)

I agree with Gavin -- The MIME MHTML spec should only affirm that MIME
must do the right thing in the way of Transfer-Encoding of whatever
HTML charsets are used.

A crux issue here is that HTML, being a markup language, has no
concern with distinguishing hard LINEFEEDS from soft LINEFEDS, so
HTTP/HTML does not care wheither the text contains LF, CR, CRLF, or
LFCR, since the HTML rendering engine ignores all hard linfeeds in any
case, and only execute HTML tag directives.

The HTML behavior must carry over to rendering HTML when it arrives
via EMail in a MIME wrapper.  So, ther shoudl be no reason to be
conacerned about the CR, LF, LFCR, CRLF, or the charset question, as
long as MIME is properly applied by both sender and receiver.

So, writing ourt MHTML spec to say that the sender MUST include the
CHARSET parameter, even when it happens to be the same as the MIME
default, is a good thing to do.

HTTP 1.1 is adopting this MUST rule, and I suggest that DRUMS shoudl
do the same, as should all MIME documents from now on, where it might
make a difference.

My postion stems form a long held belief that it is very bad business
to ever communicate by means of omitted fields or blanks in fields.
It is very hard to be explicity when communicating via implicit



From your message Thu, 4 Jul 1996 15:00:07 GMT:
}>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).
}Jacob, the reference to numeric characer references, or character
}entities is meaningless. Do you realise what this actuall means in
}terms of requirements of user agents?
}The MIME mechanisms (content transfer encodings) suffice. Let's leave
}it at that.

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



CataList Email List Search Powered by the LISTSERV Email List Manager