Re: [payload] Review of draft-ietf-payload-rtp-aptx-02
"John Lindsay" <Lindsay@worldcastsystems.com> Mon, 21 October 2013 17:25 UTC
Return-Path: <Lindsay@worldcastsystems.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D538A11E86AE for <payload@ietfa.amsl.com>; Mon, 21 Oct 2013 10:25:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 UQ5CEXaGk4kV for <payload@ietfa.amsl.com>; Mon, 21 Oct 2013 10:25:34 -0700 (PDT)
Received: from mailgate.aptcodecs.com (mailgate.aptcodecs.com [217.33.179.85]) by ietfa.amsl.com (Postfix) with ESMTP id 4461311E81ED for <payload@ietf.org>; Mon, 21 Oct 2013 10:25:33 -0700 (PDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 21 Oct 2013 18:25:32 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <8C4E0C2409735E4FBC22D754A238F94D02FDEAA9@APTSBS.apt.local>
In-Reply-To: <C15918F2FCDA0243A7C919DA7C4BE9940E71F203@xmb-aln-x01.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review of draft-ietf-payload-rtp-aptx-02
Thread-Index: AQHOzdbw2vjQftbAz0q6DC+dHfSdj5n/aArg
References: <C15918F2FCDA0243A7C919DA7C4BE9940E71F203@xmb-aln-x01.cisco.com>
From: John Lindsay <Lindsay@worldcastsystems.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, payload@ietf.org
Cc: draft-ietf-payload-rtp-aptx@tools.ietf.org
Subject: Re: [payload] Review of draft-ietf-payload-rtp-aptx-02
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Oct 2013 17:25:39 -0000
Hi A new doc has been submitted in response to comments. See notes below. John -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] Sent: 20 October 2013 21:57 To: payload@ietf.org Cc: draft-ietf-payload-rtp-aptx@tools.ietf.org Subject: Review of draft-ietf-payload-rtp-aptx-02 The WGLC has ended a few weeks ago and I just completed my review. Everything looks good except a few typos. In general, I would avoid using "ms" until it is defined "milliseconds (ms)". > Changed ms to milliseconds throughout the doc. > Ran doc through spell checker but didn't change very much if you have > specifics let me know Authors, if you can submit a revision by tomorrow (21st of Oct.), we can ship this right away. Thanks, -acbegen Other comments regarding media subtype registration (Thanks to Bjoern Hoehrmann): 1) The registration in Section 6.1 uses the old template. The current template is here: http://tools.ietf.org/html/rfc6838#section-5.6 > Updated please ensure you agree 2) Regarding ptime: It might be better to say "Defaults to 4 (milliseconds)", otherwise some might be confused whether the `ms` is part of the value. > Done 3) Regarding stereo channels: 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 `,`. > I did not change this as these parameters are passed by SDP and are allowed. In addition they are used by everyone who has implemented so far without issue?? Is there some other way that we can use to avoid this potential problem? 4) Regarding embedded-autosync-channels: 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. >>> Removed the "only" as it still has the same meaning as they are pairs hence it can only refer to Channel 1 or 2 5) Regarding the encoding considerations: This should say "framed". >>> Don't understand issue? Can you give further explanation? 6) "Restrictions on usage" field can say "RTP applications only". > Not sure what is meant by this? >Changed Intended usage: RTP applications only at the bottom of page 14? Can you ensure you agree? 7) Person & email address to contact for further information: This should be "John Lindsay email:lindsay@worldcastsystems.com" > Again cannot see the issue? Is this supposed to be in quotes? > Changed to quotes but not 100% sure this was the issue? > Person & email address to contact for further information: "John > Lindsay email:lindsay@worldcastsystems.com" 8) Author/Change controller: This should say "IETF Payload Working Group delegated from the IESG" > Done
- [payload] Review of draft-ietf-payload-rtp-aptx-02 Ali C. Begen (abegen)
- Re: [payload] Review of draft-ietf-payload-rtp-ap… John Lindsay
- Re: [payload] Review of draft-ietf-payload-rtp-ap… Ali C. Begen (abegen)