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

"Chris Lilley" <chris@w3.org>
> On Wednesday, June 19, 2002, 9:17:56 PM, Jim wrote:
>
>
> JL> "David Woolley" <david@djwhome.demon.co.uk>
> >> From: Jim Ley [SMTP:jim@jibbering.com]
> >>
> >> > Given that conformant dynamic SVG applications must implement
> JL> ECMAScript
> >> > that being the same is not IMO sufficient.
> >>
> >> If conformance requires scripting support, I would say that there is
no
> >> way that image/ is appropriate.
>
> JL> I'm not as dogmatic as that, but I do think it's a good reason to
not
> JL> consider image/svg+xml "a given", when registration is attempted,
>
> It is, first an foremost, an image format. So image/* is clearly the
> appropriate choice.

because...  citing examples of other successful registrations of content
types that are inherently document markup which include visual elements
and the ability to run programs on the client computer.

If you've got a draft of the RFC, why not make it available now, as we're
having the discussion anyway, it would help to clarify the working groups
views.


> JL> this
> JL> may well address my concerns.  Other security concerns are what
happens
> JL> when potentially dangerous content is included in a foriegnObject
> JL> element, - SVG needs to be considered as evil as the most evil
thing that
> JL> can be included in a foriegn object.
>
> No, the security concerns are those of the included content. Which is
> not quite the same thing.

I completely disagree, I need to know the security implications of a
package _before_ I deal with it, purely at the level of the mime-type, to
know through what level of security scanning I pass it through - for
example I am completely happy to have a static SVG image render straight
off, however an image with scripts I require to be viewed in a particular
browser that has added protection against bad scripts. So for content
delivered as image/svg+xml a user must believe until proven otherwise
that it contains the worst for security.

> >> If compliance
> >> requires scripting, I'm unlikely to allow my browser to be fully
> JL> compliant most
> >> of the time  and some organisations are likely to make this
corporate
> JL> policy.
>
> Disabling scripting does not make it non compliant.

I don't agree that follows, What is the argument for requiring scripting
then?  Can all the other conformance requirements also be got around with
configuration - does it matter what the defaults are?

> JL> and toggle scripts is a (currently) P1 in UAAG, so lets hope that
future
> JL> versions do have this requirement -  with both UAAG 1 and SVG 1.1
at CR
> JL> stage - is it something that could be addressed in SVG 1.1 ?
>
> I would say there is scope for clarifying what happens when scripting
> is disabled at user option, yes.

I asked specifically, that now UAAG 1 and SVG 1.1 are at the same level,
can you place the UAAG 1 requirement on conforming SVG viewers, as SVG 1
implied you were going to.

Can I also ask once again, why the SVG Working Groups charter is not
available to the public?

Jim.

Received on Thursday, 20 June 2002 07:45:36 UTC