ietf-xml-mime
[Top] [All Lists]

Re: MIME Type Review Request: image/svg+xml

2004-11-23 23:33:11

* 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.