Re: [media-types] Registration of audio/aptx

Bjoern Hoehrmann <derhoermi@gmx.net> Sat, 19 October 2013 10:17 UTC

Return-Path: <derhoermi@gmx.net>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48B311E8164 for <media-types@ietfa.amsl.com>; Sat, 19 Oct 2013 03:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level:
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN1qk5RmEyrN for <media-types@ietfa.amsl.com>; Sat, 19 Oct 2013 03:17:54 -0700 (PDT)
Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id 1B77911E818B for <media-types@ietf.org>; Sat, 19 Oct 2013 03:17:54 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id r9JAHXx8004292 for <media-types@iana.org>; Sat, 19 Oct 2013 10:17:53 GMT
Received: from netb.Speedport_W_700V ([91.35.40.173]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0MSq5p-1V8PpG0kuT-00RoL1 for <media-types@iana.org>; Sat, 19 Oct 2013 12:17:31 +0200
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>
Date: Sat, 19 Oct 2013 12:17:40 +0200
Message-ID: <9ql469lpqb3hji98qjnkla74k6fucjoras@hive.bjoern.hoehrmann.de>
References: <C15918F2FCDA0243A7C919DA7C4BE9940E71CFD8@xmb-aln-x01.cisco.com>
In-Reply-To: <C15918F2FCDA0243A7C919DA7C4BE9940E71CFD8@xmb-aln-x01.cisco.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:Ptll7p600O0z2Q1lrS3Jh4mDMhNTO2mOGlRsKfuxUq1RYcXF5aQ ciWsOG+uVXvUsJH7UgYxJt1duTNNFOCklBe8UAwhJH+T430C4NqsVI9ZljHk9YevZ5hXQvc ItjKd8wP2bDDJCTg+xx3hFnawu7gA2of8Hw/DNwmVNYHGyCAAhoVPOKKJuL4BuKqHW8Reqw Jg6iv2pgMOaPD/taxNJgw==
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Sat, 19 Oct 2013 10:17:54 +0000 (UTC)
Cc: "media-types@iana.org" <media-types@iana.org>
Subject: Re: [media-types] Registration of audio/aptx
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Oct 2013 10:17:59 -0000

* Ali C. Begen (abegen) wrote:
>The following draft is requesting to register a new media subtype (Section 6.1). Your review is appreciated. 
>https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx/?include_text=1

>Registration of media subtype audio/aptx.
>
>     MIME media type name: audio

This is based on an obsolete version of the registration template. The
current one http://tools.ietf.org/html/rfc6838#section-5.6 is slightly
different, for instance, this field should be `Type name:`.

>     MIME subtype name: aptx

(It seems a bit odd to call the codec "apt-X" but the type "aptx".)

>     Optional parameters:
>
>        ptime:
>        The recommended length of time (in milliseconds) represented by
>        the media in a packet.  Defaults to 4 ms. See Section 6 of 
>        [RFC4566].

(It might be better to say "Defaults to 4 (milliseconds)", otherwise
some might be confused whether the `ms` is part of the value.)

>        stereo-channel-pairs:
>        Defines audio channels that are stereo paired in the stream. 
>        See Section 3.  Each pair of audio channels is defined as two 
>        comma-separated values that correspond to channel numbers in 
>        the range 1..channels.  Each stereo channel pair is preceded 
>        by a '{', and followed by a '}'.  Pairs of audio channels are 
>        separated by a comma.  A channel MUST NOT be paired with more
>        than one other channel.  Absence of this parameter signals that
>        each channel has been independently encoded.

If the value includes characters like `{` then in protocols like HTTP
the value would have to be enclosed in double quotes since `{` is not
allowed as a bare token in that protocol. The situation may be similar
in RTP, and if so, that's not sufficiently clear from the text above.
The same goes for some other parameters and other characters like `,`.

>        embedded-autosync-channels:
>        Defines channels that carry embedded autosync.  embedded-
>        autosync-channels is defined as a list of comma-separated 
>        values that correspond to channel numbers in the range 1..
>        channels.  When a channel is stereo paired, embedded autosync
>        is shared across channels in the pair. Only the first channel 
>        as defined in stereo-channel-pairs MUST be specified in the 
>        embedded-autosync-channels list.

This should be rephrased to avoid combining "MUST" and "only"; it is
not clear whether specifying more than the first channel is optional
or forbidden. Same for the `embedded-aux-channels` parameter.

>     Encoding considerations: This type is only defined for transfer
>     via RTP [RFC3550].

Per http://tools.ietf.org/html/rfc6838#section-4.8 this should be one
of the values defined in that section, probably `framed`. That it is
only defined for RTP should go into the `Restrictions on usage:` field.

>     Additional information: none
>
>     Person & email address to contact for further information: John 
>     Lindsay email:lindsay@worldcastsystems.com

This would be better as `John Lindsay <lindsay@worldcastsystems.com>`.

>     Author/Change controller: John Lindsay

Since this is a registration in the standards tree, assigning change
control to an individual requires some justification, I think.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/