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

["Martin J. Dürst" <[e-mail]>]

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.

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:[e-mail]]
>> Sent: Saturday, May 21, 2011 9:46 AM
>> To: Roni Even
>> Cc: 'Pete Resnick'; [e-mail]; ietf-
>> [e-mail]; 'Ali C. Begen (abegen)'; [e-mail]
>> 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:[e-mail]]
>>> Sent: Friday, May 20, 2011 9:56 PM
>>> To: Roni Even
>>> Cc: [e-mail]; 'Ali C. Begen (abegen)';
>>> [e-mail]; [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ietf-types
>
>