Re: [payload] [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes.

On 23 May 2011, at 08:55, Martin J. Dürst wrote:
> Just some minor nits:
> 
> Instead of things like "Security considerations: See Section 9 of this document." and "Author: See Authors' Address section at the end of this document." it would be better to replace "this document" with e.g. something like [RFCxxxx], with an note to the RFC Editor/IANA to replace [RFCxxxx] with the eventual RFC number. That way, the template can stand alone.
> 
> Also, while "Change controller: IETF Audio/Video Transport working group delegated from the IESG." is quite a good description of the current reality, it's not necessarily future-proof. You don't want to go through the registration process again just because a WG gets closed. These registrations usually just have "The IETF" as a change controller, with the implicit assumption that this may involve a WG and the IESG.

The current phrasing was suggested by our area director when AVT started doing media type registrations for payload formats, and lists "delegated from the IESG" to avoid the need to redo registrations when the working group closed. I agree it needs updating, since AVT has been replaced by PAYLOAD, but the text was intentionally chosen to be more specific than just "the IETF".

Colin

> Regards,   Martin.
> 
> On 2011/05/21 16:25, Roni Even wrote:
>> Hi,
>> No problem.
>> Here are the two registration templates and a  link to the relevant section.
>> Note that it an update to existing RFC3016 registrations
>> http://www.iana.org/assignments/rtp-parameters adding optional parameters.
>> 
>> The new optional parameters are only for MP4A-LARM and they are:
>> MPS-profile-level-id, MPS-asc and SBR-enabled.
>> 
>> thanks
>> 
>> Roni
>> 
>> 1. MP4V-ES
>> 
>> http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section-6.1
>> 
>> Type name: video
>> 
>>    Subtype name: MP4V-ES
>> 
>>    Required parameters: none
>> 
>>    Optional parameters:
>> 
>>       rate: This parameter is used only for RTP transport.  It indicates
>>       the resolution of the timestamp field in the RTP header.  If this
>>       parameter is not specified, its default value of 90000 (90kHz) is
>>       used.
>> 
>>       profile-level-id: A decimal representation of MPEG-4 Visual
>>       Profile and Level indication value (profile_and_level_indication)
>>       defined in Table G-1 of [14496-2].  This parameter MAY be used in
>>       the capability exchange or session setup procedure to indicate
>>       MPEG-4 Visual Profile and Level combination of which the MPEG-4
>>       Visual codec is capable.  If this parameter is not specified by
>>       the procedure, its default value of 1 (Simple Profile/Level 1) is
>>       used.
>> 
>>       config: This parameter SHALL be used to indicate the configuration
>>       of the corresponding MPEG-4 Visual bitstream.  It SHALL NOT be
>>       used to indicate the codec capability in the capability exchange
>>       procedure.  It is a hexadecimal representation of an octet string
>>       that expresses the MPEG-4 Visual configuration information, as
>>       defined in subclause 6.2.1 Start codes of [14496-2].  The
>>       configuration information is mapped onto the octet string in an
>>       MSB-first basis.  The first bit of the configuration information
>>       SHALL be located at the MSB of the first octet.  The configuration
>>       information indicated by this parameter SHALL be the same as the
>>       configuration information in the corresponding MPEG-4 Visual
>>       stream, except for first_half_vbv_occupancy and
>>       latter_half_vbv_occupancy, if exist, which may vary in the
>>       repeated configuration information inside an MPEG-4 Visual stream
>>       (See 6.2.1 Start codes of [14496-2]).
>> 
>>    Published specification:
>> 
>>       The specifications for MPEG-4 Visual streams are presented in
>>       [14496-2].  The RTP payload format is described in this document.
>> 
>>    Encoding considerations:
>> 
>>       Video bitstreams MUST be generated according to MPEG-4 Visual
>>       specifications [14496-2].  A video bitstream is binary data and
>>       MUST be encoded for non-binary transport (for Email, the Base64
>>       encoding is sufficient).  This type is also defined for transfer
>>       via RTP.  The RTP packets MUST be packetized according to the
>>       MPEG-4 Visual RTP payload format defined in this document.
>> 
>>    Security considerations:
>> 
>>       See Section 9 of this document.
>> 
>>    Interoperability considerations:
>> 
>>       MPEG-4 Visual provides a large and rich set of tools for the
>>       coding of visual objects.  For effective implementation of the
>>       standard, subsets of the MPEG-4 Visual tool sets have been
>>       provided for use in specific applications.  These subsets, called
>>       'Profiles', limit the size of the tool set a decoder is required
>>       to implement.  In order to restrict computational complexity, one
>>       or more Levels are set for each Profile.  A Profile@Level
>>       combination allows:
>> 
>>       *  a codec builder to implement only the subset of the standard he
>>          needs, while maintaining interworking with other MPEG-4 devices
>>          included in the same combination, and
>> 
>>       *  checking whether MPEG-4 devices comply with the standard
>>          ('conformance testing').
>> 
>>       The visual stream SHALL be compliant with the MPEG-4 Visual
>>       Profile@Level specified by the parameter "profile-level-id".
>>       Interoperability between a sender and a receiver may be achieved
>>       by specifying the parameter "profile-level-id", or by arranging a
>>       capability exchange/announcement procedure for this parameter.
>> 
>>    Applications which use this Media Type:
>> 
>>       Audio and visual streaming and conferencing tools
>> 
>>    Additional information: none
>> 
>>    Person and email address to contact for further information:
>> 
>>       See Authors' Address section at the end of this document.
>> 
>>    Intended usage: COMMON
>> 
>>    Author:
>> 
>>       See Authors' Address section at the end of this document.
>> 
>>    Change controller:
>> 
>>       IETF Audio/Video Transport working group delegated from the IESG.
>> 
>> 
>> 2. MP4A-LATM
>> 
>> 
>> http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section-6.3
>> 
>> 
>>    Type name: audio
>> 
>>    Subtype name: MP4A-LATM
>> 
>>    Required parameters:
>>       rate: the rate parameter indicates the RTP time stamp clock rate.
>>       The default value is 90000.  Other rates MAY be indicated only if
>>       they are set to the same value as the audio sampling rate (number
>>       of samples per second).
>> 
>>       In the presence of SBR, the sampling rates for the core en-/
>>       decoder and the SBR tool are different in most cases.  This
>>       parameter SHALL therefore NOT be considered as the definitive
>>       sampling rate.  If this parameter is used, the server must
>>       following the rules below:
>> 
>>       *  When the presence of SBR is not explicitly signaled by the
>>          optional SDP parameters such as object parameter, profile-
>>          level-id or config string, this parameter SHALL be set to the
>>          core codec sampling rate.
>> 
>>       *  When the presence of SBR is explicitly signaled by the optional
>>          SDP parameters such as object parameter, profile-level-id or
>>          config string this parameter SHALL be set to the SBR sampling
>>          rate.
>> 
>>       NOTE: The optional parameter SBR-enabled in SDP a=fmtp is useful
>>       for implicit HE AAC / HE AAC v2 signaling.  But the SBR-enabled
>>       parameter can also be used in the case of explicit HE AAC / HE AAC
>>       v2 signaling.  Therefore, its existence itself is not the criteria
>>       to determine whether HE AAC / HE AAC v2 signaling is explicit or
>>       not.
>> 
>>    Optional parameters:
>> 
>>       profile-level-id: a decimal representation of MPEG-4 Audio Profile
>>       Level indication value defined in [14496-3].  This parameter
>>       indicates which MPEG-4 Audio tool subsets the decoder is capable
>>       of using.  If this parameter is not specified in the capability
>>       exchange or session setup procedure, its default value of 30
>>       (Natural Audio Profile/Level 1) is used.
>> 
>>       MPS-profile-level-id: a decimal representation of the MPEG
>>       Surround Profile Level indication as defined in [14496-3].  This
>>       parameter indicates the support of the MPEG Surround profile and
>>       level by the decoder to be capable to decode the stream.
>> 
>>       object: a decimal representation of the MPEG-4 Audio Object Type
>>       value defined in [14496-3].  This parameter specifies the tool to
>>       be used by the decoder.  It CAN be used to limit the capability
>>       within the specified "profile-level-id".
>> 
>>       bitrate: the data rate for the audio bit stream.
>> 
>>       cpresent: a boolean parameter indicates whether audio payload
>>       configuration data has been multiplexed into an RTP payload (see
>>       Section 5.1).  A 0 indicates the configuration data has not been
>>       multiplexed into an RTP payload and in this case the "config"
>>       parameter MUST be present, a 1 indicates that it has.  The default
>>       if the parameter is omitted is 1.  If this parameter is set to 1
>>       and the "config" parameter is present, the multiplexed
>>       configuration data and the value of the "config" parameter SHALL
>>       be consistent.
>> 
>>       config: a hexadecimal representation of an octet string that
>>       expresses the audio payload configuration data "StreamMuxConfig",
>>       as defined in [14496-3].  Configuration data is mapped onto the
>>       octet string in an MSB-first basis.  The first bit of the
>>       configuration data SHALL be located at the MSB of the first octet.
>>       In the last octet, zero-padding bits, if necessary, SHALL follow
>>       the configuration data.  Senders MUST set the StreamMuxConfig
>>       elements taraBufferFullness and latmBufferFullness to their
>>       largest respective value, indicating that buffer fullness measures
>>       are not used in SDP.  Receivers MUST ignore the value of these two
>>       elements contained in the config parameter.
>> 
>>       MPS-asc: a hexadecimal representation of an octet string that
>>       expresses audio payload configuration data "AudioSpecificConfig",
>>       as defined in [14496-3].  If this parameter is not present the
>>       relevant signaling is performed by other means (e.g. in-band or
>>       contained in the config string).
>> 
>>       The same mapping rules as for the config parameter apply.
>> 
>>       ptime: duration of each packet in milliseconds.
>> 
>>       SBR-enabled: a boolean parameter which indicates whether SBR-data
>>       can be expected in the RTP-payload of a stream.  This parameter is
>>       relevant for an SBR-capable decoder if the presence of SBR can not
>>       be detected from an out-of-band decoder configuration (e.g.
>>       contained in the config string).
>> 
>>       If this parameter is set to 0, a decoder MAY expect that SBR is
>>       not used.  If this parameter is set to 1, a decoder CAN upsample
>>       the audio data with the SBR tool, regardless whether SBR data is
>>       present in the stream or not.
>> 
>>       If the presence of SBR can not be detected from out-of-band
>>       configuration and the SBR-enabled parameter is not present, the
>>       parameter defaults to 1 for an SBR-capable decoder.  If the
>>       resulting output sampling rate or the computational complexity is
>>       not supported, the SBR tool can be disabled or run in downsampled
>>       mode.
>> 
>>       The timestamp resolution at RTP layer is determined by the rate
>>       parameter.
>> 
>>    Published specification:
>> 
>>       Encoding specifications are provided in [14496-3].  The RTP
>>       payload format specification is described in this document.
>> 
>>    Encoding considerations:
>> 
>>       This type is only defined for transfer via RTP.
>> 
>>    Security considerations:
>> 
>>       See Section 9 of this document.
>> 
>>    Interoperability considerations:
>> 
>>       MPEG-4 Audio provides a large and rich set of tools for the coding
>>       of audio objects.  For effective implementation of the standard,
>>       subsets of the MPEG-4 Audio tool sets similar to those used in
>>       MPEG-4 Visual have been provided (see Section 6.1).
>> 
>>       The audio stream SHALL be compliant with the MPEG-4 Audio Profile@
>>       Level specified by the parameters "profile-level-id" and "MPS-
>>       profile-level-id".  Interoperability between a sender and a
>>       receiver may be achieved by specifying the parameters "profile-
>>       level-id" and "MPS-profile-level-id", or by arranging in the
>>       capability exchange procedure to set this parameter mutually to
>>       the same value.  Furthermore, the "object" parameter can be used
>>       to limit the capability within the specified Profile@Level in
>>       capability exchange.
>> 
>>    Applications which use this media type:
>> 
>>       Audio and video streaming and conferencing tools.
>> 
>>    Additional information: none
>> 
>>    Personal and email address to contact for further information:
>> 
>>       See Authors' Address section at the end of this document.
>> 
>>    Intended usage: COMMON
>> 
>>    Author:
>> 
>>       See Authors' Address section at the end of this document.
>> 
>>    Change controller:
>> 
>>       IETF Audio/Video Transport working group delegated from the IESG.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: "Martin J. Dürst" [mailto:duerst@it.aoyama.ac.jp]
>>> Sent: Saturday, May 21, 2011 9:46 AM
>>> To: Roni Even
>>> Cc: 'Pete Resnick'; draft-ietf-avt-rfc3016bis.all@tools.ietf.org; ietf-
>>> types@iana.org; 'Ali C. Begen (abegen)'; payload@ietf.org
>>> Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and
>>> "MP4V-ES" media sutypes.
>>> 
>>> Hello Roni,
>>> 
>>> I fully agree with Pete. I have often told people asking for review on
>>> this list to post the registration templates themselves. I have also
>>> been on this list long enough to be able to tell you *for sure* (not
>>> just 'probably' as Pete wrote) that posting the template(s) themselves
>>> really helps.
>>> 
>>> So if you haven't done it up to now, it's never too late to change that
>>> practice. Copying the template once is a little bit more work for you
>>> than just posting some pointers, but it will make it easier for all
>>> reviewers on this list, because they don't have to follow your
>>> instructions.
>>> 
>>> Many thanks in advance and kind regards,    Martin.
>>> 
>>> 
>>> P.S.: You didn't even bother to give a direct link to the relevant
>>> section(s), which would easily be possible using http://tools.ietf.org.
>>> Of course copying the actual template is still highly preferable.
>>> 
>>> 
>>> 
>>> On 2011/05/21 7:59, Roni Even wrote:
>>>> Pete,
>>>> 
>>>> This is what we have been doing for all payload specifications. We
>>> point at
>>>> the sections with the registration templates.
>>>> 
>>>> Regards
>>>> 
>>>> Roni
>>>> 
>>>> 
>>>> 
>>>> From: Pete Resnick [mailto:presnick@qualcomm.com]
>>>> Sent: Friday, May 20, 2011 9:56 PM
>>>> To: Roni Even
>>>> Cc: ietf-types@iana.org; 'Ali C. Begen (abegen)';
>>>> draft-ietf-avt-rfc3016bis.all@tools.ietf.org; payload@ietf.org
>>>> Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM"
>>> and
>>>> "MP4V-ES" media sutypes.
>>>> 
>>>> 
>>>> 
>>>> On 4/28/11 3:30 AM, Roni Even wrote:
>>>> 
>>>> 
>>>> 
>>>> 
>>>> draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in
>>> the AVT
>>>> Working Group (currently Payload). The document updates the media
>>> subtypes
>>>> "MP4A-LATM" and "MP4V-ES"  from RFC 3016.  The new registrations are
>>> in
>>>> Section 6.1 and   Section 6.3 of the document.
>>>> 
>>>> Comments on the registration are welcome.
>>>> 
>>>> 
>>>> Roni, it would probably help if you posted the registration templates
>>>> themselves instead of pointing to the draft.
>>>> 
>>>> Thanks,
>>>> 
>>>> pr
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> ietf-types mailing list
>>>> ietf-types@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ietf-types
>> 
>> 
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload

-- 
Colin Perkins
http://csperkins.org/