- From: Chris Lilley <chris@w3.org>
- Date: Thu, 18 Nov 2010 17:40:40 +0100
- To: Noah Mendelsohn <nrm@arcanedomain.com>
- CC: Julian Reschke <julian.reschke@gmx.de>, Henri Sivonen <hsivonen@iki.fi>, Larry Masinter <LMM@acm.org>, "www-tag@w3.org WG" <www-tag@w3.org>, MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
On Monday, November 8, 2010, 7:59:54 PM, Noah wrote: NM> Julian Reschke wrote: >> Which reminds me that it may be time for the TAG to look into the >> image/sxg+xml issue. NM> I assume that's a typo for svg+xml? NM> I'd first be curious to hear what some of those responsible for RFC 3023 NM> bis think. I'm copying Chris and Murata-san. To me, having a +xml type NM> that's sometimes not XML seems bogus, but let's see what others say. Its *always XML*. It may have been encoded, so the MIME layer will need to decode it. This is why the encoding is given in a separate filed from the content type. The content type does not change. Similarly, you see the text of this email as plain text, despite the fact that it may have been encoded using quoted-printable or base-64 encoding. I would be happy to add a mention of encoding to RFC 3023bis, if needed. It seemed that it would not be needed, since such decoding happens at a separate layer, and indeed XML parsers often have no knowledge of or access to any HTTP headers that may have been available at the network layer. But recent discussions make it clear that there is room for confusion, so a mention would probably help. -- 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 Thursday, 18 November 2010 16:40:56 UTC