RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 4588, "RTP Retransmission Payload Format", July 2006

Source of RFC: avt (rai)

Errata ID: 48
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-08-14
Rejected by: Jose Rey

Section 8.1 says:

   The following MIME subtype name and parameters are introduced in this
   document: "rtx", "rtx-time", and "apt".

   The binding used for the retransmission stream to the payload type
   number is indicated by an rtpmap attribute.  The MIME subtype name
   used in the binding is "rtx".

   The "apt" (associated payload type) parameter MUST be used to map the
   retransmission payload type to the associated original stream payload
   type.  If multiple original payload types are used, then multiple
   "apt" parameters MUST be included to map each original payload type
   to a different retransmission payload type.

It should say:

   The following MIME subtype name and parameters are introduced in this
   document: "rtx", "rtx-time", and "apt".

   The binding used for the retransmission stream to the payload type
   number is indicated by an rtpmap attribute.  The MIME subtype name
   used in the binding is "rtx".  The MIME type of the retransmission
   stream MUST be the same as the MIME type of the original stream.

   The "apt" (associated payload type) parameter MUST be used to map the
   retransmission payload type to the associated original stream payload
   type.  If multiple original payload types are used, then multiple
   "apt" parameters MUST be included to map each original payload type
   to a different retransmission payload type.

Notes:

This text only addresses the use of the media *sub*-type. Apparently,
it is implied that the media *type* of the associated streams match,
but I could not find a statement to this end in the RFC.

(In accordance with the language of RFC 4588, but contrary to BCP 13,
RFC 4288, I have again used the traditional wording "MIME type" here
instead of the currently recommended "media type".)

from pending

--VERIFIER COMMENT--

Thanks for your comments. However, I don't consider them worth of correction. Most are just editorial nits, some of which are even wrong. So, for the time being as Joerg said:

"We will be happy to archive these and migt consider them if we do a revision of the RFC. But an errata document would only make sense if there is something seriously hindering interoperability. I have not seen anything falling into this category (well, and there are implementations out there from the spec)."

Report New Errata



Advanced Search