IE5.0 does not conform to RFC2376

[Chris Lilley]

David Brownell wrote:
> 
> > > > > > What this RFC appears to do is remove author control over correctly
> > > > > > labelling the encoding, and ensure that most if not all XML documents
> > > > > > get incorrectly labelled as US-ASCII.
> > > > >
> > > > > Not at all.  The best default MIME content type for all web
> > > > > servers is "application/xml".
> > > >
> > > > Why? Do you consider anything not written in US-ASCII as a text
> > > > document? I think the Unicode Consortium would disagree with you there.
> > >
> > > No, and that's not what I said:
> >
> > But it is the implication of your argument.
> 
> How could it imply that?  

Because you seemed to be advising not using text/xml for anything not in
US-ASCII

> I didn't even talk about what "text" is,
> only about what MIME guarantees.  And MIME only talks about what some
> specific content/media type categories mean, not about what "text" is.

But it talks about what text/* is .... 

> 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; *email* has those
constraints (although increasingly it does not, in practice). HTTP is
always 8-bit clean. I agree that the MIME RFCs have steadfastly tried to
pretend that MIME is an email-only thing.

Individual text/whatever registrations can overide the generic methods
of the text/* class, as for example the text/html registration does.

> 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.

> > > 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".

You have asserted this several times but not actually demonstrated it. I
pointed out that the fundemental constraint on correct handling is
whether an application understands a particular encoding, not  how that
encoding labelling is transmitted (although a method that is persistent
across local copies is preferable to one that is not).

So "guaranteed to work right everywhere" is not, in fact, a guarantee at
all.

--
Chris



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)