Re: [AVT] Interop issue with H263-1998

[Randell Jesup <rjesup at wgate.com>]

"Even, Roni" <roni.even at polycom.co.il> writes:
>I am confused.
>RFC 3555 registered the payload type for H263-1998 and H263-2000. 
>The only optional parameters specified were profile and level for
>H263-2000 payload type.
>So the statement in RFC 4629 about no older parameters is correct.
>If you claim that there are other optional parameters for H263-1998
>please point me to such a document.

No document.  My point was that many implementations use parameters
with H263, H263-1998, and H263-2000 in ways incompatible with RFC 4629.
4629 stated that older implementations will ignore these parameters.
Many (most?) won't.  I agree older *standards* don't include them, and
older implementations would ignore them *if* they strictly implemented
the older standard with no additions.  And yes, they use these parameters
with video/H263, not just H263-1998 and 2000 (though in theory that
wouldn't impact RFC 4629's statement, since it only updates 1998 and 2000).

>There was an early revision of draft-ietf-avt-rfc2429-bis that became
>RFC 4629 that by mistake listed space separated list of parameters
>instead of semicolon-separated as specified in RFC3555.

Perhaps that's what they all implemented.  But I suspect (no proof) the
mistake may have been an codifying of existing usage, which got removed
from the draft - and that causes potential interoperability problems.

>As for you second comment about the "P" parameter I do not understand
>your concerns. 

There's no syntax specifed for the apparent combination of values:

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

Without the example I would never have known that it's a comma-separated
list (I assume).  Are spaces allowed?  Who knows.  Per rfc 4288: 

>> >From RFC 4288 referenced by RFC 4566:
>> 
>>    There is no defined syntax for parameter values.  Therefore
>>    registrations MUST specify parameter value syntax. 


>RFC 4288 is a BCP for media type registration. I assume that in AVT we
>follow it but also follow RFC 3555


>Roni Even
>
>> -----Original Message-----
>> From: Randell Jesup [mailto:rjesup at wgate.com]
>> Sent: Saturday, September 08, 2007 5:03 PM
>> To: Colin Perkins
>> Cc: Regis Crinon; Franceschini Guido; Gary Sullivan; avt at ietf.org;
>Walid
>> Ali; Paltro Pier Carlo
>> Subject: Re: [AVT] Interop issue with H263-1998
>> 
>> >> 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


-- 
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