Te damos la bienvenida a nuestra comunidad, en este sitio hallarás la solucíon a lo que necesitas.
Solución:
De la RFC (3023), en la sección 3, Tipos de medios XML:
Si un documento XML, es decir, el documento XML de origen sin procesar, es legible por usuarios ocasionales, texto / xml es preferible a application / xml. Los agentes de usuario MIME (y los agentes de usuario web) que no tienen soporte explícito para texto / xml lo tratarán como texto / sin formato, por ejemplo, mostrando la entidad XML MIME como texto sin formato.
Aplicación / xml es preferible cuando la entidad XML MIME es ilegible
por usuarios ocasionales.
(énfasis mío)
Esta es una pregunta antigua, pero una que se visita con frecuencia y ahora hay recomendaciones claras disponibles de RFC 7303 que obsoleta RFC3023. En pocas palabras (sección 9.2):
The registration information for text/xml is in all respects the same
as that given for application/xml above (Section 9.1), except that
the "Type name" is "text".
Según este artículo, se prefiere application / xml.
EDITAR
Hice un pequeño seguimiento del artículo.
El autor afirma que la codificación declarada en las instrucciones de procesamiento XML, como:
puede ser ignorado cuando text/xml se utiliza el tipo de medio.
Apoyan la tesis con la definición de text/* Especificación de la familia de tipos MIME en RFC 2046, específicamente el siguiente fragmento:
4.1.2. Charset Parameter
A critical parameter that may be specified in the Content-Type field
for "text/plain" data is the character set. This is specified with a
"charset" parameter, as in:
Content-type: text/plain; charset=iso-8859-1
Unlike some other parameter values, the values of the charset
parameter are NOT case sensitive. The default character set, which
must be assumed in the absence of a charset parameter, is US-ASCII.
The specification for any future subtypes of "text" must specify
whether or not they will also utilize a "charset" parameter, and may
possibly restrict its values as well. For other subtypes of "text"
than "text/plain", the semantics of the "charset" parameter should be
defined to be identical to those specified here for "text/plain",
i.e., the body consists entirely of characters in the given charset.
In particular, definers of future "text" subtypes should pay close
attention to the implications of multioctet character sets for their
subtype definitions.
Según ellos, tales dificultades se pueden evitar al usar application/xml Tipo de Mimica. Ya sea true o no, no iría tan lejos como para evitar text/xml. En mi humilde opinión, es mejor seguir la semántica de legibilidad humana (no legibilidad) y recordar siempre especificar el juego de caracteres.