Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAOHT0HA081352; Wed, 24 Nov 2004 09:29:00 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAOHSx4m081350; Wed, 24 Nov 2004 09:28:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAOHSvvt081218 for ; Wed, 24 Nov 2004 09:28:58 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail 15912 invoked by uid 65534); 24 Nov 2004 17:28:55 -0000 Received: from dsl-213-023-052-028.arcor-ip.net (EHLO helix) (213.23.52.28) by mail.gmx.net (mp021) with SMTP; 24 Nov 2004 18:28:55 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Chris Lilley Cc: ietf-types@iana.org, ietf-xml-mime@imc.org Subject: Re: MIME Type Review Request: image/svg+xml Date: Wed, 24 Nov 2004 18:28:57 +0100 Message-ID: <41b5c0f2.218219953@smtp.bjoern.hoehrmann.de> References: <1643632730.20041102172228@w3.org> <6.0.0.20.2.20041119083958.085ea200@localhost> <856124.20041123192825@w3.org> <41a724c1.178235718@smtp.bjoern.hoehrmann.de> <145744919.20041124123025@w3.org> <41aa8dfb.205173125@smtp.bjoern.hoehrmann.de> <78409955.20041124154406@w3.org> <41aea12d.210087578@smtp.bjoern.hoehrmann.de> <218613975.20041124175456@w3.org> In-Reply-To: <218613975.20041124175456@w3.org> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * Chris Lilley wrote: >BH> Consider a *UTF-8 encoded* document >BH> >BH> Content-Type: application/xml;charset=iso-8859-1 >BH> >BH> >BH> ... >BH> >BH> ... >BH> >BH> With no BOM and using only US-ASCII characters for the rest of the >BH> document, >So in this case, although the processor that generated it is non >conforming, the content is not non conforming (but it should be) and the >processor that receives it has two possibilities: I've actually asked to get a better understanding on how you intend to change RFC3023, yet I am afraid you did not really say what happens with the document above if RFC3023bis gets approved with your changes. I would appreciate to know just a, b, c, or what else for the various cases. >b) it can note that a required encoding declaration is not present, and >throw a well formedness error. It actually can't, 0xC3 0xB6 is a legal sequence in both UTF-8 and ISO-8859-1, it would need to know that I meant to have "Björn" in the comment which it cannot know. >Consider an *8859-1 encoded* document > > Content-Type: application/xml;charset=UTF-8 > > > ... > > ... > >With your proposal, would the well formedness error (bytes occur that >cannot occur in UTF-8) be silently recovered from if the HTTP >header overrides it, even for an XML processor, while it would continue >to fail in other cases (such as server side processing)? I do not really think I've made a proposal to change RFC3023 other than that the differences between text/xml and application/xml are removed to properly reflect running code. I can only tell you what XML 1.0 and RFC 3023 require in these cases but you know that already. >It would sometimes be b) and sometimes c) depending on the particular >software and whether its reading from disk on the server or over the >net. I frankly can't understand how you consider this lack of >interoperability to be a desirable thing. I am in fact most interested to learn how you think this can be improved upon which is why I asked you about the impact of your proposal for the various cases I've mentioned. What applications currently do does not really help me to get a better understanding of that. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAOGt09v047733; Wed, 24 Nov 2004 08:55:00 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAOGt0fD047730; Wed, 24 Nov 2004 08:55:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAOGstN9047668 for ; Wed, 24 Nov 2004 08:54:55 -0800 (PST) (envelope-from chris@w3.org) Received: from localhost (localhost [127.0.0.1]) by homer.w3.org (Postfix) with ESMTP id 7664E4EFE7; Wed, 24 Nov 2004 11:54:56 -0500 (EST) Date: Wed, 24 Nov 2004 17:54:56 +0100 From: Chris Lilley Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <218613975.20041124175456@w3.org> To: Bjoern Hoehrmann Cc: ietf-types@iana.org, ietf-xml-mime@imc.org Subject: Re: MIME Type Review Request: image/svg+xml In-Reply-To: <41aea12d.210087578@smtp.bjoern.hoehrmann.de> References: <1643632730.20041102172228@w3.org> <6.0.0.20.2.20041119083958.085ea200@localhost> <856124.20041123192825@w3.org> <41a724c1.178235718@smtp.bjoern.hoehrmann.de> <145744919.20041124123025@w3.org> <41aa8dfb.205173125@smtp.bjoern.hoehrmann.de> <78409955.20041124154406@w3.org> <41aea12d.210087578@smtp.bjoern.hoehrmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, November 24, 2004, 4:41:48 PM, Bjoern wrote: BH> * Chris Lilley wrote: >>As you yourself pointed out, per RFC3023 >> >> Processors generating XML MIME entities MUST NOT label conflicting >> charset information between the MIME Content-Type and the XML >> declaration. >> >>such content is already non conforming. BH> It does not actually apply to content... Yes, that is an ambiguity that needs to be cleared up. It says things that generate the content must not do that; if that were true, then there would be no such content. Since there is, its worth splitting this into two: - Conformance for XML generators - Conformance for XML messages (headers plus bodies) >>In terms of dealing with such content if it still occurs, the XML well >>formedness rules already handle that in an entirely satisfactory manner >>and nothing further need be added. These are already well implemented >>and highly interoperable. BH> Consider a *UTF-8 encoded* document BH> Content-Type: application/xml;charset=iso-8859-1 Since that isn't image/svg+xml then it has a charset parameter, although the processor that generated it is non conforming to the existing RFC 3023. But lets press on into how to detect or resolve the error. BH> BH> ... BH> BH> ... BH> With no BOM and using only US-ASCII characters for the rest of the BH> document, Cleverly constructed example, if the processor believes the charset the processor will think the comment says Björn. However, as soon as you save it, your name is mis-spelled. I'm sure you would not like that, Björn. So in this case, although the processor that generated it is non conforming, the content is not non conforming (but it should be) and the processor that receives it has two possibilities: a) it can add the missing encoding declaration when processing and when saving to disk (note that, if the xml happened to be digitally signed and in canonical XML form, this would break the signature). See RFC 3741 b) it can note that a required encoding declaration is not present, and throw a well formedness error. Note that both of these choices will break some content and both of these choices are licensed by the relevant specifications. There is thus non-interoperability. Note further that, in the case where the charset parameter is not present, there is 100% interoperability, no breakage, all in conformance with the existing clauses in RFC 3023 which 3023bis will retain, since they are proven by implementation experience with running code to be highly robust and interoperable. So, lets take the other case, which is more interesting. Consider an *8859-1 encoded* document Content-Type: application/xml;charset=UTF-8 ... ... With your proposal, would the well formedness error (bytes occur that cannot occur in UTF-8) be silently recovered from if the HTTP header overrides it, even for an XML processor, while it would continue to fail in other cases (such as server side processing)? BH> with your proposal, which of the following behaviors of BH> implementations would be considered conforming? (see above for discussion of b and c) BH> a) it fails to process the document due to RFC3023bis/XML 1.0 errors That would be the safest course. Consider if the non-ascii character was a euro or some other currency symbol, if the document was an invoice, and was being processed by an accounting system not by a human being. Accounting systems do not have the luxury of a human to look at the invoice, go to View...Character Encoding and try various possibilities until it seems to look right, then save the document and edit the local copy and fix up the encoding declaration BH> b) it considers the comment to include "Björn" BH> c) it considers the comment to include "Björn" BH> * application/xhtml+xml (with no update to RFC3236) That is an existing type and has an existing charset parameter. Applications are thus allowed to use it, with all the complications and breakage that this entails as described above. BH> * image/svg+xml (as you propose it) There is no charset parameter. Processors that generate one and messages that contain one are in error. BH> For application/xml / application/xhtml+xml this would currently be b) BH> as the document includes 0xC3 0xB6 and the encoding is determined to be BH> ISO-8859-1 which means the sequence above represents "ö". It would sometimes be b) and sometimes c) depending on the particular software and whether its reading from disk on the server or over the net. I frankly can't understand how you consider this lack of interoperability to be a desirable thing. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAOFfwYP074079; Wed, 24 Nov 2004 07:41:58 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAOFfw0W074078; Wed, 24 Nov 2004 07:41:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAOFfp5o073926 for ; Wed, 24 Nov 2004 07:41:53 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail 13744 invoked by uid 65534); 24 Nov 2004 15:41:47 -0000 Received: from dsl-213-023-052-028.arcor-ip.net (EHLO helix) (213.23.52.28) by mail.gmx.net (mp014) with SMTP; 24 Nov 2004 16:41:47 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Chris Lilley Cc: ietf-types@iana.org, ietf-xml-mime@imc.org Subject: Re: MIME Type Review Request: image/svg+xml Date: Wed, 24 Nov 2004 16:41:48 +0100 Message-ID: <41aea12d.210087578@smtp.bjoern.hoehrmann.de> References: <1643632730.20041102172228@w3.org> <6.0.0.20.2.20041119083958.085ea200@localhost> <856124.20041123192825@w3.org> <41a724c1.178235718@smtp.bjoern.hoehrmann.de> <145744919.20041124123025@w3.org> <41aa8dfb.205173125@smtp.bjoern.hoehrmann.de> <78409955.20041124154406@w3.org> In-Reply-To: <78409955.20041124154406@w3.org> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * Chris Lilley wrote: >As you yourself pointed out, per RFC3023 > > Processors generating XML MIME entities MUST NOT label conflicting > charset information between the MIME Content-Type and the XML > declaration. > >such content is already non conforming. It does not actually apply to content... >In terms of dealing with such content if it still occurs, the XML well >formedness rules already handle that in an entirely satisfactory manner >and nothing further need be added. These are already well implemented >and highly interoperable. Consider a *UTF-8 encoded* document Content-Type: application/xml;charset=iso-8859-1 ... ... With no BOM and using only US-ASCII characters for the rest of the document, with your proposal, which of the following behaviors of implementations would be considered conforming? a) it fails to process the document due to RFC3023bis/XML 1.0 errors b) it considers the comment to include "Björn" c) it considers the comment to include "Björn" If none of these behaviors would be conforming, what would be conforming instead? What would be the answers for your proposal if application/xml is replaced by the following types and proper content as defined above: * application/xhtml+xml (with no update to RFC3236) * image/svg+xml (as you propose it) For application/xml / application/xhtml+xml this would currently be b) as the document includes 0xC3 0xB6 and the encoding is determined to be ISO-8859-1 which means the sequence above represents "ö". Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAOEi4KH003565; Wed, 24 Nov 2004 06:44:04 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAOEi4xl003563; Wed, 24 Nov 2004 06:44:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAOEi4wA003542 for ; Wed, 24 Nov 2004 06:44:04 -0800 (PST) (envelope-from chris@w3.org) Received: from localhost (localhost [127.0.0.1]) by homer.w3.org (Postfix) with ESMTP id 578204F005; Wed, 24 Nov 2004 09:44:05 -0500 (EST) Date: Wed, 24 Nov 2004 15:44:06 +0100 From: Chris Lilley Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <78409955.20041124154406@w3.org> To: Bjoern Hoehrmann Cc: ietf-types@iana.org, ietf-xml-mime@imc.org Subject: Re: MIME Type Review Request: image/svg+xml In-Reply-To: <41aa8dfb.205173125@smtp.bjoern.hoehrmann.de> References: <1643632730.20041102172228@w3.org> <6.0.0.20.2.20041119083958.085ea200@localhost> <856124.20041123192825@w3.org> <41a724c1.178235718@smtp.bjoern.hoehrmann.de> <145744919.20041124123025@w3.org> <41aa8dfb.205173125@smtp.bjoern.hoehrmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, November 24, 2004, 3:18:50 PM, Bjoern wrote: BH> * Chris Lilley wrote: >>BH> Your proposals so far render all applications for which RFC3023 would >>BH> be relevant non-compliant regardless of whether they implement only >>BH> some part of RFC3023, the entire specification or implement it not at >>BH> all. >> >>That is incorrect. You seem to miss that once RFC3023 is updated to >>ensure that the encoding and the charset are the same, the *sole* use of >>a charset parameter is for non-xml applications. BH> The use of the charset parameter so far does not seem actually relevant BH> to this discussion. If I understand correctly that you propose to make BH> Content-Type: application/xml;charset=iso-8859-1 BH> BH> ... iso-8859-1 content ... BH> non-conforming, As you yourself pointed out, per RFC3023 Processors generating XML MIME entities MUST NOT label conflicting charset information between the MIME Content-Type and the XML declaration. such content is already non conforming. BH> I would expect that your proposal includes a requirement for BH> implementations to detect this error and probably also a requirement BH> to reject such resources. Since its already non conforming, we just have to deal with the non-conforming situation. My solution further discourages such content and is consistent with the architectural principle that silent recovery from error is harmful http://www.w3.org/TR/webarch/#no-silent-recovery In terms of dealing with such content if it still occurs, the XML well formedness rules already handle that in an entirely satisfactory manner and nothing further need be added. These are already well implemented and highly interoperable. BH> Both requirements would render implementations BH> of RFC3023 non-conforming since none of them do this. Thats right, they don't raise an error. They either silently recover by considering the charset authoritative or they silently recover by considering the encoding declaration authoritative. Both interpretations are observed in running code. In addition, when saving to disk some (a few) alter the inconsistent xml encoding declaration to make it correct, others (most) do not, thus depositing a non-well-formed instance in local storage. And you are ok with that messy, non-interoperable state of affairs? >>And thus, what use is the redundant declaration? Note that currently >>there is great variability in what processors do when reading and saving >>content that has conflicting declarations. Removing the source of the >>conflict brings us onto safer ground to the area where all >>implementations behave the same. Surely you can see that this is good >>and results in more robust, interoperable behavior? BH> What do you consider the source of the conflict here? As far as I can BH> tell that would be the charset parameter and as long as implementations BH> are required to consider it to detect the character encoding the source BH> of conflict is not removed. This is doubtless why RFC 3023 says that people should not generate content that has this conflict, and why TAG says the same thing, not to generate it unless it is known to be correct. However, implementation experience since RFC 3023 was issues shows that people do it anyway, and its a significant problem; so it needs to be fixed. Pretending there is no problem does not help the situation in any way. BH> Maybe your point is that people will stop BH> using the charset parameter in a way that creates potential problems if BH> RFC3023bis has some conformance rules they make that seem reasonable to BH> expect? Right. That would include discouraging the use of an optional and inconsistently implemented charset parameter for new registrations. Existing registrations that use it we can do nothing about, although I would like to see more testing of what processors do in the case of inconsistent, non-conforming content. BH> Maybe you can draft an improved proposal to change RFC3023 and post it BH> to the relevant lists? That would certainly help the discussion. Excellent suggestion, I will do exactly that (which is, of course, why I took the action from the TAG to become co-editor. Its much more effective for the TAG to say something is wrong, and help fix it, than merely to say it is wrong). -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAOEIxsq078118; Wed, 24 Nov 2004 06:18:59 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAOEIwTU078117; Wed, 24 Nov 2004 06:18:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAOEIqPO077842 for ; Wed, 24 Nov 2004 06:18:53 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail 10252 invoked by uid 65534); 24 Nov 2004 14:18:49 -0000 Received: from dsl-213-023-052-028.arcor-ip.net (EHLO helix) (213.23.52.28) by mail.gmx.net (mp022) with SMTP; 24 Nov 2004 15:18:49 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Chris Lilley Cc: ietf-types@iana.org, ietf-xml-mime@imc.org Subject: Re: MIME Type Review Request: image/svg+xml Date: Wed, 24 Nov 2004 15:18:50 +0100 Message-ID: <41aa8dfb.205173125@smtp.bjoern.hoehrmann.de> References: <1643632730.20041102172228@w3.org> <6.0.0.20.2.20041119083958.085ea200@localhost> <856124.20041123192825@w3.org> <41a724c1.178235718@smtp.bjoern.hoehrmann.de> <145744919.20041124123025@w3.org> In-Reply-To: <145744919.20041124123025@w3.org> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * Chris Lilley wrote: >BH> Your proposals so far render all applications for which RFC3023 would >BH> be relevant non-compliant regardless of whether they implement only >BH> some part of RFC3023, the entire specification or implement it not at >BH> all. > >That is incorrect. You seem to miss that once RFC3023 is updated to >ensure that the encoding and the charset are the same, the *sole* use of >a charset parameter is for non-xml applications. The use of the charset parameter so far does not seem actually relevant to this discussion. If I understand correctly that you propose to make Content-Type: application/xml;charset=iso-8859-1 ... iso-8859-1 content ... non-conforming, I would expect that your proposal includes a requirement for implementations to detect this error and probably also a requirement to reject such resources. Both requirements would render implementations of RFC3023 non-conforming since none of them do this. So it would seem your proposal does not include such requirements, is that correct? In case this is correct, what is the point of disallowing this and yet to specify how implementations must process such content (i.e., consider the resource above ISO-8859-1 encoded)? Or does your proposal also in- clude changes to how implementations must determine the character en- coding? It would seem it does not. >And thus, what use is the redundant declaration? Note that currently >there is great variability in what processors do when reading and saving >content that has conflicting declarations. Removing the source of the >conflict brings us onto safer ground to the area where all >implementations behave the same. Surely you can see that this is good >and results in more robust, interoperable behavior? What do you consider the source of the conflict here? As far as I can tell that would be the charset parameter and as long as implementations are required to consider it to detect the character encoding the source of conflict is not removed. Maybe your point is that people will stop using the charset parameter in a way that creates potential problems if RFC3023bis has some conformance rules they make that seem reasonable to expect? Maybe you can draft an improved proposal to change RFC3023 and post it to the relevant lists? That would certainly help the discussion. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAOBUUpR095484; Wed, 24 Nov 2004 03:30:30 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAOBUUvR095482; Wed, 24 Nov 2004 03:30:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAOBUPkT095410 for ; Wed, 24 Nov 2004 03:30:25 -0800 (PST) (envelope-from chris@w3.org) Received: from localhost (localhost [127.0.0.1]) by homer.w3.org (Postfix) with ESMTP id DDDA74EFA5; Wed, 24 Nov 2004 06:30:24 -0500 (EST) Date: Wed, 24 Nov 2004 12:30:25 +0100 From: Chris Lilley Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <145744919.20041124123025@w3.org> To: Bjoern Hoehrmann Cc: ietf-types@iana.org, ietf-xml-mime@imc.org Subject: Re: MIME Type Review Request: image/svg+xml In-Reply-To: <41a724c1.178235718@smtp.bjoern.hoehrmann.de> References: <1643632730.20041102172228@w3.org> <6.0.0.20.2.20041119083958.085ea200@localhost> <856124.20041123192825@w3.org> <41a724c1.178235718@smtp.bjoern.hoehrmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wednesday, November 24, 2004, 7:32:59 AM, Bjoern wrote: BH> * Chris Lilley wrote: >>Its much more productive to fix RFC3023 to not be in conflict with Web >>Architecture which (as co-editor) i am involved in doing. BH> If your goal is to feel good when ignoring reality then that may be so, BH> if you are more concerned about interoperability of running code, which BH> is slightly more common in IETF discussions, then maybe not. Bjoern, that seems uncalled for. Lets try to be civil here. I don't describe your proposals as fleeing from reality, please do me the same courtesy. And my reasoning in all of this is, of course, existing implementations and interoperability. BH> Your pro- BH> posals so far render all applications for which RFC3023 would be rele- BH> vant non-compliant regardless of whether they implement only some part BH> of RFC3023, the entire specification or implement it not at all. That is incorrect. You seem to miss that once RFC3023 is updated to ensure that the encoding and the charset are the same, the *sole* use of a charset parameter is for non-xml applications. BH> Some of your proposals even BH> seem out of scope of RFC3023bis as they in essence make it a fatal error BH> as defined in XML 1.0 if higher-level protocol information affects the BH> detection of the character encoding of the XML entity which contradicts BH> XML 1.0. It rather seems you want to change the XML specifications in BH> which case you should talk to the W3C XML Core Working Group. No, you mis-state my position. Incidentally, since you bring up the XML Core WG, you realise that the text I cited in the ASrchitecture document was written by Tim Bray, co-editor of the XML specification? BH> Of course, assuming that I actually understand your proposals, I suspect that you do not, which would explain both the content and the tone of your comments. BH> none of BH> them has really been clear yet, you sometimes give the impression that BH> the requirements your propose to add to RFC3023bis just render some BH> content non-compliant without any actual effect on conforming BH> implementations, that would then be even worse as it would have no BH> effect in practise other than complicating theory even more. In fact, BH> in that case one would even wonder what you are actually trying to BH> achieve, as RFC 3023 already states BH> Processors generating XML MIME entities MUST NOT label conflicting BH> charset information between the MIME Content-Type and the XML BH> declaration. And thus, what use is the redundant declaration? Note that currently there is great variability in what processors do when reading and saving content that has conflicting declarations. Removing the source of the conflict brings us onto safer ground to the area where all implementations behave the same. Surely you can see that this is good and results in more robust, interoperable behavior? I am frankly puzzled by your insistence on retaining the woolly non-interoperable area while simultaneously claiming that i am unrealistic and do not care for interoperability..... -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAO6XBRl020434; Tue, 23 Nov 2004 22:33:11 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAO6XBAn020428; Tue, 23 Nov 2004 22:33:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAO6X33Y020119 for ; Tue, 23 Nov 2004 22:33:03 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail 6134 invoked by uid 65534); 24 Nov 2004 06:32:58 -0000 Received: from dsl-082-082-076-103.arcor-ip.net (EHLO helix) (82.82.76.103) by mail.gmx.net (mp027) with SMTP; 24 Nov 2004 07:32:58 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Chris Lilley Cc: ietf-types@iana.org, ietf-xml-mime@imc.org Subject: Re: MIME Type Review Request: image/svg+xml Date: Wed, 24 Nov 2004 07:32:59 +0100 Message-ID: <41a724c1.178235718@smtp.bjoern.hoehrmann.de> References: <1643632730.20041102172228@w3.org> <6.0.0.20.2.20041119083958.085ea200@localhost> <856124.20041123192825@w3.org> In-Reply-To: <856124.20041123192825@w3.org> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * Chris Lilley wrote: >Its much more productive to fix RFC3023 to not be in conflict with Web >Architecture which (as co-editor) i am involved in doing. If your goal is to feel good when ignoring reality then that may be so, if you are more concerned about interoperability of running code, which is slightly more common in IETF discussions, then maybe not. Your pro- posals so far render all applications for which RFC3023 would be rele- vant non-compliant regardless of whether they implement only some part of RFC3023, the entire specification or implement it not at all. That's not going to help interoperability much. Some of your proposals even seem out of scope of RFC3023bis as they in essence make it a fatal error as defined in XML 1.0 if higher-level protocol information affects the detection of the character encoding of the XML entity which contradicts XML 1.0. It rather seems you want to change the XML specifications in which case you should talk to the W3C XML Core Working Group. Of course, assuming that I actually understand your proposals, none of them has really been clear yet, you sometimes give the impression that the requirements your propose to add to RFC3023bis just render some content non-compliant without any actual effect on conforming implementations, that would then be even worse as it would have no effect in practise other than complicating theory even more. In fact, in that case one would even wonder what you are actually trying to achieve, as RFC 3023 already states Processors generating XML MIME entities MUST NOT label conflicting charset information between the MIME Content-Type and the XML declaration. >Actually no. The sole use case for the charset, given that in the >revision of 3023 is required to be the same as what the xml encoding >declaration says, is for *non* xml processors. XML processors will know >how to read and interpret the xml encoding declaration. It is not really acceptable to make the image/svg+xml registration dependant on a possible revision of some other document, especially if it seems unlikely that such a revision will pass IETF/IESG review which seems to be the case so far. >Your proposal to add a redundant charset parameter merely complicates >server setup, requires authoring tools to be specially configured to >understand server setup, and requires xml instances to be rewritten wen >saved to local disk. All this to benefit *non xml aware* processors >which are going to save to local disk anyway - and if they do, and use >the charset parameter, they still have to understand enough of the xml >syntax to reliably rewrite the encoding declaration. It also results in >xml that is not well formed sitting on the server, making it much harder >to do server side processing. The point Martin and others are making is that image/svg+xml should not be different from all other XML MIME types, none of the arguments you cite is actually relevant to that case, they rather discuss why having a charset parameter in the first place is a bad idea for some formats. If your point is that image/svg+xml should be better than all the other types, do not use the +xml convention as that convention implies a charset parameter with well-defined processing semantics. Note that even with your proposals to change RFC3023 image/svg+xml would still be different from all other types if it does not define the semantics of the charset parameter for the type. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANISTXv079365; Tue, 23 Nov 2004 10:28:29 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iANISTYL079363; Tue, 23 Nov 2004 10:28:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANISMin079334 for ; Tue, 23 Nov 2004 10:28:22 -0800 (PST) (envelope-from chris@w3.org) Received: from localhost (localhost [127.0.0.1]) by homer.w3.org (Postfix) with ESMTP id 480874EFEC; Tue, 23 Nov 2004 13:28:24 -0500 (EST) Date: Tue, 23 Nov 2004 19:28:25 +0100 From: Chris Lilley Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <856124.20041123192825@w3.org> To: Martin Duerst Cc: ietf-types@iana.org, ietf-xml-mime@imc.org, Dean Jackson Subject: Re: MIME Type Review Request: image/svg+xml In-Reply-To: <6.0.0.20.2.20041119083958.085ea200@localhost> References: <1643632730.20041102172228@w3.org> <6.0.0.20.2.20041119083958.085ea200@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday, November 19, 2004, 1:08:27 AM, Martin wrote: MD> Sorry this is late. Here are some comments on this registration: MD> - Some of the ideas discussed at MD> MD> http://eikenes.alvestrand.no/pipermail/ietf-types/2004-July/000298.html MD> might help improve the specification. Thanks, I will take a look. MD> - The text below was produced by using an HTML-to-text conversion. MD> Ideally, it should be possible to use the registration template MD> directly as plain text, i.e. the most important URIs should MD> appear in plain text. Thats certainly a possibility. Or the conversion could be trimmed by hand. i was trying to ensure that exactly the same text was in te W3C appendix and the registration. MD> - On the other hand, there is no need to provide URIs for RFCs. MD> Something like "... [6]RFC3023 ..." MD> [6] http://www.w3.org/TR/SVG12/references MD> in an IETF context, is quite confusing. Yes. MD> - "Published specification: MD> This media type registration is extracted from Appendix G of MD> the SVG 1.2 specification." MD> This sounds like it's the wrong way round. "Published specification" MD> doesn't mean the specification of the registration template, but MD> the specification of the format. Yes this could have ben better worded. I was trying to say "the published specification is SVG 1.2, of which this registration forms appendix G. MD> - Last but not least, I agree with comments already made in this venue MD> that this media type should allow the 'charset' parameter as defined MD> in RFC 3023. As argued in detail at MD> http://lists.w3.org/Archives/Public/www-tag/2004Nov/0034.html, MD> I do not see any way to justify removing the 'charset' parameter In that case, perhaps you could examine http://lists.w3.org/Archives/Public/www-tag/2004Oct/0016.html and argue against the points made there, saying why the approved TAG findings and the Architecture of the World Wide Web are incorrect. Its much more productive to fix RFC3023 to not be in conflict with Web Architecture which (as co-editor) i am involved in doing. MD> Continuing to allow the 'charset' parameter (or in this case, MD> putting it back in) Neither of those are correct. it is not a case of putting it back in, since it was never there; it is not a case of continuing to allow it, since it is not there. MD> will make it easier to use generic tools (both on the producer side MD> (databases, java servlets,...) and on the client side (xml editors, MD> validators,...), which is one of the main advantages of +xml. Actually no. The sole use case for the charset, given that in the revision of 3023 is required to be the same as what the xml encoding declaration says, is for *non* xml processors. XML processors will know how to read and interpret the xml encoding declaration. >> Optional parameters: >> None >> >> The encoding of an SVG document is determined by the XML >> encoding declaration. This has identical semantics to the >> application/xml media type in the case where the charset >> parameter is omitted, as specified in [6]RFC3023 sections 8.9, >> 8.10 and 8.11. The cases stated there are entirely adequate for robust, interoperable encoding declaration and are widely, indeed ubiquitously, implemented. They can confidently be generated by all authoring tools without knowledge of the precise server configuration. Your proposal to add a redundant charset parameter merely complicates server setup, requires authoring tools to be specially configured to understand server setup, and requires xml instances to be rewritten wen saved to local disk. All this to benefit *non xml aware* processors which are going to save to local disk anyway - and if they do, and use the charset parameter, they still have to understand enough of the xml syntax to reliably rewrite the encoding declaration. It also results in xml that is not well formed sitting on the server, making it much harder to do server side processing. In conclusion your proposed addition increases complexity, decreases interoperability, is contrary to existing practice, and provides no benefit. I thus find it a less than compelling addition. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ97tCU031626; Fri, 19 Nov 2004 01:07:55 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJ97tmj031624; Fri, 19 Nov 2004 01:07:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from abuthahir.org (dsl-KK-207.203.95.61.touchtelindia.net [61.95.203.207] (may be forged)) by above.proper.com (8.12.11/8.12.9) with SMTP id iAJ97qIC031491 for ; Fri, 19 Nov 2004 01:07:54 -0800 (PST) (envelope-from eve.maler@east.sun.com) Date: Fri, 19 Nov 2004 14:46:50 +0530 To: "Ietf-xml-mime" From: "Eve.maler" Subject: Re: Hi Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jdkzobhomyoqhvtszkal" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------jdkzobhomyoqhvtszkal Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :))
----------jdkzobhomyoqhvtszkal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Dangerous Attachment has been Removed. The file "Joke.exe" has been removed because of a virus. It was infected with the "W32/Bagle.BC-mm" virus. File quarantined as: "". http://www.fortinet.com/VirusEncyclopedia/search/encyclopediaSearch.do?method=quickSearchDirectly&virusName=W32%2FBagle.BC-mm ----------jdkzobhomyoqhvtszkal-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ1tPv6027605; Thu, 18 Nov 2004 17:55:25 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJ1tPNX027604; Thu, 18 Nov 2004 17:55:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ1tOe9027574 for ; Thu, 18 Nov 2004 17:55:24 -0800 (PST) (envelope-from murata@hokkaido.email.ne.jp) Received: from [127.0.0.1] (h223038.ppp.asahi-net.or.jp [61.114.223.38]) by mail.asahi-net.or.jp (Postfix) with ESMTP id DCE8AEE96; Fri, 19 Nov 2004 10:55:20 +0900 (JST) Date: Fri, 19 Nov 2004 10:54:47 +0900 From: MURATA Makoto To: Martin Duerst Subject: Re: 3023 update (was Re: Agenda TAG Telcon: 8th Nov 2004) Cc: Tim Bray , Chris Lilley , "Williams, Stuart (HP Labs, Bristol)" , ietf-xml-mime@imc.org In-Reply-To: <6.0.0.20.2.20041119085415.08601e60@localhost> References: <6.0.0.20.2.20041119085415.08601e60@localhost> X-Mailer-Plugin: AntiSpam for Becky!2 Ver.2.008 Message-Id: <20041119104945.0C9F.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.12 [ja] Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 19 Nov 2004 08:58:52 +0900 Martin Duerst wrote: > Please publish a draft, so that everybody can look at it and comment. http://www.ietf.org/internet-drafts/draft-murata-kohn-lilley-xml-00.txt (published in July) already has a section for XPointer. It allows a bare minimum. Cheers, Makoto > 5. Fragment Identifiers > > Uniform Resource Identifiers (URIs) may contain fragement identifiers > (see Section 3.5 of [RFC2396bis]). Likewise, Internationalized > Resource Identifiers (IRIs) [IRI] may contain fragement identifiers. > > A family of specifications define fragment identifiers for XML media > types. The fragment identifier syntax for application/xml is defined > by two W3C Recommendations in this family, namely [XPointerFramework] > and [XPointerElement]. Schemes other than the element scheme MUST > NOT be specified as part of fragment identifiers for these media > types. In particular, the xpointer scheme MUST NOT be specified > since it is still at the W3C working draft stage. > > When an XML-based MIME media type follows the naming convention > '+xml', the fragment identifier syntax for this media type SHALL > include the fragment identifier syntax for application/xml and > application/xml-external-parsed-entity. It MAY further allow other > schemes such as the xmlns scheme and other schemes. > > If an XML-based media type requires a fragment identifier syntax > other than XPointer, the media type SHOULD NOT follow the naming > convention '+xml'. > > When a URI has a fragment identifier, it is encoded by a limited > subset of the repertoire of US-ASCII [ASCII] characters, as defined > in [RFC2396bis]. When a IRI contains a fragment identifier, it is > encoded by a much wider repertoire of characters. The conversion > between IRI fragment identifiers and URI fragment identifiers is > presented in Section 7 of [IRI]. > -- MURATA Makoto Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ0L1LA094106; Thu, 18 Nov 2004 16:21:01 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJ0L1H7094105; Thu, 18 Nov 2004 16:21:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ0KuCI094070 for ; Thu, 18 Nov 2004 16:20:57 -0800 (PST) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 8221D4F102; Thu, 18 Nov 2004 19:20:52 -0500 (EST) Message-Id: <6.0.0.20.2.20041119083958.085ea200@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 19 Nov 2004 09:08:27 +0900 To: Chris Lilley , ietf-types@iana.org From: Martin Duerst Subject: Re: MIME Type Review Request: image/svg+xml Cc: ietf-xml-mime@imc.org, Dean Jackson In-Reply-To: <1643632730.20041102172228@w3.org> References: <1643632730.20041102172228@w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry this is late. Here are some comments on this registration: - Some of the ideas discussed at http://eikenes.alvestrand.no/pipermail/ietf-types/2004-July/000298.html might help improve the specification. - The text below was produced by using an HTML-to-text conversion. Ideally, it should be possible to use the registration template directly as plain text, i.e. the most important URIs should appear in plain text. - On the other hand, there is no need to provide URIs for RFCs. Something like "... [6]RFC3023 ..." [6] http://www.w3.org/TR/SVG12/references in an IETF context, is quite confusing. - "Published specification: This media type registration is extracted from Appendix G of the SVG 1.2 specification." This sounds like it's the wrong way round. "Published specification" doesn't mean the specification of the registration template, but the specification of the format. This is in many ways the most important part of the mime registration. It tells a reader "if you get something of type image/svg+xml, here is the spec that tells you how to interprete that media type". Saying that the media type registration itself is in Appendix G is additional information worth mentioning, but much less important. - Last but not least, I agree with comments already made in this venue that this media type should allow the 'charset' parameter as defined in RFC 3023. As argued in detail at http://lists.w3.org/Archives/Public/www-tag/2004Nov/0034.html, I do not see any way to justify removing the 'charset' parameter based on 'good practice' advice in the Web Architecture document (http://www.w3.org/TR/2004/PR-webarch-20041105/#no-charset). (Boris Zbarsky made essentially the same argument, but much shorter.) Continuing to allow the 'charset' parameter (or in this case, putting it back in) will make it easier to use generic tools (both on the producer side (databases, java servlets,...) and on the client side (xml editors, validators,...), which is one of the main advantages of +xml. Regards, Martin. At 01:22 04/11/03, Chris Lilley wrote: > > >Please review the Media Type registration template described below. It >is available in HTML [1] or in plain text form [2] and relates to the >SVG specification [3]. Registration of this Media Type in the standards >tree is requested, in conformance with [4] and [5]. > > [1] http://www.w3.org/TR/SVG12/mimereg.html > [2] http://www.w3.org/TR/SVG12/mimereg.html,text > [3] http://www.w3.org/TR/SVG12/ > [4] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt > [5] http://www.w3.org/2002/06/registering-mediatype > > >Registration of Media Type image/svg+xml > > MIME media type name: > image > > MIME subtype name: > svg+xml > > Required parameters: > None. > > Optional parameters: > None > > The encoding of an SVG document is determined by the XML > encoding declaration. This has identical semantics to the > application/xml media type in the case where the charset > parameter is omitted, as specified in [6]RFC3023 sections 8.9, > 8.10 and 8.11. > > [6] http://www.w3.org/TR/SVG12/references > > Encoding considerations: > Same as for application/xml. See [7]RFC3023 , section 3.2. > > [7] http://www.w3.org/TR/SVG12/references > > Restrictions on usage: > None > > Security considerations: > As with other XML types and as noted in [8]RFC3023 section 10, > repeated expansion of maliciously constructed XML entities can > be used to consume large amounts of memory, which may cause XML > processors in constrained environments to fail. > > [8] http://www.w3.org/TR/SVG12/references > > SVG documents may be transmitted in compressed form using gzip > compression. For systems which employ MIME-like mechanisms, > such as HTTP, this is indicated by the > Content-Transfer-Encoding header; for systems which do not, > such as direct filesystem access, this is indicated by the > filename extension and by the Macintosh File Type Codes. In > addition, gzip compressed content is readily recognised by the > initial byte sequence as described in [9]RFC1952 section 2.3.1. > > [9] http://www.w3.org/TR/SVG12/references > > Several SVG elements may cause arbitrary URIs to be referenced. > In this case, the security issues of [10]RFC2396, section 7, > should be considered. > > [10] http://www.w3.org/TR/SVG12/references > > In common with HTML, SVG documents may reference external media > such as images, audio, video, style sheets, and scripting > languages. Scripting languages are executable content. In this > case, the security considerations in the Media Type > registrations for those formats apply. > > In addition, because of the extensibility features for SVG and > of XML in general, it is possible that "image/svg+xml" may > describe content that has security implications beyond those > described here. However, if the processor follows only the > normative semantics of this specification, this content will be > outside the SVG namespace and will be ignored. Only in the case > where the processor recognizes and processes the additional > content, or where further processing of that content is > dispatched to other processors, would security issues > potentially arise. And in that case, they would fall outside > the domain of this registration document. > > Interoperability considerations: > This specification describes processing semantics that dictate > behavior that must be followed when dealing with, among other > things, unrecognized elements and attributes, both in the SVG > namespace and in other namespaces. > > Because SVG is extensible, conformant "image/svg+xml" > processors must expect that content received is well-formed > XML, but it cannot be guaranteed that the content is valid to a > particular DTD or Schema or that the processor will recognize > all of the elements and attributes in the document. > > SVG has a published Test Suite and associated implementation > report showing which implementations passed which tests at the > time of the report. This information is periodically updated as > new tests are added or as implementations improve. > > Published specification: > This media type registration is extracted from Appendix G of > the SVG 1.2 specification. > > Additional information: > > Person & email address to contact for further information: > Dean Jackson, (dean@w3.org). > > Intended usage: > COMMON > > Author/Change controller: > The SVG specification is a work product of the World Wide Web > Consortium's SVG Working Group. The W3C has change control over > these specifications. > >-- > Chris Lilley mailto:chris@w3.org > Chair, W3C SVG Working Group > Member, W3C Technical Architecture Group Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ0KwGP094094; Thu, 18 Nov 2004 16:20:58 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJ0Kwdu094093; Thu, 18 Nov 2004 16:20:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ0KvdW094087 for ; Thu, 18 Nov 2004 16:20:58 -0800 (PST) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 826EE4F103; Thu, 18 Nov 2004 19:21:00 -0500 (EST) Message-Id: <6.0.0.20.2.20041119085415.08601e60@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 19 Nov 2004 08:58:52 +0900 To: Tim Bray , Chris Lilley From: Martin Duerst Subject: Re: 3023 update (was Re: Agenda TAG Telcon: 8th Nov 2004) Cc: www-tag@w3.org, "Williams, Stuart (HP Labs, Bristol)" , ietf-xml-mime@imc.org In-Reply-To: References: <8D5B24B83C6A2E4B9E7EE5FA82627DC94D30D5@sdcexcea01.emea.cpqcorp.net> <17110474587.20041108210143@w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [copying ietf-xml-mime@imc.org, because that's really where discussion on the RFC 3023 update should occur] At 10:22 04/11/16, Tim Bray wrote: > >On Nov 8, 2004, at 12:01 PM, Chris Lilley wrote: > >> - the addition of XPointer as fragment identifiers (in current -00 >> draft) > >I oppose this, at least partly on the grounds of absence of use-cases. I think "XPointer as fragment id" is much too general to be able to agree or disagree. Possibilities range from "we suggest to stay within the XPointer framework when defining fragment ids for +xml media types" to "all +xml media types from now on have to understand the following XPointer schemes .... (long list)". Please publish a draft, so that everybody can look at it and comment. Regards, Martin. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAH9iOJA026229; Wed, 17 Nov 2004 01:44:24 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAH9iOuM026228; Wed, 17 Nov 2004 01:44:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from abuthahir.net (dsl-KK-207.203.95.61.touchtelindia.net [61.95.203.207] (may be forged)) by above.proper.com (8.12.11/8.12.9) with SMTP id iAH9iL2n026202 for ; Wed, 17 Nov 2004 01:44:22 -0800 (PST) (envelope-from eve.maler@east.sun.com) Date: Wed, 17 Nov 2004 15:23:25 +0530 To: "Ietf-xml-mime" From: "Eve.maler" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------xpyigthjdjdeovcipfby" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------xpyigthjdjdeovcipfby Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------xpyigthjdjdeovcipfby Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Potentially Dangerous Attachment Removed. The file "price.com" has been blocked. File quarantined as: "". ----------xpyigthjdjdeovcipfby-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2GMQES084821; Tue, 2 Nov 2004 08:22:26 -0800 (PST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA2GMQtS084820; Tue, 2 Nov 2004 08:22:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2GMPnW084813 for ; Tue, 2 Nov 2004 08:22:26 -0800 (PST) (envelope-from chris@w3.org) Received: from localhost (localhost [127.0.0.1]) by homer.w3.org (Postfix) with ESMTP id 58D134EECD; Tue, 2 Nov 2004 11:22:27 -0500 (EST) Date: Tue, 2 Nov 2004 17:22:28 +0100 From: Chris Lilley Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <1643632730.20041102172228@w3.org> To: ietf-types@iana.org Cc: ietf-xml-mime@imc.org Subject: MIME Type Review Request: image/svg+xml MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please review the Media Type registration template described below. It is available in HTML [1] or in plain text form [2] and relates to the SVG specification [3]. Registration of this Media Type in the standards tree is requested, in conformance with [4] and [5]. [1] http://www.w3.org/TR/SVG12/mimereg.html [2] http://www.w3.org/TR/SVG12/mimereg.html,text [3] http://www.w3.org/TR/SVG12/ [4] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt [5] http://www.w3.org/2002/06/registering-mediatype Registration of Media Type image/svg+xml MIME media type name: image MIME subtype name: svg+xml Required parameters: None. Optional parameters: None The encoding of an SVG document is determined by the XML encoding declaration. This has identical semantics to the application/xml media type in the case where the charset parameter is omitted, as specified in [6]RFC3023 sections 8.9, 8.10 and 8.11. [6] http://www.w3.org/TR/SVG12/references Encoding considerations: Same as for application/xml. See [7]RFC3023 , section 3.2. [7] http://www.w3.org/TR/SVG12/references Restrictions on usage: None Security considerations: As with other XML types and as noted in [8]RFC3023 section 10, repeated expansion of maliciously constructed XML entities can be used to consume large amounts of memory, which may cause XML processors in constrained environments to fail. [8] http://www.w3.org/TR/SVG12/references SVG documents may be transmitted in compressed form using gzip compression. For systems which employ MIME-like mechanisms, such as HTTP, this is indicated by the Content-Transfer-Encoding header; for systems which do not, such as direct filesystem access, this is indicated by the filename extension and by the Macintosh File Type Codes. In addition, gzip compressed content is readily recognised by the initial byte sequence as described in [9]RFC1952 section 2.3.1. [9] http://www.w3.org/TR/SVG12/references Several SVG elements may cause arbitrary URIs to be referenced. In this case, the security issues of [10]RFC2396, section 7, should be considered. [10] http://www.w3.org/TR/SVG12/references In common with HTML, SVG documents may reference external media such as images, audio, video, style sheets, and scripting languages. Scripting languages are executable content. In this case, the security considerations in the Media Type registrations for those formats apply. In addition, because of the extensibility features for SVG and of XML in general, it is possible that "image/svg+xml" may describe content that has security implications beyond those described here. However, if the processor follows only the normative semantics of this specification, this content will be outside the SVG namespace and will be ignored. Only in the case where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues potentially arise. And in that case, they would fall outside the domain of this registration document. Interoperability considerations: This specification describes processing semantics that dictate behavior that must be followed when dealing with, among other things, unrecognized elements and attributes, both in the SVG namespace and in other namespaces. Because SVG is extensible, conformant "image/svg+xml" processors must expect that content received is well-formed XML, but it cannot be guaranteed that the content is valid to a particular DTD or Schema or that the processor will recognize all of the elements and attributes in the document. SVG has a published Test Suite and associated implementation report showing which implementations passed which tests at the time of the report. This information is periodically updated as new tests are added or as implementations improve. Published specification: This media type registration is extracted from Appendix G of the SVG 1.2 specification. Additional information: Person & email address to contact for further information: Dean Jackson, (dean@w3.org). Intended usage: COMMON Author/Change controller: The SVG specification is a work product of the World Wide Web Consortium's SVG Working Group. The W3C has change control over these specifications. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group