[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
----------------------------------------------------------------------