Re: The 'image/svg+xml' Media Type

On Tuesday, June 18, 2002, 12:42:50 PM, Jim wrote:


JL> "Chris Lilley" <chris@w3.org>
>> On Tuesday, June 18, 2002, 12:25:04 AM, Jim wrote:
>> >> I'd be interested to know whether the W3C has any intention of
>> >> submitting an Internet-Draft for this media type in the near future;
>>
>> JL> I'd be interested to know why the WG has not already submitted one,
JL> we're
>> JL> stuck in a situation where on pragmatic grounds we have little
JL> choice but
>> JL> to have image/svg+xml if we're not going to break existing
>> JL> implementations.
>>
>> The mime type was defined in the SVG 1.0 Rec. Go ahead and use it.
>> Thats not (just) pragmatism, its standards compliance.

JL> The W3 publish standards? I thought they published recommendations...

The recommendations are themselves web standards, yes.

JL>  I
JL> appreciate that it can be time consuming and I appreciate that there
JL> were/are dependancies on other registrations,

Not on other resistrations so much, no

JL> but to have left it so long to not even have a draft,

What makes you think we don't have a draft?

What makes you think that we "left it so long"? What makes you think
that we were not involved in the "XML Media Types" discussion and that
the image/svg+xml media type was not pre-reserved as a result of those
discussions?

Also, in the past, the requirement from IANA was a 'stable
specification" which meant a Rec, so it was not possible to register
before getting a Rec. That is in process of changing, because its a
well known catch-22 situation. But it hasn't changed yet.

JL>  that the web is now stuck with image/svg+xml

"Stuck with"?

JL> whatever objections may be found to image/svg+xml .

Such as?

>> The necessary paperwork for IANA/IETF is in process, but has a number
>> of dependencies including new procedures for registration of W3C media
>> types with IANA, currently being put into place; the security section
>> as you mentioned, and the charset requirements of application/xml
>> which mandate breakage and needs to be fixed.

JL> In CERT Advisory CA-2000-02, it says you must serve text/html with a
JL> charset for security reasons - I realise XML has available defaults, but
JL> does it fully solve the problem?

Yes, it does. If the encoding ('charset') is anything other than UTF-8
or UTF-16 then it must be declared in the xml encoding declaration or
there will be a well formedness error in the XML parser. That is a lot
more robust than any non-XML media type.

>> JL> The SVG Working groups ease of inventing mime-types is something to
JL> worry
>> JL> about.
>>
>> A 'because' would have been good in that sentence.

JL> because they reference "text/ecmascript" a mime type belonging to a
JL> technology wholly outside their control

Actually, W3C staff are involved in the development of ECMAscript for
several years now.

JL> and highly unlikely to ever be a registered mime-type

On the contrary, its in process of registration.

JL> as there are strong arguments against it.

"Such as"??

JL> That shows a recklessness which is something to worry about.

I think your FUD without arguments to back it up is equally reckless,
but there we are.


-- 
 Chris                            mailto:chris@w3.org

Received on Tuesday, 18 June 2002 08:15:14 UTC