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