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: Gavin Nicol <[log in to unmask]>
Reply-To:IETF working group on HTML in e-mail <[log in to unmask]>
Date:Fri, 5 Jul 1996 06:25:54 GMT
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (20 lines)


>It is HTML that is already specified to be tolerant of of the CR, LF,
>& CRLF alternatives, so HTML must always be able to handle all of
>these cases.  This is not an EMAIL issue, since MIME will always
>deliver what it was given;-)...

To be precise, it isn't even HTML, it's HTTP. HTML, as an application
of SGML, is *required* to pass along *all* data characters and
significant record start and record ends. The progam *using* that
output stream interprets it according to some style specification. As
such, PRE doesn't *inherently* respect newlines: it is just an
application convention (and I think CSS allows you to override it
even!).

We *should* note when some content transfer encoding needs to be
applied (for example, if UCS-2 data is being sent, or if the octets in
the data stream contain values greater than 127), but we need not
specify *anything about "encodings" or other such things with regard
to content. As Stef correctly notes, MIME is responsible for sending
whatever it is given in a way that mail gateways can handle. It is the
UA's responsibility to use these mechanisms when appropriate.

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