- From: Grosso, Paul <pgrosso@ptc.com>
- Date: Mon, 7 Nov 2011 09:28:47 -0500
- To: <public-xml-core-wg@w3.org>
I'm not sure I've fully digested this, but I want to make sure others have seen it. paul -----Original Message----- From: Chris Lilley [mailto:chris@w3.org] Sent: Friday, 2011 November 04 13:18 To: www-tag@w3.org Subject: Updated status on RFC3023bis Hello www-tag, This week I briefly met with Henry and with Noah and explained some recent and upcoming changes in RFC3023bis. But the details are better committed to a public and archived email list. As you probably are aware, there were objections by some implementors to RFC3023bis deprecating text/xml on the grounds that - they still have to process it anyway (feeds, etc served as text/xml) and - their charset handling was not as defined in the spec (assume us-ascii in the case of no declared charset at the http level) but was the same as application/xml (assume what the xm document says to be true, in the absence of charset info at the http level). You will also be aware that we were unable to make RFC 3023bis do what they wanted, due to the definition of the text/* types. In the last year things have changed. I attended IETF80 and presented RFC3023bis there, explaining the problems. Harald Alvestrand initially disagreed with my reasoning and then, on closer examination of the relevant RFCs, agreed that my analysis was correct. That same day, HTTPbis resolved to remove the default charset for HTTP. I suggested that one way forward (although not an ideal one) would be to have different handling for http and for email. Alexey Melnikov, outgoing IETF Apps area director, spoke with me on that and proposed to fix the text/* handling so that http and email would once again be in alignment. He also offered to become a co-editor of RFC3023bis, which is great. He has since published an internet draft proposing the text/* changes: http://tools.ietf.org/html/draft-melnikov-mime-default-charset-01 Therefore, it seems that RFC3023bis could take a different approach: - text/xml is no longer deprecated - text/xml (and the other text/* types) would behave as application/xml does This would resolve the implementor objections and would also align the specification with existing implementation practice in browsers and xml parsers. I still have to ensure that the spec meets the TAG requirements on handling of fragment identifiers (I have followed the recent thread regarding fragments in RDFa, for example) and they suggested that I meet with you on Friday at noon to discuss it. But it does seem that we can move forward here by removing the substantial and blocking issue. -- Chris Lilley Technical Director, Interaction Domain W3C Graphics Activity Lead, Fonts Activity Lead Co-Chair, W3C Hypertext CG Member, CSS, WebFonts, SVG Working Groups
Received on Monday, 7 November 2011 14:30:37 UTC