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

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

2004-11-24 07:18:59

* 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

  <?xml version="1.0" encoding="utf-8"?>
  ... 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.