From csp@csperkins.org Tue Jan 3 10:23:39 2012 Return-Path: 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 8E7DA5E800D for ; Tue, 3 Jan 2012 10:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 ieZZOaKYq3CB for ; Tue, 3 Jan 2012 10:23:39 -0800 (PST) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id C6E0E5E800B for ; Tue, 3 Jan 2012 10:23:38 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.30]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Ri91N-0003He-gG; Tue, 03 Jan 2012 18:23:37 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540F8BD5F6@xmb-sjc-215.amer.cisco.com> Date: Tue, 3 Jan 2012 18:23:36 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2827659C-5315-4303-AE98-97F79104CB46@csperkins.org> References: <04CAD96D4C5A3D48B1919248A8FE0D540F8BD5F6@xmb-sjc-215.amer.cisco.com> To: Ali C. Begen (abegen) X-Mailer: Apple Mail (2.1251.1) Cc: payload@ietf.org Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-klv-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 18:23:39 -0000 Ali, I read this (some time ago), and it looks fine. Colin On 26 Jul 2011, at 05:34, Ali C. Begen (abegen) wrote: > The WGLC has ended a few days ago but I have not seen any comments on = the list. This is a short draft. We would appreciate to get some = comments on the list so that we can proceed with publication. >=20 > Thanks. >=20 >> -----Original Message----- >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On = Behalf Of Ali C. Begen (abegen) >> Sent: Wednesday, July 06, 2011 11:35 AM >> To: payload@ietf.org >> Subject: [payload] WGLC for draft-ietf-payload-rtp-klv-01 >>=20 >> Hi everyone, >>=20 >> This is to announce a 2-week WGLC for the following draft (ends July = 20th): >> http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-klv/ >>=20 >> Please review the document and post any questions/concerns you have = to the mailing list. >>=20 >> Thanks. >> -acbegen >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload --=20 Colin Perkins http://csperkins.org/ From internet-drafts@ietf.org Wed Jan 4 01:17:52 2012 Return-Path: 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 EE12921F86CB; Wed, 4 Jan 2012 01:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 AGCDHIV7T5Lg; Wed, 4 Jan 2012 01:17:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CC821F8522; Wed, 4 Jan 2012 01:17:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120104091751.17102.51339.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2012 01:17:51 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-sbc-02.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 09:17:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Workin= g Group of the IETF. Title : RTP Payload Format for Bluetooth's SBC Audio Codec Author(s) : Christian Hoene Frans de Bont Filename : draft-ietf-payload-rtp-sbc-02.txt Pages : 24 Date : 2012-01-04 This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the low complexity subband codec (SBC), which is the mandatory audio codec of the Advanced Audio Distribution Profile (A2DP) Specification written by the Bluetooth(r) Special Interest Group (SIG). The payload format is designed to be able to interoperate with existing Bluetooth A2DP devices, to provide high streaming audio quality, interactive audio transmission over the internet, and ultra-low delay coding for jam sessions on the internet. This document contains also a media type registration which specifies the use of the RTP payload format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-rtp-sbc-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-payload-rtp-sbc-02.txt From hoene@uni-tuebingen.de Wed Jan 4 01:32:49 2012 Return-Path: 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 2DDA121F868A for ; Wed, 4 Jan 2012 01:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 t0lVyz8xLlay for ; Wed, 4 Jan 2012 01:32:48 -0800 (PST) Received: from mx09.uni-tuebingen.de (mx09.uni-tuebingen.de [134.2.3.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9706221F864D for ; Wed, 4 Jan 2012 01:32:45 -0800 (PST) Received: from hoeneT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx09.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id q049WNji013050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Jan 2012 10:32:23 +0100 From: "Christian Hoene" To: "'Colin Perkins'" , "Frans de Bont" References: <20111215144558.9398.64451.idtracker@ietfa.amsl.com> <012f01ccbb38$fdfab350$f9f019f0$@uni-tuebingen.de> In-Reply-To: Date: Wed, 4 Jan 2012 10:32:23 +0100 Organization: =?iso-8859-1?Q?Universit=E4t_T=FCbingen?= Message-ID: <002a01cccac3$c3cb5d20$4b621760$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEzqmR2VHOaT+tJoXcykzEurEuNDwIIIr+QAeqMvTSXDpnSoA== Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.2.1.23; spam filter version: 3.2.0/2.3; host: mx09) X-AntiVirus: checked by Avira MailGate (version: 3.2.1.23; AVE: 8.2.5.34; VDF: 7.11.10.215; host: mx09); id=4917-nL1KWT Cc: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-sbc-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 09:32:49 -0000 Hello Colin, thank you for your comments. Frans De Bont has corrected the draft accordingly. Inline you find responses to the mentioned issues. Any other issue open?=20 With best regards, Christian -- Dr.-Ing. Christian Hoene University of T=FCbingen, Chair of Communication Networks Research Group Interactive Communication Systems (ICS) Sand 13, 72076 T=FCbingen, Germany Tel +49 7071 2970532, www.net.uni-tuebingen.de > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Monday, December 19, 2011 5:42 PM > To: Christian Hoene > Cc: payload@ietf.org > Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-sbc-01.txt >=20 > Christian, >=20 > Some comments on this version: >=20 > - Section 3 is background, but is written in a way that could be interpreted as > making a series of normative requirements (e.g., =93SBC can use four = or eight > subbands. The decoder shall support both; the encoder shall support at least > 8 subbands=94). Be clear whether these are normative requirements made = by > this document, or by the SBC codec specification or the SBC A2DP = profile. All of these requirements are from the SBC codec specification = [A2DPV12].=20 [FdB] In Section 3 the origin of the encoder and decoder requirements = has been made more clear. >=20 > - The draft uses =93CAN=94 throughout, but this is not an RFC 2119 = keyword. > What is meant? [FdB] The "CAN"'s have been replaced by "MUST"'s. >=20 > - Need to mandate the behaviour if the fields in the frame header = don=92t > match the SDP negotiated values. [FdB] I think that the fields in the frame header MUST be compatible = with the SDP negotiated values. [Christian Hoene] We added a sentence to drop those frames if they are = not the same. > It would be better if these parameters > were only specified in the SDP, rather than duplicating them in-band = and in > the signalling. [Christian Hoene] Agreed. We had similar discussions but in the end we decided to adopt [A2DPV12] without any changes. >=20 > - Media type registration: =93MIME type=94 -> =93Media type=94, since = this is more > general than Internet mail. [FdB] Ok. >=20 > - The formatting of the =93optional parameters=94 section of the media = type > registration is unclear. Is this supposed to include the capabilities parameter? > Is the capabilities parameter really optional? Section 7.2 seems to require it. [FdB] Formatting of the "required/optional parameters" sections has been changed to make them more clear. In Section 7.2 it is now described that = the capabilities parameter needs only be included in the SDP parameters if = it is present. > >=20 > - The change controller cannot be the AVT working group, since that no > longer exists [FdB] This has been changed to: "IETF Audio/Video Transport Payloads = working group delegated from the IESG". =20 >=20 > - Section 7.1.1 refers to the =93a=3Drtpmap:=94 attribute for the rate = and channel > parameters, but section 7.1 doesn=92t define these parameters. Need to = add > them in the required parameters section of the media type = registration. [FdB] The parameters "rate" and "channels" have been added to section = 7.1 and are used in section 7.2. From csp@csperkins.org Wed Jan 4 15:47:33 2012 Return-Path: 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 4804B21F8551 for ; Wed, 4 Jan 2012 15:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 j9wvDbH0j0rn for ; Wed, 4 Jan 2012 15:47:32 -0800 (PST) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id 654E821F8550 for ; Wed, 4 Jan 2012 15:47:32 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.30]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1RiaYN-0000KW-aU; Wed, 04 Jan 2012 23:47:31 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Colin Perkins In-Reply-To: <002a01cccac3$c3cb5d20$4b621760$@uni-tuebingen.de> Date: Wed, 4 Jan 2012 23:47:29 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111215144558.9398.64451.idtracker@ietfa.amsl.com> <012f01ccbb38$fdfab350$f9f019f0$@uni-tuebingen.de> <002a01cccac3$c3cb5d20$4b621760$@uni-tuebingen.de> To: Christian Hoene X-Mailer: Apple Mail (2.1251.1) Cc: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-sbc-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 23:47:33 -0000 Christian, Thanks, that addresses my comments. The only outstanding issue I have is that there's a lot of duplication = with the RTP payload format definition in Bluetooth A2DP specification. = Can this be removed, and done by reference, to avoid the risk of = accidental changes? Colin On 4 Jan 2012, at 09:32, Christian Hoene wrote: > Hello Colin, >=20 > thank you for your comments. Frans De Bont has corrected the draft > accordingly. Inline you find responses to the mentioned issues. >=20 > Any other issue open?=20 >=20 > With best regards, >=20 > Christian >=20 > -- > Dr.-Ing. Christian Hoene > University of T=FCbingen, Chair of Communication Networks > Research Group Interactive Communication Systems (ICS) > Sand 13, 72076 T=FCbingen, Germany > Tel +49 7071 2970532, www.net.uni-tuebingen.de >=20 >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: Monday, December 19, 2011 5:42 PM >> To: Christian Hoene >> Cc: payload@ietf.org >> Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-sbc-01.txt >>=20 >> Christian, >>=20 >> Some comments on this version: >>=20 >> - Section 3 is background, but is written in a way that could be > interpreted as >> making a series of normative requirements (e.g., =93SBC can use four = or > eight >> subbands. The decoder shall support both; the encoder shall support = at > least >> 8 subbands=94). Be clear whether these are normative requirements = made by >> this document, or by the SBC codec specification or the SBC A2DP = profile. >=20 > All of these requirements are from the SBC codec specification = [A2DPV12].=20 > [FdB] In Section 3 the origin of the encoder and decoder requirements = has > been made more clear. >=20 >>=20 >> - The draft uses =93CAN=94 throughout, but this is not an RFC 2119 = keyword. >> What is meant? >=20 > [FdB] The "CAN"'s have been replaced by "MUST"'s. >=20 >>=20 >> - Need to mandate the behaviour if the fields in the frame header = don=92t >> match the SDP negotiated values. > [FdB] I think that the fields in the frame header MUST be compatible = with > the SDP negotiated values. > [Christian Hoene] We added a sentence to drop those frames if they are = not > the same. >=20 >> It would be better if these parameters >> were only specified in the SDP, rather than duplicating them in-band = and > in >> the signalling. >=20 > [Christian Hoene] Agreed. We had similar discussions but in the end we > decided to adopt [A2DPV12] without any changes. >=20 >>=20 >> - Media type registration: =93MIME type=94 -> =93Media type=94, since = this is more >> general than Internet mail. >=20 > [FdB] Ok. >=20 >>=20 >> - The formatting of the =93optional parameters=94 section of the = media type >> registration is unclear. Is this supposed to include the capabilities > parameter? >> Is the capabilities parameter really optional? Section 7.2 seems to > require it. >=20 > [FdB] Formatting of the "required/optional parameters" sections has = been > changed to make them more clear. In Section 7.2 it is now described = that the > capabilities parameter needs only be included in the SDP parameters if = it is > present. >=20 >>=20 >>=20 >> - The change controller cannot be the AVT working group, since that = no >> longer exists >=20 > [FdB] This has been changed to: "IETF Audio/Video Transport Payloads = working > group delegated from the IESG". >=20 >>=20 >> - Section 7.1.1 refers to the =93a=3Drtpmap:=94 attribute for the = rate and > channel >> parameters, but section 7.1 doesn=92t define these parameters. Need = to add >> them in the required parameters section of the media type = registration. >=20 > [FdB] The parameters "rate" and "channels" have been added to section = 7.1 > and are used in section 7.2. >=20 --=20 Colin Perkins http://csperkins.org/ From abegen@cisco.com Sun Jan 8 11:07:01 2012 Return-Path: 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 AA06521F85D9 for ; Sun, 8 Jan 2012 11:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.949 X-Spam-Level: X-Spam-Status: No, score=-7.949 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 XamfZFRVnr-n for ; Sun, 8 Jan 2012 11:07:01 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB9321F85D7 for ; Sun, 8 Jan 2012 11:07:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1816; q=dns/txt; s=iport; t=1326049621; x=1327259221; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=wv97Y33YsRzQIcz029ZKgpovO+rHqmLFeJmqq2aZbLs=; b=BYS4kr/m6ZjaeE4K5eHL5JnCGNTquBtISLTmv5eYvdthz8hY/H9Il/PE B9xZmOJl7ogeb7hmN3P+Z6IUk3Pcjt0S+QguYTWvQjgwBV7/DijZ1hP9W nm1N7TltwW/Uvodnn5ZmWxoQ1IQMRmwtmXmHojUKvg0ylFq/0gpKdlaeu c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0AAKLnCU+rRDoJ/2dsb2JhbABDnAeQPoEFgXIBAQEEAQEBDwEdPgsMBAIBCA4DBAEBAQoGFwEGASYfCQgBAQQTCBqHYJctAZ1Riy5jBIg5nyo X-IronPort-AV: E=Sophos;i="4.71,476,1320624000"; d="scan'208";a="24370965" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 08 Jan 2012 19:07:00 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q08J6x3T013188; Sun, 8 Jan 2012 19:06:59 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 Jan 2012 11:06:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Jan 2012 11:05:41 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5410A4CC0A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <2827659C-5315-4303-AE98-97F79104CB46@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-klv-01 Thread-Index: AczKRNBaGdlHo2laSSmGS+mEZcNndwD83L2A References: <04CAD96D4C5A3D48B1919248A8FE0D540F8BD5F6@xmb-sjc-215.amer.cisco.com> <2827659C-5315-4303-AE98-97F79104CB46@csperkins.org> From: "Ali C. Begen (abegen)" To: "Colin Perkins" X-OriginalArrivalTime: 08 Jan 2012 19:06:59.0681 (UTC) FILETIME=[B299B510:01CCCE38] Cc: draft-ietf-payload-rtp-klv@tools.ietf.org, payload@ietf.org Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-klv-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 19:07:01 -0000 OK, thanks. Unless we have any other comment, I will request = publication. But since the current document has expired, it would be = good to submit a revision. Authors, could you post a revision? -acbegen > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Tuesday, January 03, 2012 1:24 PM > To: Ali C. Begen (abegen) > Cc: payload@ietf.org > Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-klv-01 >=20 > Ali, >=20 > I read this (some time ago), and it looks fine. > Colin >=20 >=20 > On 26 Jul 2011, at 05:34, Ali C. Begen (abegen) wrote: > > The WGLC has ended a few days ago but I have not seen any comments = on the list. This is a short draft. We would > appreciate to get some comments on the list so that we can proceed = with publication. > > > > Thanks. > > > >> -----Original Message----- > >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On = Behalf Of Ali C. Begen (abegen) > >> Sent: Wednesday, July 06, 2011 11:35 AM > >> To: payload@ietf.org > >> Subject: [payload] WGLC for draft-ietf-payload-rtp-klv-01 > >> > >> Hi everyone, > >> > >> This is to announce a 2-week WGLC for the following draft (ends = July 20th): > >> http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-klv/ > >> > >> Please review the document and post any questions/concerns you have = to the mailing list. > >> > >> Thanks. > >> -acbegen > >> _______________________________________________ > >> payload mailing list > >> payload@ietf.org > >> https://www.ietf.org/mailman/listinfo/payload > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 From internet-drafts@ietf.org Mon Jan 9 09:10:31 2012 Return-Path: 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 8DDB711E80AE; Mon, 9 Jan 2012 09:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 xuih6QHa9MIg; Mon, 9 Jan 2012 09:10:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504C311E807A; Mon, 9 Jan 2012 09:10:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120109171030.11913.32971.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2012 09:10:30 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-klv-02.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:10:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Workin= g Group of the IETF. Title : RTP Payload Format for SMPTE 336M Encoded Data Author(s) : J. Downs J. Arbeiter Filename : draft-ietf-payload-rtp-klv-02.txt Pages : 12 Date : 2012-01-09 This document specifies the payload format for packetization of KLV (Key-Length-Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in SMPTE 336M, into the Real-time Transport Protocol (RTP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-rtp-klv-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-payload-rtp-klv-02.txt From jeff_downs@partech.com Mon Jan 9 09:15:11 2012 Return-Path: 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 EB34C21F8796 for ; Mon, 9 Jan 2012 09:15:11 -0800 (PST) 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 szp981RdgazO for ; Mon, 9 Jan 2012 09:15:08 -0800 (PST) Received: from imail1.partech.com (imail1b.partech.com [192.133.62.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6340D11E809A for ; Mon, 9 Jan 2012 09:15:05 -0800 (PST) Received: from eclipse.partech.com (eclipse.partech.com [172.16.8.4]) by imail1.partech.com (8.13.1/8.12.11) with ESMTP id q09HETPu014212; Mon, 9 Jan 2012 12:14:30 -0500 Received: from beasley.parcorp.local (beasley.partech.com [172.16.16.70]) by eclipse.partech.com (8.12.9/8.12.9) with ESMTP id q09HERbK022076; Mon, 9 Jan 2012 12:14:28 -0500 (EST) Received: from [192.168.248.11] ([192.168.248.11]) by beasley.parcorp.local with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 12:14:27 -0500 Message-ID: <4F0B206D.8020005@partech.com> Date: Mon, 09 Jan 2012 12:14:21 -0500 From: Jeff Downs User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <04CAD96D4C5A3D48B1919248A8FE0D540F8BD5F6@xmb-sjc-215.amer.cisco.com> <2827659C-5315-4303-AE98-97F79104CB46@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D5410A4CC0A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5410A4CC0A@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2012 17:14:28.0099 (UTC) FILETIME=[24C1CD30:01CCCEF2] Cc: draft-ietf-payload-rtp-klv@tools.ietf.org, Colin Perkins , payload@ietf.org Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-klv-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:15:12 -0000 Ali, I've uploaded revision -02 of this draft just now. Colin, Thank you for reviewing and commenting on the draft. Jeff Downs PAR Government Systems On 1/8/2012 2:05 PM, Ali C. Begen (abegen) wrote: > OK, thanks. Unless we have any other comment, I will request publication. But since the current document has expired, it would be good to submit a revision. > > Authors, could you post a revision? > > -acbegen > >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: Tuesday, January 03, 2012 1:24 PM >> To: Ali C. Begen (abegen) >> Cc: payload@ietf.org >> Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-klv-01 >> >> Ali, >> >> I read this (some time ago), and it looks fine. >> Colin >> >> >> On 26 Jul 2011, at 05:34, Ali C. Begen (abegen) wrote: >>> The WGLC has ended a few days ago but I have not seen any comments on the list. This is a short draft. We would >> appreciate to get some comments on the list so that we can proceed with publication. >>> >>> Thanks. >>> >>>> -----Original Message----- >>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) >>>> Sent: Wednesday, July 06, 2011 11:35 AM >>>> To: payload@ietf.org >>>> Subject: [payload] WGLC for draft-ietf-payload-rtp-klv-01 >>>> >>>> Hi everyone, >>>> >>>> This is to announce a 2-week WGLC for the following draft (ends July 20th): >>>> http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-klv/ >>>> >>>> Please review the document and post any questions/concerns you have to the mailing list. >>>> >>>> Thanks. >>>> -acbegen >>>> _______________________________________________ >>>> payload mailing list >>>> payload@ietf.org >>>> https://www.ietf.org/mailman/listinfo/payload >>> _______________________________________________ >>> payload mailing list >>> payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >> >> -- >> Colin Perkins >> http://csperkins.org/ >> >> > From abegen@cisco.com Mon Jan 9 09:45:28 2012 Return-Path: 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 21F2F11E80AD; Mon, 9 Jan 2012 09:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.499 X-Spam-Level: X-Spam-Status: No, score=-7.499 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 g-yVDFNOwWXH; Mon, 9 Jan 2012 09:45:24 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6B71B11E809A; Mon, 9 Jan 2012 09:45:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=7046; q=dns/txt; s=iport; t=1326131123; x=1327340723; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=GIYHnkz8R/TI5DN3hW5xbcFzKuxiae4Jlx0sC23ixhA=; b=mjEq4NH/dF2JTN1jafrzuT6ZvkL3g5DtC1kV7REvk6hOZeK4asr/gdv9 ks55oH7ZhhPhGNpgvs24yOhpgAsRFHzMl1Qvektu6T/tO1aa3LUbYuPxJ v3XzzotUdJqQMYnScU5F6foTRDWAB2gUWF6O2xossW69QXxQUzQM3QTYB 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOMmC0+rRDoI/2dsb2JhbABErFOBBYF0AQQSAR07DhIBKgYYB1cBBBsah2CXfQGeQIsuYwSIBjOfKg X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; d="scan'208";a="24494474" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 09 Jan 2012 17:45:23 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q09HjN53029474; Mon, 9 Jan 2012 17:45:23 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 09:45:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jan 2012 09:45:16 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5410B0964B@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Publication request for draft-ietf-payload-rtp-klv-02.txt Thread-Index: AczO9GdI2CTP2ZXOQxOA5pXBlsVvPQ== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 09 Jan 2012 17:45:23.0029 (UTC) FILETIME=[7661A850:01CCCEF6] Cc: draft-ietf-payload-rtp-klv@tools.ietf.org, payload@ietf.org Subject: [payload] Publication request for draft-ietf-payload-rtp-klv-02.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:45:28 -0000 Shepherd writeup for draft-ietf-payload-rtp-klv-02.txt: (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 version is ready for forwarding to the IESG for publication?=20 The document shepherd is Ali Begen. He has reviewed the document and = believes it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that=20 have been performed? =20 The document has been reviewed adequately by the WG members. The = shepherd does not have concerns about the depth or breadth of the = reviews. (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML?=20 There are no such concerns. (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or=20 has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue.=20 There are no concerns from the document shepherd from this perspective. = No IPR disclosures have been made against this document. (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it? =20 No objections have been raised and the reviewers were confident in their = reviews. (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.)=20 No. (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See the Internet-Drafts = Checklist=20 and http://tools.ietf.org/tools/idnits/). Boilerplate checks are = not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews?=20 Version idnits 2.12.12 of ID Nits identifies no issues except one = comment (which is OK). (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967].=20 The document does split normative and informative references. There is a normative reference to SMPTE336M, which is a spec produced by = the SMPTE organization. This is not an RFC but it is already a produced = spec. (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation?=20 The IANA considerations have been reviewed, the registry is correctly = identified. (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker?=20 No issues. (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 Technical Summary=20 Relevant content can frequently be found in the abstract=20 and/or introduction of the document. If not, this may be=20 an indication that there are deficiencies in the abstract=20 or introduction.=20 Working Group Summary=20 Was there anything in WG process that is worth noting? For=20 example, was there controversy about particular points or=20 were there decisions where the consensus was particularly=20 rough?=20 Document Quality=20 Are there existing implementations of the protocol? Have a=20 significant number of vendors indicated their plan to=20 implement the specification? Are there any reviewers that=20 merit special mention as having done a thorough review,=20 e.g., one that resulted in important changes or a=20 conclusion that the document had no substantive issues? If=20 there was a MIB Doctor, Media Type or other expert review,=20 what was its course (briefly)? In the case of a Media Type=20 review, on what date was the request posted? This document specifies the payload format for packetization of KLV = (Key-Length-Value) Encoded Data, as defined by the Society of Motion = Picture and Television Engineers (SMPTE) in SMPTE 336M, into the = Real-time Transport Protocol (RTP). The document achieved consensus in the PAYLOAD working group. From abegen@cisco.com Wed Jan 11 11:22:15 2012 Return-Path: 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 AD1FC21F873C for ; Wed, 11 Jan 2012 11:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.274 X-Spam-Level: X-Spam-Status: No, score=-7.274 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 BgoZEkhqOJsi for ; Wed, 11 Jan 2012 11:22:15 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 02CC721F8737 for ; Wed, 11 Jan 2012 11:22:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=2153; q=dns/txt; s=iport; t=1326309735; x=1327519335; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=rTlqZIZbUHPTWO5xDrh6McBgHhQMteuHkFCQ4Z8jn8I=; b=EZhv8M9mEzSBw7oPHu4+CL4jzLMwzxFDWeDyun09NDxIxFRa9AImaIY2 y3882/s3Nw+aDRaCPRVgz11rEiSehgaGUrzLq6X1RhQNNb3S6yj9kUuNO VfcXx4GIqOhdFDDcz2a75rYgr4Bk4kS2ibHL3M/LX7/Aif6H8KT+B52eZ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAA3hDU+rRDoI/2dsb2JhbABDrQaBBYF0AQQSAR1JEgEqBhgHIDcBBAoJCBqHYJkFAZ5NiQGCOWMEiAczl0iHZw X-IronPort-AV: E=Sophos;i="4.71,494,1320624000"; d="scan'208";a="24913694" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 11 Jan 2012 19:21:57 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0BJLvEv017689; Wed, 11 Jan 2012 19:21:57 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 11:21:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jan 2012 11:21:50 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5410B0A017@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Registration of application/smpte336m Thread-Index: AczQlkSJJSeJKPUKTyiakz3lL6NNNg== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 11 Jan 2012 19:21:56.0923 (UTC) FILETIME=[48A338B0:01CCD096] Cc: payload@ietf.org Subject: [payload] Registration of application/smpte336m X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 19:22:15 -0000 Hello, draft-ietf-payload-rtp-klv-02 has finished WGLC in the PAYLOAD WG. There = is one new registration in Section 6.1 of = http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-klv/?include_text=3D= 1=20 The relevant text is copied below as well. Your comments are appreciated. Thanks.=20 -acbegen (PAYLOAD WG Co-chair) 6.1. Media Type Definition Type name: application Subtype name: smpte336m Required parameters: rate: RTP timestamp clock rate. Typically chosen based on sampling rate of metadata being transmitted, but other rates can be specified. Optional parameters: None Encoding considerations: This media type is framed and binary; see Section 4.8 of [RFC4288]. Security considerations: See Section 8 of RFCXXXX (note to RFC editor: please replace XXXX with the number assigned to this RFC). Interoperability considerations: Data items in smpte336m can be very diverse. Receivers might only be capable of interpreting a subset of the possible data items; unrecognized items are skipped. Agreement on data items to be used out of band, via application profile or similar, is typical. Published specification: RFCXXXX Applications that use this media type: Streaming of metadata associated with simultaneously streamed video and transmission of [SMPTE336M] based media formats (e.g. MXF [SMPTE377M]). Additional Information: none Person & email address to contact for further information: J. Downs ; IETF Payload Working Group 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: J. Downs J. Arbeiter Change controller: IETF Payload working group delegated from the IESG. From abegen@cisco.com Fri Jan 13 07:54:15 2012 Return-Path: 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 E572C21F8594; Fri, 13 Jan 2012 07:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.139 X-Spam-Level: X-Spam-Status: No, score=-7.139 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 nYDHYOYJdR8M; Fri, 13 Jan 2012 07:54:14 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id D982A21F857D; Fri, 13 Jan 2012 07:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=7590; q=dns/txt; s=iport; t=1326470055; x=1327679655; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=Kom9egILgoEesrFy0Li+hQ7/8EPW6aUXcrYEpVscP90=; b=Pt9wkaz4LMJQle6DlcoaEJ/AVRBcOIPEp151g/Esf/MQ2L0jZQIBIz1v kv104tn6+pmUEm1CjE+3zj1LqV4wwygta8Vsu/My1w8uS1C9ED5pNVZBc jjVEpR5CmUS9dz/Zzz4xAC2Lqz8Ara6CC2CJ2wSqSooteIQJKGMMMEGw7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANFSEE+rRDoJ/2dsb2JhbABCrRmBBYF0AQQSAR07DhIBKgYYB1cBBBsBGYdgmQYBnh6LOmMEiDyfNg X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="25288447" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 13 Jan 2012 15:54:09 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0DFs9Jk026448; Fri, 13 Jan 2012 15:54:09 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Jan 2012 07:54:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jan 2012 07:54:07 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5410BAC8BD@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (Resend) Publication request for draft-ietf-payload-rtp-klv-02.txt Thread-Index: AczQlmLykhxNTFkBT/Ko5gL/1zZ7jg== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 13 Jan 2012 15:54:09.0583 (UTC) FILETIME=[96599BF0:01CCD20B] Cc: draft-ietf-payload-rtp-klv@tools.ietf.org, payload@ietf.org Subject: [payload] (Resend) Publication request for draft-ietf-payload-rtp-klv-02.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 15:54:16 -0000 (Resend with some additional info) Shepherd writeup for draft-ietf-payload-rtp-klv-02.txt: (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 version is ready for forwarding to the IESG for publication?=20 The document shepherd is Ali Begen. He has reviewed the document and = believes it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that=20 have been performed? =20 The document has been reviewed adequately by the WG members. The = shepherd does not have concerns about the depth or breadth of the = reviews. (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML?=20 There are no such concerns. (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or=20 has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue.=20 There are no concerns from the document shepherd from this perspective. = No IPR disclosures have been made against this document. (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it? =20 No objections have been raised and the reviewers were confident in their = reviews. (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.)=20 No. (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See the Internet-Drafts = Checklist=20 and http://tools.ietf.org/tools/idnits/). Boilerplate checks are = not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews?=20 Version idnits 2.12.12 of ID Nits identifies no issues except one = comment (which is OK). (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967].=20 The document does split normative and informative references. There is a normative reference to SMPTE336M, which is a spec produced by = the SMPTE organization. This is not an RFC but it is already a produced = spec. (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation?=20 The IANA considerations have been reviewed, the registry is correctly = identified.=20 (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker?=20 No issues. (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 Technical Summary=20 Relevant content can frequently be found in the abstract=20 and/or introduction of the document. If not, this may be=20 an indication that there are deficiencies in the abstract=20 or introduction.=20 This document specifies the payload format for packetization of KLV = (Key-Length-Value) Encoded Data, as defined by the Society of Motion = Picture and Television Engineers (SMPTE) in SMPTE 336M, into the = Real-time Transport Protocol (RTP). Working Group Summary=20 Was there anything in WG process that is worth noting? For=20 example, was there controversy about particular points or=20 were there decisions where the consensus was particularly=20 rough?=20 No, it was relatively a smooth process. Document Quality=20 Are there existing implementations of the protocol? Have a=20 significant number of vendors indicated their plan to=20 implement the specification? Are there any reviewers that=20 merit special mention as having done a thorough review,=20 e.g., one that resulted in important changes or a=20 conclusion that the document had no substantive issues? If=20 there was a MIB Doctor, Media Type or other expert review,=20 what was its course (briefly)? In the case of a Media Type=20 review, on what date was the request posted? The document achieved consensus in the PAYLOAD working group. According = to the authors, there have been prototypical implementations, including = implementation inside existing open toolkits and applications. One such = prototype involved a (modified to implement) VideoLAN VLC to a = proprietary RTP-capable desktop application. The review request for media type registration has been sent to = ietf-types on Jan 11th. Here is the link: http://www.ietf.org/mail-archive/web/ietf-types/current/msg01608.html=20 From derhoermi@gmx.net Fri Jan 13 07:46:01 2012 Return-Path: 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 65A6921F8565 for ; Fri, 13 Jan 2012 07:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, 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 n82WPvk+9ypx for ; Fri, 13 Jan 2012 07:46:00 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5A1AF21F8525 for ; Fri, 13 Jan 2012 07:46:00 -0800 (PST) Received: (qmail invoked by alias); 13 Jan 2012 15:45:57 -0000 Received: from dslb-094-223-152-203.pools.arcor-ip.net (EHLO HIVE) [94.223.152.203] by mail.gmx.net (mp070) with SMTP; 13 Jan 2012 16:45:57 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/v+mQd2Njv7uQlYaE18nLcza3J5EdW23yd4uwRdj S+1+D/REz3H02G From: Bjoern Hoehrmann To: "Ali C. Begen (abegen)" Date: Fri, 13 Jan 2012 16:46:02 +0100 Message-ID: References: <04CAD96D4C5A3D48B1919248A8FE0D5410B0A017@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5410B0A017@xmb-sjc-215.amer.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-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Fri, 13 Jan 2012 08:32:47 -0800 Cc: ietf-types@iana.org, payload@ietf.org Subject: Re: [payload] [ietf-types] Registration of application/smpte336m X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 15:46:01 -0000 * Ali C. Begen (abegen) wrote: >6.1. Media Type Definition > > Type name: application > > Subtype name: smpte336m > > Required parameters: > > rate: RTP timestamp clock rate. Typically chosen based on > sampling rate of metadata being transmitted, but other rates > can be specified. > > Optional parameters: None > > Encoding considerations: This media type is framed and binary; see > Section 4.8 of [RFC4288]. Why does this include "binary"? -- 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/ From rjsparks@nostrum.com Fri Jan 13 12:01:15 2012 Return-Path: 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 D9F1511E807A for ; Fri, 13 Jan 2012 12:01:15 -0800 (PST) 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 Vp1lQTbUFbMR for ; Fri, 13 Jan 2012 12:01:15 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 359AD11E8097 for ; Fri, 13 Jan 2012 12:01:02 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q0DK0sSi046772 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 13 Jan 2012 14:00:59 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F108D74.7080203@nostrum.com> Date: Fri, 13 Jan 2012 14:00:52 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: payload@ietf.org, draft-ietf-payload-rtp-klv@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [payload] AD review: draft-ietf-payload-rtp-klv-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 20:01:16 -0000 draft-ietf-payload-rtp-klv-02 is ready to proceed and I've requested IETF Last Call. During last call, please consider making it clear what's expected if a packet with the marker bit set is lost. RjS From iesg-secretary@ietf.org Fri Jan 13 12:14:51 2012 Return-Path: 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 9793621F856F; Fri, 13 Jan 2012 12:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 7Tm6pHTBp7QH; Fri, 13 Jan 2012 12:14:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202D121F8510; Fri, 13 Jan 2012 12:14:51 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120113201451.17179.55199.idtracker@ietfa.amsl.com> Date: Fri, 13 Jan 2012 12:14:51 -0800 Cc: payload@ietf.org Subject: [payload] Last Call: (RTP Payload Format for SMPTE 336M Encoded Data) to Proposed Standard X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 20:14:51 -0000 The IESG has received a request from the Audio/Video Transport Payloads WG (payload) to consider the following document: - 'RTP Payload Format for SMPTE 336M Encoded Data' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the payload format for packetization of KLV (Key-Length-Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in SMPTE 336M, into the Real-time Transport Protocol (RTP). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-klv/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-klv/ No IPR declarations have been submitted directly on this I-D. From jeff_downs@partech.com Tue Jan 17 08:22:52 2012 Return-Path: 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 C163821F858A for ; Tue, 17 Jan 2012 08:22:52 -0800 (PST) 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 aL8psj2lrYne for ; Tue, 17 Jan 2012 08:22:51 -0800 (PST) Received: from imail1.partech.com (imail1b.partech.com [192.133.62.25]) by ietfa.amsl.com (Postfix) with ESMTP id 68FC321F8497 for ; Tue, 17 Jan 2012 08:22:47 -0800 (PST) Received: from eclipse.partech.com (eclipse.partech.com [172.16.8.4]) by imail1.partech.com (8.13.1/8.12.11) with ESMTP id q0HGJiq6003301; Tue, 17 Jan 2012 11:19:44 -0500 Received: from beasley.parcorp.local (beasley.partech.com [172.16.16.70]) by eclipse.partech.com (8.12.9/8.12.9) with ESMTP id q0HGJebM008503; Tue, 17 Jan 2012 11:19:41 -0500 (EST) Received: from [192.168.248.11] ([192.168.248.11]) by beasley.parcorp.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jan 2012 11:19:41 -0500 Message-ID: <4F159F7F.5000706@partech.com> Date: Tue, 17 Jan 2012 11:19:11 -0500 From: Jeff Downs User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: derhoermi@gmx.net References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 17 Jan 2012 16:19:41.0504 (UTC) FILETIME=[D1193400:01CCD533] Cc: ietf-types@iana.org, payload@ietf.org Subject: Re: [payload] [ietf-types] Registration of application/smpte336m X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 16:22:52 -0000 The encoding considerations text of "binary and framed" in the proposed registration of application/smpte336m (as part of draft-ietf-payload-rtp-klv-02) comes literally out of the template in draft-ietf-payload-rtp-howto-01. The format is, indeed, binary (not textual). I reviewed RFC 3555 and the usage of "binary" vs. "framed" isn't very clear to me, but as I read it the difference is whether or not the payload data can exist "standalone" without the frame headers/transport data. SMPTE 336M data can indeed exist outside such framing and be reasonably interpreted (without the notion of data timing), though this certainly does not fall within the scope of the I-D submitted by myself (rather it is the core of the SMPTE 336M specification itself). I am more than happy to defer to the expertise of others; if dropping binary is the right thing to do here I am completely ok with that change. Please include me directly on any follow-ups. Jeff Downs PAR Government Systems -----Original Message----- From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net] Sent: Friday, January 13, 2012 10:46 AM To: Ali C. Begen (abegen) Cc: ietf-types@iana.org; payload@ietf.org Subject: Re: [ietf-types] Registration of application/smpte336m * Ali C. Begen (abegen) wrote: >6.1. Media Type Definition > > Type name: application > > Subtype name: smpte336m > > Required parameters: > > rate: RTP timestamp clock rate. Typically chosen based on > sampling rate of metadata being transmitted, but other rates > can be specified. > > Optional parameters: None > > Encoding considerations: This media type is framed and binary; see > Section 4.8 of [RFC4288]. Why does this include "binary"? -- 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/ From internet-drafts@ietf.org Tue Jan 24 01:08:38 2012 Return-Path: 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 0630B21F8579; Tue, 24 Jan 2012 01:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 7Z-gWFr1WlpQ; Tue, 24 Jan 2012 01:08:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CE821F8570; Tue, 24 Jan 2012 01:08:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120124090837.515.7608.idtracker@ietfa.amsl.com> Date: Tue, 24 Jan 2012 01:08:37 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-vp8-03.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 09:08:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Workin= g Group of the IETF. Title : RTP Payload Format for VP8 Video Author(s) : Patrik Westin Henrik F Lundin Michael Glover Justin Uberti Frank Galligan Filename : draft-ietf-payload-vp8-03.txt Pages : 28 Date : 2012-01-24 This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-vp8-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-payload-vp8-03.txt From rmadinger@avt-nbg.de Mon Jan 30 09:11:47 2012 Return-Path: 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 7CD1021F8634 for ; Mon, 30 Jan 2012 09:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] 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 QAUwdZcqTKKz for ; Mon, 30 Jan 2012 09:11:46 -0800 (PST) Received: from mail08a.verio.de (mail08a.verio.de [213.198.55.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9D53421F8629 for ; Mon, 30 Jan 2012 09:11:45 -0800 (PST) Received: from mx06.stngva01.us.mxservers.net (204.202.242.35) by mail08a.verio.de (RS ver 1.0.95vs) with SMTP id 2-0244673497 for ; Mon, 30 Jan 2012 18:11:38 +0100 (CET) Received: from unknown [213.198.107.44] (EHLO mmm825.verio.de) by va1-mx06.stngva01.us.mxservers.net (mxl_mta-3.1.0-05) with ESMTP id a4fc62f4.2518551456.99328.00-009.va1-mx06.stngva01.us.mxservers.net (envelope-from ); Mon, 30 Jan 2012 12:11:38 -0500 (EST) Received: (qmail 18103 invoked from network); 30 Jan 2012 17:11:36 -0000 Received: from unknown (HELO mail.avt-nbg.de) (avtnbg@212.34.164.22) by with ESMTPA; 30 Jan 2012 17:11:36 -0000 Received: from AVT-SBS11.avt.local ([fe80::b0a2:722e:5a90:5d0d]) by AVT-SBS11.avt.local ([fe80::b0a2:722e:5a90:5d0d%12]) with mapi id 14.01.0355.002; Mon, 30 Jan 2012 18:11:36 +0100 From: Robert Madinger To: "'payload@ietf.org'" Thread-Topic: [payload] draft-rea-payload-rtp-aptx-01 Thread-Index: AczfbyFz43AliPgJQ3ailYRpCssDHQ== Date: Mon, 30 Jan 2012 17:11:34 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.96.165] Content-Type: multipart/alternative; boundary="_000_DE6259621143AA43A4E997E97556AC3A22520BAVTSBS11avtlocal_" MIME-Version: 1.0 X-Spam: [F=0.2000000000; S=0.200(2010122901); MH=0.500(2012013016)] X-MAIL-FROM: X-SOURCE-IP: [213.198.107.44] X-SF-Loop: 1 Subject: [payload] draft-rea-payload-rtp-aptx-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:16:40 -0000 --_000_DE6259621143AA43A4E997E97556AC3A22520BAVTSBS11avtlocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hallo, This is Robert Madinger from AVT Audio Video Technologies Nuremberg. We have implemented already an older version of the "RTP Payload Format for= Standard apt-X and Enhanced apt-X Codecs" in our Audio Codecs. We just hav= e to do some adaptations concerning the SDP signalling to implement the new= est draft for APT-X transmission over IP. To avoid additional steps in our software development, we would prefer the = draft to be passed on to become an RFC before we adapt our implementation. Therefore we support the draft to be passed on to become an RFC! Robert Madinger ________________________________ AVT Audio Video Technologies GmbH Nordostpark 12 D-90411 Nuernberg Phone: +49 911 5271 200 Fax: +49 911 5271 100 RMadinger@avt-nbg.de www.avt-nbg.de Managing Director: Wilfried Hecht Registered Office: Nuernberg, HRB 14317 --_000_DE6259621143AA43A4E997E97556AC3A22520BAVTSBS11avtlocal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hallo,

 

