On Tue, 2012-07-24 at 10:35 -0400, Paul Kyzivat wrote:
> Section 4.2 of RFC 4288 says: "Both type and subtype names are
> case-insensitive." That should be operable since "telephone-events" is a
> mime subtype.
Given the text in RFC 4566 section 6:
In the example above, the media types are "audio/l8" and
"audio/l16".
and the heading, in
http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml:
In addition to the RTP payload formats (encodings) listed in the RTP
Payload Types table, there are additional payload formats that do not
have static RTP payload types assigned but instead use dynamic payload
type number assignment. Each payload format is named by a registered
media subtype as listed in the following table. As new payload formats
are specified, their registered media subtypes should be added to this
table. In addition, for the payload formats listed in the RTP Payload
Types table above, the "encoding name" is also registered as a media
subtype under the media type "audio" or "video". The clock rate and
number of channels shown here are the normal values for those payload
formats that have a normal value.
I think I agree with you. But I'm wonder if the authors of RFC 4566
really considered the issue, and I expect that many implementations are
case sensitive.
Here's one more relevant text. It looks like others have considered
this problem:
RFC 4855 section 3 (Feb 2007) and also RFC 3555 section 3 (Feb 2003)
Note that the payload format (encoding) names defined in the RTP
Profile [4] are commonly shown in upper case. Media subtype names
are commonly shown in lower case. These names are case-insensitive
in both places. Similarly, parameter names are case-insensitive both
in media type strings and in the default mapping to the SDP a=fmtp
attribute.
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
