[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some text that may be useful for the update of RFC 2376
On Thu, 16 Mar 2000, MURATA Makoto wrote:
> No. Application/xml was introduced since some XML is not
> readable for casual users. As Ned Freed pointed out long time ago,
> text/* is inappropriate for something unreadable for casual users.
That is not the way I remember it. Application/xml was taken out at
one stage, and we had to lobby hard to get it put in. The reason
users want it is not to prevent xml from being spuriously displayed:
it is to ensure end-to-end integrity because the out-of-band approach
has so far failed to provide that integrity.
And what should the type be if it has parts that are readable and
parts that are unreadable? If the document is encoded with a lot
of numeric character references, it is unreadable as text/plain
but readable as text/xml: should we send documents that use
many numeric character entities as application/xml?
We need a way to ensure end-to-end integrity. If application/*
cannot provide it, what does?
Out-of-band signalling of the encoding of a file to some extent a hack to
cope with formats that are not adequately self-describing. I would have
no problem with removing text/xml entirely: we don't need to negotiate
encoding since everything can be resolved into Unicode (and, in any case,
there is no mechanism currently for an XML parser to feed information
about which encodings it accepts to the HTTP system to set up the
preferences in the first place.)