Re: [AVT] Interop issue with H263-1998

[Randell Jesup <rjesup at wgate.com>]

>> As best I can tell, there were various ad-hoc SDP setups for H.263
>> before RFC 4629.  Many of them supported optional parameters (in
>> particular resolution and MPI), in contradiction of RFC 4629 section 9.1
>> (which says that old implementations will ignore these parameters).  For
>> added fun, RFC 4629 doesn't specify the grammar for the fmtp parameters;
>> it assumes silently (based on other RFCs one assumes) that they'll be
>> delimited by semicolons.  Many/most existing H.263/263+ applications
>> delimit fmtp parameters with spaces instead.  RFC 4566 doesn't even
>> mention semicolons or the details of the ftmp string -- 4566 considers
>> the fmtp string to be none of its business.  The problem is that
>> different implementers may make different assumptions about the grammar
>> for the fmtp line.  Perhaps I've missed something...
>
>RFC 4629 section 8.2 states:
>
>    o The optional parameters, if any, MUST be included in the "a=fmtp"
>      line of SDP.  These parameters are expressed as a media type
>      string, in the form of a semicolon-separated list of
>      parameter=value pairs.

Aha.  Missed that this time (I knew I'd read that semicolons were required
somewhere, but I only searched 4566 this time).

My real point was that existing implementations used parameters (with the
same names as the ones in 4629), so the statement in 4629 that older
implementations will ignore 4629 parameters is false, and the older
implementations of h263, h263-1998 and h263-2000 often (usually?) use
spaces instead of semicolons as delimiters will cause odd interoperability
problems if someone insists on semicolons when parsing (and I suspect that
some existing implementations insist on spaces, though I have no proof of
that yet).

>The legal syntax of a media type string is specified in the MIME  RFCs,
>which are included by reference via a citation to RFC 3555.

>From RFC 4288 referenced by RFC 4566:

   There is no defined syntax for parameter values.  Therefore
   registrations MUST specify parameter value syntax.  Additionally,
   some transports impose restrictions on parameter value syntax, so
   care should be taken to limit the use of potentially problematic
   syntaxes; e.g., pure binary valued parameters, while permitted in
   some protocols, probably should be avoided.

   New parameters SHOULD NOT be defined as a way to introduce new
   functionality in types registered in the standards tree, although new
   parameters MAY be added to convey additional information that does
   not otherwise change existing functionality.  An example of this
   would be a "revision" parameter to indicate a revision level of an
   external specification such as JPEG.  Similar behavior is encouraged
   for media types registered in the vendor or personal trees but is not
   required.

The paragraph from RFC 4629 section 8.2 may cover the first paragraph
above, though I'd have expected something more descriptive of the syntax.
Witness this from 4629 - where is this syntax specified except in the
example?

      "P": Reference Picture Resampling, in which the following submodes
      are represented as a number from 1 to 4:

      1: dynamicPictureResizingByFour
      2: dynamicPictureResizingBySixteenthPel
      3: dynamicWarpingHalfPel
      4: dynamicWarpingSixteenthPel

      Example: P=1,3

The second paragraph from RFC 4288 would seem to be violated by RFC 4629.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt