Subject: [payload] Alexey Melnikov's No Objection on draft-ietf-payload-melpe-05: (with COMMENT)

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 02 Feb 2017 00:09:28 -0800

Alexey Melnikov has entered the following ballot position for
draft-ietf-payload-melpe-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-payload-melpe/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have a small issue, but I think it is important to address:

in Section 4.1: media type parameters not specified in the MIME type
registration, even though they are described later in the document. The
MIME type registration will be pasted to a separate file on IANA website,
so it must be self contained.

---

From: "Victor Demjanenko, Ph.D." <[email-masked]>
Date: Thu, 2 Feb 2017 16:12:41 -0500

Hi Alexey,

Thanks for your review and comments.  Unfortunately we don't understand the
suggested change.  We understand that only section 4.1 will be extracted and
used in another document.  What we don't understand is what specifically you
see as needing to be changed or modified.  Could you please explain it to us
non-MiME types?

Below is cut and paste from our draft?

Thanks,

Victor & Dave
---------------------------------------------

4.1  Media Type Definition

   Type names:

      audio

   Subtype name:

      MELP, MELP2400, MELP1200, and MELP600

   Required parameters:

      N/A

   Optional parameters:

      ptime, maxptime, bitrate

   Encoding considerations:

      This media type is framed and binary, see section 4.8 in RFC6838
      [RFC6838].

   Security considerations:

      Please see the security considerations in section 8 of RFCxxxx
      (this RFC).

   Interoperability considerations:

      Early implementations used MELP2400, MELP1200, and MELP600 to
      indicate both coder type and bit rate.  These media type names
      should be preserved with this registration.

   Published specification:

      N/A

   Applications that use this media type:

      N/A

   Additional information:

      N/A

   Deprecated alias names for this type:

      N/A

   Magic number(s):

      N/A

   File extension(s):

      N/A

   Macintosh file type code(s):

      N/A

   Person & email address to contact for further information:

      Victor Demjanenko, Ph.D.
      VOCAL Technologies, Ltd.
      520 Lee Entrance, Suite 202
      Buffalo, NY 14228
      USA
      Phone: +1 716 688 4675
      Email: [email-masked]

   Intended usage:

      COMMON

   Restrictions on usage:

      This media type depends on RTP framing, and hence is only defined
      for transfer via RTP [RFC3550].  Transport within other framing
      protocols is not defined at this time.

   Author:

      Victor Demjanenko

   Change controller:

      IETF Payload working group delegated from the IESG.

   Provisional registration? (standards tree only):

      No

-----Original Message-----
From: payload [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Thursday, February 2, 2017 3:09 AM
To: The IESG
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: [payload] Alexey Melnikov's No Objection on
draft-ietf-payload-melpe-05: (with COMMENT)

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

in Section 4.1: media type parameters not specified in the MIME type
registration, even though they are described later in the document. The MIME
type registration will be pasted to a separate file on IANA website, so it
must be self contained.

_______________________________________________
payload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/payload

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 3 Feb 2017 09:15:33 +0000

Hi Victor,

> On 2 Feb 2017, at 21:12, Victor Demjanenko, Ph.D. <[email-masked]> wrote:
> 
>   Optional parameters:
> 
>      ptime, maxptime, bitrate

You either need full definition of these optional parameters or references where they are defined.

Best Regards,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 03 Feb 2017 16:17:59 +0000

Hi Victor,

On Fri, Feb 3, 2017, at 04:13 PM, Victor Demjanenko, Ph.D. wrote:
> Hi Alexey,
> 
> Thanks, with your clue, I followed an example in RFC 5391 and added the
> following:

Your changes look good to me. I am not sure about the two remaining
paragraphs. They can stay as long as they are consistent (or the same)
as text in other sections.

> "   Optional parameters:
> 
>       ptime:  the recommended length of time (in milliseconds)
>          represented by the media in a packet.  It SHALL use the nearest
>          rounded-up ms integer packet duration.  For MELPe, this
>          corresponds to the values: 23, 45, 68, 90, 112, 135, 156, and
>          180.  Larger values can be used as long as they are properly
>          rounded.  See Section 6 of RFC 4566 [RFC4566].  
> 
>       maxptime:  the maximum length of time (in milliseconds) that can
>          be encapsulated in a packet.  It SHALL use the nearest rounded-
>          up ms integer packet duration.  For MELPe, this corresponds to
>          the values: 23, 45, 68, 90, 112, 135, 156, and 180.  Larger
>          values can be used as long as they are properly rounded.  See
>          Section 6 of RFC 4566 [RFC4566].
> 
>       bitrate:  specifies the MELPe coder bit rates supported.  
>          Possible values are a comma-separated list of rates from the
>          set: 2400, 1200, 600.  The modes are listed in order of
>          preference; first is preferred.  If "bitrate" is not present,
>          the fixed coder bit rate of 2400 MUST be used.  The alternate
>          encoding names, "MELP2400", "MELP1200", and "MELP600" directly
>          specify the MELPe coder bit rate of 2400, 1200, and 600
>          respectively and MUST NOT specify a "bitrate" parameter.  "
> 
> Then in section 4.2, the bulleted list is now (adding ptime and maxptime
> as
> well as simplifying bitrate):
> 
> "        o The media type ("audio") goes in SDP "m=" as the media name. 
>         o The media subtype (payload format name) goes in SDP "a=rtpmap"
>    as the encoding name. 
>         o The parameter "bitrate" goes in the SDP "a=fmtp" attribute by
>    copying it as a "bitrate=<value>" string. 
>         o  The parameters "ptime" and "maxptime" go in the SDP "a=ptime"
>    and "a=maxptime" attributes, respectively."
> 
> And the last paragraph in section 4.2 describing ptime and maxptime was
> deleted as its contents was fully conveyed in section 4.1.
> 
> Now there are two other paragraphs related to bitrate in section 4.2 that
> have I not changed.  It's possible that these can be eliminated and/or
> reduced.  Perhaps I delete all but the last sentence of the second
> paragraph?  Any opinions?
> 
> "   If the encoding name "MELP" is received without a "bitrate"
>    parameter, the fixed coder bit rate of 2400 MUST be used.  The
>    alternate encoding names, "MELP2400", "MELP1200", and "MELP600"
>    directly specify the MELPe coder bit rate of 2400, 1200, and 600
>    respectively and MUST NOT specify a "bitrate" parameter.
> 
>    The optional media type parameter, "bitrate", when present, MUST be
>    included in the "a=fmtp" attribute in the SDP, expressed as a media
>    type string in the form of a semicolon-separated list of
>    parameter=value pairs.  The string, "value", can be one or more of
>    2400, 1200, and 600 separated by commas (where each bit-rate value
>    indicates the corresponding MELPe coder).  An example of the media
>    representation in SDP for describing MELPe when all three coder bit
>    rates are supported might be:"
> 
> If the above is considered acceptable as is, I can post a new draft upon
> request.  Please let me know what and when to do this.  (Roni, Ben,
> thanks
> for your help with this as well.)
> 
> Thanks,
> 
> Victor
> 
> From: Alexey Melnikov [mailto:[email-masked]] 
> Sent: Friday, February 3, 2017 4:16 AM
> To: Victor Demjanenko, Ph.D.
> Cc: The IESG; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Dave Satterlee
> (Vocal)
> Subject: Re: [payload] Alexey Melnikov's No Objection on
> You either need full definition of these optional parameters or
> references
> where they are defined.
> 
> Best Regards,
> Alexey
> 
> 
>

---

From: "Victor Demjanenko, Ph.D." <[email-masked]>
Date: Fri, 3 Feb 2017 11:13:36 -0500

Hi Alexey,

"   Optional parameters:

Then in section 4.2, the bulleted list is now (adding ptime and maxptime as
well as simplifying bitrate):

If the above is considered acceptable as is, I can post a new draft upon
request.  Please let me know what and when to do this.  (Roni, Ben, thanks
for your help with this as well.)

Thanks,

Victor

-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]] 
Sent: Friday, February 3, 2017 4:16 AM
To: Victor Demjanenko, Ph.D.
Cc: The IESG; [email-masked]; [email-masked];
[email-masked]; [email-masked]; Dave Satterlee (Vocal)
Subject: Re: [payload] Alexey Melnikov's No Objection on
draft-ietf-payload-melpe-05: (with COMMENT)

Hi Victor,

> On 2 Feb 2017, at 21:12, Victor Demjanenko, Ph.D.
<[email-masked]> wrote:

You either need full definition of these optional parameters or references
where they are defined.

Best Regards,
Alexey