¿Cuál es la diferencia entre text / xml versus application / xml para la respuesta del servicio web?

Esta es más una pregunta general sobre la diferencia entre text/xml y application/xml . Soy bastante nuevo en la redacción de servicios web (REST – Jersey). He estado produciendo application/xml ya que es lo que aparece en la mayoría de los tutoriales / ejemplos de código que he estado usando para aprender, pero recientemente descubrí text/xml y me preguntaba qué es diferente y cuándo lo usarías. sobre la application/xml ?

De la RFC ( 3023 ), en la sección 3, Tipos de medios XML:

Si un documento XML, es decir, el documento XML fuente no procesado, es legible para usuarios casuales, text / xml es preferible a application / xml. Los agentes de usuario MIME (y los agentes de usuario web) que no tienen soporte explícito para text / xml lo tratarán como texto / texto simple, por ejemplo, mostrando la entidad XML MIME como texto sin formato. La aplicación / xml es preferible cuando la entidad XML MIME no puede leerse por usuarios ocasionales.

(énfasis mío)

Esta es una vieja pregunta, pero una que se visita con frecuencia y las recomendaciones claras están ahora disponibles de RFC7303 que obsoleto 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". 

De acuerdo con este artículo , se prefiere la aplicación / xml.


EDITAR

Hice un poco de seguimiento sobre el artículo.

El autor afirma que la encoding declarada en las instrucciones de procesamiento XML, como:

 < ?xml version="1.0" encoding="UTF-8"?> 

se puede ignorar cuando se utiliza el tipo de medio text/xml .

Respaldan la tesis con la definición de text/* especificación de familia de tipo 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", ie, 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 pueden evitarse al usar application/xml tipo MIME. Ya sea cierto o no, no llegaría tan lejos como para evitar el text/xml . En mi humilde opinión, lo mejor es seguir la semántica de la legibilidad humana (no legibilidad) y siempre recordar especificar el juego de caracteres.

application/xml es vista por svn como un tipo binario mientras que text/xml como un archivo de texto para el cual se puede mostrar una diferencia.