This is Robert Madinger from AV= T Audio Video Technologies Nuremberg.

We have implemented already an = older version of the “RTP Payload Format for Standard apt-X and Enhanced= apt-X Codecs” in our Audio Codecs. We just have to do some adaptatio= ns concerning the SDP signalling to implement the newest draft for APT-X transmission over IP.

To avoid additional steps in ou= r software development, we would prefer the draft to be passed on to become= an RFC before we adapt our implementation.

Therefore we support the draft = to be passed on to become an RFC!

 

Robert Madinger

 

_______________________= _________

AVT Audio Video Technol= ogies GmbH

Nordostpark 12

D-90411 Nuernberg<= /o:p>

Phone: &= #43;49 911 5271 200

Fax:&nbs= p;  +49 911 5271 100

RMadinger@avt-n= bg.de

www.avt-nbg.de

&nb= sp;

Managing= Director: Wilfried Hecht

Registered Office: Nuer= nberg, HRB 14317

 

--_000_DE6259621143AA43A4E997E97556AC3A22520BAVTSBS11avtlocal_-- From Rea@worldcastsystems.com Tue Jan 31 02:02:24 2012 Return-Path: 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 1A6F721F8569 for ; Tue, 31 Jan 2012 02:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 l5eib0WDbb1i for ; Tue, 31 Jan 2012 02:02:22 -0800 (PST) Received: from mailgate.aptcodecs.com (mailgate.aptcodecs.com [217.33.179.85]) by ietfa.amsl.com (Postfix) with ESMTP id A944521F8552 for ; Tue, 31 Jan 2012 02:02:21 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCDFFF.6B424D21" Date: Tue, 31 Jan 2012 10:02:19 -0000 Message-ID: <8C4E0C2409735E4FBC22D754A238F94D02A4BD23@APTSBS.apt.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] draft-rea-payload-rtp-aptx-01 Thread-Index: AczfbyFz43AliPgJQ3ailYRpCssDHQAhfLIg From: "Derrick Rea" To: Subject: Re: [payload] draft-rea-payload-rtp-aptx-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 10:02:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCDFFF.6B424D21 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Robert, =20 Thanks for reviewing draft-rea-payload-rtp-aptx-01 against your current implementation of Standard apt-X and Enhanced apt-X over IP.=20 =20 Yes there has been some media type/SDP definition changes in the latest draft. The differences between this draft and the draft-trainor-avt-rtp-aptx are not significant however. A default ptime of 4ms is now recommended and the "ip-aux" definition has changed to "out-of-bound-aux". There are a greater number of changes when compared to draft-gmassey-avt-aptx but hopefully if your products are based on this implementation the changes will not require a huge amount of work. =20 We've like to move this version of the aptx/e-aptx over RTP internet draft along the standards track as quickly as possible. The next milestones are for the document to become a Working Group document and go to Working Group Last Call. With more review, I hope this will happen soon. I know that there are a lot of manufacturers, like ourselves, who want to see this draft progress so they can implement to a defined standard and not one that is continually shifting.=20 =20 Regards, Derrick Rea =20 =20 From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Robert Madinger Sent: 30 January 2012 17:12 To: 'payload@ietf.org' Subject: [payload] draft-rea-payload-rtp-aptx-01 =20 Hallo, =20 This is Robert Madinger from AVT Audio Video Technologies Nuremberg. We have implemented already an older version of the "RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs" in our Audio Codecs. We just have to do some adaptations concerning the SDP signalling to implement the newest draft for APT-X transmission over IP. To avoid additional steps in our software development, we would prefer the draft to be passed on to become an RFC before we adapt our implementation. Therefore we support the draft to be passed on to become an RFC! =20 Robert Madinger =20 ________________________________ AVT Audio Video Technologies GmbH Nordostpark 12 D-90411 Nuernberg Phone: +49 911 5271 200 Fax: +49 911 5271 100 RMadinger@avt-nbg.de www.avt-nbg.de =20 Managing Director: Wilfried Hecht Registered Office: Nuernberg, HRB 14317 =20 ------_=_NextPart_001_01CCDFFF.6B424D21 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Robert,

 

