Lists Home |
Date Index |
- From: David Brownell <email@example.com>
- To: Chris Lilley <firstname.lastname@example.org>
- Date: Tue, 06 Apr 1999 16:29:25 -0700
Chris Lilley wrote:
> > See RFC 2046 and the discussion in section 4.1.2 for further information.
> > It says eight bit or multibyte encoded "text/*" "MUST" use a "charset=..."
> > property, which you seem to dislike; perhaps you were unaware that MIME
> > has fundamental constraints in this area.
> MIME actually need not have those constraints;
Debatable, though beside the point: it _does_ have them, and always has.
Did so since before the web existed.
> Individual text/whatever registrations can overide the generic methods
> of the text/* class, as for example the text/html registration does.
No, they need to be compatible with "text/plain" per the RFCs.
Remember that old agents must be able to handle new MIME types, and if they
do not understand the subtype ("whatever") they're allowed to treat all
"text/whatever" like "text/plain". For example, by preserving only seven
bits per character when there's no "charset=..." property.
> > RFC 2376 is being compatible
> > with this fundamental Internet standard, which IMHO is the right idea.
> Whilst making it incompatible with the fundamental W3C Recommendation,
> which is IMHO the wrong idea.
You've got it backwards: MIME predated HTTP and HTML (and W3C!) by a number
of years, so it wasn't MIME which caused the confusion underlying this
The only incompatibility I know about is what someone wrote about what it
means to transmit "text/html" over one specific transport medium (HTTP).
> > > > For a single world-wide default; that's easily understood by overworked,
> > > > underpaid, often untrained sysadmins; and hence is NOT error prone (!!),
> > > > there's a simple answer that's guaranteed to work right everywhere that
> > > > pays more than lip service to industry standards, and hence is "best".
> > > > Namely, that servers report XML documents as "application/xml".
> > That requires _no conclusions_ about what is or is not "text".
> > It only says that encoded text is most likely to be dealt with in
> > the correct way if people label XML text as "application/xml".
For example, even if people remain confused by what the "text/*"
means, there's much less confusion about what other ones mean, and you're
less likely to see critical bits stripped out of such messages because the
originator (server, etc) didn't label the type correctly.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)