RE: [AVT] Interop issue with H263-1998

["Even, Roni" <roni.even at polycom.co.il>]

Randell,
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.
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.

As for you second comment about the "P" parameter I do not understand
your concerns. 
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

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