OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: IE5.0 does not conform to RFC2376

[ Lists Home | Date Index | Thread Index ]
  • From: David Brownell <db@eng.sun.com>
  • To: Chris Lilley <chris@w3.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
overlong discussion!

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/*"
registration
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.

- Dave

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS