Registration request for MIME media type tag 3gpp-ims+xml

Bjoern Hoehrmann derhoermi at
Fri Jul 11 20:06:43 CEST 2008

* John-Luc Bakker wrote:
>In SIP, use of the accept header field and the content-type header
>field provides open and extensible data typing and type negotiation
>The Accept header field (RFC 3261, section 20.1) of a SIP request
>indicates the formats accepted by the SIP UAC. MIME media type and their
>parameters can be listed in the Accept header for that purpose. Thus,
>what the SIP UAC is indicating are the variations of the MIME type (i.e.
>application/3gpp-ims+xml) that are accepted.
>The Content-Type header field (RFC 3261, section 20.15) can be found in
>a SIP response and request and indicates the MIME media type of the SIP
>message-body. MIME media type and their parameters can be listed in the
>Content-Type header field for that purpose. Thus, it provides a hint to
>the recipient as to how to decode the material and, in particular in the
>case of "application/3gpp-ims+xml", which schema to validate the body
>The semantics of the parameter are those of the header field the
>parameter is placed in.

Thanks, I see now where my confusion is coming from. From my perspective
the semantics of the parameter and its value are the same in both cases,
and was under the impression that, as an example, you can specify ranges
in the parameter when used in 'Accept' and must specify a single version
in the 'Content-Type' parameter.

I think it would be preferable if this could be reworded to avoid this
confusion; but I can't immediately offer better text, other than some-
thing more unspecific ala "Indicates relevant 3GPP IM CN Subsystem XML
versions (e.g., that an implementation or document conforms to)" which
I am not sure you would find an improvement.
Björn Höhrmann · mailto:bjoern at ·
Weinh. Str. 22 · Telefon: +49(0)621/4309674 ·
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · 

More information about the Ietf-types mailing list