[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
In message "Re: Some text that may be useful for the update of RFC 2376",
Rick Jelliffe wrote...
>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.
I remember that you have claimed this several times, but I have never
XML people thought that application/xml is required since text/* does
not allow UTF-16. After we started this mailing list, we have learned
more from Ned.
>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.
I do not agree. Why?
>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
Although XML is based on Unicode, we certainly require negotiation and
transcoding. Some XML processors can only handle US-ASCII, 8859-1, UTF-8,
and UTF-16. There are so many legacy encodings in the world. Negotiation
and on-the-fly transcoding is certainly a good thing for I18N. If we hide
encoding information from the protocol, such transcoding becomes hard or
>(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.)
HTTP already has the accept-charset field. I do not understand your claim.
MURATA Makoto muraw3c@xxxxxxxxxxxxx