|
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
channels.
In short, being "IMPLICITLY EXPLICIT" is an OXYMORON!
Cheers...\Stef
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.
|
