RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 4778, "Operational Security Current Practices in Internet Service Provider Environments", January 2007

Source of RFC: opsec (ops)

Errata ID: 843
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-01-22
Held for Document Update by: Ron Bonica

 

Studying the recently published RFC 4788 (EVRCB)
authored by you, and comparing it with similar recent
publications,  I'm surprised to find a quite unusual
syntax used in the 'a=fmtp' SDP lines there.

Usually, media type parameters included into 'a=fmtp' SDP lines
are separated by semicolons as in the MIME type declaration.

The most recent RFC formally specifying this behaviour was
RFC 4749, Section 6.2 of which says:

   o  Any remaining parameters go in the SDP "a=fmtp" attribute by
      copying them directly from the media type string as a semicolon
      separated list of parameter=value pairs.

As another example, RFC 4396, in section 9.1, explicitely specifies
the syntax as:
        a=fmtp:<dynamic payload type>
               <parameter name>=<value>[,<value>]
               [; <parameter name>=<value>]

Note: This is *not* ABNF, as can be ssen from the context there.
      Matching RFC-4234 ABNF should have been stated there as:
        a=fmtp:<dynamic-payload-type>
               <parameter-name> "=" <value> *("," <value>)
               *(";" <parameter-name> "=" <value> *("," <value>))

This was common practice over many years.

Section 6.7 of RFC 4788 deviates from this practice, omitting
the semicolon in the examples.  From the prose description,
it is not quite clear whether the phrase,
    "... copying it directly from the MIME media type string"
was meant to comprise the separating semicolons often considered
part of MIME type parameters as well, or not.
Unfortunately, no precise formal description (ABNF) is given.
The examples given all omit the usual semicolons, e.g.:

     a=fmtp:97 silencesupp=1 dtxmax=32 dtxmin=12 hangover=1
                            ^         ^         ^

Has this omission been done intentionally?

If yes, what have been the reasons to do so?
  I fear that the unusual definition might cause
  interoperability problems; at least it makes the use
  of uniform parsing of 'a=fmtp' SDP lines impossible.

It should say:

[not submitted]

Notes:

from pending

Report New Errata