From Internet-Drafts@ietf.org Mon May 2 01:00:01 2011 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 CDDF2E062A; Mon, 2 May 2011 01:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, 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 U5YK3jCSds5N; Mon, 2 May 2011 01:00:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA6EE0689; Mon, 2 May 2011 01:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110502080001.18398.49023.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2011 01:00:01 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action:draft-ietf-payload-rfc3016bis-00.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, 02 May 2011 08:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for MPEG-4 Audio/Visual Streams Author(s) : M. Schmidt, et al. Filename : draft-ietf-payload-rfc3016bis-00.txt Pages : 32 Date : 2011-05-01 This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of Session Description Protocol (SDP). The audio payload format described in this document has some limitations. for new system designs [RFC3640] is preferred. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-rfc3016bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-payload-rfc3016bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-02005432.I-D@ietf.org> --NextPart-- From frans.de.bont@philips.com Mon May 2 01:19:29 2011 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 3C14DE06FB for ; Mon, 2 May 2011 01:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 MGAVj0zEhIAS for ; Mon, 2 May 2011 01:19:28 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1outboundpool.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBDAE0689 for ; Mon, 2 May 2011 01:19:28 -0700 (PDT) Received: from mail72-ch1-R.bigfish.com (216.32.181.170) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.8; Mon, 2 May 2011 08:19:27 +0000 Received: from mail72-ch1 (localhost.localdomain [127.0.0.1]) by mail72-ch1-R.bigfish.com (Postfix) with ESMTP id 184647E02A3 for ; Mon, 2 May 2011 08:19:27 +0000 (UTC) X-SpamScore: -47 X-BigFish: VPS-47(zz217bL15d6O9251J936eK542M1432Nzz1202hzz1033IL8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail72-ch1 (localhost.localdomain [127.0.0.1]) by mail72-ch1 (MessageSwitch) id 1304324366882606_13638; Mon, 2 May 2011 08:19:26 +0000 (UTC) Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail72-ch1.bigfish.com (Postfix) with ESMTP id D29CF1B8004D for ; Mon, 2 May 2011 08:19:26 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 2 May 2011 08:19:26 +0000 Received: from nlamsexh03.connect1.local (172.16.153.24) by connect1.philips.com (172.16.156.40) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 2 May 2011 10:19:15 +0200 Received: from NLCLUEXM01.connect1.local ([172.16.153.10]) by nlamsexh03.connect1.local ([172.16.153.24]) with mapi; Mon, 2 May 2011 10:19:07 +0200 From: "Bont, Frans de" To: "payload@ietf.org" Date: Mon, 2 May 2011 10:19:04 +0200 Thread-Topic: [payload] I-D Action:draft-ietf-payload-rfc3016bis-00.txt Thread-Index: AcwInwagV/eOAbQYRlSLtG/8wBsRngAAbJmA Message-ID: <19FE62CE8D62CF4B96C845DC556B8813927F600A30@NLCLUEXM01.connect1.local> References: <20110502080001.18398.49023.idtracker@ietfa.amsl.com> In-Reply-To: <20110502080001.18398.49023.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [payload] I-D Action:draft-ietf-payload-rfc3016bis-00.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, 02 May 2011 08:19:29 -0000 Hi, This draft has been re-submitted as a payload draft to enable the chairs to= send it to publication. The text is identical to that of draft-ietf-avt-rfc3016bis-02.txt. Best regards, Frans > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Monday 2 May 2011 10:00 > To: i-d-announce@ietf.org > Cc: payload@ietf.org > Subject: [payload] I-D Action:draft-ietf-payload-rfc3016bis-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Audio/Video Transport Payloads Working > Group of the IETF. > > > Title : RTP Payload Format for MPEG-4 Audio/Visual > Streams > Author(s) : M. Schmidt, et al. > Filename : draft-ietf-payload-rfc3016bis-00.txt > Pages : 32 > Date : 2011-05-01 > > This document describes Real-Time Transport Protocol (RTP) payload > formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams > without using MPEG-4 Systems. For the purpose of directly mapping > MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides > specifications for the use of RTP header fields and also specifies > fragmentation rules. It also provides specifications for Media Type > registration and the use of Session Description Protocol (SDP). The > audio payload format described in this document has some limitations. > for new system designs [RFC3640] is preferred. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-payload-rfc3016bis- > 00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From Internet-Drafts@ietf.org Mon May 2 03:30:02 2011 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 38377E06DC; Mon, 2 May 2011 03:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, 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 fTjkThApoIBb; Mon, 2 May 2011 03:30:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B9CE06B5; Mon, 2 May 2011 03:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110502103001.17972.79319.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2011 03:30:01 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action:draft-ietf-payload-vp8-00.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, 02 May 2011 10:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for VP8 Video Author(s) : P. Westin, H. Lundin Filename : draft-ietf-payload-vp8-00.txt Pages : 25 Date : 2011-05-02 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-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-payload-vp8-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-02032559.I-D@ietf.org> --NextPart-- From Even.roni@huawei.com Fri May 6 01:40:17 2011 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 B1FF4E06F5; Fri, 6 May 2011 01:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.798 X-Spam-Level: X-Spam-Status: No, score=-100.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_45=0.6, 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 Yhenr1u7o1WG; Fri, 6 May 2011 01:40:14 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC5AE0663; Fri, 6 May 2011 01:40:13 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKR00HE3MNGB7@szxga05-in.huawei.com>; Fri, 06 May 2011 16:38:05 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKR00AFYMNFG2@szxga05-in.huawei.com>; Fri, 06 May 2011 16:38:04 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-32-24.red.bezeqint.net [79.183.32.24]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKR006R6MMYMV@szxml11-in.huawei.com>; Fri, 06 May 2011 16:38:03 +0800 (CST) Date: Fri, 06 May 2011 11:36:15 +0300 From: Roni Even To: iesg-secretary@ietf.org, 'Robert Sparks' Message-id: <04c301cc0bc8$b24fca00$16ef5e00$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_CNlCbHFTEawsakt34vHxag)" Content-language: en-us Thread-index: AcwLyKhr5Jd/2vfeT/Ks0fngJm6j6A== Cc: payload@ietf.org, draft-ietf-payload-rfc3016bis.all@tools.ietf.org Subject: [payload] Request to publish draft-ietf-payload-rfc3016bis-00 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, 06 May 2011 08:40:17 -0000 This is a multi-part message in MIME format. --Boundary_(ID_CNlCbHFTEawsakt34vHxag) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Robert, I'd like to request that draft-ietf-payload-rfc3016bis-00, RTP Payload Format for MPEG-4 Audio/Visual Streams. I've reviewed the draft in detail, and the AVT / Payload working groups were given the opportunity to comment. The draft is documented in sufficient detail to meet the registration requirements, and doesn't conflict with other work in AVT/Payload. Accordingly, please consider it for publication. Thanks, Roni Even (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Roni Even. I have reviewed the document, and believe it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document went through a Working Group last call and people had enough time to review it. There were comments in the WGLC at AVT at the time and they were addressed in this revision of the document. This document is an update to an existing RFC and the document Shepherd feels that the review was satisfactory. The document was re-submitted as draft-ietf-payload-rfc3016bis-00 and is the same as draft-ietf-avt-rfc3016bis-02. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No Concerns (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This is an update to an existing payload specification. It has consensus of a few individual who reviewed the draft. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits?(See the Checklist and idnits ).Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The idnits tool reports some comments which are OK. The media subtype registration was sent to review to ietf-types mailing list. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA consideration section exists and is inline with the body of the document. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? No such sections (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. "This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of Session Description Protocol (SDP). The audio payload format described in this document has some limitations for new system designs [RFC3640] is preferred." Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? No issues Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The media type review was posted on April 28, 2011. The document updates RFC3016 to support existing implementations that comply with the specification in 3GPP PSS. --Boundary_(ID_CNlCbHFTEawsakt34vHxag) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Robert,

I'd like to request that draft-ietf-payload-rfc3016bis-00, RTP Payload Format for MPEG-4 Audio/Visual Streams.

I've reviewed the AVT / Payload working groups were given the opportunity to comment. The draft is documented in sufficient detail to meet the registration requirements, and doesn't conflict with other work in AVT/Payload. Accordingly, please consider it for publication.

 

Thanks,

Roni Even

 

 

( 1.a) Who for this document? Has the

        Document Shepherd personally reviewed this version of the

        document and, in particular, does he or she believe this

        version is ready for forwarding to the IESG for publication?

 

The document shepherd is Roni Even. I have reviewed the document, and believe it is ready for publication.

 

  (1.b) Has the document had adequate review both from key WG members

        and from key non-WG members ? Does t

        any concerns about the depth or breadth of the reviews that

        have been performed? 

 

The document went through a Working Group last call and people had enough time to review it. There were comments in the WGLC at AVT at the time and they were addressed in this revision of the document. This document is an update to an existing RFC and the document Shepherd feels that the review was satisfactory. The document was re-submitted as draft-ietf-payload-rfc3016bis-00 and is the same as draft-ietf-avt-rfc3016bis-02.

 

  (1.c) Does the Document Shepherd have concerns that the docum ent         needs more review from a particular or broader perspective,

        e.g., security, operational complexity, someone familiar with

        AAA, internationalization or XML?

 

No concerns

 

 

  (1.d) Does the Document Shepherd have any specific concerns or

        issues with this document that the Responsible Area Director

        and/or the IESG should be aware of? For example, perhaps he

&n bsp;&nbs ;  or she is uncomfortable with certain parts of the document, or

        has concerns whether there really is a need for it. In any

        event, if the WG has discussed those issues and has indicated

        that it still wishes to advance the document, detail those

        concerns here. Has an IPR disclosure related to this document

        been filed? If so, please include a reference to the

        disclosure and summarize the WG discussion and conclusion on

   ; & bsp;this issue.

 

No Concerns

 

(1.e) How solid is the WG consensus behind this document? Does it

        represent the strong concurrence of a few individuals, with

        others being silent, or does the WG as a whole understand and

        agree with it?

 

This is an update to an existing payload specification. It has consensus of a few individual who reviewed the draft.

 

  (1.f) Has anyone threatened an appeal or otherwise indi cated ex lass=Preformatted>        discontent? If so, please summarise the areas of conflict in

        separate email messages to the Responsible Area Director. (It

        should be in a separate email because this questionnaire is

        entered into the ID Tracker.)

 

No

  (1.g) Has the Document Shepherd personally verified that the

document satisfies all ID nits?(See the Checklist and idnits).Boilerplate checks a needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews?

 

The idnits tool reports some comments which are OK.

The media subtype registration was sent to review to ietf-types mailing list.

 

  (1.h) Has the document split its references into normative and

        informative? Are there normative references to documents that

        are not ready for advancement or are otherwise in an unclear

    &n sp;state? If such normative references exist, what is the

        strategy for their completion? Are there normative references

        that are downward references, as described in [RFC3967]? If

        so, list these downward references to support the Area

        Director in the Last Call procedure for them [RFC3967].

  

 

References are split

 

(1.i) Has the Document Shepherd verified that the document IANA

      ; & section exists and is consistent with the body

        of the document? If the document specifies protocol

        extensions, are reservations requested in appropriate IANA

        registries? Are the IANA registries clearly identified? If

        the document creates a new registry, does it define the

        proposed initial contents of the registry and an allocation

        procedure for future registrations? Does it suggest a

        reasonab le name [RFC5226]. If the

        document describes an Expert Review process has Shepherd

        conferred with the Responsible Area Director so that the IESG

        can appoint the needed Expert during the IESG Evaluation?

 

 

The IANA consideration section exists and is inline with the body of the document.

 

  (1.j) Has the Document Shepherd verified that sections of the

        document that are written in a formal language, such as XM L < atted>        code, BNF rules, MIB definitions, etc., validate correctly in

        an automated checker?

 

No such sections

 

  (1.k) The IESG approval announcement includes a Document

        Announcement Write-Up. Please provide such a Document

        Announcement Write-Up? Recent examples can be found in the

        "Action" announcements for approved documents. The approval

        announceme nt conta s:

     Technical Summary

        Relevant content can frequently be found in the abstract

        and/or introduction of the document. If not, this may be

        an indication that there are deficiencies in the abstract

        or introduction.

     

“This document describes Real-Time Transport Protocol (RTP) payload

   formats for carrying each of MPEG-4 Audio and MPEG-4 Visual

   bitstreams without using MPEG-4 Syste ms.  ctly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules.  It also provides specifications for Media Type registration and the use of Session Description Protocol (SDP).  The audio payload format described in this document has some limitations for new system designs [RFC3640] is preferred.”

 

Working Group Summary

        Was there anything in WG process that is worth noting? For

        example, was there controversy about particular points or

        were there decisions where the consensus was particularly

 &nbs p;  nbsp;rough?

     

No issues

 

 

 

Document Quality

        Are there existing implementations of the protocol? Have a

        significant number of vendors indicated their plan to

        implement the specification? Are there any reviewers that

        merit special mention as having done a thorough review,

        e.g., one that resulted in imp ortant c p>

        conclusion that the document had no substantive issues? If

        there was a MIB Doctor, Media Type or other expert review,

        what was its course (briefly)? In the case of a Media Type

        review, on what date was the request posted?

 

The media type review was posted on April 28, 2011.

The document updates RFC3016 to support existing implementations that comply with the specification in 3GPP PSS.

< bsp;