Thanks for = reviewing draft-rea-payload-rtp-aptx-01 against your current = implementation of Standard = apt-X and Enhanced apt-X over IP.

 

Yes there = has been some media type/SDP definition changes in the latest draft. The = differences between this draft and the draft-trainor-avt-rtp-aptx are = not significant however. A default ptime of 4ms is now recommended and = the “ip-aux” definition has changed to = “out-of-bound-aux”. There are a greater number of changes = when compared to draft-gmassey-avt-aptx but hopefully if your products = are based on this implementation the changes will not require a huge = amount of work.

 

We’ve like to move this = version of the aptx/e-aptx over RTP internet draft along the standards = track as quickly as possible. The next milestones are for the document = to become a Working Group document and go to Working Group Last Call. = With more review, I hope this will happen soon. I know that there are a = lot of manufacturers, like ourselves, who want to see this draft = progress so they can implement to a defined standard and not one that is = continually shifting.

 

Regards,

Derrick Rea

 

 

From: payload-bounces@ietf.org = [mailto:payload-bounces@ietf.org] On Behalf Of Robert = Madinger
Sent: 30 January 2012 17:12
To: = 'payload@ietf.org'
Subject: [payload] = draft-rea-payload-rtp-aptx-01

 

Hallo,

 

This is Robert Madinger from AVT Audio Video Technologies = Nuremberg.

We have implemented already an older version of the = “RTP Payload = Format for Standard apt-X and Enhanced apt-X Codecs” in our Audio = Codecs. We just have to do some adaptations concerning the SDP = signalling to implement the newest draft for APT-X transmission over = IP.

To = avoid additional steps in our software development, we would prefer the = draft to be passed on to become an RFC before we adapt our = implementation.

Therefore we support the draft to be passed on to become an = RFC!

 

Robert Madinger

 

________________________________=

AVT Audio Video Technologies = GmbH

Nordostpark = 12

D-90411 = Nuernberg

Phone: +49 911 5271 = 200

Fax:   +49 911 5271 = 100

RMadinger@avt-nbg.de<= /span>

www.avt-nbg.de

 

Managing Director: Wilfried = Hecht

Registered Office: Nuernberg, = HRB 14317

 

------_=_NextPart_001_01CCDFFF.6B424D21--