Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: IE5.0 does not conform to RFC2376
 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@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