--Boundary_(ID_CNlCbHFTEawsakt34vHxag)-- From Internet-Drafts@ietf.org Fri May 6 11:15:05 2011 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 28B3BE076F; Fri, 6 May 2011 11:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, 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 vSK3bCyGDvb1; Fri, 6 May 2011 11:15:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F4FE076C; Fri, 6 May 2011 11:15:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110506181503.17839.22936.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2011 11:15:03 -0700 Cc: payload@ietf.org Subject: [payload] I-D ACTION:draft-ietf-payload-rtp-g718-00.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, 06 May 2011 18:15:05 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for G.718 Speech/Audio Author(s) : G. Zorn, et al Filename : draft-ietf-payload-rtp-g718-00.txt Pages : 27 Date : 2011-04-23 This document specifies the Real-Time Transport Protocol (RTP) payload format for the Embedded Variable Bit-Rate (EV-VBR) speech/ audio codec, specified in ITU-T G.718. A media type registration for this RTP payload format is also included. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-rtp-g718-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-payload-rtp-g718-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-06110504.I-D@ietf.org> --NextPart-- From wwwrun@rfc-editor.org Fri May 6 17:20:12 2011 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 D36F4E069D; Fri, 6 May 2011 17:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.969 X-Spam-Level: X-Spam-Status: No, score=-101.969 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, 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 jp1SO+AhO+dG; Fri, 6 May 2011 17:20:08 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id A8F31E064B; Fri, 6 May 2011 17:20:08 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A9931E0742; Fri, 6 May 2011 17:20:08 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110507002008.A9931E0742@rfc-editor.org> Date: Fri, 6 May 2011 17:20:08 -0700 (PDT) Cc: payload@ietf.org, rfc-editor@rfc-editor.org Subject: [payload] RFC 6190 on RTP Payload Format for Scalable Video Coding 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: Sat, 07 May 2011 00:20:13 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6190 Title: RTP Payload Format for Scalable Video Coding Author: S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis Status: Standards Track Stream: IETF Date: May 2011 Mailbox: stewe@stewe.org, yekui.wang@huawei.com, ts@thomas-schierl.de, alex@vidyo.com Pages: 100 Characters: 250504 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-rtp-svc-27.txt URL: http://www.rfc-editor.org/rfc/rfc6190.txt This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backward compatible to RFC 6184 since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in RFC 6184. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others. [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Payloads Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From hlundin@google.com Tue May 10 07:48:07 2011 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 3EB3CE0768 for ; Tue, 10 May 2011 07:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 4c1lXAao8lzP for ; Tue, 10 May 2011 07:48:06 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id EA31FE0767 for ; Tue, 10 May 2011 07:48:05 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p4AEPg59011896 for ; Tue, 10 May 2011 07:25:47 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305037547; bh=29RZofqAM9Ojg//GjE36HNNG2ik=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=oA+6jBtZ6yId/8f4WYkP9EBvGiGAuhowLeEPq1oZHv14BvwzbqYJNd/Isj03imjVP OYDA8NnBBY7laI3RSopXw== Received: from yxp4 (yxp4.prod.google.com [10.190.4.196]) by hpaq1.eem.corp.google.com with ESMTP id p4AEOpSY006876 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 10 May 2011 07:25:21 -0700 Received: by yxp4 with SMTP id 4so2887009yxp.24 for ; Tue, 10 May 2011 07:25:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=RQm9JeAUTYNKVRcuZHCun4cU12N2/9ZfpQeYZs2q6z8=; b=eBQUYE69hY2T4PGFubEUcPqnUi8NTX/R+TFyRLgVb/6wqGJeiRu3chKnfn4PY02EoE wkqcY0RoCDYk6McIL0MQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:content-type; b=bT2k3Zewkzhe2TcdE+d4MEMedpIAhLJZDSOIuB1hNHytnq004q6fy7K2GEBf1faCZY R3r0SX0u4wd5KJjF2G2A== MIME-Version: 1.0 Received: by 10.100.105.14 with SMTP id d14mr4973468anc.26.1305037521201; Tue, 10 May 2011 07:25:21 -0700 (PDT) Received: by 10.100.136.12 with HTTP; Tue, 10 May 2011 07:25:21 -0700 (PDT) Date: Tue, 10 May 2011 16:25:21 +0200 Message-ID: From: Henrik Lundin To: payload@ietf.org, draft-ietf-payload-vp8@tools.ietf.org Content-Type: multipart/alternative; boundary=0016e645b8e8dea97904a2ecb98c X-System-Of-Record: true Subject: [payload] VP8 RTP format draft 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, 10 May 2011 14:48:07 -0000 --0016e645b8e8dea97904a2ecb98c Content-Type: text/plain; charset=ISO-8859-1 Hi all, We have uploaded a first WG document version of the RTP format for VP8: http://www.ietf.org/internet-drafts/draft-ietf-payload-vp8-00.txt. In this version, we have considered the valuable feedback we got on the earlier drafts. At IETF 80 in Prague, we had interesting discussions with Stephan Wenger and Jonathan Lennox regarding signaling support for temporal scalability. Our intention is to incorporate support for temporal scalability in the next draft revision. Sincerely, /Henrik Lundin Google --0016e645b8e8dea97904a2ecb98c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

We have uploaded a first WG document version of the RTP format for VP8:=A0<= a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-payload-vp8-00.txt= " style=3D"color:rgb(0, 0, 204)" target=3D"_blank">http://www.ietf.org/inte= rnet-drafts/draft-ietf-payload-vp8-00.txt. In this version, we have con= sidered the valuable feedback we got on the earlier drafts.

At IETF 80 in Prague, we had interesting discussions wi= th Stephan Wenger and Jonathan Lennox regarding signaling support for tempo= ral scalability. Our intention is to incorporate support for temporal scala= bility in the next draft revision.

Sincerely,
/Henrik Lundin
Google


--0016e645b8e8dea97904a2ecb98c-- From Even.roni@huawei.com Wed May 11 00:57:07 2011 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 2943BE0756 for ; Wed, 11 May 2011 00:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 QQ6RNe6rMXw3 for ; Wed, 11 May 2011 00:57:06 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5F2E06C1 for ; Wed, 11 May 2011 00:57:06 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL000ABMU2VQN@szxga03-in.huawei.com> for payload@ietf.org; Wed, 11 May 2011 15:56:55 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL000HXZU2VBS@szxga03-in.huawei.com> for payload@ietf.org; Wed, 11 May 2011 15:56:55 +0800 (CST) Received: from windows8d787f9 (bzq-79-177-8-204.red.bezeqint.net [79.177.8.204]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LL000FCBU2OL8@szxml12-in.huawei.com>; Wed, 11 May 2011 15:56:55 +0800 (CST) Date: Wed, 11 May 2011 10:55:33 +0300 From: Roni Even To: payload@ietf.org Message-id: <000c01cc0fb0$d3036ea0$790a4be0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_aJHZnH4YdRjIf15DXy0MXw)" Content-language: en-us Thread-index: AcwPsM2X1Q46kSc/QWKvkrDprIki5g== Subject: [payload] WGLC on draft-ietf-payload-rfc3189bis-00 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 May 2011 07:57:07 -0000 This is a multi-part message in MIME format. --Boundary_(ID_aJHZnH4YdRjIf15DXy0MXw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I would like to start a Working Group Last Call on draft-ietf-payload-rfc3189bis-00 , RTP Payload Format for DV (IEC 61834) Video. The WGLC will end on May 30, 2011 Please review the draft and send comments to the list. Note that section 7 discusses the changes from RFC3189. Roni Even Payload co-chair --Boundary_(ID_aJHZnH4YdRjIf15DXy0MXw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

I would like to start a Working Group Last Call on draft-ietf-payload-rfc3189bis-00, RTP Payload Format for DV (IEC 61834) Video.

 

The WGLC will end on May 30, 2011

Please review the draft and send comments to the list.

 

Note that section 7 discusses the changes from RFC3189.

 

Roni Even

Payload co-chair

 

--Boundary_(ID_aJHZnH4YdRjIf15DXy0MXw)-- From gwz@net-zen.net Sun May 15 00:47:14 2011 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 C6366E066C for ; Sun, 15 May 2011 00:47:14 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SG94cmzmiupu for ; Sun, 15 May 2011 00:47:14 -0700 (PDT) Received: from smtpauth16.prod.mesa1.secureserver.net (smtpauth16.prod.mesa1.secureserver.net [64.202.165.22]) by ietfa.amsl.com (Postfix) with SMTP id 58D76E065D for ; Sun, 15 May 2011 00:47:11 -0700 (PDT) Received: (qmail 15908 invoked from network); 15 May 2011 07:25:27 -0000 Received: from unknown (124.122.83.151) by smtpauth16.prod.mesa1.secureserver.net (64.202.165.22) with ESMTP; 15 May 2011 07:25:27 -0000 Message-ID: <4DCF84F6.3010003@net-zen.net> Date: Sun, 15 May 2011 14:47:02 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Miaolei References: <11C35F73DA9BE14D92014E6B8E22F7F004B74D@SZXEML519-MBX.china.huawei.com> In-Reply-To: <11C35F73DA9BE14D92014E6B8E22F7F004B74D@SZXEML519-MBX.china.huawei.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------080505080203020805070203" Cc: "lasse.j.laaksonen@nokia.com" , payload-chairs@tools.ietf.org, "payload@ietf.org" , yusuke hiwasaki , "'Virette, David'" Subject: Re: [payload] G.718B payload format 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, 15 May 2011 07:47:14 -0000 This is a multi-part message in MIME format. --------------080505080203020805070203 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/7/2011 2:45 PM, Miaolei wrote: > Dear Glen > > First, thanks for your hard work on G.718 payload format. Sorry for the slow reply! > > I have worked on the ITU-T G.718B(ex G.718-SWB) standardization and > would like to know the status or plan for G.718B payload format. > In the draft-ietf-avt-rtp-g718-05.txt, it was said that > ---- > ITU-T SG16 is currently working on a set of extension layers in order > to provide so-called super-wideband (SWB) audio and stereophonic > encoding extensions on top of the G.718 core codec. > ----- > > Actually the SWB mono part have been approved in ITU-T in Mar. 2010. > Stereo work is still ongoing. > Is it possible to consider the G.718B together with G.718 for the > payload format? > For example, we can add some L-IDs for the G.718B layers. It's really up to the payload WG and its Chairs, but it's OK with me. ... --------------080505080203020805070203 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="gwz.vcf" YmVnaW46dmNhcmQNCmZuOkdsZW4gWm9ybg0Kbjpab3JuO0dsZW4NCm9yZzpOZXR3b3JrIFpl bg0KYWRyOjs7O1NlYXR0bGU7V0E7O1VTQQ0KZW1haWw7aW50ZXJuZXQ6Z3d6QG5ldC16ZW4u bmV0DQp0ZWw7Y2VsbDorNjYgODcgMDQwIDQ2MTcNCm5vdGU6UEdQIEtleSBGaW5nZXJwcmlu dDogREFEMyBGNUQzIEFDRTYgNDE5NSA5QzVDICAyRUUxIDZFMTcgQjVGNiA1OTUzIEI0NUYg DQp2ZXJzaW9uOjIuMQ0KZW5kOnZjYXJkDQoNCg== --------------080505080203020805070203-- From abegen@cisco.com Sun May 15 11:03:37 2011 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 BE2A9E06D6 for ; Sun, 15 May 2011 11:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 zrOu99y4eCG8 for ; Sun, 15 May 2011 11:03:37 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 22C3EE068C for ; Sun, 15 May 2011 11:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1922; q=dns/txt; s=iport; t=1305482617; x=1306692217; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=izPWWQKQDEZBN4zM68kKLMbJb+Ndaq8rHOAbvGtBF08=; b=aq/80sX9BBIXH7xXc0qC0y2gkuM0Kyqm6knZeo3gPh41joCDzBIJeock Yd9tkelbiJVSV1jQ3MJZfpkrcVUxaU4R2Qh3NxoyMz0Hdl/Rhx4rYTluy j+SzKv8CysPlUnvR/7oKbDyrZPyZJUXoGEYAVjVPb79KrPMMZtbuxUpIG A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BACsV0E2rRDoH/2dsb2JhbACEWJJ3jVVwd6pbjQOPdoErg2eBBwSGUI15il0 X-IronPort-AV: E=Sophos;i="4.64,369,1301875200"; d="scan'208";a="448070040" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 15 May 2011 18:03:36 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4FI3aMi018202; Sun, 15 May 2011 18:03:36 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, 15 May 2011 11:03:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 15 May 2011 11:03:29 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540EFFE906@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4DCF84F6.3010003@net-zen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] G.718B payload format Thread-Index: AcwS1FIo4J7NS41gT9KxtAV9h/R7IwAVfJEw References: <11C35F73DA9BE14D92014E6B8E22F7F004B74D@SZXEML519-MBX.china.huawei.com> <4DCF84F6.3010003@net-zen.net> From: "Ali C. Begen (abegen)" To: "Glen Zorn" , "Miaolei" X-OriginalArrivalTime: 15 May 2011 18:03:36.0705 (UTC) FILETIME=[69891F10:01CC132A] Cc: lasse.j.laaksonen@nokia.com, yusuke hiwasaki , "Virette, David" , payload@ietf.org, payload-chairs@tools.ietf.org Subject: Re: [payload] G.718B payload format 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, 15 May 2011 18:03:37 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcGF5bG9hZC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86cGF5bG9hZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg R2xlbiBab3JuDQo+IFNlbnQ6IFN1bmRheSwgTWF5IDE1LCAyMDExIDM6NDcgQU0NCj4gVG86IE1p YW9sZWkNCj4gQ2M6IGxhc3NlLmoubGFha3NvbmVuQG5va2lhLmNvbTsgcGF5bG9hZC1jaGFpcnNA dG9vbHMuaWV0Zi5vcmc7IHBheWxvYWRAaWV0Zi5vcmc7IHl1c3VrZSBoaXdhc2FraTsgJ1ZpcmV0 dGUsRGF2aWQnDQo+IFN1YmplY3Q6IFJlOiBbcGF5bG9hZF0gRy43MThCIHBheWxvYWQgZm9ybWF0 DQo+IA0KPiBPbiAzLzcvMjAxMSAyOjQ1IFBNLCBNaWFvbGVpIHdyb3RlOg0KPiA+IERlYXIgR2xl bg0KPiA+DQo+ID4gRmlyc3QsIHRoYW5rcyBmb3IgeW91ciBoYXJkIHdvcmsgb24gRy43MTggcGF5 bG9hZCBmb3JtYXQuDQo+IA0KPiBTb3JyeSBmb3IgdGhlIHNsb3cgcmVwbHkhDQo+IA0KPiA+DQo+ ID4gSSBoYXZlIHdvcmtlZCBvbiB0aGUgSVRVLVQgRy43MThCKGV4IEcuNzE4LVNXQikgc3RhbmRh cmRpemF0aW9uIGFuZA0KPiA+IHdvdWxkIGxpa2UgdG8ga25vdyB0aGUgc3RhdHVzIG9yIHBsYW4g Zm9yIEcuNzE4QiBwYXlsb2FkIGZvcm1hdC4NCj4gPiBJbiB0aGUgZHJhZnQtaWV0Zi1hdnQtcnRw LWc3MTgtMDUudHh0LCBpdCB3YXMgc2FpZCB0aGF0DQo+ID4gLS0tLQ0KPiA+IElUVS1UIFNHMTYg aXMgY3VycmVudGx5IHdvcmtpbmcgb24gYSBzZXQgb2YgZXh0ZW5zaW9uIGxheWVycyBpbiBvcmRl cg0KPiA+ICAgIHRvIHByb3ZpZGUgc28tY2FsbGVkIHN1cGVyLXdpZGViYW5kIChTV0IpIGF1ZGlv IGFuZCBzdGVyZW9waG9uaWMNCj4gPiAgICBlbmNvZGluZyBleHRlbnNpb25zIG9uIHRvcCBvZiB0 aGUgRy43MTggY29yZSBjb2RlYy4NCj4gPiAtLS0tLQ0KPiA+DQo+ID4gQWN0dWFsbHkgdGhlIFNX QiBtb25vIHBhcnQgaGF2ZSBiZWVuIGFwcHJvdmVkIGluIElUVS1UIGluIE1hci4gMjAxMC4NCj4g PiBTdGVyZW8gd29yayBpcyBzdGlsbCBvbmdvaW5nLg0KPiA+IElzIGl0IHBvc3NpYmxlIHRvIGNv bnNpZGVyIHRoZSBHLjcxOEIgdG9nZXRoZXIgd2l0aCBHLjcxOCBmb3IgdGhlDQo+ID4gcGF5bG9h ZCBmb3JtYXQ/DQo+ID4gRm9yIGV4YW1wbGUsIHdlIGNhbiBhZGQgc29tZSBMLUlEcyBmb3IgdGhl IEcuNzE4QiBsYXllcnMuDQo+IA0KPiBJdCdzIHJlYWxseSB1cCB0byB0aGUgcGF5bG9hZCBXRyBh bmQgaXRzIENoYWlycywgYnV0IGl0J3MgT0sgd2l0aCBtZS4NCg0KSSB0aGluayBpdCBtYWtlcyBz ZW5zZS4gDQoNCk1pYW9sZWksIEkgYW0gYXNzdW1pbmcgeW91IGNvdWxkIHlvdXIgaGVscCB3aXRo IHRoZSB0ZXh0Pw0KDQotYWNiZWdlbg0KIA0KPiAuLi4NCg== From internet-drafts@ietf.org Mon May 16 09:54:03 2011 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 6C8E6E06CF; Mon, 16 May 2011 09:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, 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 YFlGwit67EWX; Mon, 16 May 2011 09:54:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C6EE06BB; Mon, 16 May 2011 09:54:02 -0700 (PDT) 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.54 Message-ID: <20110516165402.393.92209.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2011 09:54:02 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-avt-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, 16 May 2011 16:54:03 -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. Arbeiter J. Downs Filename : draft-ietf-avt-rtp-klv-02.txt Pages : 12 Date : 2011-05-16 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-avt-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-avt-rtp-klv-02.txt From presnick@qualcomm.com Mon May 16 13:30:13 2011 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 922E1E06E2 for ; Mon, 16 May 2011 13:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 mmRu1xOdUqzY for ; Mon, 16 May 2011 13:30:12 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id BF952E07AA for ; Mon, 16 May 2011 13:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1305577812; x=1337113812; h=message-id:date:from:user-agent:mime-version:to:cc: subject:x-priority:references:in-reply-to:content-type: x-originating-ip; z=Message-ID:=20<4DD18944.8030701@qualcomm.com>|Date:=20Mo n,=2016=20May=202011=2015:29:56=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Roni=20Even=20|CC:=20,=20"'Ali=20C.=20Begen =20(abegen)'"=20,=0D=0A=09,=20 |Subject:=20Re:=20[ietf-types]=20updating=20the=20registe ration=20of=20"MP4A-LATM"=20and=09"MP4V-ES"=0D=0A=20media =20sutypes.|X-Priority:=202=20(High)|References:=20<00b10 1cc057e$821da1e0$8658e5a0$%roni@huawei.com>|In-Reply-To: =20<00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"------------010600010401050803030103" |X-Originating-IP:=20[172.30.39.5]; bh=M8BoqbXoroggCHtzdMkecmbx7AmAMwHvNE2fgg44n3E=; b=JZGLoJVEo2YV5+Mc6BBOSK+Nie8KuNa7HnOJobJ6DGhA6SPOOM7dNPBC RGuG3pEUj+ee7cIOyDRj3GDRjJYTZCYJeyDLj0omF/+yROS8dAWvVnSkZ RoKGiWpWpNwF/Sib1UpMRy/ilDdG3QY3M7zaDUVHPXgia2FC5swY4EsXx U=; X-IronPort-AV: E=McAfee;i="5400,1158,6348"; a="91483368" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 16 May 2011 13:29:58 -0700 X-IronPort-AV: E=Sophos;i="4.64,374,1301900400"; d="scan'208,217";a="53730119" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 16 May 2011 13:29:58 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 16 May 2011 13:29:58 -0700 Message-ID: <4DD18944.8030701@qualcomm.com> Date: Mon, 16 May 2011 15:29:56 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Roni Even X-Priority: 2 (High) References: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> In-Reply-To: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> Content-Type: multipart/alternative; boundary="------------010600010401050803030103" X-Originating-IP: [172.30.39.5] X-Mailman-Approved-At: Mon, 16 May 2011 15:19:49 -0700 Cc: draft-ietf-avt-rfc3016bis.all@tools.ietf.org, ietf-types@iana.org, payload@ietf.org Subject: Re: [payload] [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. 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, 16 May 2011 20:30:13 -0000 --------------010600010401050803030103 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Did anyone review this? I have seen no responses. pr On 4/28/11 3:30 AM, Roni Even wrote: > > Hi, > > draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in > the AVT Working Group (currently Payload). The document updates the > media subtypes "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new > registrations are in Section 6.1 and Section 6.3 of the document. > > Comments on the registration are welcome. > > Thanks > > Roni Even > > Payload WG co-chair > -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 --------------010600010401050803030103 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Did anyone review this? I have seen no responses.

