[payload] Issues in RTP Payload HOWTO (draft-ietf-payload-rtp-howto-01)
Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 11 July 2011 21:27 UTC
Return-Path: <magnus.westerlund@ericsson.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 4D3B721F8BCE for <payload@ietfa.amsl.com>; Mon, 11 Jul 2011 14:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.503
X-Spam-Level:
X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvts2PgI-UGH for <payload@ietfa.amsl.com>; Mon, 11 Jul 2011 14:27:55 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2E51F21F8C16 for <payload@ietf.org>; Mon, 11 Jul 2011 14:26:51 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-68-4e1b6a9ad9e4
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B3.58.20773.A9A6B1E4; Mon, 11 Jul 2011 23:26:50 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Mon, 11 Jul 2011 23:26:49 +0200
Message-ID: <4E1B6A98.9010101@ericsson.com>
Date: Mon, 11 Jul 2011 23:26:48 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: "payload@ietf.org" <payload@ietf.org>
X-Enigmail-Version: 1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Subject: [payload] Issues in RTP Payload HOWTO (draft-ietf-payload-rtp-howto-01)
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, 11 Jul 2011 21:27:56 -0000
Hi, In the process of updating the I-D to draft-ietf-payload-rtp-howto-01 I found some issues that I think should be discusses by the WG. These issues have not be changed yet from prior version of the draft. 1. Section 4.1.3 in the I-D discuss the WG draft names of the RTP payload formats. It recommends a form that is draft-ietf-wg-rtp-<desriptive-name>-<version>. Which made more sense in the old AVT when there was more need to separate payload formats from other drafts. In the payload WG I think we can remove the recommendation for "-rtp-" in the file name. Any one against? 2. Section 7.4 and the IANA template indicates that RTP payload format Media types shall be registered also in the RTP Payload Format media types found on page: http://www.iana.org/assignments/rtp-parameters My question to the WG. Should we continue to do this? The registry is not needed for collision prevention. Its sole purpose is as a quick way of finding all the RTP payload format media types. If we think the later is good enough then the WG chairs needs to work to update that registry to be correct and complete as it currently are missing some format. They also need to ensure that this bit of procedure really is followed in all the payload formats going forward. The alternative I see it to declare the registry as discontinued and add a note that it will not any longer be maintained and that people have to look in the main registry. 3. The draft has an open issue that says: Should any procedure for the future when the Payload WG is closed be described? I think we should remove this open issue and continue without specifying that procedure. The reason is that we can't really predict the situation when there no longer are a WG that is chartered for RTP payload formats development. Several possible reasons for that can occur, and based on the situation the procedures to handle that needs to be developed at that time. Any one having a different view? Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- Re: [payload] Issues in RTP Payload HOWTO(draft-i… Ali C. Begen (abegen)
- [payload] Issues in RTP Payload HOWTO (draft-ietf… Magnus Westerlund
- Re: [payload] Issues in RTP Payload HOWTO(draft-i… Magnus Westerlund
- Re: [payload] Issues in RTP Payload HOWTO(draft-i… Magnus Westerlund