pr

On 4/28/11 3:30 AM, Roni Even wrote:

 

Hi,

 

draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in the AVT Working Group (currently Payload). The document updates the media subtypes "MP4A-LATM" and "MP4V-ES"  from RFC 3016.  The new registrations are in Section 6.1 and   Section 6.3 of the document.

Comments on the registration are welcome.

 

Thanks

Roni Even

Payload WG co-chair


-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
--------------010600010401050803030103-- From rjsparks@nostrum.com Wed May 18 09:08:42 2011 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 13267E067E for ; Wed, 18 May 2011 09:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, SPF_PASS=-0.001, 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 rzt2nUsp+0de for ; Wed, 18 May 2011 09:08:41 -0700 (PDT) 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 043D3E0665 for ; Wed, 18 May 2011 09:08:40 -0700 (PDT) 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 p4IG8a4S009549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 May 2011 11:08:36 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 18 May 2011 11:08:37 -0500 Message-Id: To: payload@ietf.org, draft-ietf-payload-rfc3016bis-00@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [payload] AD review: draft-ietf-payload-rfc3016bis-00 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, 18 May 2011 16:08:42 -0000 There are some issues to address with a draft revision before = progressing to IETF LC: Much of this text was from 3016, shouldn't the document be using the pre-5378 boilerplate (see 6.c.iii of = )? It is hard to tell what the actual changes from 3016 are (even when = using diff against 3016). The changes section should summarize the technical = changes with a little more detail. For instance, what exactly is the change to = the binary format of the LATM payload? It would also help to summarize where = requirements levels have changed. For instance, noting the change of the MAY to MUST = (actually SHALL) in section 5.3. The abstract needs to mention that the document is obsoleting 3016. Can the document explain the limitations the abstract calls out and=20 better motivate the preferrence for RFC3640? Why doesn't the abstract mention the reason for revising 3016? The document removed the word "new" from the description of some MPEG-4 features, but not all of them. Should it have removed all of them? Section 1.3 should more explicitly state that the working group believes there are NO implementations of 3016 that do not already behave as the=20= 3GPP document (and this document) specify, so there is no need to = consider=20 backwards compatability. (If that's not true, there are several places = where=20 backwards compatability needs more consideration.) The three new definitions in section 2 don't define the terms. Instead they try to clarify how values are chosen in various circumstances. This would be much clearer in a short section titled "Clarifications on = specifying sampling rates" or similar. The change control for the two media types should say PAYLOAD instead of = AVT. The second paragraph of the security considerations section starts by = exploring the existence of covert channels, then shifts to template text on = providing security to RTP. It's not clear how those existing mechanisms help with = respect to the possibility of a covert channel. Was the intent only to note that = the covert channels existed? If so, the paragraph should be split so = pointing to the security mechanisms for RTP doesn't appear to be a response to that = issue. Nits: Section 1.1, first paragraph: Why did "bitrates" get changed to = "bitrate"? Section 5.2, first paragrah: "enhance layer" should be "enhanced layer" From presnick@qualcomm.com Fri May 20 11:56:22 2011 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 BC841E06BD for ; Fri, 20 May 2011 11:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 RciYuNazWwtf for ; Fri, 20 May 2011 11:56:22 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id E00B1E06A6 for ; Fri, 20 May 2011 11:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1305917781; x=1337453781; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: x-originating-ip; z=Message-ID:=20<4DD6B937.8000109@qualcomm.com>|Date:=20Fr i,=2020=20May=202011=2013:55:51=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Roni=20Even=20|CC:=20,=20"'Ali=20C.=20Begen =20(abegen)'"=20,=0D=0A=09,=20 |Subject:=20Re:=20[ietf-types]=20updating=20the=20registe ration=20of=20"MP4A-LATM"=20and=09"MP4V-ES"=0D=0A=20media =20sutypes.|References:=20<00b101cc057e$821da1e0$8658e5a0 $%roni@huawei.com>|In-Reply-To:=20<00b101cc057e$821da1e0$ 8658e5a0$%roni@huawei.com>|Content-Type:=20multipart/alte rnative=3B=0D=0A=09boundary=3D"------------00070202010603 0703020000"|X-Originating-IP:=20[172.30.48.1]; bh=CQziePoet1iIoyoGy27Ffq/H8d6C2I7sAJdSdPrsHZ8=; b=uLwl6kiRMcYZK8ou9kWMcc9HQCFZ7DJ1RwXEwcerSYwwQXtCb3Wj/6dF BdMqqjVl/7x6/YFjACdHXy2miwqqNiFRat05wzHAUN48wPkBnD/lhkmmt yeRdXzbYByKMsdUc1fz4c6eE+0/S19T0IYfB2LtKX8jy9X36QrHL2Nyh7 E=; X-IronPort-AV: E=McAfee;i="5400,1158,6351"; a="92571725" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 20 May 2011 11:56:20 -0700 X-IronPort-AV: E=Sophos;i="4.65,242,1304319600"; d="scan'208,217";a="56005578" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 20 May 2011 11:56:20 -0700 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 20 May 2011 11:55:53 -0700 Message-ID: <4DD6B937.8000109@qualcomm.com> Date: Fri, 20 May 2011 13:55:51 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Roni Even References: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> In-Reply-To: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> Content-Type: multipart/alternative; boundary="------------000702020106030703020000" X-Originating-IP: [172.30.48.1] Cc: draft-ietf-avt-rfc3016bis.all@tools.ietf.org, ietf-types@iana.org, payload@ietf.org Subject: Re: [payload] [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. 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, 20 May 2011 18:56:22 -0000 --------------000702020106030703020000 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 4/28/11 3:30 AM, Roni Even wrote: > draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in > the AVT Working Group (currently Payload). The document updates the > media subtypes "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new > registrations are in Section 6.1 and Section 6.3 of the document. > > Comments on the registration are welcome. > Roni, it would probably help if you posted the registration templates themselves instead of pointing to the draft. Thanks, pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 --------------000702020106030703020000 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 4/28/11 3:30 AM, Roni Even wrote:

draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in the AVT Working Group (currently Payload). The document updates the media subtypes "MP4A-LATM" and "MP4V-ES"  from RFC 3016.  The new registrations are in Section 6.1 and   Section 6.3 of the document.

Comments on the registration are welcome.


Roni, it would probably help if you posted the registration templates themselves instead of pointing to the draft.

Thanks,

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
--------------000702020106030703020000-- From Even.roni@huawei.com Fri May 20 16:01:21 2011 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 3170BE06EB for ; Fri, 20 May 2011 16:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 HEcxFgE4NCse for ; Fri, 20 May 2011 16:01:20 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id CC045E06BE for ; Fri, 20 May 2011 16:01:19 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLI0098FNY2Z6@szxga04-in.huawei.com> for payload@ietf.org; Sat, 21 May 2011 07:01:14 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLI00MH2NY2IB@szxga04-in.huawei.com> for payload@ietf.org; Sat, 21 May 2011 07:01:14 +0800 (CST) Received: from windows8d787f9 ([109.64.2.135]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLI001JANXSEU@szxml12-in.huawei.com>; Sat, 21 May 2011 07:01:14 +0800 (CST) Date: Sat, 21 May 2011 01:59:35 +0300 From: Roni Even In-reply-to: <4DD6B937.8000109@qualcomm.com> To: 'Pete Resnick' Message-id: <011e01cc1741$9d4ec500$d7ec4f00$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_n1NS/ozXNEFunLfsc97eXw)" Content-language: en-us Thread-index: AcwXH7Szl29Q+QPERICvQU06PTV3pwAIa4og References: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> <4DD6B937.8000109@qualcomm.com> Cc: draft-ietf-avt-rfc3016bis.all@tools.ietf.org, ietf-types@iana.org, payload@ietf.org Subject: Re: [payload] [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. 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, 20 May 2011 23:01:21 -0000 This is a multi-part message in MIME format. --Boundary_(ID_n1NS/ozXNEFunLfsc97eXw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Pete, This is what we have been doing for all payload specifications. We point at the sections with the registration templates. Regards Roni From: Pete Resnick [mailto:presnick@qualcomm.com] Sent: Friday, May 20, 2011 9:56 PM To: Roni Even Cc: ietf-types@iana.org; 'Ali C. Begen (abegen)'; draft-ietf-avt-rfc3016bis.all@tools.ietf.org; payload@ietf.org Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. On 4/28/11 3:30 AM, Roni Even wrote: draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in the AVT Working Group (currently Payload). The document updates the media subtypes "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new registrations are in Section 6.1 and Section 6.3 of the document. Comments on the registration are welcome. Roni, it would probably help if you posted the registration templates themselves instead of pointing to the draft. Thanks, pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 --Boundary_(ID_n1NS/ozXNEFunLfsc97eXw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Pete,

This is what we have been doing for all payload specifications. We point at the sections with the registration templates.

Regards

Roni

 

From: Pete Resnick [mailto: r>Sent: Friday, May 20, 2011 9:56 PM
To: Roni Even
Cc: ietf-types@iana.org; 'Ali C. Begen (abegen)'; draft-ietf-avt-rfc3016bis.all@tools.ietf.org; payload@ietf.org
Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes.

 

On 4/28/11 3:30 AM, Roni Even wrote:


draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in the AVT Working Group (currently Payload). The document updates the media subtypes "MP4A-LATM" and "MP4V-ES"  from RFC 3016.  The new registrations are in Section 6.1 and   Section 6.3 of the document.

Comments on the registration are welcome.


Roni, i t would ed the registration templates themselves instead of pointing to the draft.

Thanks,

pr

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
--Boundary_(ID_n1NS/ozXNEFunLfsc97eXw)-- From Even.roni@huawei.com Sat May 21 00:27:34 2011 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 CDB2FE0761 for ; Sat, 21 May 2011 00:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, 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 kCjfNzzot1lq for ; Sat, 21 May 2011 00:27:28 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2C845E0750 for ; Sat, 21 May 2011 00:27:28 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLJ0075LBDLMU@szxga04-in.huawei.com> for payload@ietf.org; Sat, 21 May 2011 15:27:21 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLJ009UMBDLFG@szxga04-in.huawei.com> for payload@ietf.org; Sat, 21 May 2011 15:27:21 +0800 (CST) Received: from windows8d787f9 ([109.64.2.135]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLJ0022XBDBXJ@szxml11-in.huawei.com>; Sat, 21 May 2011 15:27:21 +0800 (CST) Date: Sat, 21 May 2011 10:25:42 +0300 From: Roni Even In-reply-to: <4DD75FBE.90409@it.aoyama.ac.jp> To: "=?iso-8859-1?Q?'=22Martin_J._D=FCrst=22'?=" Message-id: <013b01cc1788$505c5040$f114f0c0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcwXguygBn6gIh2DRX+B9M42+tIuYgAAyU5w References: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> <4DD6B937.8000109@qualcomm.com> <011e01cc1741$9d4ec500$d7ec4f00$%roni@huawei.com> <4DD75FBE.90409@it.aoyama.ac.jp> Cc: 'Pete Resnick' , ietf-types@iana.org, draft-ietf-avt-rfc3016bis.all@tools.ietf.org, payload@ietf.org Subject: Re: [payload] [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. 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: Sat, 21 May 2011 07:27:34 -0000 Hi, No problem. Here are the two registration templates and a link to the relevant = section. Note that it an update to existing RFC3016 registrations http://www.iana.org/assignments/rtp-parameters adding optional = parameters. The new optional parameters are only for MP4A-LARM and they are: MPS-profile-level-id, MPS-asc and SBR-enabled. thanks Roni 1. MP4V-ES http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section-6.1 = Type name: video Subtype name: MP4V-ES Required parameters: none Optional parameters: rate: This parameter is used only for RTP transport. It indicates the resolution of the timestamp field in the RTP header. If this parameter is not specified, its default value of 90000 (90kHz) is used. profile-level-id: A decimal representation of MPEG-4 Visual Profile and Level indication value (profile_and_level_indication) defined in Table G-1 of [14496-2]. This parameter MAY be used in the capability exchange or session setup procedure to indicate MPEG-4 Visual Profile and Level combination of which the MPEG-4 Visual codec is capable. If this parameter is not specified by the procedure, its default value of 1 (Simple Profile/Level 1) is used. config: This parameter SHALL be used to indicate the configuration of the corresponding MPEG-4 Visual bitstream. It SHALL NOT be used to indicate the codec capability in the capability exchange procedure. It is a hexadecimal representation of an octet string that expresses the MPEG-4 Visual configuration information, as defined in subclause 6.2.1 Start codes of [14496-2]. The configuration information is mapped onto the octet string in an MSB-first basis. The first bit of the configuration information SHALL be located at the MSB of the first octet. The configuration information indicated by this parameter SHALL be the same as the configuration information in the corresponding MPEG-4 Visual stream, except for first_half_vbv_occupancy and latter_half_vbv_occupancy, if exist, which may vary in the repeated configuration information inside an MPEG-4 Visual stream (See 6.2.1 Start codes of [14496-2]). Published specification: The specifications for MPEG-4 Visual streams are presented in [14496-2]. The RTP payload format is described in this document. Encoding considerations: Video bitstreams MUST be generated according to MPEG-4 Visual specifications [14496-2]. A video bitstream is binary data and MUST be encoded for non-binary transport (for Email, the Base64 encoding is sufficient). This type is also defined for transfer via RTP. The RTP packets MUST be packetized according to the MPEG-4 Visual RTP payload format defined in this document. Security considerations: See Section 9 of this document. Interoperability considerations: MPEG-4 Visual provides a large and rich set of tools for the coding of visual objects. For effective implementation of the standard, subsets of the MPEG-4 Visual tool sets have been provided for use in specific applications. These subsets, called 'Profiles', limit the size of the tool set a decoder is required to implement. In order to restrict computational complexity, one or more Levels are set for each Profile. A Profile@Level combination allows: * a codec builder to implement only the subset of the standard he needs, while maintaining interworking with other MPEG-4 devices included in the same combination, and * checking whether MPEG-4 devices comply with the standard ('conformance testing'). The visual stream SHALL be compliant with the MPEG-4 Visual Profile@Level specified by the parameter "profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameter "profile-level-id", or by arranging a capability exchange/announcement procedure for this parameter. Applications which use this Media Type: Audio and visual streaming and conferencing tools Additional information: none Person and email address to contact for further information: See Authors' Address section at the end of this document. Intended usage: COMMON Author: See Authors' Address section at the end of this document. Change controller: IETF Audio/Video Transport working group delegated from the IESG. 2. MP4A-LATM http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section-6.3=20 Type name: audio Subtype name: MP4A-LATM Required parameters: rate: the rate parameter indicates the RTP time stamp clock rate. The default value is 90000. Other rates MAY be indicated only if they are set to the same value as the audio sampling rate (number of samples per second). In the presence of SBR, the sampling rates for the core en-/ decoder and the SBR tool are different in most cases. This parameter SHALL therefore NOT be considered as the definitive sampling rate. If this parameter is used, the server must following the rules below: * When the presence of SBR is not explicitly signaled by the optional SDP parameters such as object parameter, profile- level-id or config string, this parameter SHALL be set to the core codec sampling rate. * When the presence of SBR is explicitly signaled by the optional SDP parameters such as object parameter, profile-level-id or config string this parameter SHALL be set to the SBR sampling rate. NOTE: The optional parameter SBR-enabled in SDP a=3Dfmtp is useful for implicit HE AAC / HE AAC v2 signaling. But the SBR-enabled parameter can also be used in the case of explicit HE AAC / HE AAC v2 signaling. Therefore, its existence itself is not the criteria to determine whether HE AAC / HE AAC v2 signaling is explicit or not. Optional parameters: profile-level-id: a decimal representation of MPEG-4 Audio Profile Level indication value defined in [14496-3]. This parameter indicates which MPEG-4 Audio tool subsets the decoder is capable of using. If this parameter is not specified in the capability exchange or session setup procedure, its default value of 30 (Natural Audio Profile/Level 1) is used. MPS-profile-level-id: a decimal representation of the MPEG Surround Profile Level indication as defined in [14496-3]. This parameter indicates the support of the MPEG Surround profile and level by the decoder to be capable to decode the stream. object: a decimal representation of the MPEG-4 Audio Object Type value defined in [14496-3]. This parameter specifies the tool to be used by the decoder. It CAN be used to limit the capability within the specified "profile-level-id". bitrate: the data rate for the audio bit stream. cpresent: a boolean parameter indicates whether audio payload configuration data has been multiplexed into an RTP payload (see Section 5.1). A 0 indicates the configuration data has not been multiplexed into an RTP payload and in this case the "config" parameter MUST be present, a 1 indicates that it has. The default if the parameter is omitted is 1. If this parameter is set to 1 and the "config" parameter is present, the multiplexed configuration data and the value of the "config" parameter SHALL be consistent. config: a hexadecimal representation of an octet string that expresses the audio payload configuration data "StreamMuxConfig", as defined in [14496-3]. Configuration data is mapped onto the octet string in an MSB-first basis. The first bit of the configuration data SHALL be located at the MSB of the first octet. In the last octet, zero-padding bits, if necessary, SHALL follow the configuration data. Senders MUST set the StreamMuxConfig elements taraBufferFullness and latmBufferFullness to their largest respective value, indicating that buffer fullness measures are not used in SDP. Receivers MUST ignore the value of these two elements contained in the config parameter. MPS-asc: a hexadecimal representation of an octet string that expresses audio payload configuration data "AudioSpecificConfig", as defined in [14496-3]. If this parameter is not present the relevant signaling is performed by other means (e.g. in-band or contained in the config string). The same mapping rules as for the config parameter apply. ptime: duration of each packet in milliseconds. SBR-enabled: a boolean parameter which indicates whether SBR-data can be expected in the RTP-payload of a stream. This parameter is relevant for an SBR-capable decoder if the presence of SBR can not be detected from an out-of-band decoder configuration (e.g. contained in the config string). If this parameter is set to 0, a decoder MAY expect that SBR is not used. If this parameter is set to 1, a decoder CAN upsample the audio data with the SBR tool, regardless whether SBR data is present in the stream or not. If the presence of SBR can not be detected from out-of-band configuration and the SBR-enabled parameter is not present, the parameter defaults to 1 for an SBR-capable decoder. If the resulting output sampling rate or the computational complexity is not supported, the SBR tool can be disabled or run in downsampled mode. The timestamp resolution at RTP layer is determined by the rate parameter. Published specification: Encoding specifications are provided in [14496-3]. The RTP payload format specification is described in this document. Encoding considerations: This type is only defined for transfer via RTP. Security considerations: See Section 9 of this document. Interoperability considerations: MPEG-4 Audio provides a large and rich set of tools for the coding of audio objects. For effective implementation of the standard, subsets of the MPEG-4 Audio tool sets similar to those used in MPEG-4 Visual have been provided (see Section 6.1). The audio stream SHALL be compliant with the MPEG-4 Audio Profile@ Level specified by the parameters "profile-level-id" and "MPS- profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameters "profile- level-id" and "MPS-profile-level-id", or by arranging in the capability exchange procedure to set this parameter mutually to the same value. Furthermore, the "object" parameter can be used to limit the capability within the specified Profile@Level in capability exchange. Applications which use this media type: Audio and video streaming and conferencing tools. Additional information: none Personal and email address to contact for further information: See Authors' Address section at the end of this document. Intended usage: COMMON Author: See Authors' Address section at the end of this document. Change controller: IETF Audio/Video Transport working group delegated from the IESG. > -----Original Message----- > From: "Martin J. D=FCrst" [mailto:duerst@it.aoyama.ac.jp] > Sent: Saturday, May 21, 2011 9:46 AM > To: Roni Even > Cc: 'Pete Resnick'; draft-ietf-avt-rfc3016bis.all@tools.ietf.org; = ietf- > types@iana.org; 'Ali C. Begen (abegen)'; payload@ietf.org > Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" = and > "MP4V-ES" media sutypes. >=20 > Hello Roni, >=20 > I fully agree with Pete. I have often told people asking for review on > this list to post the registration templates themselves. I have also > been on this list long enough to be able to tell you *for sure* (not > just 'probably' as Pete wrote) that posting the template(s) themselves > really helps. >=20 > So if you haven't done it up to now, it's never too late to change = that > practice. Copying the template once is a little bit more work for you > than just posting some pointers, but it will make it easier for all > reviewers on this list, because they don't have to follow your > instructions. >=20 > Many thanks in advance and kind regards, Martin. >=20 >=20 > P.S.: You didn't even bother to give a direct link to the relevant > section(s), which would easily be possible using = http://tools.ietf.org. > Of course copying the actual template is still highly preferable. >=20 >=20 >=20 > On 2011/05/21 7:59, Roni Even wrote: > > Pete, > > > > This is what we have been doing for all payload specifications. We > point at > > the sections with the registration templates. > > > > Regards > > > > Roni > > > > > > > > From: Pete Resnick [mailto:presnick@qualcomm.com] > > Sent: Friday, May 20, 2011 9:56 PM > > To: Roni Even > > Cc: ietf-types@iana.org; 'Ali C. Begen (abegen)'; > > draft-ietf-avt-rfc3016bis.all@tools.ietf.org; payload@ietf.org > > Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" > and > > "MP4V-ES" media sutypes. > > > > > > > > On 4/28/11 3:30 AM, Roni Even wrote: > > > > > > > > > > draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in > the AVT > > Working Group (currently Payload). The document updates the media > subtypes > > "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new registrations are > in > > Section 6.1 and Section 6.3 of the document. > > > > Comments on the registration are welcome. > > > > > > Roni, it would probably help if you posted the registration = templates > > themselves instead of pointing to the draft. > > > > Thanks, > > > > pr > > > > > > > > > > > > > > _______________________________________________ > > ietf-types mailing list > > ietf-types@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-types From duerst@it.aoyama.ac.jp Fri May 20 23:46:53 2011 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 9F565E0747 for ; Fri, 20 May 2011 23:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.79 X-Spam-Level: X-Spam-Status: No, score=-99.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 J6tgS2CdHiCE for ; Fri, 20 May 2011 23:46:52 -0700 (PDT) Received: from acintmta01.acbb.aoyama.ac.jp (acintmta01.acbb.aoyama.ac.jp [133.2.20.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6E193E073A for ; Fri, 20 May 2011 23:46:51 -0700 (PDT) Received: from acmse01.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta01.acbb.aoyama.ac.jp (secret/secret) with SMTP id p4L6kh9U013843 for ; Sat, 21 May 2011 15:46:43 +0900 Received: from (unknown [133.2.206.133]) by acmse01.acbb.aoyama.ac.jp with smtp id 2d8b_3932_172ba91a_8376_11e0_a914_001d096c5b62; Sat, 21 May 2011 15:46:43 +0900 Received: from [IPv6:::1] ([133.2.210.5]:33975) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 21 May 2011 15:46:48 +0900 Message-ID: <4DD75FBE.90409@it.aoyama.ac.jp> Date: Sat, 21 May 2011 15:46:22 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Roni Even References: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> <4DD6B937.8000109@qualcomm.com> <011e01cc1741$9d4ec500$d7ec4f00$%roni@huawei.com> In-Reply-To: <011e01cc1741$9d4ec500$d7ec4f00$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 21 May 2011 07:45:11 -0700 Cc: 'Pete Resnick' , ietf-types@iana.org, draft-ietf-avt-rfc3016bis.all@tools.ietf.org, payload@ietf.org Subject: Re: [payload] [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. 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: Sat, 21 May 2011 06:46:53 -0000 Hello Roni, I fully agree with Pete. I have often told people asking for review on this list to post the registration templates themselves. I have also been on this list long enough to be able to tell you *for sure* (not just 'probably' as Pete wrote) that posting the template(s) themselves really helps. So if you haven't done it up to now, it's never too late to change that practice. Copying the template once is a little bit more work for you than just posting some pointers, but it will make it easier for all reviewers on this list, because they don't have to follow your instructions. Many thanks in advance and kind regards, Martin. P.S.: You didn't even bother to give a direct link to the relevant section(s), which would easily be possible using http://tools.ietf.org. Of course copying the actual template is still highly preferable. On 2011/05/21 7:59, Roni Even wrote: > Pete, > > This is what we have been doing for all payload specifications. We point at > the sections with the registration templates. > > Regards > > Roni > > > > From: Pete Resnick [mailto:presnick@qualcomm.com] > Sent: Friday, May 20, 2011 9:56 PM > To: Roni Even > Cc: ietf-types@iana.org; 'Ali C. Begen (abegen)'; > draft-ietf-avt-rfc3016bis.all@tools.ietf.org; payload@ietf.org > Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and > "MP4V-ES" media sutypes. > > > > On 4/28/11 3:30 AM, Roni Even wrote: > > > > > draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in the AVT > Working Group (currently Payload). The document updates the media subtypes > "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new registrations are in > Section 6.1 and Section 6.3 of the document. > > Comments on the registration are welcome. > > > Roni, it would probably help if you posted the registration templates > themselves instead of pointing to the draft. > > Thanks, > > pr > > > > > > > _______________________________________________ > ietf-types mailing list > ietf-types@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-types From Even.roni@huawei.com Mon May 23 06:44:44 2011 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 EC2BEE0788 for ; Mon, 23 May 2011 06:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.149 X-Spam-Level: X-Spam-Status: No, score=-105.149 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, 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 7B1unc1d6ynD for ; Mon, 23 May 2011 06:44:43 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id DCA67E0783 for ; Mon, 23 May 2011 06:44:42 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLN0058PHZJ7A@szxga03-in.huawei.com> for payload@ietf.org; Mon, 23 May 2011 21:40:31 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLN008PGHZJ1I@szxga03-in.huawei.com> for payload@ietf.org; Mon, 23 May 2011 21:40:31 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-15-76.red.bezeqint.net [79.181.15.76]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLN00EDKHXCIB@szxml12-in.huawei.com>; Mon, 23 May 2011 21:40:31 +0800 (CST) Date: Mon, 23 May 2011 16:37:38 +0300 From: Roni Even In-reply-to: <4DDA12DE.6090505@it.aoyama.ac.jp> To: "=?ISO-8859-1?Q?'=22Martin_J._D=FCrst=22'?=" Message-id: <004201cc194e$c23be370$46b3aa50$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=ISO-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcwZHtFqNTAqvB7ARHSSIsfWJZF6oQALs1RA References: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> <4DD6B937.8000109@qualcomm.com> <011e01cc1741$9d4ec500$d7ec4f00$%roni@huawei.com> <4DD75FBE.90409@it.aoyama.ac.jp> <013b01cc1788$505c5040$f114f0c0$%roni@huawei.com> <4DDA12DE.6090505@it.aoyama.ac.jp> Cc: 'Pete Resnick' , ietf-types@iana.org, draft-ietf-avt-rfc3016bis.all@tools.ietf.org, payload@ietf.org Subject: Re: [payload] [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. 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, 23 May 2011 13:44:45 -0000 Hi, Good comment about AVT and the references , I will the authors to change before the registration. Regards Roni > -----Original Message----- > From: "Martin J. D=FCrst" [mailto:duerst@it.aoyama.ac.jp] > Sent: Monday, May 23, 2011 10:55 AM > To: Roni Even > Cc: 'Pete Resnick'; draft-ietf-avt-rfc3016bis.all@tools.ietf.org; = ietf- > types@iana.org; 'Ali C. Begen (abegen)'; payload@ietf.org > Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" = and > "MP4V-ES" media sutypes. >=20 > Just some minor nits: >=20 > Instead of things like "Security considerations: See Section 9 of this > document." and "Author: See Authors' Address section at the end of = this > document." it would be better to replace "this document" with e.g. > something like [RFCxxxx], with an note to the RFC Editor/IANA to > replace > [RFCxxxx] with the eventual RFC number. That way, the template can > stand > alone. >=20 > Also, while "Change controller: IETF Audio/Video Transport working > group > delegated from the IESG." is quite a good description of the current > reality, it's not necessarily future-proof. You don't want to go > through > the registration process again just because a WG gets closed. These > registrations usually just have "The IETF" as a change controller, = with > the implicit assumption that this may involve a WG and the IESG. >=20 > Regards, Martin. >=20 > On 2011/05/21 16:25, Roni Even wrote: > > Hi, > > No problem. > > Here are the two registration templates and a link to the relevant > section. > > Note that it an update to existing RFC3016 registrations > > http://www.iana.org/assignments/rtp-parameters adding optional > parameters. > > > > The new optional parameters are only for MP4A-LARM and they are: > > MPS-profile-level-id, MPS-asc and SBR-enabled. > > > > thanks > > > > Roni > > > > 1. MP4V-ES > > > > http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section- > 6.1 > > > > Type name: video > > > > Subtype name: MP4V-ES > > > > Required parameters: none > > > > Optional parameters: > > > > rate: This parameter is used only for RTP transport. It > indicates > > the resolution of the timestamp field in the RTP header. If > this > > parameter is not specified, its default value of 90000 = (90kHz) > is > > used. > > > > profile-level-id: A decimal representation of MPEG-4 Visual > > Profile and Level indication value > (profile_and_level_indication) > > defined in Table G-1 of [14496-2]. This parameter MAY be = used > in > > the capability exchange or session setup procedure to = indicate > > MPEG-4 Visual Profile and Level combination of which the = MPEG- > 4 > > Visual codec is capable. If this parameter is not specified > by > > the procedure, its default value of 1 (Simple Profile/Level = 1) > is > > used. > > > > config: This parameter SHALL be used to indicate the > configuration > > of the corresponding MPEG-4 Visual bitstream. It SHALL NOT = be > > used to indicate the codec capability in the capability > exchange > > procedure. It is a hexadecimal representation of an octet > string > > that expresses the MPEG-4 Visual configuration information, = as > > defined in subclause 6.2.1 Start codes of [14496-2]. The > > configuration information is mapped onto the octet string in > an > > MSB-first basis. The first bit of the configuration > information > > SHALL be located at the MSB of the first octet. The > configuration > > information indicated by this parameter SHALL be the same as > the > > configuration information in the corresponding MPEG-4 Visual > > stream, except for first_half_vbv_occupancy and > > latter_half_vbv_occupancy, if exist, which may vary in the > > repeated configuration information inside an MPEG-4 Visual > stream > > (See 6.2.1 Start codes of [14496-2]). > > > > Published specification: > > > > The specifications for MPEG-4 Visual streams are presented in > > [14496-2]. The RTP payload format is described in this > document. > > > > Encoding considerations: > > > > Video bitstreams MUST be generated according to MPEG-4 Visual > > specifications [14496-2]. A video bitstream is binary data > and > > MUST be encoded for non-binary transport (for Email, the > Base64 > > encoding is sufficient). This type is also defined for > transfer > > via RTP. The RTP packets MUST be packetized according to the > > MPEG-4 Visual RTP payload format defined in this document. > > > > Security considerations: > > > > See Section 9 of this document. > > > > Interoperability considerations: > > > > MPEG-4 Visual provides a large and rich set of tools for the > > coding of visual objects. For effective implementation of = the > > standard, subsets of the MPEG-4 Visual tool sets have been > > provided for use in specific applications. These subsets, > called > > 'Profiles', limit the size of the tool set a decoder is > required > > to implement. In order to restrict computational complexity, > one > > or more Levels are set for each Profile. A Profile@Level > > combination allows: > > > > * a codec builder to implement only the subset of the > standard he > > needs, while maintaining interworking with other MPEG-4 > devices > > included in the same combination, and > > > > * checking whether MPEG-4 devices comply with the standard > > ('conformance testing'). > > > > The visual stream SHALL be compliant with the MPEG-4 Visual > > Profile@Level specified by the parameter "profile-level-id". > > Interoperability between a sender and a receiver may be > achieved > > by specifying the parameter "profile-level-id", or by > arranging a > > capability exchange/announcement procedure for this = parameter. > > > > Applications which use this Media Type: > > > > Audio and visual streaming and conferencing tools > > > > Additional information: none > > > > Person and email address to contact for further information: > > > > See Authors' Address section at the end of this document. > > > > Intended usage: COMMON > > > > Author: > > > > See Authors' Address section at the end of this document. > > > > Change controller: > > > > IETF Audio/Video Transport working group delegated from the > IESG. > > > > > > 2. MP4A-LATM > > > > > > http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section- > 6.3 > > > > > > Type name: audio > > > > Subtype name: MP4A-LATM > > > > Required parameters: > > rate: the rate parameter indicates the RTP time stamp clock > rate. > > The default value is 90000. Other rates MAY be indicated = only > if > > they are set to the same value as the audio sampling rate > (number > > of samples per second). > > > > In the presence of SBR, the sampling rates for the core en-/ > > decoder and the SBR tool are different in most cases. This > > parameter SHALL therefore NOT be considered as the definitive > > sampling rate. If this parameter is used, the server must > > following the rules below: > > > > * When the presence of SBR is not explicitly signaled by the > > optional SDP parameters such as object parameter, profile- > > level-id or config string, this parameter SHALL be set to > the > > core codec sampling rate. > > > > * When the presence of SBR is explicitly signaled by the > optional > > SDP parameters such as object parameter, profile-level-id > or > > config string this parameter SHALL be set to the SBR > sampling > > rate. > > > > NOTE: The optional parameter SBR-enabled in SDP a=3Dfmtp is > useful > > for implicit HE AAC / HE AAC v2 signaling. But the SBR- > enabled > > parameter can also be used in the case of explicit HE AAC / = HE > AAC > > v2 signaling. Therefore, its existence itself is not the > criteria > > to determine whether HE AAC / HE AAC v2 signaling is explicit > or > > not. > > > > Optional parameters: > > > > profile-level-id: a decimal representation of MPEG-4 Audio > Profile > > Level indication value defined in [14496-3]. This parameter > > indicates which MPEG-4 Audio tool subsets the decoder is > capable > > of using. If this parameter is not specified in the > capability > > exchange or session setup procedure, its default value of 30 > > (Natural Audio Profile/Level 1) is used. > > > > MPS-profile-level-id: a decimal representation of the MPEG > > Surround Profile Level indication as defined in [14496-3]. > This > > parameter indicates the support of the MPEG Surround profile > and > > level by the decoder to be capable to decode the stream. > > > > object: a decimal representation of the MPEG-4 Audio Object > Type > > value defined in [14496-3]. This parameter specifies the = tool > to > > be used by the decoder. It CAN be used to limit the > capability > > within the specified "profile-level-id". > > > > bitrate: the data rate for the audio bit stream. > > > > cpresent: a boolean parameter indicates whether audio payload > > configuration data has been multiplexed into an RTP payload > (see > > Section 5.1). A 0 indicates the configuration data has not > been > > multiplexed into an RTP payload and in this case the "config" > > parameter MUST be present, a 1 indicates that it has. The > default > > if the parameter is omitted is 1. If this parameter is set = to > 1 > > and the "config" parameter is present, the multiplexed > > configuration data and the value of the "config" parameter > SHALL > > be consistent. > > > > config: a hexadecimal representation of an octet string that > > expresses the audio payload configuration data > "StreamMuxConfig", > > as defined in [14496-3]. Configuration data is mapped onto > the > > octet string in an MSB-first basis. The first bit of the > > configuration data SHALL be located at the MSB of the first > octet. > > In the last octet, zero-padding bits, if necessary, SHALL > follow > > the configuration data. Senders MUST set the StreamMuxConfig > > elements taraBufferFullness and latmBufferFullness to their > > largest respective value, indicating that buffer fullness > measures > > are not used in SDP. Receivers MUST ignore the value of = these > two > > elements contained in the config parameter. > > > > MPS-asc: a hexadecimal representation of an octet string that > > expresses audio payload configuration data > "AudioSpecificConfig", > > as defined in [14496-3]. If this parameter is not present = the > > relevant signaling is performed by other means (e.g. in-band > or > > contained in the config string). > > > > The same mapping rules as for the config parameter apply. > > > > ptime: duration of each packet in milliseconds. > > > > SBR-enabled: a boolean parameter which indicates whether SBR- > data > > can be expected in the RTP-payload of a stream. This > parameter is > > relevant for an SBR-capable decoder if the presence of SBR = can > not > > be detected from an out-of-band decoder configuration (e.g. > > contained in the config string). > > > > If this parameter is set to 0, a decoder MAY expect that SBR > is > > not used. If this parameter is set to 1, a decoder CAN > upsample > > the audio data with the SBR tool, regardless whether SBR data > is > > present in the stream or not. > > > > If the presence of SBR can not be detected from out-of-band > > configuration and the SBR-enabled parameter is not present, > the > > parameter defaults to 1 for an SBR-capable decoder. If the > > resulting output sampling rate or the computational = complexity > is > > not supported, the SBR tool can be disabled or run in > downsampled > > mode. > > > > The timestamp resolution at RTP layer is determined by the > rate > > parameter. > > > > Published specification: > > > > Encoding specifications are provided in [14496-3]. The RTP > > payload format specification is described in this document. > > > > Encoding considerations: > > > > This type is only defined for transfer via RTP. > > > > Security considerations: > > > > See Section 9 of this document. > > > > Interoperability considerations: > > > > MPEG-4 Audio provides a large and rich set of tools for the > coding > > of audio objects. For effective implementation of the > standard, > > subsets of the MPEG-4 Audio tool sets similar to those used = in > > MPEG-4 Visual have been provided (see Section 6.1). > > > > The audio stream SHALL be compliant with the MPEG-4 Audio > Profile@ > > Level specified by the parameters "profile-level-id" and = "MPS- > > profile-level-id". Interoperability between a sender and a > > receiver may be achieved by specifying the parameters > "profile- > > level-id" and "MPS-profile-level-id", or by arranging in the > > capability exchange procedure to set this parameter mutually > to > > the same value. Furthermore, the "object" parameter can be > used > > to limit the capability within the specified Profile@Level in > > capability exchange. > > > > Applications which use this media type: > > > > Audio and video streaming and conferencing tools. > > > > Additional information: none > > > > Personal and email address to contact for further information: > > > > See Authors' Address section at the end of this document. > > > > Intended usage: COMMON > > > > Author: > > > > See Authors' Address section at the end of this document. > > > > Change controller: > > > > IETF Audio/Video Transport working group delegated from the > IESG. > > > > > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: "Martin J. D=FCrst" [mailto:duerst@it.aoyama.ac.jp] > >> Sent: Saturday, May 21, 2011 9:46 AM > >> To: Roni Even > >> Cc: 'Pete Resnick'; draft-ietf-avt-rfc3016bis.all@tools.ietf.org; > ietf- > >> types@iana.org; 'Ali C. Begen (abegen)'; payload@ietf.org > >> Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" > and > >> "MP4V-ES" media sutypes. > >> > >> Hello Roni, > >> > >> I fully agree with Pete. I have often told people asking for review > on > >> this list to post the registration templates themselves. I have = also > >> been on this list long enough to be able to tell you *for sure* = (not > >> just 'probably' as Pete wrote) that posting the template(s) > themselves > >> really helps. > >> > >> So if you haven't done it up to now, it's never too late to change > that > >> practice. Copying the template once is a little bit more work for > you > >> than just posting some pointers, but it will make it easier for all > >> reviewers on this list, because they don't have to follow your > >> instructions. > >> > >> Many thanks in advance and kind regards, Martin. > >> > >> > >> P.S.: You didn't even bother to give a direct link to the relevant > >> section(s), which would easily be possible using > http://tools.ietf.org. > >> Of course copying the actual template is still highly preferable. > >> > >> > >> > >> On 2011/05/21 7:59, Roni Even wrote: > >>> Pete, > >>> > >>> This is what we have been doing for all payload specifications. We > >> point at > >>> the sections with the registration templates. > >>> > >>> Regards > >>> > >>> Roni > >>> > >>> > >>> > >>> From: Pete Resnick [mailto:presnick@qualcomm.com] > >>> Sent: Friday, May 20, 2011 9:56 PM > >>> To: Roni Even > >>> Cc: ietf-types@iana.org; 'Ali C. Begen (abegen)'; > >>> draft-ietf-avt-rfc3016bis.all@tools.ietf.org; payload@ietf.org > >>> Subject: Re: [ietf-types] updating the registeration of = "MP4A-LATM" > >> and > >>> "MP4V-ES" media sutypes. > >>> > >>> > >>> > >>> On 4/28/11 3:30 AM, Roni Even wrote: > >>> > >>> > >>> > >>> > >>> draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call = in > >> the AVT > >>> Working Group (currently Payload). The document updates the media > >> subtypes > >>> "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new registrations > are > >> in > >>> Section 6.1 and Section 6.3 of the document. > >>> > >>> Comments on the registration are welcome. > >>> > >>> > >>> Roni, it would probably help if you posted the registration > templates > >>> themselves instead of pointing to the draft. > >>> > >>> Thanks, > >>> > >>> pr > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> ietf-types mailing list > >>> ietf-types@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ietf-types > > > > From duerst@it.aoyama.ac.jp Mon May 23 00:55:43 2011 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 9BB3CE06F7 for ; Mon, 23 May 2011 00:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.741 X-Spam-Level: X-Spam-Status: No, score=-99.741 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, 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 8o7fi8lh5VOX for ; Mon, 23 May 2011 00:55:40 -0700 (PDT) Received: from acintmta01.acbb.aoyama.ac.jp (acintmta01.acbb.aoyama.ac.jp [133.2.20.33]) by ietfa.amsl.com (Postfix) with ESMTP id D8CB0E0720 for ; Mon, 23 May 2011 00:55:38 -0700 (PDT) Received: from acmse02.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta01.acbb.aoyama.ac.jp (secret/secret) with SMTP id p4N7tS4I030394 for ; Mon, 23 May 2011 16:55:30 +0900 Received: from (unknown [133.2.206.133]) by acmse02.acbb.aoyama.ac.jp with smtp id 446e_05d0_0667358e_8512_11e0_bdfb_001d0969ab06; Mon, 23 May 2011 16:55:28 +0900 Received: from [IPv6:::1] ([133.2.210.5]:60924) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 23 May 2011 16:55:30 +0900 Message-ID: <4DDA12DE.6090505@it.aoyama.ac.jp> Date: Mon, 23 May 2011 16:55:10 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Roni Even References: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> <4DD6B937.8000109@qualcomm.com> <011e01cc1741$9d4ec500$d7ec4f00$%roni@huawei.com> <4DD75FBE.90409@it.aoyama.ac.jp> <013b01cc1788$505c5040$f114f0c0$%roni@huawei.com> In-Reply-To: <013b01cc1788$505c5040$f114f0c0$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 23 May 2011 15:09:24 -0700 Cc: 'Pete Resnick' , ietf-types@iana.org, draft-ietf-avt-rfc3016bis.all@tools.ietf.org, payload@ietf.org Subject: Re: [payload] [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. 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, 23 May 2011 07:55:43 -0000 Just some minor nits: Instead of things like "Security considerations: See Section 9 of this document." and "Author: See Authors' Address section at the end of this document." it would be better to replace "this document" with e.g. something like [RFCxxxx], with an note to the RFC Editor/IANA to replace [RFCxxxx] with the eventual RFC number. That way, the template can stand alone. Also, while "Change controller: IETF Audio/Video Transport working group delegated from the IESG." is quite a good description of the current reality, it's not necessarily future-proof. You don't want to go through the registration process again just because a WG gets closed. These registrations usually just have "The IETF" as a change controller, with the implicit assumption that this may involve a WG and the IESG. Regards, Martin. On 2011/05/21 16:25, Roni Even wrote: > Hi, > No problem. > Here are the two registration templates and a link to the relevant section. > Note that it an update to existing RFC3016 registrations > http://www.iana.org/assignments/rtp-parameters adding optional parameters. > > The new optional parameters are only for MP4A-LARM and they are: > MPS-profile-level-id, MPS-asc and SBR-enabled. > > thanks > > Roni > > 1. MP4V-ES > > http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section-6.1 > > Type name: video > > Subtype name: MP4V-ES > > Required parameters: none > > Optional parameters: > > rate: This parameter is used only for RTP transport. It indicates > the resolution of the timestamp field in the RTP header. If this > parameter is not specified, its default value of 90000 (90kHz) is > used. > > profile-level-id: A decimal representation of MPEG-4 Visual > Profile and Level indication value (profile_and_level_indication) > defined in Table G-1 of [14496-2]. This parameter MAY be used in > the capability exchange or session setup procedure to indicate > MPEG-4 Visual Profile and Level combination of which the MPEG-4 > Visual codec is capable. If this parameter is not specified by > the procedure, its default value of 1 (Simple Profile/Level 1) is > used. > > config: This parameter SHALL be used to indicate the configuration > of the corresponding MPEG-4 Visual bitstream. It SHALL NOT be > used to indicate the codec capability in the capability exchange > procedure. It is a hexadecimal representation of an octet string > that expresses the MPEG-4 Visual configuration information, as > defined in subclause 6.2.1 Start codes of [14496-2]. The > configuration information is mapped onto the octet string in an > MSB-first basis. The first bit of the configuration information > SHALL be located at the MSB of the first octet. The configuration > information indicated by this parameter SHALL be the same as the > configuration information in the corresponding MPEG-4 Visual > stream, except for first_half_vbv_occupancy and > latter_half_vbv_occupancy, if exist, which may vary in the > repeated configuration information inside an MPEG-4 Visual stream > (See 6.2.1 Start codes of [14496-2]). > > Published specification: > > The specifications for MPEG-4 Visual streams are presented in > [14496-2]. The RTP payload format is described in this document. > > Encoding considerations: > > Video bitstreams MUST be generated according to MPEG-4 Visual > specifications [14496-2]. A video bitstream is binary data and > MUST be encoded for non-binary transport (for Email, the Base64 > encoding is sufficient). This type is also defined for transfer > via RTP. The RTP packets MUST be packetized according to the > MPEG-4 Visual RTP payload format defined in this document. > > Security considerations: > > See Section 9 of this document. > > Interoperability considerations: > > MPEG-4 Visual provides a large and rich set of tools for the > coding of visual objects. For effective implementation of the > standard, subsets of the MPEG-4 Visual tool sets have been > provided for use in specific applications. These subsets, called > 'Profiles', limit the size of the tool set a decoder is required > to implement. In order to restrict computational complexity, one > or more Levels are set for each Profile. A Profile@Level > combination allows: > > * a codec builder to implement only the subset of the standard he > needs, while maintaining interworking with other MPEG-4 devices > included in the same combination, and > > * checking whether MPEG-4 devices comply with the standard > ('conformance testing'). > > The visual stream SHALL be compliant with the MPEG-4 Visual > Profile@Level specified by the parameter "profile-level-id". > Interoperability between a sender and a receiver may be achieved > by specifying the parameter "profile-level-id", or by arranging a > capability exchange/announcement procedure for this parameter. > > Applications which use this Media Type: > > Audio and visual streaming and conferencing tools > > Additional information: none > > Person and email address to contact for further information: > > See Authors' Address section at the end of this document. > > Intended usage: COMMON > > Author: > > See Authors' Address section at the end of this document. > > Change controller: > > IETF Audio/Video Transport working group delegated from the IESG. > > > 2. MP4A-LATM > > > http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section-6.3 > > > Type name: audio > > Subtype name: MP4A-LATM > > Required parameters: > rate: the rate parameter indicates the RTP time stamp clock rate. > The default value is 90000. Other rates MAY be indicated only if > they are set to the same value as the audio sampling rate (number > of samples per second). > > In the presence of SBR, the sampling rates for the core en-/ > decoder and the SBR tool are different in most cases. This > parameter SHALL therefore NOT be considered as the definitive > sampling rate. If this parameter is used, the server must > following the rules below: > > * When the presence of SBR is not explicitly signaled by the > optional SDP parameters such as object parameter, profile- > level-id or config string, this parameter SHALL be set to the > core codec sampling rate. > > * When the presence of SBR is explicitly signaled by the optional > SDP parameters such as object parameter, profile-level-id or > config string this parameter SHALL be set to the SBR sampling > rate. > > NOTE: The optional parameter SBR-enabled in SDP a=fmtp is useful > for implicit HE AAC / HE AAC v2 signaling. But the SBR-enabled > parameter can also be used in the case of explicit HE AAC / HE AAC > v2 signaling. Therefore, its existence itself is not the criteria > to determine whether HE AAC / HE AAC v2 signaling is explicit or > not. > > Optional parameters: > > profile-level-id: a decimal representation of MPEG-4 Audio Profile > Level indication value defined in [14496-3]. This parameter > indicates which MPEG-4 Audio tool subsets the decoder is capable > of using. If this parameter is not specified in the capability > exchange or session setup procedure, its default value of 30 > (Natural Audio Profile/Level 1) is used. > > MPS-profile-level-id: a decimal representation of the MPEG > Surround Profile Level indication as defined in [14496-3]. This > parameter indicates the support of the MPEG Surround profile and > level by the decoder to be capable to decode the stream. > > object: a decimal representation of the MPEG-4 Audio Object Type > value defined in [14496-3]. This parameter specifies the tool to > be used by the decoder. It CAN be used to limit the capability > within the specified "profile-level-id". > > bitrate: the data rate for the audio bit stream. > > cpresent: a boolean parameter indicates whether audio payload > configuration data has been multiplexed into an RTP payload (see > Section 5.1). A 0 indicates the configuration data has not been > multiplexed into an RTP payload and in this case the "config" > parameter MUST be present, a 1 indicates that it has. The default > if the parameter is omitted is 1. If this parameter is set to 1 > and the "config" parameter is present, the multiplexed > configuration data and the value of the "config" parameter SHALL > be consistent. > > config: a hexadecimal representation of an octet string that > expresses the audio payload configuration data "StreamMuxConfig", > as defined in [14496-3]. Configuration data is mapped onto the > octet string in an MSB-first basis. The first bit of the > configuration data SHALL be located at the MSB of the first octet. > In the last octet, zero-padding bits, if necessary, SHALL follow > the configuration data. Senders MUST set the StreamMuxConfig > elements taraBufferFullness and latmBufferFullness to their > largest respective value, indicating that buffer fullness measures > are not used in SDP. Receivers MUST ignore the value of these two > elements contained in the config parameter. > > MPS-asc: a hexadecimal representation of an octet string that > expresses audio payload configuration data "AudioSpecificConfig", > as defined in [14496-3]. If this parameter is not present the > relevant signaling is performed by other means (e.g. in-band or > contained in the config string). > > The same mapping rules as for the config parameter apply. > > ptime: duration of each packet in milliseconds. > > SBR-enabled: a boolean parameter which indicates whether SBR-data > can be expected in the RTP-payload of a stream. This parameter is > relevant for an SBR-capable decoder if the presence of SBR can not > be detected from an out-of-band decoder configuration (e.g. > contained in the config string). > > If this parameter is set to 0, a decoder MAY expect that SBR is > not used. If this parameter is set to 1, a decoder CAN upsample > the audio data with the SBR tool, regardless whether SBR data is > present in the stream or not. > > If the presence of SBR can not be detected from out-of-band > configuration and the SBR-enabled parameter is not present, the > parameter defaults to 1 for an SBR-capable decoder. If the > resulting output sampling rate or the computational complexity is > not supported, the SBR tool can be disabled or run in downsampled > mode. > > The timestamp resolution at RTP layer is determined by the rate > parameter. > > Published specification: > > Encoding specifications are provided in [14496-3]. The RTP > payload format specification is described in this document. > > Encoding considerations: > > This type is only defined for transfer via RTP. > > Security considerations: > > See Section 9 of this document. > > Interoperability considerations: > > MPEG-4 Audio provides a large and rich set of tools for the coding > of audio objects. For effective implementation of the standard, > subsets of the MPEG-4 Audio tool sets similar to those used in > MPEG-4 Visual have been provided (see Section 6.1). > > The audio stream SHALL be compliant with the MPEG-4 Audio Profile@ > Level specified by the parameters "profile-level-id" and "MPS- > profile-level-id". Interoperability between a sender and a > receiver may be achieved by specifying the parameters "profile- > level-id" and "MPS-profile-level-id", or by arranging in the > capability exchange procedure to set this parameter mutually to > the same value. Furthermore, the "object" parameter can be used > to limit the capability within the specified Profile@Level in > capability exchange. > > Applications which use this media type: > > Audio and video streaming and conferencing tools. > > Additional information: none > > Personal and email address to contact for further information: > > See Authors' Address section at the end of this document. > > Intended usage: COMMON > > Author: > > See Authors' Address section at the end of this document. > > Change controller: > > IETF Audio/Video Transport working group delegated from the IESG. > > > > > > > > > > > > >> -----Original Message----- >> From: "Martin J. Dürst" [mailto:duerst@it.aoyama.ac.jp] >> Sent: Saturday, May 21, 2011 9:46 AM >> To: Roni Even >> Cc: 'Pete Resnick'; draft-ietf-avt-rfc3016bis.all@tools.ietf.org; ietf- >> types@iana.org; 'Ali C. Begen (abegen)'; payload@ietf.org >> Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and >> "MP4V-ES" media sutypes. >> >> Hello Roni, >> >> I fully agree with Pete. I have often told people asking for review on >> this list to post the registration templates themselves. I have also >> been on this list long enough to be able to tell you *for sure* (not >> just 'probably' as Pete wrote) that posting the template(s) themselves >> really helps. >> >> So if you haven't done it up to now, it's never too late to change that >> practice. Copying the template once is a little bit more work for you >> than just posting some pointers, but it will make it easier for all >> reviewers on this list, because they don't have to follow your >> instructions. >> >> Many thanks in advance and kind regards, Martin. >> >> >> P.S.: You didn't even bother to give a direct link to the relevant >> section(s), which would easily be possible using http://tools.ietf.org. >> Of course copying the actual template is still highly preferable. >> >> >> >> On 2011/05/21 7:59, Roni Even wrote: >>> Pete, >>> >>> This is what we have been doing for all payload specifications. We >> point at >>> the sections with the registration templates. >>> >>> Regards >>> >>> Roni >>> >>> >>> >>> From: Pete Resnick [mailto:presnick@qualcomm.com] >>> Sent: Friday, May 20, 2011 9:56 PM >>> To: Roni Even >>> Cc: ietf-types@iana.org; 'Ali C. Begen (abegen)'; >>> draft-ietf-avt-rfc3016bis.all@tools.ietf.org; payload@ietf.org >>> Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" >> and >>> "MP4V-ES" media sutypes. >>> >>> >>> >>> On 4/28/11 3:30 AM, Roni Even wrote: >>> >>> >>> >>> >>> draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in >> the AVT >>> Working Group (currently Payload). The document updates the media >> subtypes >>> "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new registrations are >> in >>> Section 6.1 and Section 6.3 of the document. >>> >>> Comments on the registration are welcome. >>> >>> >>> Roni, it would probably help if you posted the registration templates >>> themselves instead of pointing to the draft. >>> >>> Thanks, >>> >>> pr >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> ietf-types mailing list >>> ietf-types@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-types > > From Even.roni@huawei.com Fri May 27 23:05:15 2011 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 3E440E069E for ; Fri, 27 May 2011 23:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=1.999, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 B9N13YFgevqC for ; Fri, 27 May 2011 23:05:14 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id CC2B2E068B for ; Fri, 27 May 2011 23:05:13 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLW0056C68H2V@szxga04-in.huawei.com> for payload@ietf.org; Sat, 28 May 2011 14:05:05 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLW003YG68H08@szxga04-in.huawei.com> for payload@ietf.org; Sat, 28 May 2011 14:05:05 +0800 (CST) Received: from windows8d787f9 ([109.65.42.220]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLW004JW6877C@szxml11-in.huawei.com> for payload@ietf.org; Sat, 28 May 2011 14:05:05 +0800 (CST) Date: Sat, 28 May 2011 09:02:59 +0300 From: Roni Even To: payload@ietf.org Message-id: <034a01cc1cfc$eab5efb0$c021cf10$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/mixed; boundary="Boundary_(ID_0iRNPrHh5nlMWTKvCVC63Q)" Content-language: en-us Thread-index: AcwPsM2X1Q46kSc/QWKvkrDprIki5gNS+7dg Subject: [payload] FW: WGLC on draft-ietf-payload-rfc3189bis-00 - askin for reviews!!!! 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: Sat, 28 May 2011 06:05:15 -0000 This is a multi-part message in MIME format. --Boundary_(ID_0iRNPrHh5nlMWTKvCVC63Q) Content-type: multipart/alternative; boundary="Boundary_(ID_svFlbdRlxmBYe507fLOyOQ)" --Boundary_(ID_svFlbdRlxmBYe507fLOyOQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I have not seen any feedback in the list. Please find some time and review the draft Thanks Roni Even Payload co-chair From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, May 11, 2011 10:56 AM To: payload@ietf.org Subject: [payload] WGLC on draft-ietf-payload-rfc3189bis-00 Hi, I would like to start a Working Group Last Call on draft-ietf-payload-rfc3189bis-00 , RTP Payload Format for DV (IEC 61834) Video. The WGLC will end on May 30, 2011 Please review the draft and send comments to the list. Note that section 7 discusses the changes from RFC3189. Roni Even Payload co-chair --Boundary_(ID_svFlbdRlxmBYe507fLOyOQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

I have not seen any = feedback in the list.

Please find some time and review the = draft

Thanks

Roni = Even

Payload co-chair

 

From:= = payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Roni Even
Sent: Wednesday, May 11, 2011 10:56 = AM
To: payload@ietf.org
Subject: [payload] WGLC on = draft-ietf-payload-rfc3189bis-00

 

Hi,

I would like to = start a Working Group Last Call on draf= t-ietf-payload-rfc3189bis-00, RTP Payload Format for DV (IEC 61834) = Video.

 

The WGLC will end on May 30, = 2011

Please review the draft = and send comments to the list.

 

Note that = section 7 discusses the changes from RFC3189.

 

Roni = Even

Payload = co-chair

 

 

= --Boundary_(ID_svFlbdRlxmBYe507fLOyOQ)-- --Boundary_(ID_0iRNPrHh5nlMWTKvCVC63Q) Content-type: text/plain; name=ATT00021.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ATT00021.txt _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload --Boundary_(ID_0iRNPrHh5nlMWTKvCVC63Q)-- From gwz@net-zen.net Sat May 28 03:28:02 2011 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 20FE5E06CF for ; Sat, 28 May 2011 03:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.655 X-Spam-Level: X-Spam-Status: No, score=-102.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, 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 v+lWEy5tI8Rc for ; Sat, 28 May 2011 03:28:01 -0700 (PDT) Received: from p3plsmtpa01-02.prod.phx3.secureserver.net (p3plsmtpa01-02.prod.phx3.secureserver.net [72.167.82.82]) by ietfa.amsl.com (Postfix) with SMTP id 4979FE06B7 for ; Sat, 28 May 2011 03:28:01 -0700 (PDT) Received: (qmail 19115 invoked from network); 28 May 2011 10:28:00 -0000 Received: from unknown (124.120.202.195) by p3plsmtpa01-02.prod.phx3.secureserver.net (72.167.82.82) with ESMTP; 28 May 2011 10:27:59 -0000 Message-ID: <4DE0CE2A.7070306@net-zen.net> Date: Sat, 28 May 2011 17:27:54 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Roni Even References: <034a01cc1cfc$eab5efb0$c021cf10$%roni@huawei.com> In-Reply-To: <034a01cc1cfc$eab5efb0$c021cf10$%roni@huawei.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------030701040207090507030802" Cc: draft-ietf-payload-rfc3189bis@tools.ietf.org, payload@ietf.org Subject: Re: [payload] FW: WGLC on draft-ietf-payload-rfc3189bis-00 - askin for reviews!!!! 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: Sat, 28 May 2011 10:28:02 -0000 This is a multi-part message in MIME format. --------------030701040207090507030802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A number of acronyms are neither expanded upon first usage nor listed in a separate terminology section. Examples: DV, DCT, PCM, DIF... Section 1 says: This document specifies payload formats for encapsulating both consumer- and professional use DV format data streams into the Real- time Transport Protocol (RTP) [RFC3550]. I think that either the hyphen after the word "consumer" should be removed or one should be appended to the word "professional". Section 2.2 says: Timestamp: 32-bit 90 kHz timestamp representing the time at which the first data in the frame was sampled. All RTP packets within the same video frame MUST have the same timestamp. The timestamp SHOULD increment by a multiple of the nominal interval for one DV frame time, as given in the following table: +----------+----------------+---------------------------------------+ | Mode | Frame rate | Increase of one DV frame in 90kHz | | | (Hz) | timestamp | +----------+----------------+---------------------------------------+ One assumes that the term "nominal interval for one DV frame time" maps to the table heading "Increase of one DV frame in 90kHz timestamp" but this is by no means clear. In the table itself, the last two lines include the construct "(*)" which I would expect to refer to a note marked with "*": | 720-60p | 59.94 | 3003(*) | | 720-50p | 50 | 3600(*) | However, there are no further occurrences of "*" in the document. There is the following, which might be divined to be associated with the table entries mentioned above: Note that even in the 720-line DV system, the data in two video frames shall be processed within one DV frame duration of the 1080- line system. Audio data and subcode data in the 720-line system are processed in the same way as the 1080-line system. Therefore in the 720-line system, the increase of one DV frame corresponds two video frames time. What does the last sentence mean? s/Marker bit (M): The marker bit of the RTP fixed header is set to one on the last packet of a video frame, and otherwise, must be zero./Marker bit (M): The marker bit of the RTP fixed header is set to one on the last packet of a video frame, and otherwise, MUST be zero. In Section 2.3, paragraph 2, cannot parse "sending DIF- sequence header and subcode DIF blocks". I'm a little confused by the "Optional parameters" part of the Media Type Registration for DV Audio (Section 3.1.2). It says: Optional parameters: audio: whether the DV stream includes audio data or not. Permissible values for audio are bundled and none. Defaults to none. Since the media type is audio, how can no audio data be present? Section 6 says: This document updates RFC3189 (older version of this document), but the front page header says "Obsoletes: 3189 (if approved)". Which is it? Further, this phrase doesn't make a lot of sense to me: and some registration forms are just updated by this document. --------------030701040207090507030802 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------030701040207090507030802-- From cabo@tzi.org Sat May 28 06:50:38 2011 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 5A3BEE06E6 for ; Sat, 28 May 2011 06:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 6l6fIHfS-QfD for ; Sat, 28 May 2011 06:50:37 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id AC561E06E3 for ; Sat, 28 May 2011 06:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p4SDoII1009814; Sat, 28 May 2011 15:50:19 +0200 (CEST) Received: from static-31-220-136-60.inaddr.netsign.net (unknown [31.220.136.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44741F6F; Sat, 28 May 2011 15:50:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4DE0CE2A.7070306@net-zen.net> Date: Sat, 28 May 2011 15:50:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <034a01cc1cfc$eab5efb0$c021cf10$%roni@huawei.com> <4DE0CE2A.7070306@net-zen.net> To: Glen Zorn X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Sat, 28 May 2011 07:56:58 -0700 Cc: draft-ietf-payload-rfc3189bis@tools.ietf.org, payload@ietf.org Subject: Re: [payload] FW: WGLC on draft-ietf-payload-rfc3189bis-00 - askin for reviews!!!! 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: Sat, 28 May 2011 13:50:38 -0000 On May 28, 2011, at 12:27, Glen Zorn wrote: > A number of acronyms are neither expanded upon first usage nor listed = in > a separate terminology section. Examples: DV, DCT, PCM, DIF... Yes, it is probably worthwhile to add an abbreviations section. > Section 1 says: >=20 > This document specifies payload formats for encapsulating both > consumer- and professional use DV format data streams into the Real- > time Transport Protocol (RTP) [RFC3550]. >=20 > I think that either the hyphen after the word "consumer" should be > removed or one should be appended to the word "professional". Probably the latter. > Section 2.2 says: >=20 > Timestamp: 32-bit 90 kHz timestamp representing the time at which = the > first data in the frame was sampled. All RTP packets within the = same > video frame MUST have the same timestamp. The timestamp SHOULD > increment by a multiple of the nominal interval for one DV frame > time, as given in the following table: >=20 > = +----------+----------------+---------------------------------------+ > | Mode | Frame rate | Increase of one DV frame in 90kHz = | > | | (Hz) | timestamp = | > = +----------+----------------+---------------------------------------+ >=20 > One assumes that the term "nominal interval for one DV frame time" = maps > to the table heading "Increase of one DV frame in 90kHz timestamp" but > this is by no means clear. (It's kind of clear if you have read RFC 3551.) Maybe we should reword table head to Increase of 90kHz timestamp per DV frame > In the table itself, the last two lines include the construct "(*)" > which I would expect to refer to a note marked with "*": >=20 > | 720-60p | 59.94 | 3003(*) = | > | 720-50p | 50 | 3600(*) = | >=20 > However, there are no further occurrences of "*" in the document. = There > is the following, which might be divined to be associated with the = table > entries mentioned above: Yes, we should add "(*) " before "Note" in the following line: > Note that even in the 720-line DV system, the data in two video > frames shall be processed within one DV frame duration of the 1080- > line system. Audio data and subcode data in the 720-line system are > processed in the same way as the 1080-line system. Therefore in the > 720-line system, the increase of one DV frame corresponds two video > frames time. >=20 > What does the last sentence mean? Maybe it should be rephrased: Therefore in the 720-line system, the timestamp increase given in the third column = corresponds to two video frames time. > s/Marker bit (M): The marker bit of the RTP fixed header is set to one > on the last packet of a video frame, and otherwise, must be = zero./Marker > bit (M): The marker bit of the RTP fixed header is set to one on the > last packet of a video frame, and otherwise, MUST be zero. Yes. > In Section 2.3, paragraph 2, cannot parse "sending DIF- sequence = header > and subcode DIF blocks". s/DIF- /DIF-/ The intent is: When you unbundle, you send these special DIF blocks with the video = half, not with the audio half. So, maybe we should rephrase: When unbundled audio and video streams are sent, any DIF-sequence header and subcode DIF blocks to be sent MUST be included in the video stream. > I'm a little confused by the "Optional parameters" part of the Media > Type Registration for DV Audio (Section 3.1.2). It says: >=20 > Optional parameters: >=20 > audio: whether the DV stream includes audio data or not. > Permissible values for audio are bundled and none. Defaults = to > none. >=20 > Since the media type is audio, how can no audio data be present? Indeed, the audio format parameter should be on video streams only. > Section 6 says: >=20 > This document updates RFC3189 (older version of this document), >=20 > but the front page header says "Obsoletes: 3189 (if approved)". Which > is it? Further, this phrase doesn't make a lot of sense to me: >=20 > and some registration forms are just updated by this document. No, this replaces ("obsoletes") 3189; we need to fix the "updates" = wording. Thanks, Glen, for this attentive review! Gruesse, Carsten From gwz@net-zen.net Sat May 28 20:12:41 2011 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 117B4E06A5 for ; Sat, 28 May 2011 20:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.652 X-Spam-Level: X-Spam-Status: No, score=-102.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, 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 QESE5cWI1Qm5 for ; Sat, 28 May 2011 20:12:39 -0700 (PDT) Received: from p3plsmtpa07-07.prod.phx3.secureserver.net (p3plsmtpa07-07.prod.phx3.secureserver.net [173.201.192.236]) by ietfa.amsl.com (Postfix) with SMTP id AED6AE0680 for ; Sat, 28 May 2011 20:12:39 -0700 (PDT) Received: (qmail 31793 invoked from network); 29 May 2011 03:12:38 -0000 Received: from unknown (124.120.107.248) by p3plsmtpa07-07.prod.phx3.secureserver.net (173.201.192.236) with ESMTP; 29 May 2011 03:12:38 -0000 Message-ID: <4DE1B99F.30505@net-zen.net> Date: Sun, 29 May 2011 10:12:31 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Carsten Bormann References: <034a01cc1cfc$eab5efb0$c021cf10$%roni@huawei.com> <4DE0CE2A.7070306@net-zen.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------020105060105070306060409" Cc: draft-ietf-payload-rfc3189bis@tools.ietf.org, payload@ietf.org Subject: Re: [payload] FW: WGLC on draft-ietf-payload-rfc3189bis-00 - askin for reviews!!!! 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, 29 May 2011 03:12:41 -0000 This is a multi-part message in MIME format. --------------020105060105070306060409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/28/2011 8:50 PM, Carsten Bormann wrote: ... >> Section 2.2 says: >> >> Timestamp: 32-bit 90 kHz timestamp representing the time at which the >> first data in the frame was sampled. All RTP packets within the same >> video frame MUST have the same timestamp. The timestamp SHOULD >> increment by a multiple of the nominal interval for one DV frame >> time, as given in the following table: >> >> +----------+----------------+---------------------------------------+ >> | Mode | Frame rate | Increase of one DV frame in 90kHz | >> | | (Hz) | timestamp | >> +----------+----------------+---------------------------------------+ >> >> One assumes that the term "nominal interval for one DV frame time" maps >> to the table heading "Increase of one DV frame in 90kHz timestamp" but >> this is by no means clear. > > (It's kind of clear if you have read RFC 3551.) Maybe to you... > Maybe we should reword table head to > > Increase of 90kHz timestamp per DV frame Sorry, I guess that my comments may have lacked clarity: what I'm saying is that it would be much clearer if the text and table heading matched: either change "nominal interval for one DV frame time" to "increase of the 90kHz timestamp per DV frame" or vice versa. Basically, I want to be able to think less about a table than the surrounding text, but in this case I had to think more about it. > ... >> Note that even in the 720-line DV system, the data in two video >> frames shall be processed within one DV frame duration of the 1080- >> line system. Audio data and subcode data in the 720-line system are >> processed in the same way as the 1080-line system. Therefore in the >> 720-line system, the increase of one DV frame corresponds two video >> frames time. >> >> What does the last sentence mean? > > Maybe it should be rephrased: > > Therefore in the > 720-line system, the timestamp increase given in the third column corresponds to two video > frames time. That's better, I think. ... >> In Section 2.3, paragraph 2, cannot parse "sending DIF- sequence header >> and subcode DIF blocks". > > s/DIF- /DIF-/ > > The intent is: > When you unbundle, you send these special DIF blocks with the video half, not with the audio half. > > So, maybe we should rephrase: > > When unbundled audio and video streams are sent, any DIF-sequence header > and subcode DIF blocks to be sent MUST be included in the video stream. Much better, I think! ... --------------020105060105070306060409 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------020105060105070306060409-- From csp@csperkins.org Sun May 29 04:39:23 2011 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 F1595E071A for ; Sun, 29 May 2011 04:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.783 X-Spam-Level: X-Spam-Status: No, score=-102.783 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 dQRHYxHjzVSX for ; Sun, 29 May 2011 04:39:22 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id D687BE0716 for ; Sun, 29 May 2011 04:39:21 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.21]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QQeJ9-0004A8-lG; Sun, 29 May 2011 11:37:26 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <4DDA12DE.6090505@it.aoyama.ac.jp> Date: Sun, 29 May 2011 12:37:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> <4DD6B937.8000109@qualcomm.com> <011e01cc1741$9d4ec500$d7ec4f00$%roni@huawei.com> <4DD75FBE.90409@it.aoyama.ac.jp> <013b01cc1788$505c5040$f114f0c0$%roni@huawei.com> <4DDA12DE.6090505@it.aoyama.ac.jp> To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= X-Mailer: Apple Mail (2.1084) Cc: 'Pete Resnick' , ietf-types@iana.org, draft-ietf-avt-rfc3016bis.all@tools.ietf.org, payload@ietf.org Subject: Re: [payload] [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. 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, 29 May 2011 11:39:24 -0000 On 23 May 2011, at 08:55, Martin J. D=FCrst wrote: > Just some minor nits: >=20 > Instead of things like "Security considerations: See Section 9 of this = document." and "Author: See Authors' Address section at the end of this = document." it would be better to replace "this document" with e.g. = something like [RFCxxxx], with an note to the RFC Editor/IANA to replace = [RFCxxxx] with the eventual RFC number. That way, the template can stand = alone. >=20 > Also, while "Change controller: IETF Audio/Video Transport working = group delegated from the IESG." is quite a good description of the = current reality, it's not necessarily future-proof. You don't want to go = through the registration process again just because a WG gets closed. = These registrations usually just have "The IETF" as a change controller, = with the implicit assumption that this may involve a WG and the IESG. The current phrasing was suggested by our area director when AVT started = doing media type registrations for payload formats, and lists "delegated = from the IESG" to avoid the need to redo registrations when the working = group closed. I agree it needs updating, since AVT has been replaced by = PAYLOAD, but the text was intentionally chosen to be more specific than = just "the IETF". Colin > Regards, Martin. >=20 > On 2011/05/21 16:25, Roni Even wrote: >> Hi, >> No problem. >> Here are the two registration templates and a link to the relevant = section. >> Note that it an update to existing RFC3016 registrations >> http://www.iana.org/assignments/rtp-parameters adding optional = parameters. >>=20 >> The new optional parameters are only for MP4A-LARM and they are: >> MPS-profile-level-id, MPS-asc and SBR-enabled. >>=20 >> thanks >>=20 >> Roni >>=20 >> 1. MP4V-ES >>=20 >> = http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section-6.1 >>=20 >> Type name: video >>=20 >> Subtype name: MP4V-ES >>=20 >> Required parameters: none >>=20 >> Optional parameters: >>=20 >> rate: This parameter is used only for RTP transport. It = indicates >> the resolution of the timestamp field in the RTP header. If = this >> parameter is not specified, its default value of 90000 (90kHz) = is >> used. >>=20 >> profile-level-id: A decimal representation of MPEG-4 Visual >> Profile and Level indication value = (profile_and_level_indication) >> defined in Table G-1 of [14496-2]. This parameter MAY be used = in >> the capability exchange or session setup procedure to indicate >> MPEG-4 Visual Profile and Level combination of which the MPEG-4 >> Visual codec is capable. If this parameter is not specified by >> the procedure, its default value of 1 (Simple Profile/Level 1) = is >> used. >>=20 >> config: This parameter SHALL be used to indicate the = configuration >> of the corresponding MPEG-4 Visual bitstream. It SHALL NOT be >> used to indicate the codec capability in the capability = exchange >> procedure. It is a hexadecimal representation of an octet = string >> that expresses the MPEG-4 Visual configuration information, as >> defined in subclause 6.2.1 Start codes of [14496-2]. The >> configuration information is mapped onto the octet string in an >> MSB-first basis. The first bit of the configuration = information >> SHALL be located at the MSB of the first octet. The = configuration >> information indicated by this parameter SHALL be the same as = the >> configuration information in the corresponding MPEG-4 Visual >> stream, except for first_half_vbv_occupancy and >> latter_half_vbv_occupancy, if exist, which may vary in the >> repeated configuration information inside an MPEG-4 Visual = stream >> (See 6.2.1 Start codes of [14496-2]). >>=20 >> Published specification: >>=20 >> The specifications for MPEG-4 Visual streams are presented in >> [14496-2]. The RTP payload format is described in this = document. >>=20 >> Encoding considerations: >>=20 >> Video bitstreams MUST be generated according to MPEG-4 Visual >> specifications [14496-2]. A video bitstream is binary data and >> MUST be encoded for non-binary transport (for Email, the Base64 >> encoding is sufficient). This type is also defined for = transfer >> via RTP. The RTP packets MUST be packetized according to the >> MPEG-4 Visual RTP payload format defined in this document. >>=20 >> Security considerations: >>=20 >> See Section 9 of this document. >>=20 >> Interoperability considerations: >>=20 >> MPEG-4 Visual provides a large and rich set of tools for the >> coding of visual objects. For effective implementation of the >> standard, subsets of the MPEG-4 Visual tool sets have been >> provided for use in specific applications. These subsets, = called >> 'Profiles', limit the size of the tool set a decoder is = required >> to implement. In order to restrict computational complexity, = one >> or more Levels are set for each Profile. A Profile@Level >> combination allows: >>=20 >> * a codec builder to implement only the subset of the standard = he >> needs, while maintaining interworking with other MPEG-4 = devices >> included in the same combination, and >>=20 >> * checking whether MPEG-4 devices comply with the standard >> ('conformance testing'). >>=20 >> The visual stream SHALL be compliant with the MPEG-4 Visual >> Profile@Level specified by the parameter "profile-level-id". >> Interoperability between a sender and a receiver may be = achieved >> by specifying the parameter "profile-level-id", or by arranging = a >> capability exchange/announcement procedure for this parameter. >>=20 >> Applications which use this Media Type: >>=20 >> Audio and visual streaming and conferencing tools >>=20 >> Additional information: none >>=20 >> Person and email address to contact for further information: >>=20 >> See Authors' Address section at the end of this document. >>=20 >> Intended usage: COMMON >>=20 >> Author: >>=20 >> See Authors' Address section at the end of this document. >>=20 >> Change controller: >>=20 >> IETF Audio/Video Transport working group delegated from the = IESG. >>=20 >>=20 >> 2. MP4A-LATM >>=20 >>=20 >> = http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section-6.3 >>=20 >>=20 >> Type name: audio >>=20 >> Subtype name: MP4A-LATM >>=20 >> Required parameters: >> rate: the rate parameter indicates the RTP time stamp clock = rate. >> The default value is 90000. Other rates MAY be indicated only = if >> they are set to the same value as the audio sampling rate = (number >> of samples per second). >>=20 >> In the presence of SBR, the sampling rates for the core en-/ >> decoder and the SBR tool are different in most cases. This >> parameter SHALL therefore NOT be considered as the definitive >> sampling rate. If this parameter is used, the server must >> following the rules below: >>=20 >> * When the presence of SBR is not explicitly signaled by the >> optional SDP parameters such as object parameter, profile- >> level-id or config string, this parameter SHALL be set to = the >> core codec sampling rate. >>=20 >> * When the presence of SBR is explicitly signaled by the = optional >> SDP parameters such as object parameter, profile-level-id or >> config string this parameter SHALL be set to the SBR = sampling >> rate. >>=20 >> NOTE: The optional parameter SBR-enabled in SDP a=3Dfmtp is = useful >> for implicit HE AAC / HE AAC v2 signaling. But the SBR-enabled >> parameter can also be used in the case of explicit HE AAC / HE = AAC >> v2 signaling. Therefore, its existence itself is not the = criteria >> to determine whether HE AAC / HE AAC v2 signaling is explicit = or >> not. >>=20 >> Optional parameters: >>=20 >> profile-level-id: a decimal representation of MPEG-4 Audio = Profile >> Level indication value defined in [14496-3]. This parameter >> indicates which MPEG-4 Audio tool subsets the decoder is = capable >> of using. If this parameter is not specified in the capability >> exchange or session setup procedure, its default value of 30 >> (Natural Audio Profile/Level 1) is used. >>=20 >> MPS-profile-level-id: a decimal representation of the MPEG >> Surround Profile Level indication as defined in [14496-3]. = This >> parameter indicates the support of the MPEG Surround profile = and >> level by the decoder to be capable to decode the stream. >>=20 >> object: a decimal representation of the MPEG-4 Audio Object = Type >> value defined in [14496-3]. This parameter specifies the tool = to >> be used by the decoder. It CAN be used to limit the capability >> within the specified "profile-level-id". >>=20 >> bitrate: the data rate for the audio bit stream. >>=20 >> cpresent: a boolean parameter indicates whether audio payload >> configuration data has been multiplexed into an RTP payload = (see >> Section 5.1). A 0 indicates the configuration data has not = been >> multiplexed into an RTP payload and in this case the "config" >> parameter MUST be present, a 1 indicates that it has. The = default >> if the parameter is omitted is 1. If this parameter is set to = 1 >> and the "config" parameter is present, the multiplexed >> configuration data and the value of the "config" parameter = SHALL >> be consistent. >>=20 >> config: a hexadecimal representation of an octet string that >> expresses the audio payload configuration data = "StreamMuxConfig", >> as defined in [14496-3]. Configuration data is mapped onto the >> octet string in an MSB-first basis. The first bit of the >> configuration data SHALL be located at the MSB of the first = octet. >> In the last octet, zero-padding bits, if necessary, SHALL = follow >> the configuration data. Senders MUST set the StreamMuxConfig >> elements taraBufferFullness and latmBufferFullness to their >> largest respective value, indicating that buffer fullness = measures >> are not used in SDP. Receivers MUST ignore the value of these = two >> elements contained in the config parameter. >>=20 >> MPS-asc: a hexadecimal representation of an octet string that >> expresses audio payload configuration data = "AudioSpecificConfig", >> as defined in [14496-3]. If this parameter is not present the >> relevant signaling is performed by other means (e.g. in-band or >> contained in the config string). >>=20 >> The same mapping rules as for the config parameter apply. >>=20 >> ptime: duration of each packet in milliseconds. >>=20 >> SBR-enabled: a boolean parameter which indicates whether = SBR-data >> can be expected in the RTP-payload of a stream. This parameter = is >> relevant for an SBR-capable decoder if the presence of SBR can = not >> be detected from an out-of-band decoder configuration (e.g. >> contained in the config string). >>=20 >> If this parameter is set to 0, a decoder MAY expect that SBR is >> not used. If this parameter is set to 1, a decoder CAN = upsample >> the audio data with the SBR tool, regardless whether SBR data = is >> present in the stream or not. >>=20 >> If the presence of SBR can not be detected from out-of-band >> configuration and the SBR-enabled parameter is not present, the >> parameter defaults to 1 for an SBR-capable decoder. If the >> resulting output sampling rate or the computational complexity = is >> not supported, the SBR tool can be disabled or run in = downsampled >> mode. >>=20 >> The timestamp resolution at RTP layer is determined by the rate >> parameter. >>=20 >> Published specification: >>=20 >> Encoding specifications are provided in [14496-3]. The RTP >> payload format specification is described in this document. >>=20 >> Encoding considerations: >>=20 >> This type is only defined for transfer via RTP. >>=20 >> Security considerations: >>=20 >> See Section 9 of this document. >>=20 >> Interoperability considerations: >>=20 >> MPEG-4 Audio provides a large and rich set of tools for the = coding >> of audio objects. For effective implementation of the = standard, >> subsets of the MPEG-4 Audio tool sets similar to those used in >> MPEG-4 Visual have been provided (see Section 6.1). >>=20 >> The audio stream SHALL be compliant with the MPEG-4 Audio = Profile@ >> Level specified by the parameters "profile-level-id" and "MPS- >> profile-level-id". Interoperability between a sender and a >> receiver may be achieved by specifying the parameters "profile- >> level-id" and "MPS-profile-level-id", or by arranging in the >> capability exchange procedure to set this parameter mutually to >> the same value. Furthermore, the "object" parameter can be = used >> to limit the capability within the specified Profile@Level in >> capability exchange. >>=20 >> Applications which use this media type: >>=20 >> Audio and video streaming and conferencing tools. >>=20 >> Additional information: none >>=20 >> Personal and email address to contact for further information: >>=20 >> See Authors' Address section at the end of this document. >>=20 >> Intended usage: COMMON >>=20 >> Author: >>=20 >> See Authors' Address section at the end of this document. >>=20 >> Change controller: >>=20 >> IETF Audio/Video Transport working group delegated from the = IESG. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: "Martin J. D=FCrst" [mailto:duerst@it.aoyama.ac.jp] >>> Sent: Saturday, May 21, 2011 9:46 AM >>> To: Roni Even >>> Cc: 'Pete Resnick'; draft-ietf-avt-rfc3016bis.all@tools.ietf.org; = ietf- >>> types@iana.org; 'Ali C. Begen (abegen)'; payload@ietf.org >>> Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" = and >>> "MP4V-ES" media sutypes. >>>=20 >>> Hello Roni, >>>=20 >>> I fully agree with Pete. I have often told people asking for review = on >>> this list to post the registration templates themselves. I have also >>> been on this list long enough to be able to tell you *for sure* (not >>> just 'probably' as Pete wrote) that posting the template(s) = themselves >>> really helps. >>>=20 >>> So if you haven't done it up to now, it's never too late to change = that >>> practice. Copying the template once is a little bit more work for = you >>> than just posting some pointers, but it will make it easier for all >>> reviewers on this list, because they don't have to follow your >>> instructions. >>>=20 >>> Many thanks in advance and kind regards, Martin. >>>=20 >>>=20 >>> P.S.: You didn't even bother to give a direct link to the relevant >>> section(s), which would easily be possible using = http://tools.ietf.org. >>> Of course copying the actual template is still highly preferable. >>>=20 >>>=20 >>>=20 >>> On 2011/05/21 7:59, Roni Even wrote: >>>> Pete, >>>>=20 >>>> This is what we have been doing for all payload specifications. We >>> point at >>>> the sections with the registration templates. >>>>=20 >>>> Regards >>>>=20 >>>> Roni >>>>=20 >>>>=20 >>>>=20 >>>> From: Pete Resnick [mailto:presnick@qualcomm.com] >>>> Sent: Friday, May 20, 2011 9:56 PM >>>> To: Roni Even >>>> Cc: ietf-types@iana.org; 'Ali C. Begen (abegen)'; >>>> draft-ietf-avt-rfc3016bis.all@tools.ietf.org; payload@ietf.org >>>> Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" >>> and >>>> "MP4V-ES" media sutypes. >>>>=20 >>>>=20 >>>>=20 >>>> On 4/28/11 3:30 AM, Roni Even wrote: >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in >>> the AVT >>>> Working Group (currently Payload). The document updates the media >>> subtypes >>>> "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new registrations = are >>> in >>>> Section 6.1 and Section 6.3 of the document. >>>>=20 >>>> Comments on the registration are welcome. >>>>=20 >>>>=20 >>>> Roni, it would probably help if you posted the registration = templates >>>> themselves instead of pointing to the draft. >>>>=20 >>>> Thanks, >>>>=20 >>>> pr >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> ietf-types mailing list >>>> ietf-types@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-types >>=20 >>=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload --=20 Colin Perkins http://csperkins.org/ From ikob@riken.jp Sun May 29 08:20:33 2011 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 DF40AE06ED for ; Sun, 29 May 2011 08:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 Sh7cVURYMHVA for ; Sun, 29 May 2011 08:20:32 -0700 (PDT) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBF2E0662 for ; Sun, 29 May 2011 08:20:31 -0700 (PDT) Received: from [10.0.1.4] (p005187.dynamic.ppp.asahi-net.or.jp [221.113.5.187]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id 0146BE596D; Mon, 30 May 2011 00:20:23 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Katsushi Kobayashi In-Reply-To: <4DE1B99F.30505@net-zen.net> Date: Mon, 30 May 2011 00:20:23 +0900 Content-Transfer-Encoding: 7bit Message-Id: <2B753781-14FC-4F38-84DD-57CC861656A2@riken.jp> References: <034a01cc1cfc$eab5efb0$c021cf10$%roni@huawei.com> <4DE0CE2A.7070306@net-zen.net> <4DE1B99F.30505@net-zen.net> To: Glen Zorn X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Sun, 29 May 2011 09:20:08 -0700 Cc: draft-ietf-payload-rfc3189bis@tools.ietf.org, Carsten Bormann , payload@ietf.org Subject: Re: [payload] FW: WGLC on draft-ietf-payload-rfc3189bis-00 - askin for reviews!!!! 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, 29 May 2011 15:20:34 -0000 Glen, Thank you for your clarification. We will update our draft. On 2011/05/29, at 12:12, Glen Zorn wrote: > On 5/28/2011 8:50 PM, Carsten Bormann wrote: > >> Maybe we should reword table head to >> >> Increase of 90kHz timestamp per DV frame > > Sorry, I guess that my comments may have lacked clarity: what I'm saying > is that it would be much clearer if the text and table heading matched: > either change "nominal interval for one DV frame time" to "increase of > the 90kHz timestamp per DV frame" or vice versa. Basically, I want to > be able to think less about a table than the surrounding text, but in > this case I had to think more about it. ---- Katsushi Kobayashi